[cabfpub] Misissuance of certificates

Ryan Sleevi sleevi at google.com
Mon Nov 9 14:16:16 UTC 2015

On Mon, Nov 9, 2015 at 5:29 AM, Dean Coclin <Dean_Coclin at symantec.com>

> Sig,
> You made a statement in another email which, if I'm remembering correctly,
> said something like this: If a cert is issued from a public root, for
> public domains, for use by the public, then its contents is automatically
> public.

If a cert transitively chains to a publicly trusted root, it should be
public, technically constrained subordinate CA notwithstanding.

We've already seen CA's CPSes and Relying Party Agreements attempt to use
either copyright or trademark to prevent the distribution of such
certificates. This is why, for example, the Mozilla Inclusion Policy was
updated to include this disclaimer with respect to Intermediate
certificates"All disclosure MUST be made freely available and without
additional requirements, including, but not limited to, registration, legal
agreements, or restrictions on redistribution of the certificates in whole
or in part." or, for example, why Chromium's CT policy and RFC 6962 are
worded in such a way to prevent things like 'paywalls' or 'auth gates'

> Is this based on:
> 1. An authoritative definition? (if so, please cite a reference)
> 2. A commonly held belief?
> 3. Your own interpretation?

Given that Certificate Authorities trusted by a given Root Program are
entrusted by that Root Program to operate in the interest of the public
(or, alternatively defined, that Root Program's users, which at least
according to the CA/Browser Forum's bylaws is particularly interested in
those that provide software to 'the general Public'), it's arguably
reasonable to see #2 as the expectations of both users and Root Programs.

> Also, I think Inigo raised some privacy concerns that may make the above a
> violation of local laws.

Considering that our very documents refer to them as "Publicly Trusted
Certificates", it is intrinsic in the definition that they be Public in
order to be Publicly Trusted. Any CA that is issuing certificates that they
cannot freely and readily disclose due to local jurisdictions either:
a) Needs to relocate jurisdictions
b) Change their issuance process to not impinge upon such local
c) Request that their CA be removed from being Publicly Trusted.

In concrete, and absolute, terms: Privacy is not a justification for nor a
shield during misissuance.

> Your text below doesn't address that. That may be problematic for a 1 week
> timeline, especially if there are many domain owners that need to be
> consulted.

Why would any form of disclosure need to wait for the domain holders being

I'm sorry, I absolutely do not buy this argument. If a CA misissues a
certificate, it must be prepared to disclose the full contents of that
certificate. Doubly so if such a misissued certificate was not delivered to
the domain holder - there is zero standing for that domain holder to argue
for non-disclosure.

> Are you saying that any cert not in compliance with the BRs constitutes
> misissuance?


> In the future, when name redaction is allowed for OV/DV, publishing the
> full certificate negates the value of name redaction. So for example,
> consider a case where the cert was issued to the right recipient, but the
> misissuance was the addition of a misleading OU field, or a "MUST INCLUDE"
> extension is omitted. The proposal would force CAs to reveal the redacted
> names.

You speak of name redaction, which I suspect involves Certificate
Transparency, but what is relevant for the CA/Browser Forum is that of
Technically Constrained Subordinate CAs.

Unlike the Mozilla policy which the BR language was originally modeled
after, the advocates of introducing technically constrained certificates as
a class within the BR kept all of the BR obligations in scope for such
certificates, except that of the audit.

That is, where Mozilla's policy would have exempted such certificates from
the burden of compliance with Mozilla's policy (both audits and profile),
the BRs only exempt audit, not profile.

As such, a leaf certificate issued underneath such an intermediate IS
misissued and ostensibly the parent CA of the issuer-of-misissuance (aka,
the root CA that signed the intermediate) SHOULD reasonably be expected to
detect this during their quarterly audits.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151109/1afda80a/attachment-0003.html>

More information about the Public mailing list