[cabfpub] Proposed addition to BRs allowing issuance of <2048
ryan.hurst at globalsign.com
Thu Jun 13 21:06:25 UTC 2013
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.
>> 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.
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