Kyle Hamilton wrote, On 2008-12-29 01:08: > On Sun, Dec 28, 2008 at 11:26 PM, Anders Rundgren wrote:
>>> [suggestion of XER snipped] >> According to a recent discussion in PKIX the only safe way dealing >> with certificates is treating them as blobs because a lot of CAs do >> not use proper DER encoding. > If they don't use proper DER encoding, conforming software is required > to reject them. Mozilla reserves the right to reject CAs from the > trust program if they issue nonconforming certificates, for example. > And a lot of CAs do not abide by the requirement (from RFC 5280 nee > 3280, but not RFC 2459) of a positive serial number, either (X.509 > itself allows for 0, and openssl will implicitly use 00 with its > 'x509' command). NSS has a rather strict DER decoder. So certs that don't conform to DER are not very likely to be usable by NSS. But some of the requirements of the IETF RFCs go beyond the requirements of DER, and NSS enforces many (most?) but not all of those additional requirements. For example, the certificate serial number is a DER INTEGER (primitive ASN.1 types are always spelled in all CAPS), and DER INTEGERs can be positive, negative or zero. NSS is happy with any correctly DER encoded integer, and doesn't reject negative values (the RFC explicitly allows this, IIRC). On other other hand, NSS does strictly enforce the rule that serial numbers must be unique, and NSS requires that no two different certs share the same serial number. > The entire point of DER is that there's one-and-only-one true > encoding. (That's what separates DER from BER.) Well, yes and no. One area where that falls apart is Directory Names (DNs, a.k.a. Distinguished Names). ASN.1 defines numerous different overlapping character sets, and the X.50x definition of DNs allows most attributes to be encoded in any of the character sets that are capable of encoding them. So, given an attribute value that consists entirely of ASCII alphanumeric characters, there are numerous different ways to encode it, all valid. That defeats the "one true encoding" idea. RFC 3280 attempted to solve that problem by requiring that one particular encoding (UTF8) be used in any attribute that X.50x permits to be encoded in any of several character sets. RFC 3280 said that conformant implementations may ASSUME that attributes encoded in different character sets are encodings of different values, and NSS does exactly that. But now RFC 5280, the successor to RFC 3280, allows the use multiple character sets again, and seems to require conformant implementations to be able to compare and match attributes even in different character sets. So the "one true encoding" idea is thoroughly ruined in the world of X.509 certificates, IMO. In any case, NSS does not yet claim conformance to RFC 5280, and probably will not for quite some time. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
