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?"
On Mon, Aug 7, 2017 at 9:25 PM, Peter Gutmann via dev-security-policy <
> Ryan Sleevi via dev-security-policy <email@example.com>
> >>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
> 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
> extension? If it sees a CRL with one of the extensions where you ignore
> 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
> 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
> 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
> 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
> 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.
> dev-security-policy mailing list
dev-security-policy mailing list