[cabfpub] Need exception to 1024-bit revocation requirement

Ryan Sleevi sleevi at google.com
Thu Jun 6 20:58:10 UTC 2013


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.

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

Likewise, it seems very inconsistent to grant exceptions for 'legacy'
reasons, while still requiring new applicants to adhere to the more
stringent standards. I'm sure you can understand why such
inconsistencies comes with great debate and even greater hesitation.

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


On Thu, Jun 6, 2013 at 12:36 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> It’s come to our attention that we’ve issued 1024-bit SSL certs to customers
> that use them with what are called “pre-PCI POS PIN acceptance devices”, and
> that those devices are incapable of working with a 2048-bit key. VISA has
> stated that those devices may be used until December 31, 2014 (see
> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDcQFjAA&url=http%3A%2F%2Fusa.visa.com%2Fdownload%2Fmerchants%2Fretirement-of-pre-pci-attended-pos-pin-entry-devices.pdf&ei=Nd6wUaa2ForXigKb-4BY&usg=AFQjCNHtHptM1jQudRTl8pnMx-MKC7z6fw&sig2=ItouLeVwv8wkQYGpi9nPVQ&bvm=bv.47534661,d.cGE)
> , and our customers feel that revoking them will cause grave financial harm.
> These devices perform the client side of SSL, so there is no browser
> involved at all. It’s unfortunate that these certs chain up to public roots
> and are therefore subject to Baseline Requirements, but I believe that it
> was standard practice for CAs to issue all SSL certs from their public
> roots. In many cases we didn’t even know that the customer was using them
> with a device and not a browser.
> Therefore I feel we need an exception to not revoke 1024-bit certs that we
> determine are used by these devices. Given the environment in which they are
> used, and given that VISA is forcing customers to phase these out, I feel it
> would be very low risk to simply let these certs live until their
> expiration.
> I welcome your comments.
> -Rick
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

More information about the Public mailing list