------------------------------------------------------------------------
*From:* dev-security-policy
<[email protected]> on behalf of Dimitris
Zacharopoulos via dev-security-policy
<[email protected]>
*Sent:* 04 October 2019 05:43
*To:* mozilla-dev-security-policy
<[email protected]>
*Subject:* Re: Policy 2.7 Proposal:Extend Section 8 to Encompass
Subordinate CAs
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.
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
[email protected] 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
>
>
> -----Original Message-----
> From: dev-security-policy
<[email protected]> On Behalf Of Wayne
Thayer via dev-security-policy
> Sent: Thursday, October 3, 2019 2:45 PM
> To: mozilla-dev-security-policy
<[email protected]>
> 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
>> 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
>
>
> On Fri, May 10, 2019 at 1:58 PM Wayne Thayer <[email protected]>
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 <[email protected]>
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 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/175aed5f145ae0f29735a1380
>>> 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 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/7a33f1d065733c19b6030261c
>>> 1a11f860c30dc10 [3] https://wiki.mozilla.org/CA:Symantec_Issues
>>>
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
