[cabfpub] Reply: Ballot 188 - Clarify use of term "CA" in Baseline Requirements

Thu Mar 2 06:57:53 UTC 2017

CFCA votes NO.

发件人: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] 代表 Steve Medin via Public
发送时间: 2017年3月2日 2:08
收件人: CA/Browser Forum Public Discussion List
抄送: Steve Medin
主题: Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements

Symantec votes NO. We appreciate both the original effort and the issues raised below.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Friday, February 24, 2017 5:29 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements

Apologies for this late batch of feedback; Google is continuing to discover new details related to various misissuances by CAs that is otherwise occupying significant time.

I have some concerns with some of these provisions, even if I think on the whole, the sum is certainly where we desire to see things. Given that voting has now begun, I'm hoping to gather feedback on how a secondary ballot might correct these matters, if indeed these concerns are valid, prior to voting. Otherwise, we will need to carefully evaluate whether the risk of these issues exceeds the value the overall ballot provides.

That said, I appreciate the folks who have driven this ballot to this period, as it helps make sure we prioritize and provide the actionable feedback that might make it easier to support this or a future ballot, as below:

On Thu, Feb 16, 2017 at 11:08 AM, Ben Wilson via Public <public at cabforum.org> wrote:

*       Insert a new definition for "Externally Operated Subordinate CA" as: "A third party Subordinate CA Operator, not the Root CA Operator or its Affiliate, that is in possession or control of the Private Key associated with the Subordinate CA Certificate." 

*       Insert a new definition for "Internally Operated Subordinate CA" as: "A Subordinate CA Operator, operated by a Root CA Operator or its Affiliate, that is in possession or control of the Private Key associated with the Subordinate CA Certificate."

I think this is a potentially problematic definition, in that it relates to the scope of the operations of the audit, as well as matters below that I highlight. I'm hoping the proposers and drafters can clarify (or link to previous discussions) as to the reason in which "or its Affiliate" was introduced into these definitions, or to highlight where it was already a natural and existing part of these definitions.

In Section 4.9.1.2 (Reasons for Revoking a Subordinate CA Certificate)

Replace with:

The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:

1.      The Externally Operated Subordinate CA requests revocation in writing;
2.      The Externally Operated Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;

Can you highlight/explain why this was limited to "Externally Operated"? I cannot see why these reasonings don't apply to Internally Operated Subordinate CAs as well, due to the above introduction of "or its Affiliate".

5.      The Issuing CA is made aware that the Subordinate CA Certificate was not issued in accordance with, or that the Externally Operated Subordinate CA has not complied with these Requirements or the applicable Certificate Policy or Certification Practice Statement;

This change seems problematic in that it suggests that revocation is not required for Internally Operated Subordinate CAs to comply with the Requirements or the applicable Certificate Policy or Certification Practice Statement.

Can you clarify where the equivalent provision might already exist, or if this is adopted, where it would exist in the new document?

In Section 4.9.9 (On-line revocation/status checking availability)

Replace with:

OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:

1.      Be signed by the Private Key associated with the Root CA Certificate or the Subordinate CA Certificate that issued the Certificates whose revocation status is being checked, or
2.      Be signed by an OCSP Responder whose Certificate is issued by the Root CA Certificate or Subordinate CA Certificate that issued the Certificate whose revocation status is being checked.

In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.

One potential problem with this change is that it removes the association of subject naming which previously existed. That is, I'm wondering whether or not this opens the opportunity for an OCSP response to be signed by the same key, but to present a different byName ResponderID within the ResponseData of the BasicOCSPResponse. The language present in 6960 4.2.2.3 states "The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response.  Therefore, the information MUST correspond to the certificate that was used to sign the response.", but the change from "signed by the CA" to "signed by the Private Key" arguably leaves it ambiguous as to the associated certificate used to sign a signed OCSP response.

Put differently (since I understand this is subtle)

