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

[Peter Bowen]

> On Feb 28, 2017, at 11:36 PM, Dimitris Zacharopoulos <jimmy at it.auth.gr> wrote:
> 
> On 1/3/2017 7:16 πμ, Peter Bowen wrote:
>> I realize this is super late feedback, but after doing an internal review of this ballot, I think it actually makes a key issue worse rather than solving it.
>> 
>> According to the ballot, "Root CA Certificate” is now defined as "A CA Certificate in which the Public Key has been digitally signed by its corresponding Private Key.”  This basically means that every self-signed certificate is now considered a Root CA Certificate.  This definition is then used in section 6.1.1.1: "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:” and in 6.1.7 when discussing the limitations of key usage.
>> 
>> This effectively means that any CA that wants to create a self-signed certificate, even if it is intended to be used as a subordinate CA, must follow the key generation procedure where they must have an auditor witness or write a report based on watching the video tape.  It also means that any key found in a self-signed certificate cannot be used to sign end-entity certificates.  
>> 
>> Given the clear focus on compliance to specifications as written, I think that this is a bug that can easily bite many CAs.  I know I don’t want to be restricted using a CA for issuing server certificates just because I happened to create a self-signed certificate for that CA.
>> 
>> Thanks,
>> Peter
>> 
> 
> Hi Peter,
> 
> The original (currently effective) BR language is:
> 
> "Root Certificate:  The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs.”

Add to that "Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates."

> I think, the concern you raise already exists in the current BRs. The current 6.1.1.1 makes things even worse: "For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:"
> 
> It mixes up Root CA Key Pairs (an organization doesn't have key pairs) and we also get the Affiliate of the Root CA in there as well.

I don’t want to rehash many WG calls, but it is clear that most usages of “CA” in the BRs today mean a single issuer (that is a specific Name and Public Key).  The WG said it wanted to make as few changes possible to the BRs to clarify when it was meant to be “Name+Key” and when it meant to be “CA Operator” (which I note has become a term with this ballot, albeit with adjectives such as “Root” prepended).  Instead we ended up with changes all over the BRs.


> The new 6.1.1.1 would replace the first sentence as "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”.

I think 6.1.7 is the more worrying part.  This was added after I stopped attending the calls and I did not catch the interplay until now that will cause browsers to be able to use the existence of a self-signed certificate as evidence of mis-issuance.  Given that some browser’s current state is that anything that doesn’t comply with the letter of the BRs is mis-issuance, I don’t think we should be adopting anything that causes existing practices with no security concerns to become mis-issuance.

> An improvement to address your valid concern would be to combine the "Root Certificate" with the "Root CA Operator" definition which is "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".
> 
> Perhaps changing the "Root CA Certificate" as "A CA Certificate in which the Public Key has been digitally signed by its corresponding Private Key with the intention to be distributed by Application Software Suppliers as a trust anchor". Would that work? 

That might work.  But it doesn’t solve the other half of the issue; sometimes non-self-signed certificates are distributed as trust anchors.

This ballot started as a very straight forward issue: for a very small number of places, we care whether multiple issuers are operated by the same organization.  How do we differentiate that from talking about a single issuer?

I appreciate all the work you and Ben put into this, but I think the resulting ballot opens holes that I don’t want to be used against me.

Thanks,
Peter