On 21/08/2017 16:22, Robert Moskowitz wrote:
On 08/21/2017 10:03 AM, Salz, Rich wrote:
If the root is going to be trusted, make its serial number be one. ☺
Otherwise use eight bytes of random as the serial number, if you
follow CABF guidelines.
Kind of where my thinking is going. But once I make it '1', it might
as well be 1 byte rand! :)
Well 1 - 127 random...
But no need to make it 20 octets. Just leave it at 8. And yes, I can
see some jump on the 'save' 7 bytes bandwagon.
Note that while the random bits in the serial number are technically
there to defend against attacks on the issuing CA if that CA uses an
old/outdated algorithm, the real issue is retaining compatibility
with Browsers that blindly assume that certificates are created
according to the contractual requirements applied to public CAs such
as DigiCert.
One of those is 20 bytes max (after DER encoding, thus 159 bits max).
Another is at least 64 fresh random bits in each serial number
generated by the CA.
Another may or may not be 20 bytes min (before DER encoding, thus
153 bits min).
Also why I have to work out BER to compare that sizing to DER. Trying
to do that today.
BER is never shorter than DER.
However for internal processing in memory-restricted devices, it may be
possible/easy to save space by using a simplified encoding internally,
and then convert to DER on the fly when talking to standard software
(such as Web Browsers) externally. This will ultimately be a trade off
between code size (to do the conversion) and data size (to store the
certificate).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