Imagine Private Key A is associated with Certificate 1 and Certificate 2. Certificate 1's associated Issuer Name is "Foo", Certificate 2's associated Issuer Name is "Bar". At present, I do not believe this is forbidden under the Baseline Requirements (or under this proposal). Under this model, it seems that I potentially could issue a certificate whose issuer is Certificate 1 ("Foo"), but then create an OCSP response with responderID byName of "Bar", and then sign with Private Key A.

Under 6960, this meets the definition that "the information MUST correspond to the certificate that was used to sign the response" - since Certificate 2 was 'used' to sign the response, using Certificate 1's Private Key.

Have I missed somewhere in the intersection of this Ballot, the existing Baseline Requirements, and 6960 where this scenario (as insane as it is) is prohibited?

In Section 4.9.10 (On-line revocation checking requirements)

*       Replace the first sentence with "Each CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements".
*       Replace the last sentence, which currently reads: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a 'good' status for such certificates." with: "OCSP Responders for Subordinate CA Certificates that are Technically Constrained in accordance with Section 7.1.5 are exempt from this prohibition on responding "good" to OCSP requests for the status on Certificates that have not been issued."

This changes a MUST NOT into a SHOULD NOT, and a SHOULD NOT into a MAY, although I believe unintentionally. 

The current MUST NOT is derived from two sentences in the existing language:

"If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status."

"Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates"

Combined, that makes it a MUST NOT for non-TCSCs, and SHOULD NOT for TCSCs.

With this new language, it becomes

"If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status."

"OCSP Responders for Subordinate CA Certificates that are Technically Constrained in accordance with Section 7.1.5 are exempt from this prohibition on responding "good" to OCSP requests for the status on Certificates that have not been issued."

By removing the MUST NOT, non-existent certs from non-TCSCs fall into the first clause, which is SHOULD NOT.

Further, by stating 'exempt from this prohibition', for TCSCs, this moves the SHOULD NOT into nothingness (effectively, a 'MAY')

As per RFC 2119, "SHOULD NOT" is equivalent to "NOT RECOMMENDED (but allowed)", while MUST NOT (aka "SHALL NOT") means an absolute prohibition.

Was this intentional?

In Section 5.4.1 (Types of events recorded)

Replace subsections 1 and 2 in the second paragraph of so that they read:

The CA SHALL record at least the following events:

1. Private Key lifecycle management events for the Root CA Certificate or Subordinate CA Certificate, including:

Does this mean items A and B are removed, or was it proposed to leave them in place? The language is ambiguous, given the text below.

2. Certificate lifecycle management events for the Root CA Certificate, Subordinate CA Certificate, and Subscriber Certificates, including:

a.      Certificate requests, renewal, and re-key requests, and revocation;
b.      All verification activities stipulated in these Requirements and the CA's Certification Practice Statement;
c.      Date, time, phone number used, persons spoken to, and end results of verification telephone calls;
d.      Acceptance and rejection of certificate requests; Frequency of Processing Log

Was this a typo? Can you explain what "Frequency of processing log" is meant to be in this context?

e.      Issuance of Certificates; and
f.      Generation of Certificate Revocation Lists and OCSP entries.

In Section 6.1.1.1 (CA Key Pair Generation)

Replace the first two paragraphs with the following:

For a Key Pair generated to be associated with either (i) a Root CA Certificate or (ii) a Subordinate CA Certificate to be operated by an Externally Operated Subordinate CA, the CA SHALL:

1.      prepare and follow a Key Generation Script,
2.      have a Qualified Auditor witness the Key Pair generation process or record a video of the entire Key Pair generation process, and
3.      have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.

For a Key Pair generated to be associated with a Subordinate CA Certificate to be operated by the Root CA Operator or its Affiliates, the CA SHOULD:

Why does this not use the term Internally Operated Subordinate CA? It would seem that this would be semantically accurate and correspond to the (ii) above to completely cover the set of Sub CA Certificates.

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

In all cases, the CA SHALL:

