More on cert serialnumbers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

More on cert serialnumbers

Robert Moskowitz
I have been researching serial number in cert based on Jakob's comment:

"- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
standalone
  numbers and as DER-encoded numbers.  Note that this is not the default in
  the openssl ca program.

- Serial numbers contain cryptographically strong random bits, currently at
  least 64 random bits, though it is best if the entire serial number looks
  random from the outside.  This is not implemented by the openssl ca
program."

And this is supposedly from the CA/B BF?

Though Erwann responded:

"There’s no such requirement. It MUST be at most 20 octets long"

I see how for all certs other than the root (get to that later), I can
control this with:

openssl rand -hex 20 > serial

then use 'openssl ca ...'

But from Kyle's comment, the first bit must be ZERO.

"I tend not to re-use keys, so I've found that putting 20 bytes (while
clearing the high bit) of a digest of the SubjectPublicKeyInfo as the
serial number works in that circumstance.  [if you leave the high bit
set, then DER mandates that it be encoded with a leading 0x00 byte,
which makes it 21 bytes... which can cause problems with things built
for PKIX.]"

Will that be the case with the above 'openssl rand', or is there some
other step needed to zero out the first bit.

And is the openssl rand function 'safe' to use?  Is it cryptographically
strong?

As for the root cert created with 'openssl req ... -new -x509', it seems
that a random 8 octet serial number is provided.  Is there a way to
boost that to 20 octects?  Does it matter per Erwann's comment above?

Actually, I am trying to keep certs small, and the CAs I picture are not
for millions of certs  Smaller serial number size would be the preferred
situation...

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

OpenSSL - User mailing list
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

Karl Denninger
In reply to this post by Robert Moskowitz


On 8/17/2017 09:40, Robert Moskowitz wrote:
I have been researching serial number in cert based on Jakob's comment:

"- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
 numbers and as DER-encoded numbers.  Note that this is not the default in
 the openssl ca program.

- Serial numbers contain cryptographically strong random bits, currently at
 least 64 random bits, though it is best if the entire serial number looks
 random from the outside.  This is not implemented by the openssl ca program."

And this is supposedly from the CA/B BF?

Though Erwann responded:

"There’s no such requirement. It MUST be at most 20 octets long"

I see how for all certs other than the root (get to that later), I can control this with:

openssl rand -hex 20 > serial

then use 'openssl ca ...'

But from Kyle's comment, the first bit must be ZERO.
So since the 20 octets is a maximum and not a requirement use -hex 19 instead, and if this results in DER placing a leading 0x00 byte you're still ok.  This also complies with the ballot that Rich mentioned since you have more entropy than required.

At least I think that meets the requirements....

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
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" <[hidden email]> wrote:

    https://cabforum.org/2016/07/08/ballot-164/
   
   
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

Robert Moskowitz


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" <[hidden email]> 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?)

For now I will use:

openssl rand -hex 18 > serial

My reading on 'openssl rand' SEEMS to indicate it is cryptographically
strong (provided you have entropy.  See:  cat
/proc/sys/kernel/random/entropy_avail

For constrained IoT, I would like to use the smallest possible. Thus the
clarifying the 64bit question above.

thanks

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

Robert Moskowitz
In reply to this post by Karl Denninger


On 08/17/2017 10:49 AM, Karl Denninger wrote:

>
>
> On 8/17/2017 09:40, Robert Moskowitz wrote:
>> I have been researching serial number in cert based on Jakob's comment:
>>
>> "- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
>> standalone
>>  numbers and as DER-encoded numbers.  Note that this is not the
>> default in
>>  the openssl ca program.
>>
>> - Serial numbers contain cryptographically strong random bits,
>> currently at
>>  least 64 random bits, though it is best if the entire serial number
>> looks
>>  random from the outside.  This is not implemented by the openssl ca
>> program."
>>
>> And this is supposedly from the CA/B BF?
>>
>> Though Erwann responded:
>>
>> "There’s no such requirement. It MUST be at most 20 octets long"
>>
>> I see how for all certs other than the root (get to that later), I
>> can control this with:
>>
>> openssl rand -hex 20 > serial
>>
>> then use 'openssl ca ...'
>>
>> But from Kyle's comment, the first bit must be ZERO.
> So since the 20 octets is a maximum and not a requirement use -hex 19
> instead, and if this results in DER placing a leading 0x00 byte you're
> still ok.  This also complies with the ballot that Rich mentioned
> since you have more entropy than required.
>
> At least I think that meets the requirements....

And 19 is more than 18!  And the first time I tried this I got:

a2b7499f19b3b7b4a54ccd2036d59a4a906756

And the 2nd time I tried with 20:

f7f01d018605411c8788a82e465d7991d574b08f

So that first bit can really be a problem.  Probably about 1/2 the time!  :)

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

OpenSSL - User mailing list
In reply to this post by Robert Moskowitz
Bonjour,

> Le 17 août 2017 à 17:10, Robert Moskowitz <[hidden email]> 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" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

Robert Moskowitz
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 <[hidden email]> 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" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

Mark H. Wood
In reply to this post by OpenSSL - User mailing list
On Thu, Aug 17, 2017 at 03:29:56PM +0000, Erwann Abalea via openssl-users wrote:
> 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.

How does one mechanically distinguish public vs. private CAs?

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

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

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: More on cert serialnumbers

OpenSSL - User mailing list

> Le 18 août 2017 à 15:18, Mark H. Wood <[hidden email]> a écrit :
>
> On Thu, Aug 17, 2017 at 03:29:56PM +0000, Erwann Abalea via openssl-users wrote:
>> 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.
>
> How does one mechanically distinguish public vs. private CAs?

OS/Browser-granted or user-granted. Each browser does it differently.

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