[cabfpub] Need exception to 1024-bit revocation requirement

[Rick Andrews]

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.

> 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.

> 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.