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

Ryan Hurst ryan.hurst at globalsign.com
Thu Jun 13 21:06:25 UTC 2013


-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Ryan Sleevi
Sent: Thursday, June 13, 2013 2:01 PM
To: Rick Andrews
Cc: public at cabforum.org
Subject: Re: [cabfpub] Proposed addition to BRs allowing issuance of <2048

On Thu, Jun 13, 2013 at 1:57 PM, Rick Andrews <Rick_Andrews at symantec.com>
> On Jun 13, 2013, at 9:45 PM, "Ryan Sleevi" <sleevi at google.com> wrote:
>> I don't view it as the CA/B Forum imposing requirements on 
>> non-browser clients - merely, we're imposing requirements on browser
> I should have said that it's the impression of our non-browser customers.
That's what they've told me.
>> 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.
> True, but my initial point was that it has not been common practice to
keep our roots separate. All the CAs I talked to. To reiterate: even where
we had separate roots (or the intention to use separate roots) I believe
there have been cases where customers found our roots in our website and
embedded them without our knowledge.
>> 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.
> I agree with Rob Stradling that the policies of many trust stores makes
this suggestion unworkable. I don't think there's a silver bullet here; we
just have to do a better job at trying to pry apart these different usages
in the future.
> -Rick

Wouldn't it be better for the industry to push for an exception to those
policies, which carry no security risk to users, then, rather than
encouraging a practice that the industry recognizes has security problems?
Public mailing list
Public at cabforum.org

More information about the Public mailing list