Re: More on cert serialnumbers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bonjour,

> Le 17 août 2017 à 17:10, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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.

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.

The 20 octets max comes from RFC5280, keep it.
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.
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.

Cordialement,
Erwann Abalea

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux