Audits for new subCAs

[Wayne Thayer]

Recently I've received a few questions about audit requirements for
subordinate CAs newly issued from roots in our program. Mozilla policy
section 5.3.2 requires these to be disclosed "within a week of certificate
creation, and before any such subCA is allowed to issue certificates.", but
says nothing about audits.

The fundamental question is 'when must a new subCA be audited?' It is clear
that the TSP's [1] next period-of-time statement must cover all subCAs,
including any new ones. However, it is not clear if issuance from a new
subCA is permitted prior to being explicitly included in an audit.

I believe that it is common practice for TSPs to begin issuing from new
subCAs prior to inclusion in an audit. This practice is arguably supported
by paragraph 3 of BR 8.1 which reads:

If the CA has a currently valid Audit Report indicating compliance with an
> audit scheme listed in Section 8.1, then no pre-issuance readiness
> assessment is necessary.
>

When disclosing a new subCA, the TSP can select "CP/CPS same as parent" and
"Audits same as parent" in CCADB to indicate that the same policies apply
to the new subordinate as to the root.

This issue was raised at the CA/Browser Forum meeting in October 2016 [2].

Three options have been proposed to resolve this ambiguity:
1. Permit a new subCA to be used for issuance prior to being listed on an
audit report.
2. Require the TSP to attest that the new subCA complies with a set of
existing policies prior to issuance [3].
3. Require an audit report (point-in-time or period-of-time) covering the
new subCA before any issuance (possibly with an exception for test
certificates or certificates required for audit purposes).

Please consider these options in the context of a TSP with a current audit
for the parent root that has issued a new subCA, and for which the new
subCA is operating under existing policies and in an existing operational
environment. If this is not the case, I would propose that a new audit
covering the subCA be required.

This is #32 on the policy issues list [4].

I would like to request everyone's input on this topic. Based on our
discussion, I may propose that we address this issue in policy version 2.6.

- Wayne

[1] To avoid confusion, I've chosen to use the term Trust Service Provider
(TSP) to refer to the CA organization.
[2] https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-
39-minutes/#Disclosure-of-Subordinate-CAs
<https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Disclosure-of-Subordinate-CAs>
[3] https://cabforum.org/pipermail/public/2016-September/008464.html
[4] https://github.com/mozilla/pkipolicy/issues/32
<https://github.com/mozilla/pkipolicy/issues/32>

[Jakob Bohm]

Since rotating issuing SubCAs on a regular basis is a best practice to
mitigate the cost of SubCA key compromise (e.g. quarterly or monthly,
maybe more often for someone like LetsEncrypt), it would be highly
impractical to require fresh audits for each such periodic key
generation ceremony.

Having the generation of fresh SubCAs under established procedures be
considered a normal operational task, that just requires a notification
of the new SubCA cert to CCADB, plus inclusion in the next annual audit
would be much more practical, and would encourage the use of frequently
rotated SubCA keys.

One practical limitation for the issuance period of a SubCA is the worst
case size of the resulting CRL (imagine a CRL revoking all but one of
the certificates under a SubCA, then consider the download size of that
CRL for those who still use that method of revocation checking).


Technical note:

The ordinary lifecycle of a SubCA has 5 phases:

1. Generated but not yet issuing, upload to CCADB must occur within
the first 7 days of this phase.

2. Issuing, issued certificates may last as long as end of this phase
+ max cert duration for this SubCA.

3. Revocation only, no new EE certs issued, revocation signatures
(including OCSP certs) still signed. Ideally, this mode is enforced by
an irreversible HSM setting per SubCA. Early in this phase a SubCA
should publish a signed list of all issued EE certs (e.g. serial plus
strong hashes of full cert).

4. All expired, historical revocation only. In this phase the SubCA
issues revocation messages for expired certificates that were reported
as compromised, misissued etc. after their expiry. This is to help
relying parties (Mozilla users) detect if previously signed data was
false. This period will be short for TLS certs, but much longer for
e-mail certs (because a mail program like Thunderbird can store and
check e-mails that are years old when revisiting them in the user
interface).

5. Final revocations. The last act of a SubCA should be to sign a
non-expiring (or very long lived) set of revocation messages (CRLs and
canned OCSP responses), after which the private key is destroyed. Audit
logs etc. are retained for future audits. After this, OCSP responders
will need to reject (without signature) any queries for multiple certs
and never issued certs.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[David E. Ross]

On 3/23/2018 11:34 AM, Wayne Thayer wrote:
> Recently I've received a few questions about audit requirements for
> subordinate CAs newly issued from roots in our program. Mozilla policy
> section 5.3.2 requires these to be disclosed "within a week of certificate
> creation, and before any such subCA is allowed to issue certificates.", but
> says nothing about audits.

"CA" = "certification authority"

Do you really mean "subordinate certification authorities newly issued
from roots"? If so, what does that mean? Or do you mean "subordinate
certificates newly issued from roots"?

I do not really want to be picky. However, when dealing with something
as important as Internet security, being picky is mandatory.

--
David E. Ross
<http://www.rossde.com/>

President Trump: Please stop using Twitter. We need
to hear your voice and see you talking. We need to know
when your message is really your own and not your attorney's.

[Wayne Thayer]

Apologies. By choosing to use the term TSP when referring to an
organization operating a PKI, I thought I had made my meaning clear. I now
realize I inferred "certificate" when I used the term "subordinate CA". I
meant "subordinate CA certificate" in all cases where I wrote "subordinate
CA" or "subCA".

For reference, there has been an ongoing CA/Browser Forum discussion aimed
at disambiguating the term "CA":
https://cabforum.org/pipermail/policyreview/2016-May/000291.html

On Fri, Mar 23, 2018 at 4:08 PM, David E. Ross via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 3/23/2018 11:34 AM, Wayne Thayer wrote:

