[cabfpub] Terminology/Style question
sleevi at google.com
Thu Apr 6 07:48:44 MST 2017
On Sun, Apr 2, 2017 at 8:39 PM, Peter Bowen via Public <public at cabforum.org>
> I’m trying to draft a proposed revision to the BRs and ran into a
> terminology/style question.
> 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.
> A Certification Authority (CA) has a single Distinguished Name (DN) and
> one or more Key Pairs. Therefore a CA has at least one Private Key and
> at least one Public Key and may have multiple Private Keys and Public Keys.
> Which of the following is preferred:
> A Signature is created using a Private Key. (It is not created _by_ a
> Private Key.)
> 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.
> 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.
> A Signature is the result of signing data using a Private Key. (It is not
> signed _by_ a Private Key.)
> 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.
> 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
> The difference been the A and B versions with whether or not to use a
> possessive noun with an inanimate object (the CA).
> 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?
Thanks for tackling this, Peter, and thanks for checking in on the list
early on :)
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.
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.
Support for this is as follows:
* 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"
* RFC 6960, Section 2.7, "If an OCSP responder knows that a particular CA's
private key has been compromised"
* RFC 6960, Section 4.1.1, "issuerKeyHash is the hash of the issuer's
* RFC 6960, Section 4.1.2, "The primary reason to use the hash of the CA's
* 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
* RFC 6960, Section 4.2.1, "KeyHash ::= OCTET STRING -- SHA-1 hash of the
responder's public key"
* RFC 6960, Section 184.108.40.206, "... and the certificate being checked for
revocation were signed by the same key."
* RFC 5280, Section 3.2, "... the public key of the CA that signed the
* RFC 5280, Section 3.2, "... signed by one CA, and zero or more additional
certificates of CAs signed by other CAs."
* 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."
* RFC 5280, Section 220.127.116.11, "The issuer field identifies the entity that
has signed and issued the certificate."
* RFC 5280, Section 5.2.5, "The CRL is signed using the CRL issuer's
* RFC 5280, Section 8, "On a larger scale, compromise of a CA's private
signing key may have a catastrophic effect"
* RFC 5280, Section 8, "Loss of a CA's private signing key may also be
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public