[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Ryan Sleevi]

Some example issues on why I think this is may be premature, or at
least warrant significant thought from CAs that see these practices as
acceptable:

- 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?
- 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?
- If requirements for subject names change / validation of data, is it
valid to issue a certificate with the same Subject?
- 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.

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. The simplest heuristic for this would be
examining the notBefore and notAfter date, rejecting certificates with
non-BR compliant validity periods, among other things. The further
implications this has on other elements of the certificates - ranging
from appropriate EKUs, name validation practices, the representation
of subject information - lead one to think this would not be a motion
we could support.

Cheers,


On Thu, Aug 8, 2013 at 3:36 PM, Wayne Thayer <wthayer at godaddy.com> wrote:
> This issue was discussed on the call this morning, resulting in a couple of
> actions. First off, Ben and Jeremy are going to propose language for a new
> required Subscriber Agreement clause that permits retroactive changes to the
> terms based on new requirements from browsers or audits as suggested by
> Robin.
>
>
>
> The other action item was to recirculate the proposed language to carve out
> an exception for reissuing/rekeying certificates longer than the BR imposed
> 60 or 39 months in cases where the expiration date of the certificate
> doesn’t change. This would define the terms “rekey” and “reissue”, and
> create an exception for rekeys and changes to SANs on 4 & 5 year certs after
> Apr 1, 2015. It requires CAs to follow all other aspects of the BRs
> including key type and length when rekeying/ reissuing a certificate. Ryan
> asked that everyone carefully consider the implications of this and raise
> any potential problems now.  This proposal already has two endorsers and I
> plan to move it to a ballot next week, pending the results of these
> discussions.
>
>
>
> Motion Begins
>
>
>
> Add the following definitions to section 4:
>
>
>
> Reissue – the act of issuing a new Certificate with the identical Subject
> and Expiry Date as a previously issued and valid Certificate, to the same
> Subscriber as the original Certificate.
>
>
>
> Rekey – see Reissue.
>
>
>
> Add section 9.4.1 Reissuance
>
>
>
> Reissued Certificates MUST conform to all requirements set forth in this
> document for newly issued Certificates, including those in sections 9.4
> (Validity Period) and 11.3 (Age of Certificate Data).
>
>
>
> Notwithstanding the requirements set forth in the preceding paragraph,
> Certificates issued prior to the effective date of this document having a
> Validity Period greater than 60 months, AND; Certificates issued prior to 1
> April 2015, having a Validity Period greater than 39 months; MAY be Reissued
> with a Validity Period exceeding these requirements but not to exceed the
> Valid To date of the originally issued certificate, provided that the
> Reissued Certificate is otherwise in full compliance with all other
> technical and verification requirements contained in this document.
>
>
>
> Motion Ends
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>