This methodology of "letting everyone decide which parts of the spec/BRs aren't important" doesn't make sense. If there's something wrong with the spec, let's fix it! (Perhaps X.509 validation needs its own equivalent of the "fetch" specification). Giving each CA unilateral authority to ignore what they want is not how we get to a cleaner, better, more secure, spec or PKI. BTW, the reason you know they were unilaterally ignoring things is that this thread was started by an independent security researcher, and not by the CAs in question!
If the CAs had noticed themselves, they could have sent an email to m.d.s.p, "Hey, we noticed some of our certs were triggering warnings on crt.sh, we looked into and it's because of an encoding issue with large serials. We're revoking those certs, and looking into the bug in our issuance code, but we're pretty sure this happened because the text in RFC 5280 is a bit vague, can we do something to make this more clear?" Alex On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan Sleevi via dev-security-policy <dev-security-policy@lists.mozilla.org> > writes: > > >>Pragmatically, does anything known break on the extra byte there? > > > >Yes. NSS does. Because NSS properly implements 5280. > > I would say that's probably more a flaw in NSS then. Does anyone's > implementation seriously expect things to work, and by extension break if > they > don't, as 5280 says it should? What happens to NSS if it sees a policy > explicitText longer than 200 bytes? If it sees a CRL with an unknown > critical > extension? If it sees a CRL with one of the extensions where you ignore > the > actual contents of the CRL and instead use revocation information hidden > in a > sub-extension (sorry, can't remember the name of that one at the moment). > > That's just the first few things that came to mind, there are a million > (well, > thousands. OK, maybe hundreds. At least a dozen) bizarre, arbitrary, and > often illogical requirements (for example with the critical extension thing > the only sensible action is to do the opposite of what the RFC says) in > 5280 > that I'm pretty sure NSS, and probably most other implementations as well, > don't conform to, or are even aware of. So saying "it happens to break our > code" is a perfectly valid response, but claiming better standards > conformance > than everyone else is venturing onto thin ice. > > More generally, I don't think there's any PKI implementation that can > claim to > "properly implement 5280" because there's just too much weird stuff in > there > for anyone to fully comprehend and be conformant to. As a corollary, since > there are also things in there that are illogical, a hypothetical > implementation that really was fully conformant could be regarded as broken > when it does things that the spec requires but that no-one would expect an > implementation to do. > > Peter. > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
