(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #336452 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=336452 Imported into Bugzilla on 04/24/00 17:01) We are decoding an empty bit string. The DER is 03 01 00. The ASN.1 parser is asserting at secasn1d.c, line 1253 (on the HCL 1.57 tag): PR_ASSERT( state->pending > 0 ); It looks like maybe it can't handle the special case of an empty bit string, where there is only one content octet, as opposed to the normal case where the first content octet is the number of extra bits and the actualcontent starts on the second content octet. We ran into this while decoding a certificate that had an empty NS cert type extension. ------- Additional Comments From repka 12/03/98 14:16 ------- Does it work anyway if you continue past the assert? If not, can you tell me how badly you need it fixed (or in what release you would need it fixed)? (BTW, it seems a screwy way to encode an empty string. I don't see why, even for a BIT STRING, a plain length of zero isn't used to represent an empty string. Who made the cert?)

Moving this bug over to bugzilla and reassigning to relyea so it doesn't get lost; not sure who will own the ASN.1 code in my absence. Also, nicolson never replied to my questions or bugged us about getting a fix, which is probably why I then forgot about this bug altogether. It's probably worth checking into at some point -- though it might be a strange encoding, the decoder should always either handle something or give up gracefully. Adding stevep to the cc list in case he has anything to add or knows anything about a "certificate that had an empty NS cert type extension".

Confirming, because of Bugsplat import. Gerv

Move bug status to assigned. (at least until I find a new owner for the DER encoder.