Policy Update Proposal: Timeline for Disclosing SubCAs

[Kathleen Wilson]

Topic to discuss [1]:
“(D3) Make the timeline clear about when the audit statements and
disclosure has to happen for new audited/disclosed subCAs.

Section 10 of the Inclusion Policy says:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
“The CA with a certificate included in Mozilla’s CA Certificate Program
MUST disclose this information before any such subordinate CA is allowed
to issue certificates.”

Additionally, section 8.1 of version 1.3 of the Baseline Requirements
specifies when the audits must occur: “before issuing Publicly-Trusted
Certificates, the CA SHALL successfully complete a point-in-time
readiness assessment performed in accordance with applicable standards
under one of the audit schemes listed in Section 8.1. The point-in-time
readiness assessment SHALL be completed no earlier than twelve (12)
months prior to issuing Publicly-Trusted Certificates and SHALL be
followed by a complete audit under such scheme within ninety (90) days
of issuing the first Publicly-Trusted Certificate.”

What further clarification needs to be added to Mozilla’s CA Certificate
Policy to make it more clear when the audit statements and disclosure
has to happen for new subCAs?

As always, I will appreciate your thoughtful and constructive input into
this discussion.

Kathleen

PS: Note for CAB Forum folks: I think there are several references to
section 8.1 throughout version 1.3 of the BRs that should actually be
references to section 8.4 (the section that lists the audit schemes).

[1]
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_That_Need_To_Be_Discussed

[Ryan Sleevi]

On Tue, November 3, 2015 4:24 pm, Kathleen Wilson wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and

> disclosure has to happen for new audited/disclosed subCAs.

> What further clarification needs to be added to Mozilla’s CA Certificate

> Policy to make it more clear when the audit statements and disclosure
> has to happen for new subCAs?

Thanks for continuing to drive the discussion, Kathleen.

I think with respect to the Mozilla policy, the Baseline Requirements
themselves are quite explicit as to what the requirements are, and they're
a reasonable set of requirements. Where the disconnect appears to be is
how these are translated into auditable criteria under WebTrust or ETSI,
which unfortunately seems to be what a number of CAs (particularly ETSI
CAs, based on the issues) are relying on, rather than the standard they're
held to.

There are a number of ways to draw attention to this, but I think we
should be careful about how much attention we draw to it, relative to the
BRs as a whole.

I'm not necessarily advocating these options, but hopefully they can spark
a more thoughtful and thorough discussion:

Example 1: "The CA with a certificate included in Mozilla’s CA Certificate
Program
MUST disclose this information prior to the signing of the subordinate CA
certificate."

Example 2: "The CA with a certificate included in Mozilla's CA Certificate
Program MUST disclose this information following the completion of a point
in time readiness assessment, as described in Section 8.[whatever] of the
Baseline Requirements, and prior to the issuance of the first Publicly
Trusted Certificate."

Example 3: Keep the present language, but similar to documents such as
https://wiki.mozilla.org/CA:Schedule or
https://wiki.mozilla.org/CA:How_to_apply as an informal explanation of the
technical language.

I can think of pros and cons for each of these examples, but I present
them as ways to get people to think of the issues, as well as to see if
there are alternative solutions to the issue raised.

[Kathleen Wilson]

On 11/3/15 7:09 PM, Ryan Sleevi wrote:
> On Tue, November 3, 2015 4:24 pm, Kathleen Wilson wrote:
>> Topic to discuss [1]:

Thanks, Ryan. All 3 of those examples seem like reasonable options to me.

Does anyone else have an opinion about this?

In regards to the timeline of when a CA must publicly disclose their
non-technically-constrained intermediate certs...

How about for the case of cross-signing with an existing CA whose root
cert is *not* currently included in Mozilla's root store?

How about for the case of cross-signing with an existing CA whose root
cert *is* currently included in Mozilla's root store?

Thanks,
Kathleen

[Charles Reiss]

