Subject: RE: DER encoding of KeyUsage BIT STRING

From: Ambarish Malpani <[email-masked]>
Date: Tue, 06 Mar 2001 14:37:45 -0800

SSLeay/OpenSSL does that. Seems to work pretty well with most
things.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2001 11:52 AM
> To: [email-masked]
> Subject: Re: DER encoding of KeyUsage BIT STRING
> 
> 
> 
> 
> John Thielens <[email-masked]> writes:
> 
> >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.
> 
> Is there really a toolkit out there which does that?  
> Wouldn't that break about
> 90% of the certificates in existence?
> 
> (I'm not just being facetious with that question, I can't 
> imagine how anyone
>  could field a toolkit which recodes certs into correct DER 
> without finding
>  that almost everything they try fails to work after the 
> recoding.  Which
>  toolkit is this?  I should probably put a warning about this 
> in the style
>  guide).
> 
> >1) the "unusual" CA is at fault for generating an improper 
> DER encoding with
> >trailing 0's explicit in a BIT STRING.
> 
> Yes, look up the rules for named bit strings in X.680/690 (I 
> don't have a copy
> handy at the moment so I can't quote chapter and verse).  
> OTOH the CA isn't
> that unusual, a lot of CAs and implementations do this (thus 
> my surprise that
> the toolkit managed to get past any field testing with that 
> behaviour).
> 
> Peter.
>

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 06 Mar 2001 23:11:27 +0000

> SSLeay/OpenSSL does that. Seems to work pretty well with most

The way OpenSSL handles BIT STRINGs goes something like this...

If the BIT STRING comes from an decoding a BIT STRING then the encoded
structure will precisely match the decoded one. This is primarily to
avoid breaking signatures.

If the BIT STRING is created internally then the number of unused bits
is set appropriately according to the number of trailing zeroes.

If the BIT STRING has certain flags set (which effectively mark it as
unnamed) then the number of bits is set to zero.

None of this however applies to certificate extensions because the
actual encoding is wrapped in an OCTET STRING. The actual extension
could contain completely unstructured garbage and it would still
reencode properly. 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.