I will try to think up some use cases as this doesn’t come up that often. I am not saying that these are applicable to Entrust. However, I do know that since we need to support many clients and browsers which are continually changing and updating policies, there is a chance that a CA may need some maintenance for best browser ubiquity.
So some use cases could be certificate expiry, lengthen CA lifetime, add in AIA, mistakenly sign the certificate with the wrong hash, mistakenly sign the certificate with the wrong pathlength, sign the CA by a different CA, etc. Please note we have always supported CNs in subordinate CAs. Our software does not support unique CNs for subordinate CA certificates. I am also open to discuss bad results and security issues, but am hoping we can discuss those as a separate discussion. Thanks, Bruce. From: Ryan Sleevi [mailto:[email protected]] Sent: Wednesday, April 26, 2017 2:20 PM To: Bruce Morton <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; Gervase Markham <[email protected]> Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 199 - Require commonName in Root and Intermediate Certificates On Wed, Apr 26, 2017 at 2:17 PM, Bruce Morton <[email protected]<mailto:[email protected]>> wrote: 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. Right, apologies I wasn't clearer - what's the use case for 'renewing' an intermediate? What functionality are you achieving versus, say, naming it as a new intermediate? 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. Right, that's the bit of unnecessary complexity that I think is harmful (and can think of a variety of situations where it's caused a Bad Result for Security).
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
