DER encoding of KeyUsage BIT STRING

[John Thielens <johnt@xxxxxxxxxxxx>]

I am encountering a problem with a CA that chooses to always encode the KeyUsage BIT STRING as a bit string of length 9, even if this length includes trailing 0's.  Every other CA I have encountered encodes KeyUsage as a minimum-length BIT STRING, stripping off any trailing 0's.

>From 2459:

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

For example, a CA certificate with digitalSignature (0), nonRepudiation (1), keyCertSign (5), and cRLSign (6), mapped out as:
   BITS = 1100 0110 0
which would appear "normally" as:
  03 (BIT STRING) 02 (of length 2) 01 (with 1 pad bit) C6 (BITS as above)
in this "unusual" case appears as:
  03 (BIT STRING) 03 (of length 3) 07 (with 7 pad bits) C6 00 (BITS as above)

Ordinarily, I wouldn't even notice.  But in this case, the certificate goes through a toolkit that parses the certificate into an internal canonical form and then regenerates its own DER encoded certificate, thereby changing the second encoding into the first.  You can imagine the consequences when I calculate the hash on the tbsCertificate that results.

So which statement is true?

1) the "unusual" CA is at fault for generating an improper DER encoding with trailing 0's explicit in a BIT STRING.

2) the toolkit is at fault for not preserving the explicit trailing 0's in an alternate DER encoding of the KeyUsage BIT STRING with a semantic subtlety.

3) the "unusual" CA is using the technically most correct encoding, and the rest of the world shares a flaw where trailing 0's are truncated improperly.

Thanks for any insight from the DER experts!

John Thielens
ValiCert