(Wearing an individual hat)
On Thu, Mar 9, 2017 at 4:18 PM, Jeremy Rowley via dev-security-policy <
> Although we have a policy
> against using live certificates for testing, the policy was not followed in
> this case.
Can you share why? Can you share what steps you'll be taking to make sure
policies are followed in the future? I think we've seen some pretty stark
examples about what can happen when a CA doesn't follow its policies for
test certificates - from CNNIC to Symantec.
> However, I think this discussion raises some very interesting points about
> real world scenarios and RFC 5280 that should be addressed. DigiCert
> actually has three items that routinely show up on CABLint:
> 1) Use of teletext in strings (although this only occurs in
> re-issues/duplicates of previously issued certificates)
Is this in the issuer field? Or in the subject information? I can
understand if your issuer cert has this issue, but I don't think there's
any good reason for this for the subject information.
> 2) Too long of fields, primarily the O and OU fields
> 3) Use of underscore characters in certs
> We've had an open item to fix these issues for a while, but haven't
> prioritized them because:
> a) From a technical standpoint, the WebPKI supports them,
> b) The inclusion of longer names reflects the real world where company
> names are often longer than 64 char, especially in Europe and Asia
> (translating international names to puny-code rarely results in a nice
> c) We haven't felt that there are sufficiently significant risks
> associated with the issues to spend resources addressing them considering a
> and b compared to higher priorities (like our current project of requiring
> only 169 validation methods), and
> d) Lots of CAs have the same or similar issues under RFC 5280
> to CABLint, and those issues don't seem to be garnering a lot of attention
> (perhaps because of higher risk issues taking priority).
I gotta admit, this sounds pretty disheartening.
"We know we have issues, we've known about them for a while, but we've kept
doing it, because we don't think it's a big deal, and everyone else is
The BRs, in part, exist to avoid that judgement call, because we see time
and time again where CAs are making that judgement call and it's not ending
well. If you don't think it belongs, then why not propose BR changes? If
you don't think it's important, then why not propose root policy changes?
I appreciate the effort towards only 169 validation methods, but how are
we, the relying parties, supposed to know that DigiCert won't, say,
deprioritize following the BRs on that because y'all decide it's not a big
security issue, and instead want to focus on a new product offering, since
(besides whatever revenue benefit it might have), it gets more sites on
As for other CAs, shouldn't you be making sure your house is in order
first? :) But also, if there are other issues, shouldn't you be pushing for
greater disclosure and transparency? We constantly see this correlation
between smoke and fire - and if you're seeing smoke, don't you think it
should be raised?
I appreciate the principled stance you're mention, but I'm sure you can
realize the systemic and endemic harm that comes from "Trust us to evaluate
whether compliance is right or not" - we know that's absolutely a failed
mindset from the past decade of failures. Why isn't the principle "Be above
reproach" - which includes improving security as a natural consequence?
> In fact, I think security is improved by providing these
> certificates because these customers/domains would remain unsecured without
> certificates or be forced to truncate/omit important information. I believe
> most CAs have reached the same conclusion after considering the large
> of issues reported through CABLint.
"We should be able to misissue certs, because at least people are on HTTPS"
- this is a terrible argument, and I have a tremendous amount of respect
for you, but I'm shocked to hear you make it, given your knowledge of the
industry. Misissuance of any form is a terrible practice, regardless of the
reasons, precisely because it starts us into the subjective realm.
> The discussion also raises an interesting question of when issues become
> significant enough they need to be addressed on the Mozilla list or require
> revocation. For example, one of our cross-signed partners issued a large
> number of certificates that lacked the proper OID. Should each of these
> certs warrant a discussion and separate revocation decision?
Discuss the problem - not the certificates.
Discuss what you're doing to address the problem. What caused the issue.
How many certificates did it affect? What steps are you taking? When will
those be complete?
> The browsers
> don't do anything with this information so I'm unsure whether them revoking
> all the certs (which the cross-signed partner did) and replacing them with
> certs having an appropriate policy OID made a huge difference in the state
> of security. Should we start a thread on the Mozilla list about each cert
> with issues detected in CABLint?
Yes! If they're violations of the Baseline Requirements, yes! If you're not
sure, yes! If you can't point to a specific reason why it is a false
positive - by showing, for example, a misinterpreted or misapplied rule -
> Even if we assume half are false positives,
> that's about 2000 new discussion items for this group. If so, can we
> establish a priority ranking by the browsers for these discussions?
Look, you're representing an organization trusted with the keys for the
Internet. Billions - plural - of products rely on you to exercise a duty of
care with that trust. Today, that duty of care is measured by how well you
follow the Baseline Requirements, and how seriously you take that duty of
care. It's great that you feel you're doing a bangup job and these are
minor issues, but don't sweep them under the rug. Be transparent. Be
honest. Be open. And be willing to acknowledge that things can and do need
Are the BRs perfect? No. Are IETF docs perfect? Of course not. But they're
the bare minimum, and failure to abide by those rules, especially on a
systemic and knowing basis, vastly undermines trust, because it's unclear
what other corners you might be willing to cut without telling anyone. And
that's a suspicion that you shouldn't stoke by brushing the concerns off as
glibly as this seems to.