> > Recently I've received a few questions about audit requirements for
> > subordinate CAs newly issued from roots in our program. Mozilla policy
> > section 5.3.2 requires these to be disclosed "within a week of
> certificate
> > creation, and before any such subCA is allowed to issue certificates.",
> but
> > says nothing about audits.
>

> "CA" = "certification authority"
>
> Do you really mean "subordinate certification authorities newly issued
> from roots"? If so, what does that mean? Or do you mean "subordinate
> certificates newly issued from roots"?
>
> I do not really want to be picky. However, when dealing with something
> as important as Internet security, being picky is mandatory.
>
> --
> David E. Ross
> <http://www.rossde.com/>
>
> President Trump: Please stop using Twitter. We need
> to hear your voice and see you talking. We need to know
> when your message is really your own and not your attorney's.

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

[Peter Bowen]

On Fri, Mar 23, 2018 at 11:34 AM, Wayne Thayer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> Recently I've received a few questions about audit requirements for
> subordinate CAs newly issued from roots in our program. Mozilla policy
> section 5.3.2 requires these to be disclosed "within a week of certificate
> creation, and before any such subCA is allowed to issue certificates.", but
> says nothing about audits.
>

Unsurprisingly, I support option #2. However I think is it important
that there are three distinct things that need to be covered:

1) Key generation for the new CA
2) Assertion of controls for the new CA
3) Issuance of a CA certificate, by an existing trusted CA, that names
the new CA as the subject

I does make sense to allow a slight delay in disclosure such that a
single ceremony can be used to generate the key and issue a CA
certificate, but a week seems plenty generous.

Thanks,
Peter

[Wayne Thayer]

Peter,

Are you advocating for option #2 (TSP self-attestation) because you think
that option #3 (audit) is unreasonable, or because you believe there is a
benefit to Mozilla's users in a self-attestation beyond what we get from
the existing requirement for CCADB disclosure?

[Peter Bowen]

Both :)

Having a new audit per online CA is going to be very expensive and
cause TSPs heavily limit the number of online CAs they have.
Additionally all of these would be point-in-time audits, which only
report on design of controls. Assuming the design is consistent
between CAs, then there is no value in having additional audit
reports.

However I do think there is value in having the CA provide a statement
that the same controls will apply to the new CA and commit to
including the CA in the next audit. Otherwise it could be over a year
before it is noted that the CA does not have adequate controls. The
"same audit as parent" does not make sense for new CAs, as the new CA
is not included in the audit scope. I'm sure automated audit report
processing will notice this and throw an error once it is online.

[Bruce]

Entrust does the following:
- Each subCA certificate is created through a audited ceremony. The auditor creates a report indicating the key ID and the CPS which was used for key generation.
- When it is time for the subCA to go into production, an intermediate certificate is issued from a root. The intermediate certificate will meet the requirements of the CPS and the BRs if applicable.
- The subCA can now issue certificates. The end entity certificates will have a certificate policy which is stated in the CPS. As such, issuing a certificate is an assertion that the subCA is issuing in accordance with the certificate policy and CPS.
- The new subCA is compliance audited at the next time in our annual audit cycle. Note the new subCA is operated the same as all other CAs meeting the same certificate policy.

I would note that if there was a significant change such as data center location or new certificate policy, then we may want to consider a point-in-time readiness assessment. I think that all CAs required a point-in-time readiness assessment, before we started to issue EV certificates.

I suppose that I am stating that I support option 1 as I think the option 2 attestments are already covered. However, option 3 may be required for a new data center or a policy which has not been previously audited.

Thanks, Bruce.

[Buschart, Rufus]

Operating a technically unconstrained issuing CA, Siemens CA (aka TSP) does something very similar in case a new CA is necessary:

* In an audited ceremony based on the operational and technical controls audited in the last annual audit a key pair is generated on one of the HSMs
* A CSR is constructed and sent to our cross signing partner, together with the witness report of the auditor, filled with all the information required by Microsoft in the Audit Cover Letter Template
* The cross signing partner checks the report and creates the certificate for the issuing CA After receiving the new certificate we update our CPS Only after the new CPS is published certificates are issued

In the next annual audit the new CA is part of the normal audit.

So I would recommend to choose a combination of options #1 and #2.

With best regards,
Rufus Buschart

Siemens AG
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.b...@siemens.com

www.siemens.com/ingenuityforlife

[Wayne Thayer]

Thanks everyone for your input on this topic. I'm hearing consensus that we
should not require a newly issued subordinate CA certificate to appear on
an audit statement prior to being used to sign end-entity certificates.
This is something that could be clarified in our policy with a statement
such as "Newly issued subordinate CA certificates MUST appear on the CAs
next period-of-time audit statements" in section 5.3.2.

