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 <r...@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@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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
