Adding to Jeremy's post, I believe we need to also define a normative requirement to mark an unconstrained Intermediate CA Certificate not operated by the entity that controls the Root Key. Section of the Baseline Requirements requires an explicit policy identifier for these subCAs. The anyPolicy identifier is not permitted. So, I assume that all Intermediate CA Certificates that include the anyPolicy identifier should be operated by the Issuing CA (or an Affiliate).

Unfortunately -in one sense-, the BRs allow more specific policy identifiers even for Intermediate CA Certificates that ARE operated by the Issuing CA, so it is hard to differentiate which subCA is "Internal" or "External".

I believe this is serious enough to consider the possibility of requiring a specific policy identifier (assigned by the CABF) to be included in externally-operated subCA Certificates, in addition to any other policy identifiers that the Issuing CA has chosen for that CA Certificate. Of course, other solutions might be available.

Mozilla is also going over a close investigation of unconstrained subCAs that are missing audits and possibly included in oneCRL. I don't believe these subCAs should be grandfathered in. However, others that have supplied audit reports, following Mozilla Policies and indicating compliance with the BRs, should be grandfathered.


On 2019-10-04 3:06 π.μ., Jeremy Rowley via dev-security-policy wrote:
Hey Wayne,

I think there might be confusion on how the notification is supposed to happen. 
Is notification through CCADB sufficient? We've uploaded all of the Sub CAs to 
CCADB including the technically constrained ICAs. Each one that is 
hosted/operated by itself is marked that way using the Subordinate CA Owner 
field. Section 8 links to emailing but operationally, 
CCADB has become the default means of providing this notice. If you're 
expecting email, that may be worth clarifying in case CAs missed that an email 
is required. I know I missed that, and because CCADB is the common method of 
notification there is a chance that notice was considered sent but not in the 
expected way.

There's also confusion over the "new to Mozilla" language I think. I interpreted this 
language as organizations issued cross-signs after the policy. For example, Siemens operated a Sub 
CA through Quovadis prior to policy date so they aren't "new" to the CA space even if 
they were re-certified. However, they would be new in the sense you identified - they haven't gone 
through an extensive review by the community.  If the goal is to ensure the community review 
happens for each Sub CA, then requiring all recertifications to go through an approval process 
makes sense instead of making an exception for new. I'm not sure how many exist currently, but if 
there are not that many organizations, does a grandfathering clause cause unnecessary complexity? I 
realize this is not in DigiCert's best interest, but the community may benefit the most by simply 
requiring a review of all Sub CAs instead of trying to grandfather in existing cross-signs.  Do you 
have an idea on the number that might entail
  ? At worst, we waste a bunch of time discovering that all of these are 
perfectly operated and that they could have been grandfathered in the first 
place. At best, we identify some critical issues and resolve them as a 

If there are a significant number of unconstrained on-prem CAs, then language that 
requires a review on re-signing would be helpful.  Perhaps say "As of X date, a CA 
MUST NOT sign a non-technically constrained certificate where cA=True for keys that are 
hosted external to the CA's infrastructure or that are not operated in accordance with 
the issuing CA's policies and procedures unless Mozilla has first granted permission for 
such certificate"? The wording needs work of course, but the idea is that they go 
through the discussion and Mozilla signs off. A process for unconstrained Sub CAs that is 
substantially similar to the root inclusion makes sense, but there is documentation on 
CCADB for the existing ones. Still, this documentation should probably made available, 
along with the previous incident reports, to the community for review and discussion. 
Afterall, anything not fully constrained is essentially operating the same as a fully 
embedded root.

Speaking on a personal, non-DigiCert note, I think on-prem sub CAs are a bad 
idea, and I fully support more careful scrutiny on which entities are 
controlling keys. Looking at the DigiCert metrics, the on-prem Sub CAs are 
responsible for over half of the incident reports, with issues ranging from 
missed audit dates to incorrect profile information. The long cycle in getting 
information,  being a middle-man information gathering, and trying to convey 
both Mozilla and CAB forum policy makes controlling compliance very difficult, 
and a practice I would not recommend to any CA. Once you've established a 
relationship as a signer CA (or acquired a relationship), extraditing yourself 
is... difficult.  The certificates end up embedded on smart cards, used by 
government institutions and pinned in weird places. And the unfortunate part is 
you don't have the direct relationship with the end-user to offer counsel 
against some of the practices. That extra abstraction layer between the CA and 
   store program ends up adding a lot more complexity than you'd initially 
think. Delegating the CA responsibility ends up being a bad idea and takes 
years to fix. DigiCert is finally down to the final few TLS sub CAs (5) and 
each are operating in OCSP signing mode only. They'll all be revoked in 2020.


-----Original Message-----
From: dev-security-policy <> On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, October 3, 2019 2:45 PM
To: mozilla-dev-security-policy <>
Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

I'd like to revisit this topic because I see it as a significant change and am 
surprised that it didn't generate any discussion.

Taking a step back, a change [1] to notification requirements was made last 
year to require CAs that are signing unconstrained subordinate CAs (including 
cross-certs) controlled by a different organization to notify Mozilla. We have 
received few, if any, notifications of this nature, so I have to wonder if CAs 
are adhering to this requirement.

