[cabfpub] Need exception to 1024-bit revocation requirement

Ryan Sleevi sleevi at google.com
Thu Jun 6 21:51:07 UTC 2013

On Thu, Jun 6, 2013 at 2:30 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> I'm checking when we issued the certs in question. If we issued them before the BR Effective Date of 1 July 2012 then my understanding is that we don't need to revoke them because they aren't covered by the BRs.
> Ryan, I added some comments below.
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi at google.com]
>> Rick,
>> I thought on the topic of exceptions we agreed that the CA/Browser
>> Forum is not really in a place to grant such exceptions. This is
>> something you'll need to work out with the Trust Anchor Stores you
>> participate in, and whether or not they will accept a Baseline
>> Requirement Audit that failed, due to the inability to meet the
>> requirements set forth by the BRs. The point of the Baseline
>> Requirements is to establish just that - a baseline - but the
>> enforcement and application of that still remains with the individual
>> Trust Anchor Stores. The CA/B Forum doesn't decide what roots are
>> approved, so I can't see how it can possibly grant exceptions.
> Yes, I recall that discussion but I still feel an exception to the BR might be appropriate here. CAs (I'm sure it's not just us) have issued certs for non-browser use, and by default we issued them from the same roots. In retrospect, we should have created a private root for that other use to separate the risk. But these devices in question (as an example) were deployed almost 10 years ago, well before the creation of the CABF. It's even likely that we were never even consulted when they were developed. The devices manufacturer could have just found our roots on our web site and installed them in the devices as their own internal trust store, so that the devices could talk to servers with certs purchased from public CAs.


To re-iterate the points discussed previously, what does "an exception" mean?

The BRs provide a framework for the Auditing Guidelines incorporated
into work by ETSI/WebTrust, which then feed into the various Trust
Store programs - both those that participate in this group and those
that may not. Removing a line item from the BR - or in fact, negating
the BRs entirely, does not cause an immediate change in how audits are
performed, nor does it change what such Trust Stores expect. As we've
seen, the weaker the BRs are, the more the Trust Stores themselves
maintain their own policy, and the stronger they are, the more the
Trust Stores simply defer to the BRs. Regardless of what the BRs say,
however, the Trust Stores have an expectation about their members that
is not something the CA/Browser Forum dictates nor directly

If your concern is that Symantec will be unable to pass an audit
conducted according to the Baseline Requirements, then that seems like
exactly something you should be discussing with the Trust Stores
directly - because ultimately, it's up to them/us as to whether or not
to accept a Root that cannot pass such an audit, and under what
conditions such a failure might be acceptable.

On a related note, given the significance of this request, and please
forgive my naivete, but if the argument is that you can't transition
these (other uses/issuance practices) from your existing roots - for
example, because you cannot change the root in these devices - doesn't
that suggest that, going forward, when applying or maintaining
membership in the Trust Anchor Stores, you should be considering
applying with only a "Web PKI only" hierarchy/root.

There should be nothing that would prevent your "Web PKI only"
hierarchy from being cross-certified by your existing "Legacy" PKI,
allowing interoperability with all these legacy devices and clients,
but it would ensure that going forward, your issuance practices are
able to adjust to the changing Web PKI threat model - including
rapidly, if necessary for the protection and security of the web. It
would also reduce the risk of new clients from needing to trust all
possible issuance practices.

I just feel like we've seen this sort of legacy issue before, with the
deprecation of MD5, we're seeing it again with 1024-bit certs, and I'm
sure within a few years time, we'll be revisiting it once more with
SHA-1 (which will be much more difficult than MD5, no doubt). As an
industry, this is something we have to continue to get better at
responding to and improving the ecosystem - which is why I think a lot
of us are here and participating in this forum - and I want to make
sure we don't allow ourselves to unintentionally undermine those

>> I think this also highlights the real risks to the users of open web
>> when the entire PKI hierarchy is trusted/participates in the root
>> store. Given the attacks we've seen - particularly on infrastructure
>> that was perceived as unrelated to the core infrastructure (such as
>> Microsoft's Terminal Services CA MD5 collision attack for FLAME) - it
> As an aside, one part of the Flame attack didn't even require an MD5 collision. That was needed only for Windows 7. Older OSes accepted terminal services licenses as certs that were allowed to sign code updates.
>> seems all the more important that if trust is to be maintained in the
>> public PKI, then consistent security standards are needed. For
>> operations that are not concerned with issuing as part of the Web PKI,
>> it seems more appropriate to be using a separate root - or for CAs to
>> be applying with intermediates to be added to the Trust Anchor stores,
>> rather than their entire PKI hierarchy.
>> The ability for CAs to rapidly respond to the ever changing threat and
>> cryptographic landscape is vital for the public trust - and the
>> inability to do so for 'legacy' reasons is quite troubling. The
>> deprecation of 1024-bit certificates has been a long time coming, and
>> that these issues weren't realized until such a last minute are
>> concerning, especially after all the discussion and debate on the
>> topic and timeline.
> We respond quickly when it's in our ability to do so. It's just not possible to push Visa to quickly phase out the old devices. It's not our core business; I have no idea if there are millions or billions of these devices out there. I believe they've looked at risk and business realities and decided that 1 December 2014 was an acceptable compromise.

Naturally, I'm sure you can understand why this would be concerning.
That one segment is unable or unwilling to respond rapidly is
unfortunate, but it should not be able to undermine the need for the
Web PKI to continue to improve and adapt to the threats facing it.

>> From the browser side, I think the most concerning thing about your
>> statements is this: Are there any technical controls in place (for
>> example, EKUs or contraints) that prevent any certificates in this
>> hierarchy from being usable for SSL/TLS. This includes both the
>> existing end-entity certs and any intermediates that would chain to or
>> otherwise participate in the issuance process.
> I don't understand your question. Are there technical controls in place that prevents certs from being used for SSL? They were intended to be used for SSL.

Thanks for confirming that these certs do present possible risk to the
Web PKI and the users that rely upon it.


More information about the Public mailing list