Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

[Wayne Thayer]

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 subordinate.
> 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 3.1.2.1. That is, that the policy is applicable to a CA and all
> subordinate CAs technically capable of issuing (server or e-mail)
> certificates
> 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 Section
> 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:
https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8
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 https://github.com/mozilla/pkipolicy/issues/169 and
https://github.com/mozilla/pkipolicy/issues/140

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

[1] https://github.com/mozilla/pkipolicy/issues/122
[2]
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10
[3] https://wiki.mozilla.org/CA:Symantec_Issues

[Wayne Thayer]

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

- Wayne

[Wayne Thayer]

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 certificate(s);
>

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 policy.

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

[1]
https://github.com/mozilla/pkipolicy/commit/7a33f1d065733c19b6030261c1a11f860c30dc10
[2]
https://github.com/mozilla/pkipolicy/commit/175aed5f145ae0f29735a13801a5639e70f1f0a8

[Jeremy Rowley]

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 certif...@Mozilla.org 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 community.

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 root 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.

Jeremy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Dimitris Zacharopoulos]

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 7.1.6.3 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.


Dimitris.

[Rob Stradling]

Dimitris,

Since CAs should already be disclosing that an intermediate certificate is "externally-operated" by populating the "Subordinate CA Owner" field in the CCADB record, what's the benefit of duplicating this information in the intermediate certificate itself?

What happens if an intermediate certificate starts life as "externally-operated" but later becomes "internally-operated", or vice-versa? (e.g., the root CA company acquires the intermediate CA company).

It's possible to update a CCADB record. It's not possible to update a certificate.

________________________________
From: dev-security-policy <dev-security-...@lists.mozilla.org> on behalf of Dimitris Zacharopoulos via dev-security-policy <dev-secur...@lists.mozilla.org>
Sent: 04 October 2019 05:43

[Dimitris Zacharopoulos]

On 2019-10-04 12:56 μ.μ., Rob Stradling wrote:
> Dimitris,
>
> Since CAs should already be disclosing that an intermediate
> certificate is "externally-operated" by populating the "Subordinate CA
> Owner" field in the CCADB record, what's the benefit of duplicating
> this information in the intermediate certificate itself?
>
> What happens if an intermediate certificate starts life as
> "externally-operated" but later becomes "internally-operated", or
> vice-versa?  (e.g., the root CA company acquires the intermediate CA
> company).
>
> It's possible to update a CCADB record.  It's not possible to update a
> certificate.
>

That makes sense. This means that Mozilla has a way to know exactly how
many externally-operated CAs are in the Root program, provided all CAs
updated this "Subordinate CA Owner" field correctly, meaning that the
"Subordinate CA Owner" operates/manages the CA keys.

Dimitris.

> ------------------------------------------------------------------------
> *From:* dev-security-policy

> <dev-security-...@lists.mozilla.org> on behalf of Dimitris
> Zacharopoulos via dev-security-policy
> <dev-secur...@lists.mozilla.org>

> *Sent:* 04 October 2019 05:43
> *To:* mozilla-dev-security-policy
> <mozilla-dev-s...@lists.mozilla.org>
> *Subject:* Re: Policy 2.7 Proposal:Extend Section 8 to Encompass

[Wayne Thayer]

Thanks Jeremy.

On Thu, Oct 3, 2019 at 5:06 PM Jeremy Rowley <jeremy...@digicert.com>

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 certif...@Mozilla.org 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.
>
>

Considering that section 8 links to an email address where it states
"MUST notify
Mozilla <certif...@mozilla.org>", I'm skeptical that there is confusion,
but I do agree that it makes sense for the notification to be triggered via
an update to CCADB rather than an email. I'll look in to this.

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.

That's the correct interpretation, barring any further clarifications...

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 community.
>
>

It appears to be at least 2 dozen organizations, based on the "subordinate
CA owner" field in CCADB. I say "at least" because, as Dimitris noted,
we're just now identifying intermediates that are incorrectly labeled as
falling under the parent certificate's audits.

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.
>
>

Grandfathering in organizations currently in control of an unconstrained
subordinate CA, but requiring them to go through an approval process before
obtaining a new subordinate CA certificate seems like a good approach. I do
however have concerns about requiring a process similar to the root
inclusion process. We expect the root CA to take responsibility for the
organizations they certify, so a lighter process that acts as a
verification of the decision made by the root CA is appropriate here. To
put it another way, applying the full root inclusion process to externally
operated unconstrained subordinate CA certificates is not much different
than forbidding them. I do agree that policy docs and audits should be made
available as part of this review.

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 root 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.
>
>

Unless I'm missing something, DigiCert is continuing to issue externally
operated S/MIME sub CAs, e.g. https://crt.sh/?id=1652799594

[Jeremy Rowley]

