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

[Ryan Sleevi]

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/20170224/809a48a8/attachment-0003.html>