[cabfpub] Need exception to 1024-bit revocation requirement

[Phillip]

Side point, could we have a CABForum policy that we NEVER choose 1 january as a drop dead date?

There are many reasons why that is a really bad choice, not least the fact that there are many other time related issues that can hit on that day and it is a real bear doing debugging from customer service.

1 April is a better choice.


On Jun 6, 2013, at 5:16 PM, Hill, Brad wrote:

>> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public