I did flag that part as wearing my personal hat 😊.

The Trust Italia Sub CA is an example of where confusion may arise in the policy and where the complexity arises in these relationships. This was not necessarily a “new” CA from what I understood. This is also why I qualified the shut down in 2020 as the non-browser TLS. We aren’t expanding the sub CAs beyond what exists while we figure out what to do with existing infrastructures that are using them.

That said, still wearing a personal hat, I do think the community should have access to this information and review the entities that transitively chain up to the Mozilla root program for sMIME or TLS. There should be a review of all these sub CAs, including the Trust Italia one we replaced. The only reason I can see grandfathering is if there are too many to review at one time. Then grandfather the new ones and review before a new CA is required to issue. That’ll spur CAs to bring the on-prem Sub CAs forward for review.

The bigger question to me, is how should this review take place? Should the root CA sponsor the sub CA and talk about the infrastructure and operations? I think there should be an established process of how this occurs, and the process is probably slightly different than roots because of the extra party (root CA) involved.

From: Wayne Thayer <wth...@mozilla.com>
Sent: Friday, October 4, 2019 12:40 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Policy 2.7 Proposal:Extend Section 8 to Encompass Subordinate CAs

Thanks Jeremy.

On Thu, Oct 3, 2019 at 5:06 PM Jeremy Rowley <jeremy...@digicert.com<mailto:jeremy...@digicert.com>> 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 certif...@Mozilla.org<mailto:certif...@Mozilla.org> 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.

Considering that section 8 links to an email address where it states "MUST notify Mozilla<mailto:certif...@mozilla.org>", I'm skeptical that there is confusion, but I do agree that it makes sense for the notification to be triggered via an update to CCADB rather than an email. I'll look in to this.

On Fri, May 10, 2019 at 1:58 PM Wayne Thayer <wth...@mozilla.com<mailto:wth...@mozilla.com>> wrote:

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

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer]

I made a change to the new section 8.1 language intended to include in the
scope both the transfer of existing subordinate CA certificates and the
signing of new subordinate CA certificates that are controlled by an
organization other than the CA:
https://github.com/mozilla/pkipolicy/commit/e3da5aa27bfa02c73b3c474a3aa0420623999333

"Obtains control of" is language that we already use in section 8.

For now, I'd like to allow organizations that currently control a
subordinate CA certificate to be grandfathered in, and the current proposal
does that. The proposals to further strengthen these requirements by
requiring public discussion for organizations already in control of a subCA
are now documented in issue #195 [1].

Regarding the potentially unclear requirement that notifications are made
via email to certif...@mozilla.org, I'm open to trying to clarify this,
but we're not ready to move the notifications into CCADB. I've created
issue #149 [2] to track that as a future change.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/195
[2] https://github.com/mozilla/pkipolicy/issues/194

On Fri, Oct 4, 2019 at 5:18 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:

> I did flag that part as wearing my personal hat 😊.
>
>
>
> The Trust Italia Sub CA is an example of where confusion may arise in the
> policy and where the complexity arises in these relationships. This was not
> necessarily a “new” CA from what I understood. This is also why I qualified
> the shut down in 2020 as the non-browser TLS. We aren’t expanding the sub
> CAs beyond what exists while we figure out what to do with existing
> infrastructures that are using them.
>
>
>
> That said, still wearing a personal hat, I do think the community should
> have access to this information and review the entities that transitively
> chain up to the Mozilla root program for sMIME or TLS. There should be a
> review of all these sub CAs, including the Trust Italia one we replaced.
> The only reason I can see grandfathering is if there are too many to review
> at one time. Then grandfather the new ones and review before a new CA is
> required to issue. That’ll spur CAs to bring the on-prem Sub CAs forward
> for review.
>
>
>
> The bigger question to me, is how should this review take place? Should
> the root CA sponsor the sub CA and talk about the infrastructure and
> operations? I think there should be an established process of how this
> occurs, and the process is probably slightly different than roots because
> of the extra party (root CA) involved.
>
>
>

> *From:* Wayne Thayer <wth...@mozilla.com>
> *Sent:* Friday, October 4, 2019 12:40 PM
> *To:* Jeremy Rowley <jeremy...@digicert.com>
> *Cc:* mozilla-dev-security-policy <
> mozilla-dev-s...@lists.mozilla.org>
> *Subject:* Re: Policy 2.7 Proposal:Extend Section 8 to Encompass

> Subordinate CAs
>
>
>
> Thanks Jeremy.
>
>
>
> On Thu, Oct 3, 2019 at 5:06 PM Jeremy Rowley <jeremy...@digicert.com>

> 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 certif...@Mozilla.org 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.
>
>
>
> Considering that section 8 links to an email address where it states "MUST notify

> Mozilla <certif...@mozilla.org>", I'm skeptical that there is

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>