On 11/04/15 00:24, Kathleen Wilson wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure has
> to happen for new audited/disclosed subCAs.
>
> Section 10 of the Inclusion Policy says:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
> “The CA with a certificate included in Mozilla’s CA Certificate Program MUST
> disclose this information before any such subordinate CA is allowed to issue
> certificates.”
>
> Additionally, section 8.1 of version 1.3 of the Baseline Requirements specifies
> when the audits must occur: “before issuing Publicly-Trusted Certificates, the
> CA SHALL successfully complete a point-in-time readiness assessment performed in
> accordance with applicable standards under one of the audit schemes listed in
> Section 8.1. The point-in-time readiness assessment SHALL be completed no
> earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates
> and SHALL be followed by a complete audit under such scheme within ninety (90)
> days of issuing the first Publicly-Trusted Certificate.”
>
> What further clarification needs to be added to Mozilla’s CA Certificate Policy
> to make it more clear when the audit statements and disclosure has to happen for
> new subCAs?

My impression is that Mozilla need not be explicitly notified of new subCAs; the
disclosure may take the form of an update on the CA's website (perhaps even just
a new version of the CPS). If so, this would seem to make it difficult for
Mozilla or others to monitor adherence to this policy.

For a small number of CAs, I'm not sure where I am supposed to find these
disclosures. For example, where are the (non-DigiCert/Verizon-operated) subCAs
of Baltimore CyberTrust Root disclosed? (I checked the CPS, CP,
http://cybertrust.omniroot.com/repository/ ,
https://www.digicert.com/digicert-root-certificates.htm , searched
bugzilla.mozilla.org, and didn't find it -- I assume I'm missed something?)

[Ryan Sleevi]

On Thu, November 5, 2015 12:51 pm, Charles Reiss wrote:
> My impression is that Mozilla need not be explicitly notified of new
> subCAs; the
> disclosure may take the form of an update on the CA's website (perhaps
> even just
> a new version of the CPS). If so, this would seem to make it difficult for
> Mozilla or others to monitor adherence to this policy.

This is merely temporary; the transition to Salesforce will see CAs
entering in / disclosing their subordinates. Some CAs are already trying
this method and providing feedback / working through kinks, but
ultimately, the goal is to ensure this information is reliably and
consistently provided.

[Kathleen Wilson]

By the time version 2.3 of Mozilla’s CA Cert Policy is published, I hope
to have issued a CA Community License to every included CA. Taking that
into consideration; I propose changing the policy as follows.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
“10. … The CA with a certificate included in Mozilla’s CA Certificate
Program MUST disclose this information *in the CA Community in
Salesforce* <link to https://wiki.mozilla.org/CA:SalesforceCommunity>

before any such subordinate CA is allowed to issue certificates

*chaining up to the CA’s included root certificate*. …”

Additionally, I also propose that we change the first bullet point in
this section, because in the CA Community in Salesforce the CA is
expected to copy-paste in the contents of the .pem file for the
intermediate cert.
“10. … For a certificate to be considered publicly disclosed and
audited, the following information MUST be provided: ..."
CURRENT text:
"- The full DER-encoded X.509 certificate (Each issuing CA should
provide one .p7c, .zip, or .tgz file containing all of the
non-technically-constrained intermediate certificates that it has
signed.); …”
CHANGE to:
“- The PEM (Privacy-enhanced Electronic Mail) Base64 encoded DER X.509
certificate, enclosed between "-----BEGIN CERTIFICATE-----" and
"-----END CERTIFICATE-----";”


Also, in the https://wiki.mozilla.org/CA:SalesforceCommunity wiki page I
propose adding the following section:
== When to Add Intermediate Certificate Data ==
As per Mozilla’s CA Certificate Inclusion policy, all certificates that
are capable of being used to issue new certificates, that are not
technically constrained (via Extended Key Usage and Name Constraint
settings), and that directly or transitively chain to a certificate
included in Mozilla’s CA Certificate Program MUST be audited in
accordance with Mozilla’s CA Certificate Policy and MUST be publicly
disclosed by the CA that has their certificate included in Mozilla’s CA
Certificate Program.

The CA with a certificate included in Mozilla’s CA Certificate Program

MUST add the PEM-encoded X.509 intermediate certificate and the
corresponding CP/CPS and Audit documentation to the CA Community in
Salesforce before the subordinate CA begins issuing Publicly-Trusted
Certificates that chain up to the CA’s included root certificate.
~~

As always, I will appreciate your thoughtful and constructive input

about this proposal.

Kathleen

[Gervase Markham]

