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

[Horne, Rob]

I've been expecting such a proposal to come out of the recent discussions. Rick's suggested text makes an excellent starting point.

To my mind the issue here is the compliance requirements are too browser centric, which isn't necessarily a bad thing but will continue to throw up problems for non-browser usage of SSL and PKI in general. Using separate roots is one idea but as pointed out currently the number allowed in mainstream root programs is limited. Could turning off trust bits alleviate the problem? Or could there be a way to set criteria according to cert profiles? For example could it be possible to trust a root but limit the actions capable of being enacted using a cert chained to it?

Rob




-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: 13 June 2013 19:22
To: public at cabforum.org
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
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public