[cabfpub] Terminology/Style question

Peter Bowen pzb at amzn.com
Tue Apr 4 07:20:18 MST 2017


> On Apr 4, 2017, at 1:19 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr> wrote:
> 
> On 4/4/2017 8:42 πμ, Peter Bowen wrote:
>> 
>>> On Apr 2, 2017, at 11:30 PM, Dimitris Zacharopoulos via Public <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>>> 
>>> On 3/4/2017 3:39 πμ, Peter Bowen via Public wrote:
>>>> I’m trying to draft a proposed revision to the BRs and ran into a terminology/style question.
>>>> 
>>>> Given:
>>>> 
>>>> 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)[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.
>>>> 
>>>> 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 Key.
>>>> 
>>>> 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,
>>>> Peter
>>> 
>>> In these examples (1A, 1B, 2A, 2B), as I read it, "issued by a CA" refers to the "Issuing CA" (materialized in a CA Certificate with a specific subject DN which is then used in the "Issuer" field of issued Certificates) and not the "CA" as an organization. This actually reflects the language of X.509 and RFC5280 which basically describe CAs as "Issuing CAs" rather than organizations in control of one or more Issuing CAs, as the BRs often suggest. 
>> 
>> I was rather trying to avoid the CA-as-issuer vs CA-as-organization distinction in these examples.  The primary reason I raised the 1:1 mapping (or lack thereof) is to explain why it is _the_ Distinguished Name vs _a_ Distinguished Name.
>> 
>>> Perhaps before answering your questions, we should probably agree on this: If we have 
>>> a CA Certificate with subject DN "C=XX, O=Example Org, CN=Issuing CA", Certificate Serial Number A and keypair A
>>> a CA Certificate with subject DN "C=XX, O=Example Org, CN=Issuing CA", Certificate Serial Number B and and keypair B
>>> are we talking about the same "Issuing CA"?
>>> Note1: You will notice that the "Certificate Serial Number" is not the serialNumber field in the subject DN.
>>> 
>>> Note2: In order to achieve having exactly the same DN in CA Certificates and different keys, you probably need to use different Root hierarchies otherwise you would probably violate section 4.1.2.6 of RFC5280 that require unique DN under one Issuing CA. It the Issuing CA is a Root CA, then the issued CA Certificates under this Root should have unique DNs. Does this make sense
>>> 
>> A single issuing CA can have multiple keys if it rotates keys.  There is at least one public CA that has done this.
> 
> By keeping exactly the same DN? Does this align with 4.1.2.6 of RFC 5280 that require unique DNs under one Issuing CA (probably a Root CA in this case)

I’m not sure what part of 4.1.2.6 says this is not allowed.  In fact it says: "A CA MAY issue more than one certificate with the same DN to the same subject entity.”

Consider a situation where CAs are licensed by a central authority.  A single legal entity may operate multiple CAs.  This sort of requirement exists in other industries; for example the requirement in many US states that each restaurant kitchen be inspected and licensed even if a single company owns multiple kitchens.  In the case of a licensed CA, it is clear that it is a specific subject entity.  Therefore issuing more than multiple certificates with the same DN to that entity with different key pairs is fine.

>> 
>> While not mentioned, two different Issuing CAs can have the same key pair.  
> 
> I don't remember reading any requirement that prevents this.
> 
>> 
>> So, to answer your question: I would say those are both the same “Issuing CA”.  
> 
> If two CA Certificates have exactly the same DN as in the example above, we agree that we are talking about the same "Issuing CA". However, we need to understand if the re-key process of an Issuing CA is in accordance with RFC 5280 since this is not a "self-issued certificate" that 5280 explicitly allows for keeping the same DN.

As long as it is the same subject entity, then you can re-key.

Consider certificates issued with the subject DN: CN=*.google.com <http://google.com/>, O=Google Inc, L=Mountain View, ST=California, C=US.  crt.sh shows many many with this DN with different keys: https://crt.sh/?cn=*.google.com&dir=^&sort=2 <https://crt.sh/?cn=*.google.com&dir=%5E&sort=2>  There are millions more similar cases where the CA has “renewed” a certificate with a new key or "rekeyed" a certificate.  Are you saying that CAs are somehow different from other entities?

Thanks,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170404/762b5454/attachment.html>


More information about the Public mailing list