Re: rfc 3280

[Sam Roberts <sroberts@certicom.com>]

I sometimes use sha-1 to generate serial numbers, but instead of adding
a byte if the digest output has the high bit set I took the other
approach - zero the high bit.

I don't think that it significantly increases the chance of collision,
it just decreases the effective hash space from 2^160 to 2^159, which
is still fairly large.

Cheers,
Sam

Wrote "David A. Cooper" <david.cooper@nist.gov>, on Mon, Nov 17, 2003 at 05:41:22PM -0500:
> >RFC 3280 also says:
> >the sign bit in the DER encoding of the INTEGER value MUST be
> >zero - this can be done by adding a leading (leftmost) `00'H octet if 
> >necessary.
> >... serial numbers can be expected to
> >contain long integers.  Certificate users MUST be able to handle
> >serialNumber values up to 20 octets in length.  Conformant CAs MUST
> >NOT use serialNumber values longer than 20 octets.
> >
> >Is the 20 byte limit calculated before or after
> >adding the 00 byte? (This matters because some CAs
> >use a 20 byte SHA1 value instead of a serial number,
> >and that value may need a pad byte.) 
> 
> I do not see any problem using a SHA-1 value as a serial number.  In 
> theory, there could be a hash collision that would result in a CA 
> issuing two certificates with the same serial number, but I would guess 
> that the odds of this happening are so small that it is not worth 
> worrying about.
> 
> On the other hand, I interpret RFC 3280 to require that the entire 
> encoding of the serial number fit within 20 octets.  So, if one used a 
> SHA-1 hash to generate serial numbers, any hash values whose most 
> significant bit was set would require a padding byte to make the 
> resulting value a positive integer, leading to a 21 octet serial number 
> that does not conform to the requirements of RFC 3280.

-- 
Sam Roberts <sroberts@certicom.com>