[cabfpub] Proposed addition to BRs allowing issuance of <2048

[Ryan Sleevi]

On Thu, Jun 13, 2013 at 11:22 AM, Rick Andrews
<Rick_Andrews at symantec.com> wrote:
> For those who were not in attendance at the CABF meeting in Munich, I'd like to offer some background about this proposal.
>
> I explained that we CAs have always maintained a small set of roots from which we issued all SSL certs; those for "web pki" (where the client is a human using a browser) and "non-web pki" (where the client is a phone or a PCI device or some other non-browser app). Indeed, even a year or two ago, no one talked about "web pki". But now in 2013 it makes a lot of sense to keep separate the roots that CAs use for web pki and non-web pki. We're not there now, not even close. For the CABF to now impose restrictions on what CAs do for non-browser clients is unfair to those customers.

I don't view it as the CA/B Forum imposing requirements on non-browser
clients - merely, we're imposing requirements on browser clients. For
organizations that kept their PKI separated by purposes - such as
keeping distinct roots for purposes such as Document Signing, are not
at all affected by these changes.

Since it's clear that on the Internet, legacy never dies, perhaps it's
more reasonable to discuss paths going forward.

For example, cutting a 'new' root that will have all certificates
underneath it comply with the Baseline Requirements, and use that root
for inclusion in all trust anchor stores going forward. After all, the
Baseline Requirements are only required by Trust Stores for Roots
included in their program.

For your legacy clients that may wish to interop with both BR and
non-BR sites, you can cross-sign your BR-compliant root with your
'legacy' root(s).

I don't see this as being much different from some of the other
transitions that have happened, such as to stronger keys or hash
algorithms, so we know this process works. Your non-BR compliant certs
can be issued off a PKI path fully separate from your BR root, while
still chaining to your legacy root. This will also allow you the
opportunity to begin phasing them into distinct PKIs, if you so wish.

>
> In the future, we will attempt to move non-browser applications like this to non-browser roots, but for now they are very much intertwined.  It was agreed that I would draft a ballot to add an exception to the BRs for this purpose, just as we have an exception in the BRs to allow issuance from the root. That exception, I might add, is predominantly for non-web pki applications, because all modern browsers can handle chained certs.
>
> -Rick
>