I was not advocating "letting everyone decide". I was advocating that
Mozilla show some restraint, intelligence and common sense in wielding
the new weapons that certlint and crt.sh have given us.
This shouldn't be race as to who wields the weapon first, forgiving CAs
only if they happen to report faster than some other newsgroup
participant.
This is similar to if a store boss gets a new surveillance camera in the
shop and sees that some employees are taking extra breaks when there are
few customers in the store. It would be unreasonable for such a store
boss to discipline this with similar zeal as seeing some employees
genuinely steeling cash out of the register or selling stolen items out
of the back door. Instead the fact that they work less when there is
less work to do should inspire reevaluation of any old rule that they
are not allowed to have a watercooler chat during work hours.
Now such a reevaluation might result in requiring them to use such
occasions to clean the floors or do some other chores (Mozilla equiv:
Deciding that the rule is important for good reason and needs to be
followed in the future) or it could result in relaxing the rule as
long as they stand ready the moment a customer arrives (Mozilla equiv:
Relaxing the requirement, initially just for Mozilla, later perhaps as a
BR change).
Dogmatically insisting on enforcing rules that were previously not
enforced due to lack of detection, just because "rules are rules" or
other such arguments seems overzealous.
On 08/08/2017 15:16, Alex Gaynor wrote:
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
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
