RE: DER encoding of KeyUsage BIT STRING

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

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

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  ambarish@xxxxxxxxxxxx
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Peter Gutmann [mailto:pgut001@xxxxxxxxxxxxxxxxx]
> Sent: Tuesday, March 06, 2001 11:52 AM
> To: ietf-pkix@xxxxxxx
> Subject: Re: DER encoding of KeyUsage BIT STRING
> 
> 
> 
> 
> John Thielens <johnt@xxxxxxxxxxxx> 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.
>