Re: [openssl-users] More on cert serialnumbers

[Erwann Abalea via openssl-users]

> Le 18 août 2017 à 15:18, Mark H. Wood  a écrit :
> 
> On Thu, Aug 17, 2017 at 03:29:56PM +, 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

Re: [openssl-users] More on cert serialnumbers

[Mark H. Wood]

On Thu, Aug 17, 2017 at 03:29:56PM +, 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


signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 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  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" 
 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

Re: [openssl-users] More on cert serialnumbers

[Erwann Abalea via openssl-users]

Bonjour,

> Le 17 août 2017 à 17:10, Robert Moskowitz  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" 
>>  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

Re: [openssl-users] More on cert serialnumbers

[Robert Moskowitz]

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

Re: [openssl-users] 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" 
 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

Re: [openssl-users] More on cert serialnumbers

[Karl Denninger]

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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] More on cert serialnumbers

[Salz, Rich via openssl-users]

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" 
 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

Re: [openssl-users] More on cert serialnumbers

[Salz, Rich via openssl-users]

https://cabforum.org/2016/07/08/ballot-164/


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

[openssl-users] 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