On 19/11/15 23:09, Kathleen Wilson wrote:
> “10. … The CA with a certificate included in Mozilla’s CA Certificate
> Program MUST disclose this information *in the CA Community in
> Salesforce* <link to https://wiki.mozilla.org/CA:SalesforceCommunity>
> before any such subordinate CA is allowed to issue certificates
> *chaining up to the CA’s included root certificate*. …”

I would say "disclose this information to Mozilla in a manner Mozilla
will specify before any such". There's no need to specify the exact tool
in a policy. Separation of policy and mechanism :-)

> “10. … For a certificate to be considered publicly disclosed and
> audited, the following information MUST be provided: ..."

Similarly, I would change this to "the full certificate contents in a
format Mozilla specifies".

> Also, in the https://wiki.mozilla.org/CA:SalesforceCommunity wiki page I
> propose adding the following section:

That's not a policy document, so you can change it how you like :-)

Gerv

[Peter Bowen]

On Tue, Nov 3, 2015 at 4:24 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure
> has to happen for new audited/disclosed subCAs.
>
> Section 10 of the Inclusion Policy says:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> “The CA with a certificate included in Mozilla’s CA Certificate Program MUST
> disclose this information before any such subordinate CA is allowed to issue
> certificates.”
>
> Additionally, section 8.1 of version 1.3 of the Baseline Requirements
> specifies when the audits must occur: “before issuing Publicly-Trusted
> Certificates, the CA SHALL successfully complete a point-in-time readiness
> assessment performed in accordance with applicable standards under one of
> the audit schemes listed in Section 8.1. The point-in-time readiness
> assessment SHALL be completed no earlier than twelve (12) months prior to
> issuing Publicly-Trusted Certificates and SHALL be followed by a complete
> audit under such scheme within ninety (90) days of issuing the first
> Publicly-Trusted Certificate.”
>
> What further clarification needs to be added to Mozilla’s CA Certificate
> Policy to make it more clear when the audit statements and disclosure has to
> happen for new subCAs?

It would be good to clarify whether "subordinate CA" means the
operator of the subordinate CA (a company or individual) or if it
means the CA itself (e.g. the tuple of keypair and distinguished
name).

I think that the reasonable view is that:
- Each operator of one or more CAs must have publicly posted either a
Type 1/Point in Time audit report or a Type 2/Period of Time audit
report prior to receiving a cross-certification from another CA that
is publicly trusted (e.g. is either in the trust store or is
themselves cross certified)
- Each cross-certificate must be publicly disclosed prior to the
subject CA issuing certificates. The disclosure must include the
items listed (e.g. each individual subject CA must list the CP, CPS,
operator name, and operator URL) and must be updated when reasonably
possible to include a test website URL. (see
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Third-Party_Subordinate_CAs_that_are_not_Technically_Constrained)

I would also add an allowance for the case where a cross-certficate is
issued to an existing CA which already has another public
cross-certificate and is already issuing certificates. In this case
the new cross-certificate and subject CA information must be disclosed
with X business days of issuance.

This ensures that the audit is complete before cross-certification and
that there is not a gap where the cross-certified CA is issuing
certificates without being disclosed. It also ensures that all
cross-certificates are disclosed, not just the first one a CA
receives.

Thanks,
Peter

[Charles Reiss]

On 11/19/15 23:09, Kathleen Wilson wrote:
> By the time version 2.3 of Mozilla’s CA Cert Policy is published, I hope to have
> issued a CA Community License to every included CA. Taking that into
> consideration; I propose changing the policy as follows.
>

[snip]

>
> As always, I will appreciate your thoughtful and constructive input about this
> proposal.

Shouldn't there also be something in the policy about when and how CAs should
provide updated annual public attestation statements for the subCAs? (I assume
the 30 days from the updated audit being available to the CA in the Maintainence
Policy is appropriate for this.)

[David E. Ross]

On 11/20/2015 12:33 PM, Peter Bowen wrote [in part]:
> It would be good to clarify whether "subordinate CA" means the
> operator of the subordinate CA (a company or individual) or if it
> means the CA itself (e.g. the tuple of keypair and distinguished
> name).

This reflects the too casual use of "CA" by too many individuals to mean
"certification authority" and "root certificate". "CA" is used for both
-- often by the same individual -- but with different meanings at
different times. That is why the acronym should not be used at all in
any formal policy.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Peter Bowen]

On Tue, Nov 3, 2015 at 4:24 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure
> has to happen for new audited/disclosed subCAs.
>

