[cabfpub] Need exception to 1024-bit revocation requirement

[Hill, Brad]

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

A very enthusiastic +1.  What possible reason is there for embedded devices intended for a dedicated function in a closed business ecosystem to be default-trusted as servers on the public Web by every browser?

These were the same type of arguments we heard against deprecating internal name certificates - that there were, e.g., chat systems operating entirely in closed network contexts that would break if we made changes to protect the public.

It doesn't seem like it would cause "grave financial harm" for Visa to begin trusting a non-public CA when it contacts these devices.  Are the devices incapable of being re-provisioned with new certificates from a different root, or just using 2048 bit ones?

-Brad


> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-
> bounces at cabforum.org] On Behalf Of Ryan Sleevi
> Sent: Thursday, June 06, 2013 1:58 PM
> To: Rick Andrews
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Need exception to 1024-bit revocation requirement
> 
> 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.
> 
> 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.
> 
> Cheers,
> Ryan
> 
> 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&ca
> d=rja
> >
> &ved=0CDcQFjAA&url=http%3A%2F%2Fusa.visa.com%2Fdownload%2Fmerc
> hants%2F
> > retirement-of-pre-pci-attended-pos-pin-entry-
> devices.pdf&ei=Nd6wUaa2Fo
> > rXigKb-4BY&usg=AFQjCNHtHptM1jQudRTl8pnMx-
> MKC7z6fw&sig2=ItouLeVwv8wkQYG
> > pi9nPVQ&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
> >
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public