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

Dimitris Zacharopoulos jimmy at it.auth.gr
Mon Feb 27 18:52:43 UTC 2017


Hello Ryan,

Thank you for the thorough review. I will also try to answer (inline) as
many as I can. We can and should definitely continue improving the BRs
to remove ambiguous language in a secondary ballot.


On 25/2/2017 12:29 πμ, Ryan Sleevi via Public wrote:
> 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.

Peter already provided some clarity for this. The "Affiliate" language
was not introduced by this ballot. It was already mentioned in several
sections of the BRs (6.1.1.1 "CA Key Pair Generation", 6.1.2 "Private
Key Delivery to Subscriber", 6.2.6 "Private Key Transfer into or from a
Cryptographic Module", 7.1.2.2 "Subordinate CA Certificate" and  7.1.6.3
"Subordinate CA Certificates").

Since this ballot was only about providing clarity in some terms, we did
not propose any policy changes. The BRs have a different policy a) when
a Subordinate CA is operated by the same entity as the Root CA or an
Affiliate, b) when a Subordinate CA is operated by a different entity
that is not an Affiliate of the entity that controls the Root CA. We
called the first case an "Internally Operated Subordinate CA" and the
second case an "Externally Operated Subordinate CA" to make things more
clear. As the BRs are currently written, we need two different
definitions for Subordinate CAs because of the different requirements.


>
>     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?

Peter's answer should cover this. Your follow-up questions challenge the
fact that the current BRs treat Root Operator's "Affiliates" in a
different way than the non-Affiliates but this is a policy matter and
should be discussed separately. In any case, I don't think it changes
the fact that all Subordinate CAs (whether internally or externally
operated) need to be audited. In the case of Internally Operated
Subordinate CAs, the audit might be covered in the Root Operator audit,
and this information should be included in the audit scope.

>  
>
>     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?

The current BRs, say:

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

1. Be signed by the CA that issued the Certificates whose revocation
status is being checked, or

2. Be signed by an OCSP Responder whose Certificate is signed by the CA
that issued the Certificate whose

revocation status is being checked.


After several discussions within the WG, it was agreed that the most
accurate technical language is that "Private Keys sign Certificates".
Certificates, don't sign Certificates. So, we ended up saying "Private
keys associated with Root Certificate or Subordinate CA Certificate". I
believe numbered items 1. and 2. of the ballot proposal, even though
they have longer sentences, make it clear that the OCSP Responses come
from "the Root CA Certificate or Subordinate CA Certificate that issued
the Certificate whose revocation status is being checked" or an OCSP
responder Certificate issued by "the Root CA Certificate or Subordinate
CA Certificate that issued the Certificate whose revocation status is
being checked".

Section 4.2.2.3 in RFC6960, say that the basic response type contains
"/either the name of the responder or a hash of the responder's public
key as the ResponderID/"

So, according to your example, if the ResponderID was the hash of the
Subordinate CA Certificate's public key, it would not be prohibited even
though that key would be included in two or more Subordinate CA
Certificates. Perhaps the multiple CA Certificates with the same
key-pair scenario is not entirely addressed. We could update the BRs to
specifically include language for the ResponderID information, if you
think people would be puzzled about what information should be included
in that field.


>  
>
>     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?

This specific change was addressed during the discussion phase
(https://www.mail-archive.com/public@cabforum.org/msg02652.html).

>
>  
>
>     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.

As Peter said, A and B are not removed.

>  
>
>
>     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?

A typo indeed. It is clear in the red-lined version.

>  
>
>     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.

It would be clearer if we used the term "Internally Operated Subordinate
CA" and maybe shorten the sentence since this language is repeating
what's already in the definition of an Internally Operated Subordinate
CA. Noted for future improvement.

>  
>
>
>     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.

The current BRs use the language "generate the keys" for 1-3 and "log
its CA key generation..." for 4. The words "key" and "keys" are in
lowercase. Since the entire section 6.1.1.1 discusses about "CA Key Pair
Generation", IMO it should be clear enough. However, it makes sense to
replace the word "Key" with "Key Pair" to make it even clearer.

>  
>
>     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.

Correct. It should be "Key usage purposes (as per X.509 v3 key usage
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?

The reasoning was the same as with section 4.9.1.2. The Root Operator is
responsible for all Private Keys associated with Internally Operated
Subordinate CA Certificates. Note that the first paragraph of 6.2.6
starts with "If the Issuing CA generated the Private Key on behalf
of...". When we discussed about this in the Policy WG, we said that the
Root Operator should never need to generate a CA Private Key on behalf
of an Internally Operated Subordinate CA because it is considered the
same organization.

>  
>
>     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?

Correct. We missed that. We should replace it with the same language "If
the Subordinate CA Operator is not allowed...."

>  
>
>     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.
>

It should also be resolved. Noted for future improvement.

>
>     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?

The rest of the section remains the same. It doesn't remove the
obligation for the CA (this covers ALL CA organizations, including
affiliates) to perform quarterly self-audits.

The reasoning for changing the last paragraph to only "Externally
Operated Subordinate CAs", was that the language dictates that the
"Issuing CA SHALL monitor adherence...". We thought that it doesn't make
sense to have one organization monitor adherence to it's own
organization. It is already required for the Root CA Operator to adhere
to its own CP and/or CPS (that must cover all Internally Operated
Subordinate CAs), check against a randomly selected sample, etc, as
specified in the first paragraph of section 8.7.


>  
>
>     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.

Here are the two definitions introduced:

*Root CA Operator:*  The top-level Certification Authority (i.e. an
organization) whose CA Certificate (or associated Public Key) is
distributed by Application Software Suppliers as a trust anchor

*Internally Operated Subordinate CA:* 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

The Root CA Operator is already -by definition- responsible for all
actions related to its Internally Operated Subordinate CAs and
Affiliates. The "extra" warranties of the last paragraph of section
9.6.1 IMO, refer to other entities (i.e. organizations) that are
non-Affiliates with the Issuing CA. It is there to state that if a CA
trusts a "stranger" (an Externally Operated Subordinate CA) to control a
CA Key, the Issuing CA will be ultimately responsible for any wrongdoing
of that "stranger".

If any other member of the Policy Review WG, or another CA/B Forum
member, would like to offer better responses to Ryan's concerns, please
feel free to do so.

Voting ends on Thursday March 2 at 22:00 UTC but the remaining issues
will be tracked and addressed in a future ballot.


Best regards,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170227/a2c9bad8/attachment-0003.html>


More information about the Public mailing list