> What further clarification needs to be added to Mozilla’s CA Certificate
> Policy to make it more clear when the audit statements and disclosure has to
> happen for new subCAs?

Given that it is Mozilla policy to require all CAs to follow the
CA/Browser Forum Baseline Requirements, and that the Baseline
Requirements require that "the CA SHALL publicly disclose its
Certificate Policy and/or Certification Practice Statement through an
appropriate and readily accessible online means that is available on a
24x7 basis" and that "the CA SHALL disclose all Cross Certificates
that identify the CA as the Subject, provided that the CA arranged for
or accepted the establishment of the trust relationship (i.e. the
Cross Certificate at issue)," should Mozilla require that disclosure
of the CP, CPS, operator name, and operator URL for all
cross-certificates prior to use?

I realize that Mozilla carved out allowance for not disclosing, but
the CA/Browser Forum did not adopt this, instead only exempting
technically constrained CAs from the audit requirement. Maybe this is
a place where the Mozilla policy can aligned with the BRs.

Thanks,
Peter

[Gervase Markham]

On 23/11/15 15:57, Peter Bowen wrote:
> I realize that Mozilla carved out allowance for not disclosing, but
> the CA/Browser Forum did not adopt this, instead only exempting
> technically constrained CAs from the audit requirement. Maybe this is
> a place where the Mozilla policy can aligned with the BRs.

This sounds like an item for the policy v2.3 discussion, if it's not on
there already. Kathleen?

Gerv

[Kathleen Wilson]

> On 23/11/15 15:57, Peter Bowen wrote:
>> I realize that Mozilla carved out allowance for not disclosing, but
>> the CA/Browser Forum did not adopt this, instead only exempting
>> technically constrained CAs from the audit requirement. Maybe this is
>> a place where the Mozilla policy can aligned with the BRs.
>

Are you referring to section 3.2.6 of the BRs?
~~
3.2.6. Criteria for Interoperation or Certification
The CA SHALL disclose all Cross Certificates that identify the CA as the

Subject, provided that the CA arranged
for or accepted the establishment of the trust relationship (i.e. the

Cross Certificate at issue).
~~

Or were you referring to something else?

From BR Definitions:
Cross Certificate: A certificate that is used to establish a trust
relationship between two Root CAs.
Root CA: The top level Certification Authority whose Root Certificate is
distributed by Application Software
Suppliers and that issues Subordinate CA Certificates.

Kathleen

[Peter Bowen]

On Thu, Dec 3, 2015 at 10:31 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>> On 23/11/15 15:57, Peter Bowen wrote:
>>>
>>> I realize that Mozilla carved out allowance for not disclosing, but
>>> the CA/Browser Forum did not adopt this, instead only exempting
>>> technically constrained CAs from the audit requirement. Maybe this is
>>> a place where the Mozilla policy can aligned with the BRs.
>>
>>
>
>

> Are you referring to section 3.2.6 of the BRs?
> ~~
> 3.2.6. Criteria for Interoperation or Certification

> The CA SHALL disclose all Cross Certificates that identify the CA as the

> Subject, provided that the CA arranged
> for or accepted the establishment of the trust relationship (i.e. the Cross

> Certificate at issue).
> ~~
>
> Or were you referring to something else?
>
> From BR Definitions:
> Cross Certificate: A certificate that is used to establish a trust
> relationship between two Root CAs.
> Root CA: The top level Certification Authority whose Root Certificate is
> distributed by Application Software
> Suppliers and that issues Subordinate CA Certificates.

I was but forgot that the definition of cross certificate in the BRs
is different from the X.509 definition. I was thinking of this
definition:

[Kathleen Wilson]

So, the BRs do not mention disclosure of any intermediate certificates
other than cross-signing relationships between root certs included in
the major root stores. So, on this particular topic we do not want to
align Mozilla policy with the BRs. Correct?

Kathleen

[Peter Bowen]

On Thu, Dec 3, 2015 at 11:17 AM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> On 12/3/15 11:04 AM, Peter Bowen wrote:
>>

> So, the BRs do not mention disclosure of any intermediate certificates other
> than cross-signing relationships between root certs included in the major
> root stores. So, on this particular topic we do not want to align Mozilla
> policy with the BRs. Correct?

Agreed. However it does raise the question of whether the Mozilla
policy should be:

