I know we are not talking cross-certificates here, but if you were, sometimes a cross-certificate is issued for a time period less than the subject CA’s private key usage so certificates subordinate to the intermediate CA may actually have a lifetime longer than one cert issued to it, even though the subscriber certs do expire before the intermediate CA’s expiration..
I’m wondering about the use case where a new Root while applying to various trust stores asks for a cross-certificate from someone already trusted while its application is being processed. If the process takes longer than anticipated, they may ask for a second cross-cert from the trusted root to carry them through the extended period. Another example might be an update to accommodate changes in name constraints or policies allowed for the subordinate CA. Maybe a customer enterprise has been bought or merged and rather than needing to establish a new CA they want to continue using the same CA but allow it to issue to the new name of the customer. From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Wednesday, April 26, 2017 1:53 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Ryan Sleevi <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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. NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
