[cabfpub] Need exception to 1024-bit revocation requirement

Rich Smith richard.smith at comodo.com
Fri Jun 7 19:17:16 UTC 2013


+1

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Phillip
> Sent: Friday, June 07, 2013 3:07 PM
> To: Hill, Brad
> Cc: Rick Andrews; public at cabforum.org
> Subject: Re: [cabfpub] Need exception to 1024-bit revocation
> requirement
> 
> 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
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130607/ff8390d6/attachment-0003.bin>


More information about the Public mailing list