> On Feb 28, 2017, at 11:36 PM, Dimitris Zacharopoulos <[email protected]> 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 _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
