[cabfpub] Misissuance of certificates

Ryan Sleevi sleevi at google.com
Mon Jan 18 20:00:17 UTC 2016


On Mon, Jan 18, 2016 at 11:53 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> I don’t recall that as being the case.  I think the discussion stalled
> because certain national programs used the anyEKU and their national
> policies conflicted with the BRs.  I know we all agreed serverAuth ought to
> be included.  The question was on no EKU and anyEKU as they are both
> technically server certs.
>

Isn't that what I said? ;)

no EKU and anyEKU are both accepted by all browsers as being valid for
issuance.
There were some CAs who, as you note, in collaboration with certain
national PKI projects, had issued a number of such intermediate
certificates, but wished to exclude them from BR compliance.

And that's where and how we stalled - CAs that were capable of issuing
certificates trusted for TLS authentication wished to be out of scope of
issuance.

There was the suggestion of who should bear that cost - either the CAs
doing this, which would need to either stop participating in such programs
or reissue intermediates, or browsers, with the proposal being that all new
software only accept serverAuth EKUs. There was, unsurprisingly, also
objections about whether the EKUs should chain - that is, in RFC 5280, they
apply to the leaf certificate, but as implemented by many libraries, the
intermediate's EKU set is expected to be a superset of the leaf EKU set.

This discussion reached an impasse because neither party was really willing
to budge. In response, both Mozilla and Microsoft implemented root program
requirements that made this clear, with Mozilla's policy language being
very explicit that anything that can technically cause issuance needs to be
in scope of a BR audit, or be technically restricted from such issuance.

So now we're having this conversation again, but with clearer policies as
to what browsers expect. Does that make this national policies go away? No.
But it sets out the expectation of what constitutes publicly trusted, and
therefore what constitutes as scope of needing BR audits.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160118/fc64ffb8/attachment-0003.html>


More information about the Public mailing list