[openssl-users] More on cert serialnumbers

Robert Moskowitz rgm at htt-consult.com
Thu Aug 17 15:41:07 UTC 2017


Erwann,

thank you for your response.

On 08/17/2017 11:29 AM, Erwann Abalea via openssl-users wrote:
> Bonjour,
>
>> Le 17 août 2017 à 17:10, Robert Moskowitz <rgm at htt-consult.com> a écrit :
>>
>>
>>
>> On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:
>>> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  Which means, you want to make sure the high bit is off, else the DER encoding will make it 21 bytes.
>>>
>>> So the new –rand_serial flag I am adding to the CA command will make call RAND_bytes to get 18 bytes.
>>>
>>>
>>> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" <openssl-users at openssl.org> wrote:
>>>
>>>      https://cabforum.org/2016/07/08/ballot-164/
>> “Effective September 30, 2016, CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.”
>>
>> What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial number is OK?  Or 2^64 bit serial number represented in HEX (how long is that?)
> That means that the serial number SHALL be at least 64 bits (8 octets) long, and at least 64 of the bits of the serial number come from a cryptographically strong pseudo random number generator.

ARGH!  Octets, not Hex!  :)


> The BR are for public CAs, not private CAs; even if some of those requirements are considered « good practice » (the 64 bits out of a CSPRNG is such a req), they cannot be forced on private CAs.
> And unless some or all of the browsers also apply these requirements to private CAs, you’re not forced to follow them all.

This may get interesting for some IoT situations.  The client certs 
would be used in protocols like CoAP (DTLS), but the server would be 
used by both the IoT clients and standard browsers.  If this were for a 
'smartcity' situation, the CA is probably public...

> The 20 octets max comes from RFC5280, keep it.

Think we got that.

> MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant anymore).
> The 64 bits from a CSPRNG is a tradeoff allowing the use of a non-collision-resistant hash function for slightly longer for transition periods, it’s nice if you can easily follow it, but browsers probably won’t enforce it.
> The 2048bits minimum RSA key is really a good practice and shouldn’t be left over. Switch to ECDSA if your target permits it.

All my work on this project is ECDSA P-256 and I am chomping at the bit, 
so to speak, for Ed25519...

> The CN deprecation and use of SAN:dNSName instead is a target of some browsers for private CAs; it may require more work for you, but there’s a benefit. CN has been populated with too much garbage (FQDN, domain, service name, IP address, person name, …), the SAN extension has nice baskets to put your eggs in (dNSName and iPAddress), and it works beautifully with NameConstraints.

I think I got this pretty much worked out now.

> Cordialement,
> Erwann Abalea

And thank you

Bob



More information about the openssl-users mailing list