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

Wed Mar 1 18:08:16 UTC 2017

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 
<mailto: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/20170301/48b80766/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5744 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170301/48b80766/attachment-0001.p7s>