This requirement applies as follows:

an organization other than the CA obtains control of an unconstrained
intermediate certificate (as defined in section 5.3.2 of this policy)
that directly or transitively chains to the CA's included

Is the "obtains control" language being interpreted to mean that this only 
applies when control of the private keys change, and not when a CA signs a key controlled 
by a different organization? I believe the intent is for this to apply in both situations 
- otherwise it is trivial to bypass.

The new change [2] proposed for version 2.7 of our policy goes one step further 
and places transfers and signings of unconstrained subordinate CAs clearly in 
the scope of section 8.1, including the following language:

If the receiving or acquiring company is new to the Mozilla root program,
it must demonstrate compliance with the entirety of this policy and
there MUST be a public discussion regarding their admittance to the
root program, which Mozilla must resolve with a positive conclusion in
order for the affected certificate(s) to remain in the root program.
If the entire CA operation is not included in the scope of the
transaction, issuance is not permitted until the discussion has been resolved 
with a positive conclusion.

That means any organization "new to the Mozilla root program" for which a CA 
signs an unconstrained subordinate CA or cross-cert must go through an approval process 
including a public discussion before issuing certificates in order to comply with this 

It also means that we need to decide what "new to the Mozilla root program"
means. Organizations that control unconstrained subordinate CAs have not been considered 
members of the program in the past, so it's easy to argue that every such organization 
will be "new to the Mozilla root program"
if/when this policy goes into effect. However, it may be more practical to 
"grandfather in" organizations that are currently in control of unconstrained 
subordinate CAs.

This also raises the question of what it means to "demonstrate compliance with the 
entirety of this policy". Section 8.1 has historically applied to companies 
acquiring root CAs and we have not required them to go through the entire inclusion 
process - only a public discussion. Should that same interpretation apply to 
unconstrained subordinate CA?

Before proposing any changes, I'd like to ask for everyone's input on these and 
any other concerns stemming from this policy proposal.

- Wayne


On Fri, May 10, 2019 at 1:58 PM Wayne Thayer <> wrote:

Having received no comments on these proposed changes, I plan to
include them in version 2.7 of our policy.

- Wayne

On Fri, Apr 19, 2019 at 11:55 AM Wayne Thayer <> wrote:

Ryan Sleevi made the following proposal:

Issue #122 [1] previously discussed Section 8 in the context of
subordinate CAs, with a change [2] being made to include subordinate
CAs (in the context of Section 5.3.2) within scope of notification requirements.

However, as presently worded, it's ambiguous as to whether or not
Sections 8.1 through 8.3 also apply to subordinate CAs, or whether
the only disclosure required is upon the initial introduction of the 
This confusion results from language such as in Section 8.1, "or
when an organization buys the private key of a certificate in
Mozilla's root program", implying that private keys which
transitively chain to a root certificate within Mozilla's program are exempt 
from such requirements.

This ambiguity creates incentives for situations such as
cross-signing CAs that might otherwise or have been otherwise
rejected from direct inclusion within the Mozilla program. It
further creates issues with respect to the supervision of audits and auditors.

While it is true that the signing CA accepts the risk that an
unfavorable verdict on the subordinate may impact the root, the cost
of such a decision is primarily borne by Mozilla and the broader
community, in that they are responsible for the collateral ecosystem
challenges and devising appropriate solutions. This has been
demonstrated, for example, through the discussion of Symantec issues [3].

Because Mozilla and the community bear significant cost, especially
as more time passes and more certificates are issued, the following
changes are suggested:

    1. Align Section 8, and its subsections, with language similar to
    that of Section That is, that the policy is applicable to a CA and
    all subordinate CAs technically capable of issuing (server or e-mail)
    2. With respect to Section 8.1, extend the requirements of the last
    paragraph to the issuance of subordinate CA certificates. Namely, if the
    private key is in possession of an entity that is new to the Mozilla root
    program, or subject to a CP or CPS that is new to the Mozilla Root Program,
    that prior to the issuance of such a certificate, there be a public
    discussion that results in a favorable conclusion.

With the current policy as written, an existing/included root CA
that plans to exit the CA business might be prohibited (by virtue of
8.1) from selling the business or (by virtue of Section 8.3) from
transferring the private key material. However, they are fully
permitted to cross-certify a new 'root' and then proverbially close
up shop - with no consideration for if their root gets removed as a
consequence. These are the same set of concerns that led to the
introduction of Section 8, but today exist due to the ambiguity with respect to 
the subsections.

I've proposed a fix for this issue:
1a5639e70f1f0a8 It also attempts to clarify the applicability of
section 8.3 as "only"
when section 8.1 and/or section 8.2 also apply.

This is and

I will greatly appreciate everyone's input on this topic. In
particular, I would like to hear from CAs that would be affected by
the requirement for any new subordinate CAs to go through a public
discussion before issuing certificates, with the outcome being
positive or else the subordinate CA certificate will be added to OneCRL 
(section 8.1).

- Wayne

1a11f860c30dc10 [3]

dev-security-policy mailing list

dev-security-policy mailing list

dev-security-policy mailing list

Reply via email to