[cabfpub] [EXTERNAL]Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Bruce Morton]

Our software does not support change the identity of a CA when you issue it a new certificate. I assume that this is similar issuing passports. When an individual gets a passport they put their identity in the passport, when they renew their passport, they use the same identity.

We do use CNs for subordinate CAs and the CNs are unique per CA. We do not use unique CNs per CA certificate.

Please also note that the unique CN is also for a unique private key.

Bruce.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, April 26, 2017 1:53 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Gervase Markham <gerv at mozilla.org>; Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 199 - Require commonName in Root and Intermediate Certificates



On Wed, Apr 26, 2017 at 1:25 PM, Bruce Morton via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
Hi Gerv,

I'm also confused with the proposal, so wanted to discuss our methodology.

From our point of view, we create a subordinate certification authority and give this CA a distinguished name. We use the CN to give the CA a unique identifier, so that the common name will not be mixed up with any other subordinate CAs.

Then we need to give the subordinate CA trust, so we issue it a subordinate CA certificate from a root CA. The subordinate CA certificate will have the same distinguished name.

All fantastic so far...

If for some reason we need to issue the subordinate CA another CA certificate (e.g., the original certificate expires), then the new certificate will have the identical subject name as the original.

Could you explain the use cases here? This introduces a significant amount of complexity (ergo: risk) into the Web PKI. The situation you described - the original expiring - should not require the reissuance with the same name, because no leaf certificate should have exceeded the validity window of the intermediate. As you approach the intermediates expiration, minimally, you could/should have begun transitioning off of it.

What other use cases exist to imbue this? I can certainly understand situations like "add additional extensions", but there again, a new name (for new certificates) could imbue the new powers and capabilities. The only reason to reissue the existing certificate is to retroactively imbue the extant certificates with new capabilities, and I'm curious when that situation is necessary.

Otherwise, it should hopefully seem uncontroversial to identify a new common name for this new certificate with new capabilities (whether the validity period or the extension-based capability). But I'm interested to learn why CAs do so, and if there's any particular need/advantage over simply issuing a new intermediate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170426/9fddd9f9/attachment-0002.html>