[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Wayne Thayer]

>- What to do when names are added or removed, such as for UCC certificates. Under which version of the BR should these names be validated?

The proposal states that all BR requirements must be met other than the duration

>- When names are added/removed for keys with legacy cryptographic algorithms (eg: RSA < 2048 bits in an EE cert issued prior to 2013-12-31), is this permissible or must the customer *also* rekey?

Must rekey.  The proposal states that all BR requirements must be met other than the duration

>- If requirements for subject names change / validation of data, is it valid to issue a certificate with the same Subject?

Again, this is a very narrow exception that addresses the sunsetting of certs with lifetimes greater than 39 months.  It doesn't allow anything else to be bypassed.

>- How can these certificates be distinguished from 'new' certificates?
>As clearly practiced by CAs that are performing this, presently, the notAfter is set to the date of issuance (suggesting that CAs recognize they are, indeed, issuing new certs). This makes it difficult, if not impossible, for UAs to perform programatic enforcements based on BR effective dates.

We could retain the original issuance date, but I recall hearing objections to that.

>Regardless of what is adopted in this group or for the BRs, I do want to highlight that browsers may choose to reject such certificates as being untrustworthy.

If that's the case, then there's no sense in moving forward with this.  I doubt that any CA wants to issue certs that are rejected as untrustworthy in any browser.