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

[Rick Andrews]

One more thing I forgot to mention: Tom Albertson of Microsoft made it clear that his metric is whether or not the existence of the certificate in question can cause harm to Windows users (not just IE users). For him, it's not enough that the certificate is not used by a browser. He would like us to pay attention to the possibility that a 1024-bit certificate might harm Windows users. Tom, I hope I've characterized your position correctly.

-Rick

> -----Original Message-----
> From: Rick Andrews
> Sent: Thursday, June 13, 2013 11:22 AM
> To: public at cabforum.org
> Cc: 'Yngve N. Pettersen'
> Subject: RE: [cabfpub] Proposed addition to BRs allowing issuance of
> <2048
> 
> 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.
> 
> -Rick
> 
> > -----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
> > <2048
> >
> > 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,
> > just
> > > 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
> > approved.
> >
> > 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
> > bit
> > OCSP for 2048 bit issuers.
> >
> >   - There should be an absolute sunset for this exception, preferably
> > with
> > 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
> > this
> > 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
> > every
> > application that can be upgraded to a different server that have a
> > 2048+
> > bit certificate. That way the damage potential of allowing 1024-bit
> > keys
> > is limited further, since only the obsolete client applications are
> > using
> > that server, not the more capable ones.
> >
> > --
> > Sincerely,
> > Yngve N. Pettersen
> >
> > Using Opera's mail client: http://www.opera.com/mail/
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public