1.      generate the Key in a physically secured environment as described in the CA's Certificate Policy and/or Certification Practice Statement;
2.      generate the Key using personnel in trusted roles under the principles of multiple person control and split knowledge;
3.      generate the Key within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's Certificate Policy and/or Certification Practice Statement;
4.      log its Key generation activities; and
5.      maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

This again is a subtle but important change. Under the existing language, keys plural is used, to indicate that it is a Key Pair - of Public and Private keys. The change to "the Key" leaves it ambiguous as to whether this was meant to be "the Key Pair", "the Public Key", or "the Private Key".

The fact that 5 specifically states Private Key, but 1-4 does not, further amplifies this confusion as to whether the omission was intentional.

Change the title of Section 6.1.7 as "Key usage purposes (as per X.509 v3 key usage field)"

It is not a field. It is an extension.

In Section 6.2.6 (Private key transfer into or from a cryptographic module)

Replace with:

If the Issuing CA generated the Private Key on behalf of an Externally Operated Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Externally Operated Subordinate CA.

If the Issuing CA becomes aware that an Externally Operated Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Externally Operated Subordinate CA, then the Issuing CA SHALL revoke all Subordinate CA Certificates that include the Public Key corresponding to the communicated Private Key.

Similarly, this creates the scenario where an Internally Operated Subordinate CA is operated with different infrastructure than the audit, at least based on my current understanding about the scope of the engagement not necessarily covering the "Affiliates" portion.

Is there a reason this was reduced in scope and/or can you highlight where the scope is functionally equivalent to the existing text?

In Section 7.1.5 (Name Constraints)

Replace the last paragraph with:

If the Subordinate CA Operator is not allowed to issue certificates with dNSNames, then the Subordinate CA Certificate MUST include a zero-length dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate MUST include at least one dNSName in permittedSubtrees.

The preceding paragraph states "Subordinate CA Certificate is not allowed to issue certificates". This change introduces an asymmetry between the two. Was this intentional? Is it significant?

In Section 8.1 (Frequency or circumstances of assessment)

Replace the first paragraph with:

CA Certificates MUST either be (a) Technically Constrained in line with section 7.1.5 and be audited in line with section 8.7 only, or (b) be fully audited in line with all requirements of this section (8). A Certificate is deemed capable of being used to issue certificates for server authentication if it contains an X.509v3 basicConstraints extension with the CA boolean set to true and has no EKU, the id-kp-anyExtendedKeyUsage [RFC5280] EKU, or the id-kp-serverAuth [RFC5280] EKU.

Is the CA Certificate what is audited? My understanding is that the CP/CPS of the Organization are audited, which includes the operational security of the Private Key and what it signs/issues. I realize this is somewhat of a parallel bug to the existing text, but I'm surprised that the WG did not suggest this should be resolved.

In Section 8.7 (Self-Audits)

Replace the last paragraph with:

During the period in which a Technically Constrained Externally Operated Subordinate CA issues Certificates, the Issuing CA SHALL monitor adherence to the Issuing CA's Certificate Policy and/or Certification Practice Statement and the Externally Operated Subordinate CA's Certificate Policy and/or Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Externally Operated Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA SHALL ensure adherence to all applicable Certificate Policies and/or Certification Practice Statements.

Much like several other changes mentioned above, this limits the scope of the existing text from "internal or external" to simply "external". Thus it reduces the scope of examination for internally operated subordinate CA certificates, which may be operated by an Afilliate under a distinct CP/CPS. Is that fair to say?

In Section 9.6.1 (CA representations and warranties)

Replace the last paragraph with:

The Root CA Operator SHALL be responsible for the performance and warranties of its Externally Operated Subordinate CAs, for the Externally Operated Subordinate CAs' compliance with these Requirements, and for all liabilities and indemnification obligations of the Externally Operated Subordinate CAs under these Requirements, as if the Root CA Operator were the Externally Operated Subordinate CA issuing the Certificates.

Yet another asymmetry between the existing text that appears to introduce a loophole with respect to 'internally operated' subordinate CAs. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170302/503958ed/attachment-0002.html>