Okay, meta-discussion here... My understanding is that:
If an extension is marked critical, and an implementation does not understand it, it MUST stop processing the certificate or CRL. If an extension is NOT marked critical, and an implementation does not understand it, it MAY stop processing the certificate or CRL. How did the language in 5280 change the behavior of critical CRL extensions? -Kyle H On Mon, Feb 23, 2009 at 9:17 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > Kyle Hamilton wrote, On 2009-02-23 20:19: > >> There is only one last question that I'm going to ask, since it is >> relevant here: Which version of PKIX (3280 or 5280) does HKP issue >> certificates to be conformant to? My understanding is that NSS supports >> 3280 (and not 5280); if there are certificates issued to 5280-not-3280 >> standards, this might cause issues and need to be readdressed. >> >> If they issue certificates to the 3280 profile, I have no problems with >> their inclusion. If they issue certificates to the 5280 profile, I >> withhold my assent pending additional technical evaluation. > > I'm not aware that they're doing anything that is not allowed by RFC 3280. > > Both RFC 3280 and RFC 5280 define a minimum set of things that a > "conformant" product must do, and also a bunch of optional things that > are allowed but not required. As you might expect, this means that > there are numerous products out there that do not implement all the > optional bells and whistles. NSS implements quite a few of the optional > features, but not all. > > As a CA, if you want your certs to be usable by the widest set of products > possible, you will restrict yourself to using only the features that the > RFC (either one) requires all conformant implementations to support. > If you're a CA making certs only for use with certain products, all of > which are known to support some optional feature, then using that optional > feature is more reasonable. This CA is using optional features that are not > ubiquitous, yet expects its certs to be widely accepted throughout the > web. That doesn't violate any RFC, but it may keep their certs from > being universally accepted. > > Lots of CAs learn this lesson the hard way, but they do learn. IINM, the > South Korean's no longer make their certificate policy extensions critical. > The Hungarians no longer make their qcStatement extensions critical, IINM. > It won't be that easy in this case, but I expect the CA will find a > solution. > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