It's not yet clear to me if we should require something more than
disclosure of the actual certificate because:
* All end-entity certificates are already required to contain "A Policy
Identifier, defined by the issuing CA, that indicates a Certificate Policy
asserting the issuing CA's adherence to and compliance with these
Requirements" (BR 7.1.2.3). Isn't this enough to assert the controls
applied to the subCA certificate?
* I'm not opposed to explicitly stating that any newly issued subCA
certificate MUST appear in the appropriate CP/CPS before being used, but
isn't that obvious?
* The amount of effort needed to verify compliance with a new requirement
for a management assertion (option #2) is significant and could outweigh
the benefit we receive from those documents.
* Peter's sample assertion letter [1] includes a link to an auditor's key
generation ceremony report. Can this type of audit report be shared
publicly? If so, those might be a reasonable thing to require via a new
field in CCADB.

- Wayne

[1]
https://cabforum.org/pipermail/public/attachments/20160923/3da206b8/attachment-0001.bin

[Ryan Sleevi]

On Thu, Mar 29, 2018 at 2:46 PM, Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Thanks everyone for your input on this topic. I'm hearing consensus that we
> should not require a newly issued subordinate CA certificate to appear on
> an audit statement prior to being used to sign end-entity certificates.
>

There's a little danger here in this phrasing. If a CA generates a key, has
a report, and then places it in a safe for 3 years before issuing the first
cert, I would think you'd want some reports covering this. In particular,
what are the controls around the safe that were protecting the key? How do
we know they didn't simply stow it on a USB stick in someone's unlocked
desk? etc

> This is something that could be clarified in our policy with a statement
> such as "Newly issued subordinate CA certificates MUST appear on the CAs
> next period-of-time audit statements" in section 5.3.2.
>

This mitigates one window of vulnerability - reducing the span from
multiple years to, at most, one year.

> It's not yet clear to me if we should require something more than
> disclosure of the actual certificate because:
> * All end-entity certificates are already required to contain "A Policy
> Identifier, defined by the issuing CA, that indicates a Certificate Policy
> asserting the issuing CA's adherence to and compliance with these
> Requirements" (BR 7.1.2.3). Isn't this enough to assert the controls
> applied to the subCA certificate?
> * I'm not opposed to explicitly stating that any newly issued subCA
> certificate MUST appear in the appropriate CP/CPS before being used, but
> isn't that obvious?
>

Obvious for who?
It's not obvious CAs are doing it, no.
For relying parties, it's equally not obvious, but presumably being
inferred by trying to map the policy OID back.

> * The amount of effort needed to verify compliance with a new requirement
> for a management assertion (option #2) is significant and could outweigh
> the benefit we receive from those documents.
> * Peter's sample assertion letter [1] includes a link to an auditor's key
> generation ceremony report. Can this type of audit report be shared
> publicly? If so, those might be a reasonable thing to require via a new
> field in CCADB.
>

I think, for new CAs, the KGC report and the stated CP/CPS, combined with
ensuring that the next audit that covers the period of time stated on the
KGC report includes that certificate, seems like a reasonable balance.

[crawfo...@gmail.com]

I think BR 6.1.1.1 is a little confusing on when a root key generation observation report is required, because it uses the term “Root CA Key Pair” in a section that seems to be addressing CAs that are not root CAs.

For other CA Key Pairs created after the Effective Date that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:

1. prepare and follow a Key Generation Script and
2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process.

[Wayne Thayer]

Tim,

On Fri, Mar 30, 2018 at 7:00 AM, crawfordtimj--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thursday, March 29, 2018 at 2:56:17 PM UTC-5, Ryan Sleevi wrote:

> I think BR 6.1.1.1 is a little confusing on when a root key generation
> observation report is required, because it uses the term “Root CA Key Pair”
> in a section that seems to be addressing CAs that are not root CAs.
>
> For other CA Key Pairs created after the Effective Date that are for the
> operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:
>

> This part seems clear to me.

1. prepare and follow a Key Generation Script and
> 2. have a Qualified Auditor witness the Root CA Key Pair generation
> process or record a video of the entire Root CA Key Pair generation process.
>
>

If you are commenting on the word "Root" in #2, then I think this is meant
to apply to both Root and subordinate CA key pairs, so both instances of
the word "Root" should be struck.

[Wayne Thayer]

On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
> I think, for new CAs, the KGC report and the stated CP/CPS, combined with
> ensuring that the next audit that covers the period of time stated on the
> KGC report includes that certificate, seems like a reasonable balance.
>

I'll add this to the list for 2.6 and propose some language in a new
"Policy 2.6 Proposal" thread.

Thanks,

Wayne

[Julian Inza]

There are also some situations in that a root CA in an organization is issuing a Certificate for a Sub-CA in a different organization.

In my opinion, both organization should perform an audit conforming EN 319 411-2.

An interesting point would be to identify which information of the CAR (Conformity Assessment Report)is of interest for the Country Supervisory Body and wich is of interest for Mozilla or other Browsers aligned with CAB Forum.

One is key element to be included in the TSL and the other to browser (for instance Mozilla) related Root certificates programs.

Best regards,


Julian Inza

[Jakob Bohm]

When a CA issues a SubCA for another organization, the common situation
is one of:

A. The SubCA is technically constrained to identities validated by the
parent CA as belonging exclusively to that other organization. This
should be seen as a variant of issuing wildcard certificates, but with
more stringent checks. Requiring an audit at the parent CA would be
pointless overkill. Current Mozilla Policy seems to handle this case
well.

B. The SubCA is actually the root of another audited CA (cross signing).
Here the traditional and sufficient requirement is a full audit of the
other CA, including that other CA going through the new CA process
soon before/after the cross signing, but benefiting from the cross-
signature until relying parties receive the updated root store that
trusts that other CA.

So in neither case do I see a need to re-audit the parent CA.

[Jakob Bohm]

On 29/03/2018 20:46, Wayne Thayer wrote:
> Thanks everyone for your input on this topic. I'm hearing consensus that we
> should not require a newly issued subordinate CA certificate to appear on
> an audit statement prior to being used to sign end-entity certificates.
> This is something that could be clarified in our policy with a statement
> such as "Newly issued subordinate CA certificates MUST appear on the CAs
> next period-of-time audit statements" in section 5.3.2.
>
> It's not yet clear to me if we should require something more than
> disclosure of the actual certificate because:
> * All end-entity certificates are already required to contain "A Policy
> Identifier, defined by the issuing CA, that indicates a Certificate Policy
> asserting the issuing CA's adherence to and compliance with these
> Requirements" (BR 7.1.2.3). Isn't this enough to assert the controls
> applied to the subCA certificate?
> * I'm not opposed to explicitly stating that any newly issued subCA
> certificate MUST appear in the appropriate CP/CPS before being used, but
> isn't that obvious?

While Entrust happens to do this, as a relying party, I dislike frequent
updates to CP/CPS documents just for such formal changes.

This is because the CP/CPS is a lengthy legal document which relying
parties are "supposed to" read and understand. Thus each such needless
change generates a huge wave of millions of relying parties being
supposed to obtain and read through that document, a complete waste of
our time as relying parties.

It is much more reasonable, from a relying party perspective, for such
informational details to be in a parallel document and/or be postponed
until a scheduled annual or rarer document update (Yes I am aware of the
BR that such needless updates be done annually for no reason at all).

[Wayne Thayer]

On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> While Entrust happens to do this, as a relying party, I dislike frequent
> updates to CP/CPS documents just for such formal changes.
>

> This creates a huge loophole. The CP/CPS is the master set of policies the
TSP agrees to be bound by and audited against. If a TSP doesn't include a
new subCA certificate in the scope of their CP/CPS, then from an audit
perspective there is effectively no policy that applies to the subCA.
Similarly, if the TSP claims to implement a new policy but doesn't include
it in their CP/CPS, then the audit will not cover it (unless it's a BR
requirement that has made it into the BR audit criteria).

This is because the CP/CPS is a lengthy legal document which relying
> parties are "supposed to" read and understand. Thus each such needless
> change generates a huge wave of millions of relying parties being
> supposed to obtain and read through that document, a complete waste of
> our time as relying parties.
>

> I think you're confusing the Relying Party Agreement with the CP/CPS. Even
so, you've pointed out that it is absurd to use this as an argument against
regular CP/CPS updates.

TSPs are now required to maintain change logs in their CP/CPS. Would not a
quick glance at that meet your needs?

It is much more reasonable, from a relying party perspective, for such
> informational details to be in a parallel document and/or be postponed
> until a scheduled annual or rarer document update (Yes I am aware of the
> BR that such needless updates be done annually for no reason at all).
>

> How would you distinguish between details and material changes? I would
argue that a new subCA certificate is more than an informational detail.

The point of the BR requirement is to create some documentation indicating
that a TSP is regularly reviewing and updating their CP/CPS.

[Jakob Bohm]

On 03/04/2018 02:15, Wayne Thayer wrote:
> On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>> While Entrust happens to do this, as a relying party, I dislike frequent
>> updates to CP/CPS documents just for such formal changes.
>>
>> This creates a huge loophole. The CP/CPS is the master set of policies the
> TSP agrees to be bound by and audited against. If a TSP doesn't include a
> new subCA certificate in the scope of their CP/CPS, then from an audit
> perspective there is effectively no policy that applies to the subCA.
> Similarly, if the TSP claims to implement a new policy but doesn't include
> it in their CP/CPS, then the audit will not cover it (unless it's a BR
> requirement that has made it into the BR audit criteria).
>

If the CP/CPS states as an auditable requirements that all SubCAs are
logged in the trusted hardware of the root CA HSM, listed in the
dedicated public document and audited, there is no need for that list to
be included verbatim in the CP/CPS any more than there is a need for
most other routine activities to change the CP/CPS.

> This is because the CP/CPS is a lengthy legal document which relying
>> parties are "supposed to" read and understand. Thus each such needless
>> change generates a huge wave of millions of relying parties being
>> supposed to obtain and read through that document, a complete waste of
>> our time as relying parties.
>>
>> I think you're confusing the Relying Party Agreement with the CP/CPS. Even
> so, you've pointed out that it is absurd to use this as an argument against
> regular CP/CPS updates.
>

Relying party agreements (and subscriber agreements too) often
incorporate the CP/CPS by reference.

> TSPs are now required to maintain change logs in their CP/CPS. Would not a
> quick glance at that meet your needs?

Only to the extent such logs are sufficient to determine how much of the
document is literally (not just subjectively) unchanged. And provided
any conflict between the change log and the actual document shall be
resolved to the benefit of all third parties.

>
> It is much more reasonable, from a relying party perspective, for such
>> informational details to be in a parallel document and/or be postponed
>> until a scheduled annual or rarer document update (Yes I am aware of the
>> BR that such needless updates be done annually for no reason at all).
>>
>> How would you distinguish between details and material changes? I would
> argue that a new subCA certificate is more than an informational detail.
>

Details include such routine numerical changes as date of last review
(where that review does not result in any other change), changing the
list of CA certificates or changing the name brand of HSM hardware,
exact locations of technical facilities (as opposed to changing the
country and jurisdiction) etc.

Substantial changes are things that could actually affect the
willingness of parties to trust or request certificates, such as the
used validation methods, the contracting entity, the jurisdiction
capable of interfering with operations and issuance etc.

> The point of the BR requirement is to create some documentation indicating
> that a TSP is regularly reviewing and updating their CP/CPS.
>

However that could equally just be a management statement (copied in the
audit report if necessary), that the CP/CPS was reviewed on YYYY/MM/DD
and found to remain compliant to BRs version X.Y.Z. Mozilla policy
version A.B, ETSI standard EEE EEE and that the actual practice remains
within its limits.

There could also be restricting legal addendums saying things like
"Although our current CPS allows us to issue 5 year certificates based
on a sworn statement from a notary public, we will not and have not done
so since YYYY/MM/DD". Such addendums would be to satisfy those who no
longer accept that particular practice but would have no effect on the
relationship with parties that accept the CPS including the option to do
so.

[Ryan Sleevi]

On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 03/04/2018 02:15, Wayne Thayer wrote:
>

>> On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>>
>>> While Entrust happens to do this, as a relying party, I dislike frequent
>>> updates to CP/CPS documents just for such formal changes.
>>>
>>> This creates a huge loophole. The CP/CPS is the master set of policies
>>> the
>>>
>> TSP agrees to be bound by and audited against. If a TSP doesn't include a
>> new subCA certificate in the scope of their CP/CPS, then from an audit
>> perspective there is effectively no policy that applies to the subCA.
>> Similarly, if the TSP claims to implement a new policy but doesn't include
>> it in their CP/CPS, then the audit will not cover it (unless it's a BR
>> requirement that has made it into the BR audit criteria).
>>
>>

> If the CP/CPS states as an auditable requirements that all SubCAs are
> logged in the trusted hardware of the root CA HSM, listed in the
> dedicated public document and audited, there is no need for that list to
> be included verbatim in the CP/CPS any more than there is a need for
> most other routine activities to change the CP/CPS.
>

This is not true. A CP/CPS is not bound to the organization, it's bound to
specific operations, and as such, the creation of a subCA by an
organization has no implicit binding to a CP/CPS.

>
> This is because the CP/CPS is a lengthy legal document which relying
>>
>>> parties are "supposed to" read and understand. Thus each such needless
>>> change generates a huge wave of millions of relying parties being
>>> supposed to obtain and read through that document, a complete waste of
>>> our time as relying parties.
>>>
>>> I think you're confusing the Relying Party Agreement with the CP/CPS.
>>> Even
>>>
>> so, you've pointed out that it is absurd to use this as an argument
>> against
>> regular CP/CPS updates.
>>
>>

> Relying party agreements (and subscriber agreements too) often
> incorporate the CP/CPS by reference.

Can you point out to where that's required by Mozilla policy or by the
Baseline Requirements?

> TSPs are now required to maintain change logs in their CP/CPS. Would not a
>> quick glance at that meet your needs?
>>
>

> Only to the extent such logs are sufficient to determine how much of the
> document is literally (not just subjectively) unchanged. And provided
> any conflict between the change log and the actual document shall be
> resolved to the benefit of all third parties.
>

What? No.

> It is much more reasonable, from a relying party perspective, for such
>>
>>> informational details to be in a parallel document and/or be postponed
>>> until a scheduled annual or rarer document update (Yes I am aware of the
>>> BR that such needless updates be done annually for no reason at all).
>>>
>>> How would you distinguish between details and material changes? I would
>>>
>> argue that a new subCA certificate is more than an informational detail.
>>
>>

> Details include such routine numerical changes as date of last review
> (where that review does not result in any other change), changing the
> list of CA certificates or changing the name brand of HSM hardware,
> exact locations of technical facilities (as opposed to changing the
> country and jurisdiction) etc.
>

These are all material and substantial changes.

> Substantial changes are things that could actually affect the
> willingness of parties to trust or request certificates, such as the
> used validation methods, the contracting entity, the jurisdiction
> capable of interfering with operations and issuance etc.
>
>

> The point of the BR requirement is to create some documentation indicating
>> that a TSP is regularly reviewing and updating their CP/CPS.
>>
>>

> However that could equally just be a management statement (copied in the
> audit report if necessary), that the CP/CPS was reviewed on YYYY/MM/DD
> and found to remain compliant to BRs version X.Y.Z. Mozilla policy
> version A.B, ETSI standard EEE EEE and that the actual practice remains
> within its limits.
>
> There could also be restricting legal addendums saying things like
> "Although our current CPS allows us to issue 5 year certificates based
> on a sworn statement from a notary public, we will not and have not done
> so since YYYY/MM/DD". Such addendums would be to satisfy those who no
> longer accept that particular practice but would have no effect on the
> relationship with parties that accept the CPS including the option to do
> so.

These all sound like rather terrible ideas, and while having been adopted
by some CAs in the past, are shown to be regularly problematic as to
forming a meaningful opinion as to whether the CA is themselves
trustworthy, particularly such CAs that argue for 'hidden' addendums, as
has happened in the past.

[Jakob Bohm]

On 03/04/2018 14:57, Ryan Sleevi wrote:
> On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On 03/04/2018 02:15, Wayne Thayer wrote:
>>
>>> On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
>>> dev-secur...@lists.mozilla.org> wrote:
>>>
>>>
>>>> While Entrust happens to do this, as a relying party, I dislike frequent
>>>> updates to CP/CPS documents just for such formal changes.
>>>>
>>>> This creates a huge loophole. The CP/CPS is the master set of policies
>>>> the
>>>>
>>> TSP agrees to be bound by and audited against. If a TSP doesn't include a
>>> new subCA certificate in the scope of their CP/CPS, then from an audit
>>> perspective there is effectively no policy that applies to the subCA.
>>> Similarly, if the TSP claims to implement a new policy but doesn't include
>>> it in their CP/CPS, then the audit will not cover it (unless it's a BR
>>> requirement that has made it into the BR audit criteria).
>>>
>>>
>> If the CP/CPS states as an auditable requirements that all SubCAs are
>> logged in the trusted hardware of the root CA HSM, listed in the
>> dedicated public document and audited, there is no need for that list to
>> be included verbatim in the CP/CPS any more than there is a need for
>> most other routine activities to change the CP/CPS.
>>
>
> This is not true. A CP/CPS is not bound to the organization, it's bound to
> specific operations, and as such, the creation of a subCA by an
> organization has no implicit binding to a CP/CPS.
>

A CP/CPS covers (by its very nature) all SubCA signing operations
by a covered CA private key and as others have pointed out, each
compliant SubCA is required to contain an OID identifying the applicable
CP/CPS.

Thus a CP/CPS can state that it covers all CA keys and certs listed in
public document X and that all SubCAs referencing that CP/CPS and issued
by a covered CA key must be added to public document X, which shall be
published and archived in a specific way, such as in the CA
organizations public repository, sent to all enrolled root programs and
logged to CT.

The CP/CPS can also state that the CA HSM must store, in a secured
hardware log, all signed SubCA certs (or even all issued certs), this
log will be one of the key things checked by auditors (it already is in
the current WebTrust and ETSI auditing standards, as part of the
sampling of previously issued end entity certs).

>
>>
>> This is because the CP/CPS is a lengthy legal document which relying
>>>
>>>> parties are "supposed to" read and understand. Thus each such needless
>>>> change generates a huge wave of millions of relying parties being
>>>> supposed to obtain and read through that document, a complete waste of
>>>> our time as relying parties.
>>>>
>>>> I think you're confusing the Relying Party Agreement with the CP/CPS.
>>>> Even
>>>>
>>> so, you've pointed out that it is absurd to use this as an argument
>>> against
>>> regular CP/CPS updates.
>>>
>>>
>> Relying party agreements (and subscriber agreements too) often
>> incorporate the CP/CPS by reference.
>
>
> Can you point out to where that's required by Mozilla policy or by the
> Baseline Requirements?
>

It is not a BR, it is an observation of common practice.

>
>> TSPs are now required to maintain change logs in their CP/CPS. Would not a
>>> quick glance at that meet your needs?
>>>
>>
>> Only to the extent such logs are sufficient to determine how much of the
>> document is literally (not just subjectively) unchanged. And provided
>> any conflict between the change log and the actual document shall be
>> resolved to the benefit of all third parties.
>>
>
> What? No.
>

If the Change Log is only informative (from a legal standpoint), then it
does not relieve those who read the document of the burden of actually
checking that nothing else was changed.

>
>> It is much more reasonable, from a relying party perspective, for such
>>>
>>>> informational details to be in a parallel document and/or be postponed
>>>> until a scheduled annual or rarer document update (Yes I am aware of the
>>>> BR that such needless updates be done annually for no reason at all).
>>>>
>>>> How would you distinguish between details and material changes? I would
>>>>
>>> argue that a new subCA certificate is more than an informational detail.
>>>
>>>
>> Details include such routine numerical changes as date of last review
>> (where that review does not result in any other change), changing the
>> list of CA certificates or changing the name brand of HSM hardware,
>> exact locations of technical facilities (as opposed to changing the
>> country and jurisdiction) etc.
>>
>
> These are all material and substantial changes.
>

Only if those things are hardcoded into the text of the CPS, rather than
being in different documents that are restricted (by the CPS) to only
provide those details. For example, a CPS can state that the HSM must
be officially validated to FIPS 140-3 level 3 or higher, and that the
secured CA facility is located in Mountain View, while leaving it to
other documents to state if the HSM is a specific model from nCipher or
IBM, and which exact building contains the secure equipment (the latter
might even be a secret).

Similarly for a list of current and past CA certs and a list where the
officials sign of on having reviewed the CPS document on specific dates.

This is fundamentally similar to how a CPS may refer to the latest BRs
without having to be updated for each ballot that affects only other
CAs.

>
>> Substantial changes are things that could actually affect the
>> willingness of parties to trust or request certificates, such as the
>> used validation methods, the contracting entity, the jurisdiction
>> capable of interfering with operations and issuance etc.
>>
>>
>> The point of the BR requirement is to create some documentation indicating
>>> that a TSP is regularly reviewing and updating their CP/CPS.
>>>

But it seems unnecessary that meta-data about a decision not to change
the CP/CPS is stored inside the CP/CPS thereby changing it anyway.

>>>
>> However that could equally just be a management statement (copied in the
>> audit report if necessary), that the CP/CPS was reviewed on YYYY/MM/DD
>> and found to remain compliant to BRs version X.Y.Z. Mozilla policy
>> version A.B, ETSI standard EEE EEE and that the actual practice remains
>> within its limits.
>>
>> There could also be restricting legal addendums saying things like
>> "Although our current CPS allows us to issue 5 year certificates based
>> on a sworn statement from a notary public, we will not and have not done
>> so since YYYY/MM/DD". Such addendums would be to satisfy those who no
>> longer accept that particular practice but would have no effect on the
>> relationship with parties that accept the CPS including the option to do
>> so.
>
>
> These all sound like rather terrible ideas, and while having been adopted
> by some CAs in the past, are shown to be regularly problematic as to
> forming a meaningful opinion as to whether the CA is themselves
> trustworthy, particularly such CAs that argue for 'hidden' addendums, as
> has happened in the past.
>

I am talking about public addendums, reviewed by auditors and root
programs, and in the case of Mozilla, uploaded to the CCADB or Bugzilla.

[Ryan Sleevi]

On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> A CP/CPS covers (by its very nature) all SubCA signing operations
> by a covered CA private key and as others have pointed out, each
> compliant SubCA is required to contain an OID identifying the applicable
> CP/CPS.
>
> Thus a CP/CPS can state that it covers all CA keys and certs listed in
> public document X and that all SubCAs referencing that CP/CPS and issued
> by a covered CA key must be added to public document X, which shall be
> published and archived in a specific way, such as in the CA
> organizations public repository, sent to all enrolled root programs and
> logged to CT.
>
> The CP/CPS can also state that the CA HSM must store, in a secured
> hardware log, all signed SubCA certs (or even all issued certs), this
> log will be one of the key things checked by auditors (it already is in
> the current WebTrust and ETSI auditing standards, as part of the
> sampling of previously issued end entity certs).
>

This all sounds good, but it does not reflect reality.

Consider a sub-CA whose control has been transferred - as has recently been
discussed here. The certificate does not magically change Policy OIDs, it
does not get revoked and reissued with a new policy OID, and yet, it is
operated under a distinct, new, and different CP/CPS.

As such, the proposed solution is fundamentally flawed, and resting on a
flawed assumption about how both CP/CPS works and the ecosystem works. For
this very reason, it seems extremely valuable - if not vitally necessary -
to ensure the scope is clearly and fairly stated, particularly when
engaging auditors who themselves will be bound by the scope of the publicly
stated documents, to the extent permitted within the scope of the audit.

Let's close a loophole. Not introduce more.

>
>
>
>>
>>> This is because the CP/CPS is a lengthy legal document which relying
>>>
>>>>
>>>> parties are "supposed to" read and understand. Thus each such needless
>>>>> change generates a huge wave of millions of relying parties being
>>>>> supposed to obtain and read through that document, a complete waste of
>>>>> our time as relying parties.
>>>>>
>>>>> I think you're confusing the Relying Party Agreement with the CP/CPS.
>>>>> Even
>>>>>
>>>>> so, you've pointed out that it is absurd to use this as an argument
>>>> against
>>>> regular CP/CPS updates.
>>>>
>>>>
>>>> Relying party agreements (and subscriber agreements too) often
>>> incorporate the CP/CPS by reference.
>>>
>>
>>
>> Can you point out to where that's required by Mozilla policy or by the
>> Baseline Requirements?
>>
>>

> It is not a BR, it is an observation of common practice.
>

I disagree even to the claim that it's "common" practice. There is only one
CA that has ever raised this as a practical matter of concern, but their
practices are so fundamentally outmoded that it's hardly to be considered
the model of a good CA operation.

> It is much more reasonable, from a relying party perspective, for such
>>>
>>>>
>>>> informational details to be in a parallel document and/or be postponed
>>>>> until a scheduled annual or rarer document update (Yes I am aware of
>>>>> the
>>>>> BR that such needless updates be done annually for no reason at all).
>>>>>
>>>>> How would you distinguish between details and material changes? I would
>>>>>
>>>>> argue that a new subCA certificate is more than an informational
>>>> detail.
>>>>
>>>>
>>>> Details include such routine numerical changes as date of last review
>>> (where that review does not result in any other change), changing the
>>> list of CA certificates or changing the name brand of HSM hardware,
>>> exact locations of technical facilities (as opposed to changing the
>>> country and jurisdiction) etc.
>>>
>>>
>> These are all material and substantial changes.
>>
>>

> Only if those things are hardcoded into the text of the CPS, rather than
> being in different documents that are restricted (by the CPS) to only
> provide those details. For example, a CPS can state that the HSM must
> be officially validated to FIPS 140-3 level 3 or higher, and that the
> secured CA facility is located in Mountain View, while leaving it to
> other documents to state if the HSM is a specific model from nCipher or
> IBM, and which exact building contains the secure equipment (the latter
> might even be a secret).
>
> Similarly for a list of current and past CA certs and a list where the
> officials sign of on having reviewed the CPS document on specific dates.
>
> This is fundamentally similar to how a CPS may refer to the latest BRs
> without having to be updated for each ballot that affects only other
> CAs.

I'm not sure your point - it's an objective goal to require the CP/CPS to
be updated as appropriate, and to fully and accurately reflect the CAs
operations. Each change is a material change, and should be fairly and
fully stated within the CP/CPS to the point that it's relevant to the
Baseline Requirements. That is, the CP/CPS must itself demonstrate complete
satisfaction of those requirements - or of Mozilla requirements. Burying
those in independent addenda, separately versioned, is to create a
fundamental loophole with regard to CP/CPS updates and policies, when these
changes practically matter. Your example - of specifying specific device -
is a bad example, precisely because one expects to see within the CP/CPS
the compliance with the expected policy (namely, an attestation of FIPS
140-2 Level 3). Similarly, as it applies to overall adherance with either
the BRs or Mozilla Policy, it's not unreasonable to expect sufficient
detail to demonstrate that compliance to be stated within the CP/CPS
itself, not addendum. While it may be that the CA produces supplementary
documentation (such as for the non-public portions of the audits) that
details the full performance, within the CP/CPS itself, one expects to see
all the information.

>From a relying party point of view, it should be possible to understand the
CA's operations in a single pair of documents, without having to
cross-reference a set of nested or interrelated policy documents, some of
which may conflict due to their updates, and some of which may be created
in order to play semantic loopholes with regards to policy compliance.

>
>
>
>
>> Substantial changes are things that could actually affect the
>>> willingness of parties to trust or request certificates, such as the
>>> used validation methods, the contracting entity, the jurisdiction
>>> capable of interfering with operations and issuance etc.
>>>
>>>
>>> The point of the BR requirement is to create some documentation
>>> indicating
>>>
>>>> that a TSP is regularly reviewing and updating their CP/CPS.
>>>>
>>>>

> But it seems unnecessary that meta-data about a decision not to change
> the CP/CPS is stored inside the CP/CPS thereby changing it anyway.
>

If you'd followed past discussions, you'd see it's explicitly desired to
take that explicit step, because that provides public attestation of that
step in a consistent, defined, and audited manner. It's a fundamentally
necessary part of public trust, and this has been discussed rather at
length precisely because of that.

[Jakob Bohm]

It is not usually a "concern" of the CAs. Many CAs have no inherent
problem forcing all their relying parties to reread 100 pages of
legalese every few months, just like many websites don't have any
problem demanding that users reread overlong terms of service every time
they fancy a new minor adjustment to some corner or their product
portfolio.

It is a concern of relying parties subject to such CA practices or
otherwise wishing to independently check if a CPS is worthy of their
trust.

It the very nature of CA hierarchies that most relying parties do not
usually know or care about every certificate and SubCA in existence,
only about the assurances that no bad certificates (including SubCAs)
will issue.

Relying parties frequently don't have the technical ability to create
custom entries in their copy of OneCRL (or equivalent) for specific
SubCAs that they disagree with anyway.

Note that I mentioned a hypothetical CPS requiring compliance with the
future (current draft is withdrawn) FIPS 140-3, not just FIPS 140-2.
Thus above and beyond the BRs. It could similarly have required FIPS
140-2 Level 4 or additional validation to some other standard.

>
>>
>>
>>
>>
>>> Substantial changes are things that could actually affect the
>>>> willingness of parties to trust or request certificates, such as the
>>>> used validation methods, the contracting entity, the jurisdiction
>>>> capable of interfering with operations and issuance etc.
>>>>
>>>>
>>>> The point of the BR requirement is to create some documentation
>>>> indicating
>>>>
>>>>> that a TSP is regularly reviewing and updating their CP/CPS.
>>>>>
>>>>>
>> But it seems unnecessary that meta-data about a decision not to change
>> the CP/CPS is stored inside the CP/CPS thereby changing it anyway.
>>
>
> If you'd followed past discussions, you'd see it's explicitly desired to
> take that explicit step, because that provides public attestation of that
> step in a consistent, defined, and audited manner. It's a fundamentally
> necessary part of public trust, and this has been discussed rather at
> length precisely because of that.
>

I am opposing the tendency to add ever more crud and noise to the CPS
documents and their updates by redundantly requiring evermore CCADB data
etc. to be duplicated in policy documents. Not making the problem worse
by adding new such requirements is a first step towards cleaning up
the current overhead.

[Ryan Sleevi]

On Thu, Apr 5, 2018 at 4:08 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 04/04/2018 16:01, Ryan Sleevi wrote:
>

>> On Tue, Apr 3, 2018 at 11:42 AM, Jakob Bohm via dev-security-policy <
>>
>> dev-secur...@lists.mozilla.org> wrote:
>>
>> On 03/04/2018 14:57, Ryan Sleevi wrote:
>>>
>>> On Mon, Apr 2, 2018 at 9:03 PM, Jakob Bohm via dev-security-policy <
>>>> dev-secur...@lists.mozilla.org> wrote:
>>>>
>>> Relying party agreements (and subscriber agreements too) often
>>>>>>
>>>>> incorporate the CP/CPS by reference.
>>>>>
>>>>>
>>>>
>>>> Can you point out to where that's required by Mozilla policy or by the
>>>> Baseline Requirements?
>>>>
>>>>
>>>> It is not a BR, it is an observation of common practice.
>>>
>>>
>> I disagree even to the claim that it's "common" practice. There is only
>> one
>> CA that has ever raised this as a practical matter of concern, but their
>> practices are so fundamentally outmoded that it's hardly to be considered
>> the model of a good CA operation.
>>
>>

> It is not usually a "concern" of the CAs. Many CAs have no inherent
> problem forcing all their relying parties to reread 100 pages of
> legalese every few months, just like many websites don't have any
> problem demanding that users reread overlong terms of service every time
> they fancy a new minor adjustment to some corner or their product
> portfolio.
>
> It is a concern of relying parties subject to such CA practices or
> otherwise wishing to independently check if a CPS is worthy of their
> trust.
>

Thank you for clarifying your position. This does not seem to be a
meaningful objection against the policy change - that is, it's a concern
about how CAs operationalize these practices, which is not something that
Mozilla is imposing on the community. As such, I do not think this concern
is reasonable.

> But it seems unnecessary that meta-data about a decision not to change
>>> the CP/CPS is stored inside the CP/CPS thereby changing it anyway.
>>>
>>>
>> If you'd followed past discussions, you'd see it's explicitly desired to
>> take that explicit step, because that provides public attestation of that
>> step in a consistent, defined, and audited manner. It's

>> <https://maps.google.com/?q=stent,+defined,+and+audited+manner.+It's&entry=gmail&source=g>

>> a fundamentally
>> necessary part of public trust, and this has been discussed rather at
>> length precisely because of that.
>>
>>

> I am opposing the tendency to add ever more crud and noise to the CPS
> documents and their updates by redundantly requiring evermore CCADB data
> etc. to be duplicated in policy documents. Not making the problem worse
> by adding new such requirements is a first step towards cleaning up
> the current overhead.

I see. In this regard, we fundamentally disagree as to the value provided
by the community, likely in part due to misunderstandings that the policy
documents represent public commitments that the broader community relies
upon, and their consistency is in-scope for the audits (which is not
necessarily the case for addendum). As such, it is of critical necessity to
ensure that community expectations are clearly stated within a CP/CPS in
clear and unambiguous ways.

Stating it as a "problem" thus misstates the value provided, and I think is
an objection that should not be considered.

[Peter Bowen]

On Mon, Apr 2, 2018 at 5:15 PM, Wayne Thayer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>>
>> While Entrust happens to do this, as a relying party, I dislike frequent
>> updates to CP/CPS documents just for such formal changes.
>>
> This creates a huge loophole. The CP/CPS is the master set of policies the
> TSP agrees to be bound by and audited against. If a TSP doesn't include a
> new subCA certificate in the scope of their CP/CPS, then from an audit
> perspective there is effectively no policy that applies to the subCA.
> Similarly, if the TSP claims to implement a new policy but doesn't include
> it in their CP/CPS, then the audit will not cover it (unless it's a BR
> requirement that has made it into the BR audit criteria).

A CP is an optional document and may be maintained by an entity other
than the CA. For example there may be a common policy that applies to
all CAs that have a path to a certain anchor. So including the CA
list in a CP is not useful.

I also don't think that the CPS is the right place to list the CAs.
The CPS of a CA is an attribute of the CA, but the CAs are not an
attribute of a CPS. This is why I strongly suggest that the CA make a
signed binding statement that a new subCA will follow CPS X and that
the new subCA will be included in the next audit. It gets the
relationship correct.

Thanks,
Peter

[Wayne Thayer]

On Fri, Apr 6, 2018 at 3:09 PM, Peter Bowen <pzb...@gmail.com> wrote:

>
> A CP is an optional document and may be maintained by an entity other
> than the CA. For example there may be a common policy that applies to
> all CAs that have a path to a certain anchor. So including the CA
> list in a CP is not useful.
>
> I also don't think that the CPS is the right place to list the CAs.
> The CPS of a CA is an attribute of the CA, but the CAs are not an
> attribute of a CPS. This is why I strongly suggest that the CA make a
> signed binding statement that a new subCA will follow CPS X and that
> the new subCA will be included in the next audit. It gets the
> relationship correct.
>

> My definition of a binding assertion is one that the auditor is obligated
to include in the scope of their next audit. How would that be the case
here? I'm interpreting this management assertion a new document that
Mozilla would need to process but that wouldn't provide any value over the
existing requirement that the TSP provide a CPS link (or choose 'same as
parent') in the CCADB record for the new subordinate CA certificate.