[lamps] Encoding errors in draft-ietf-lamps-samples-01

["David A. Cooper" <[e-mail]>]

I ran the ten sample certificates in draft-ietf-lamps-samples-01 through 
a certificate checker that I wrote several years ago and it highlighted 
a couple of issues with the sample certificates.

The first issue is that the keyUsage extensions in the certificates are 
not DER encoded. The keyUsage extensions in the certificates are all 
encoded in the form "03 03 07 XX 00."

It seems that the developer of the encoder mistakenly believed that the 
bit string should always be 9 bits long in order to correspond to the 
definition of keyUsage:

    KeyUsage ::= BIT STRING {
                digitalSignature        (0),
                nonRepudiation          (1), -- recent editions of X.509
    have
                                     -- renamed this bit to
    contentCommitment
                keyEncipherment         (2),
                dataEncipherment        (3),
                keyAgreement            (4),
                keyCertSign             (5),
                cRLSign                 (6),
                encipherOnly            (7),
                decipherOnly            (8) }

However, X.680 and X.690 specify that when encoding a named bit list, 
such as above, any trailing zeros must be removed. So, a keyUsage 
extension with just digitalSignature and nonRepudiation set would be 
encoded as a bit string that is only two bits long ('11') and a keyUsage 
extension with just keyAgreement set would be encoded as a bit string 
that is five bits long ('00001').

So, the correct encoding for the keyUsage extension would be:

  * "03 02 01 06" for the CA certificate
  * "03 02 06 C0" for the digital signature certificates
  * "03 02 05 20" for the encryption certificates
  * "03 02 03 08" for the key agreement certificates

The second issue the program highlighted is that the certificates in 
Sections 4.1, 4.3, 7.3, and 8.1 contain negative serial numbers. While 
this is permitted by X.509, Section 4.1.2.2 of RFC 5280 requires 
conforming CAs to use positive integers as serial numbers.

Thanks,

David Cooper