Subject: [pkix] Fw: RFC 5280 and the maximum permitted value for certificate serial number

From: Tom Gindin <[email-masked]>
Date: Fri, 4 Mar 2011 12:46:35 -0500

The formula given in my earlier message had the sign flipped. It's 
2**(2N-D), where D is the number of bits which vary randomly - 159 in this 
example or 158 if you use Peter's "set the top two bits to 01".  The 
results are still astronomical (beyond 10**-23) for a trillion or fewer 
certificates.

                Tom Gindin

----- Forwarded by Tom Gindin/Watson/IBM on 03/04/2011 12:40 PM -----

From:
Tom Gindin/Watson/IBM@IBMUS
To:
Peter Gutmann <[email-masked]>
Cc:
[email-masked], [email-masked]
Date:
03/04/2011 09:43 AM
Subject:
Re: [pkix] RFC 5280 and the maximum permitted value for certificate serial 
number
Sent by:
[email-masked]

        Peter:

        It's nowhere near that extreme.  If N is the base 2 logarithm of 
the number of certificates issued by a given issuer name, the expected 
number of duplicate serial numbers is about 2**(159-2N).  If you issue 150 

certificates for every living person N will be 40 or so, giving 2**-79 
expected duplicates.  I wouldn't lose much sleep over that, and I doubt 
most CA's do either.
         All these discussions are equally applicable to RIPEMD-160, if 
people prefer that to SHA-1.

                Tom Gindin

From:
Peter Gutmann <[email-masked]>
To:
[email-masked], [email-masked], [email-masked], 
[email-masked]
Cc:
[email-masked]
Date:
03/03/2011 11:08 PM
Subject:
Re: [pkix] RFC 5280 and the maximum permitted value for certificate serial 

number
Sent by:
[email-masked]

Santosh Chokhani <[email-masked]> writes:

>And how do you make the serial number unique?
>
>Howsoever unlikely, SHA-1 hash may not be unique.

Given that the chances of a duplicate are 1 in 2^159, I'm not going to be
losing any sleep over it.

Peter.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Thomas Pornin <[email-masked]>
Date: Fri, 04 Mar 2011 13:26:44 -0500

On Fri, 2011-03-04 at 15:13 +0100, Peter Rybar wrote:
> Thomas,
> Freely available Recommendation X.509 on pages 10 and 12 of ITU-T Rec. X.509 (08/2005) contains clear information about encoding.
> http://www.itu.int/rec/T-REC-X.509-200508-I
> 
> X.509 is not DER encoded, some part are BER encoded e.g. Bit String with special conditions like:
> g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero;

Actually this is DER. For instance, conditions b) and g) together imply
that a BIT STRING shall be encoded in exactly the same way that DER
mandates. If you use DER encoding you automatically comply with all the
rules given in X.509, and since the point of those rules is to have a
deterministic encoding, one can say that only DER complies. Saying that
the "distinguished encoding" which X.509 talks about as "BER with
additional rules" is DER is not an exaggeration.

What is special in certificates is that DER is required only for the
signed part (the "TBSCertificate"). The external wrapper (the SEQUENCE
which contains the TBS, the signature identifier and the signature
value) can use BER.

Also, X.509 says that "the Directory" shall be lenient in what it
accepts; in particular, when verifying a signature on a signed object,
the input data shall be the bytes as received, _not_ the bytes which
could be constructed by some sort of reencoding.

	--Thomas Pornin