1) All certificates with CA:TRUE must be disclosed or

2) All certificates with CA:TRUE must be disclosed except:
- certificates that meet the technically constrained definition
- certificates where the issuer is not required to be disclosed due to
the previous line or

3) All certificates with CA:TRUE must be disclosed except certificates
where the Issuing CA is technically constrained

Option #3 would require disclosing the technically constrained
certificate but nothing further down the graph.

Thanks,
Peter

[Kathleen Wilson]

On 12/3/15 11:34 AM, Peter Bowen wrote:
> Agreed. However it does raise the question of whether the Mozilla
> policy should be:
>
> 1) All certificates with CA:TRUE must be disclosed or
>
> 2) All certificates with CA:TRUE must be disclosed except:
> - certificates that meet the technically constrained definition
> - certificates where the issuer is not required to be disclosed due to
> the previous line or
>
> 3) All certificates with CA:TRUE must be disclosed except certificates
> where the Issuing CA is technically constrained
>
> Option #3 would require disclosing the technically constrained
> certificate but nothing further down the graph.
>
> Thanks,
> Peter
>

My interpretation of sections 8-10 of Mozilla's policy is #2.

> 2) All certificates with CA:TRUE must be disclosed except:
> - certificates that meet the technically constrained definition
> - certificates where the issuer is not required to be disclosed due to
> the previous line

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"8. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate
included in Mozilla’s CA Certificate Program, MUST be operated in
accordance with Mozilla’s CA Certificate Policy and MUST either be
technically constrained or be publicly disclosed and audited."

And I think the BRs are in alignment with this.
"Technically Constrained Subordinate CA Certificate: A Subordinate CA
certificate which uses a combination of Extended Key Usage settings and
Name Constraint settings to limit the scope within which the Subordinate
CA Certificate may issue Subscriber or additional Subordinate CA
Certificates.
8.1. FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT
Certificates that are capable of being used to issue new certificates
MUST either be Technically Constrained in line with section 7.1.5 and
audited in line with section 8.7 only, or Unconstrained and fully
audited in line with all remaining requirements from this section. A
Certificate is deemed as capable of being used to issue new certificates
if it contains an X.509v3 basicConstraints extension, with the cA
boolean set to true and is therefore by definition a Root CA Certificate
or a Subordinate CA Certificate."


Kathleen

[Kathleen Wilson]

Another thing to consider in updating the policy is in regards to test
certificates versus certificates issued to customers.
e.g. Does the disclosure need to happen before test certificates are
issued?
Or does the disclosure just need to happen before non-test certificates
are issued? (or certificates are issued to customers, or such)

Kathleen

[Peter Bowen]

On Mon, Dec 14, 2015 at 5:39 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>
> Another thing to consider in updating the policy is in regards to test
> certificates versus certificates issued to customers.
> e.g. Does the disclosure need to happen before test certificates are issued?
> Or does the disclosure just need to happen before non-test certificates are
> issued? (or certificates are issued to customers, or such)

Kathleen,

There is no definition of "test certificate" so carving out a specific
exception for test certificates seems unworkable. That being said, it
would seem reasonable that one should be able to generate a keypair
for a new CA, cut a cross-certificate from an existing CA, and issue
the first certificate(s) in one ceremony. I don't think it is
reasonable to require a waiting period between key generation and
certificate issuance.

Therefore, I would revise my earlier recommendation, and suggest
placing a timeliness requirement on disclosure -- publicly disclose
within X days of first issuance. If there is a strong interest in
pre-disclosure, then maybe allowing disclosure of the planned
Distinguished Name of the CA and applicable documents would be
appropriate with a supplementary disclosure of the public key after
generation.

Thanks,
Peter

[Charles Reiss]

I think, at least for externally operated subCAs, Mozilla should require
predisclosure. This would make it clear that the parent CA was committed to
disclosing the subCA. I'm sceptical of an 'X days after issuing' requirement to
provide similar assurance given that externally one can't generally distinguish
between a parent CA complicity issuing a series of short-lived subCAs until
something goes wrong and a parent CA being fooled into issuing a subCA that gets
abused very quickly.

Also, whatever timeline Mozilla provides for disclosure needs to avoid the
catch-22 when issuing a cross-certificate for an existing CA, for which first
issuance is many days before the subCA certificate is issued.