[cabfpub] Proposed addition to BRs allowing issuance of <2048
Rick_Andrews at symantec.com
Thu Jun 13 18:22:02 UTC 2013
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.
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.
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Yngve N. Pettersen
> Sent: Tuesday, June 11, 2013 2:31 PM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Proposed addition to BRs allowing issuance of
> On Tue, 11 Jun 2013 22:56:07 +0200, Rick Andrews
> <Rick_Andrews at symantec.com> wrote:
> > As discussed in our face-to-face meeting in Munich, I propose the
> > following addition to the BRs. I believe there was consensus to allow
> > issuance of <2048 bit end entity certs in certain specific cases,
> > as the BRs currently allow for issuance directly from the root for
> > certain specific cases. Please see attached pdf.
> Personally, I don't like this proposal, and think it should not be
> However, if it should be approved I suggest the following improvements:
> - The allowed purposes need to be defined in a stricter fashion,
> particularly #1 (infrastructure), which IMO can be read to allow 1024
> OCSP for 2048 bit issuers.
> - There should be an absolute sunset for this exception, preferably
> a list of uses and reasoning why they deserve an exception, or there
> should be a good explanation for why not.
> - Number #3a should specify a deployment date that is well before
> year, at least before 2008, preferably 2005. The current phrasing could
> allow somebody to claim and be granted an exception for a system first
> deployed in the past couple of years (or this year, if "Effective Date"
> refers to the current year).
> My preference would also be that the customer is required to migrate
> application that can be upgraded to a different server that have a
> bit certificate. That way the damage potential of allowing 1024-bit
> is limited further, since only the obsolete client applications are
> that server, not the more capable ones.
> Yngve N. Pettersen
> Using Opera's mail client: http://www.opera.com/mail/
> Public mailing list
> Public at cabforum.org
More information about the Public