<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 2, 2017 at 8:39 PM, Peter Bowen via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’m trying to draft a proposed revision to the BRs and ran into a terminology/style question.<br>
<br>
Given:<br>
<br>
Key Pair: a set of cryptographic keys, usable with an asymmetric key cryptographic algorithm, consisting of a Private Key, a Public Key, and associated parameters. For any given Private Key and parameter set, there exists exactly one associated Public Key.<br>
<br>
A Certification Authority (CA) has a single Distinguished Name (DN)[1] and one or more Key Pairs[2].  Therefore a CA has at least one Private Key and at least one Public Key and may have multiple Private Keys and Public Keys.<br>
<br>
Which of the following is preferred:<br>
<br>
A Signature is created using a Private Key.  (It is not created _by_ a Private Key.)<br>
1A) A Certificate is issued by a CA when a Signature is created over a TBSCertificate with the Distinguished Name of a CA in the Issuer component using a Private Key of the CA.<br>
1B) A Certificate is issued by a CA when a Signature is created over a TBSCertificate with the CA’s Distinguished Name in the Issuer component using the CA’s Private Key.<br>
<br>
A Signature is the result of signing data using a Private Key. (It is not signed _by_ a Private Key.)<br>
2A) A Certificate is issued by a CA when a TBSCertificate with the Distinguished Name of a CA in the Issuer component is signed using a Private Key of the CA.<br>
2B) A Certificate is issued by a CA when a TBSCertificate with the CA’s Distinguished Name in the Issuer component is signed using the CA’s Private Key.<br>
<br>
The difference been the A and B versions with whether or not to use a possessive noun with an inanimate object (the CA).<br>
<br>
I would like to use one of these consistently and follow the style for other cases.  Any one care to suggest which should be used?<br>
<br>
Thanks,<br>
Peter<br></blockquote><div><br></div><div>Thanks for tackling this, Peter, and thanks for checking in on the list early on :)</div><div><br></div><div>My own preference is biased towards the IETF set of documents (5280 & 6960 particularly). Despite the IETF process being one of humans, and easily flawed (as we saw with CAA discussions), it's useful to take advantage of any consistency we can with those sets of documents.</div><div><br></div><div>Because of that, I defer to the possessive, and to the act of signing as a verb. That is, of these, 2B is the most preferable.</div><div><br></div><div>Support for this is as follows:</div><div>* RFC 6960, Section 2.6, "The key that sign's a certificate's status information need not be the same key that signed the certificate"</div><div>* RFC 6960, Section 2.7, "If an OCSP responder knows that a particular CA's private key has been compromised"</div><div>* RFC 6960, Section 4.1.1, "issuerKeyHash is the hash of the issuer's public key"</div><div>* RFC 6960, Section 4.1.2, "The primary reason to use the hash of the CA's public key"</div><div>* RFC 6960, Section 4.1.2, "Two CAs will never, however, have the same public key unless the CAs either explicitly decided to share _their_ private key or the key of one of the CAs was compromised" (emphasis added on possessive)</div><div>* RFC 6960, Section 4.2.1, "KeyHash ::= OCTET STRING -- SHA-1 hash of the responder's public key"</div><div>* RFC 6960, Section 4.2.2.2, "... and the certificate being checked for revocation were signed by the same key."</div><div>* RFC 5280, Section 3.2, "... the public key of the CA that signed the certificate"</div><div>* RFC 5280, Section 3.2, "... signed by one CA, and zero or more additional certificates of CAs signed by other CAs."</div><div>* RFC 5280, Section 3.3, "This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time-stamped list identifying revoked certificates that is signed by a CA or CRL issuer and made freely available in a public repository."</div><div>* RFC 5280, Section 4.1.2.4, "The issuer field identifies the entity that has signed and issued the certificate."</div><div>* RFC 5280, Section 5.2.5, "The CRL is signed using the CRL issuer's private key."</div><div>* RFC 5280, Section 8, "On a larger scale, compromise of a CA's private signing key may have a catastrophic effect"</div><div>* RFC 5280, Section 8, "Loss of a CA's private signing key may also be problematic."</div><div><br></div></div></div></div>