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

Ryan Sleevi sleevi at google.com
Thu Jun 13 14:00:57 MST 2013


On Thu, Jun 13, 2013 at 1:57 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> 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 clients.
>
> 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?


More information about the Public mailing list