[cabfpub] Need exception to 1024-bit revocation requirement

Ryan Sleevi sleevi at google.com
Fri Jun 7 16:50:36 MST 2013


While the high bandwidth of the F2F may help, it comes with the
unfortunate tradeoff of moving away from the public list. Given the
impact that Trust Store Programs granting exceptions may have - both
in the overall ecosystem and on other CAs, it seems just as important
to continue discussing the merits on this list, as we have been.


On Fri, Jun 7, 2013 at 4:20 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> Ryan, it's unfortunate that no one from Google will be at the F2F next week, because I suspect we'll discuss this. Is there any chance you or others could participate via conf call if one could be arranged?
>
> -Rick
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Ryan Sleevi
>> Sent: Friday, June 07, 2013 4:19 PM
>> To: Rob Stradling
>> Cc: Rick Andrews; public at cabforum.org
>> Subject: Re: [cabfpub] Need exception to 1024-bit revocation
>> requirement
>>
>> That is, of course, one possibility. That's why I want to better
>> understand what the full risk model is, before we talk about
>> exceptions.
>>
>> Cheers,
>> Ryan
>>
>> On Fri, Jun 7, 2013 at 1:06 PM, Rob Stradling
>> <rob.stradling at comodo.com> wrote:
>> > On 07/06/13 18:32, Ryan Sleevi wrote:
>> >>
>> >> Rick,
>> >>
>> >> 1) Are there any intermediates involved that may be 1024-bit in
>> order
>> >> to accommodate these devices?
>> >
>> >
>> > Assuming the Visa devices can handle Intermediates, might the
>> following idea
>> > work?
>> >
>> > - Issue a dedicated Intermediate that, after Dec 31st 2013, will
>> issue new
>> > 1024-bit certs for Visa devices.
>> > - Ask the browsers to blacklist that Intermediate.
>> > - Declare (by adding an exception to the BRs and/or by updating Root
>> Program
>> > policies) that certs issued by blacklisted Intermediates are
>> considered
>> > out-of-scope for the BRs / WebPKI.
>> >
>> > (I realize this isn't quite what Microsoft's disallowedcert.stl,
>> NSS's
>> > active distrust flags, etc, were intended to be used for!  But could
>> this
>> > idea work?)
>> >
>> >
>> >> 2) Can you share the certificate extension profile(s) used in the
>> >> issuance of these certificates, for any other concerns that may
>> >> involve "exceptions" to the BRs. For example, basicConstraints and
>> the
>> >> like.
>> >>
>> >> While I'm extremely sympathetic to the real world issues that come
>> up
>> >> with any change to the Web PKI, I'm also extremely uncomfortable
>> with
>> >> the notion of exceptions because something is hard or expensive,
>> >> because it creates certain perverse incentives.
>> >>
>> >>> From the perspective of the Trust Store Program, what message does
>> it
>> >>
>> >> send all the other members (who may or may not participate in the
>> >> CA/Browser Forum) who proceeded to phase these out, and may have
>> also
>> >> incurred significant costs in doing so - financial or technical.
>> It's
>> >> very difficult to establish a reasonable and equitable bar here -
>> >> saying exceptions will be granted if it costs $X to comply would
>> >> naturally favour larger parties, while other approaches, such as
>> >> percentages, advantage others.
>> >>
>> >> "Security" is far from black and white, a point I well understand,
>> but
>> >> I think we stand at the edge of a very slippery slope, and I want to
>> >> make sure we recognize that in these discussions.
>> >>
>> >> When we talk about the Web PKI, we must realize there's two layers
>> >> 1) How people "intend" for things to work
>> >> 2) How it actually works.
>> >>
>> >> I hear your argument for an exception to be arguing from a position
>> of
>> >> the first point. I'm trying to understand the implications from the
>> >> position of the second point, since in the end, that's the only one
>> >> that matters.
>> >>
>> >>
>> >> On Fri, Jun 7, 2013 at 9:29 AM, Rick Andrews
>> <Rick_Andrews at symantec.com>
>> >> wrote:
>> >>>
>> >>> The problem is that any CA that has issued such SSL certs to such
>> non-web
>> >>> PKI applications, and needs to continue to issue them for business
>> >>> continuity, will fail their audit and will have to engage in a
>> discussion
>> >>> with each trust store owner to convince them to retain their roots.
>> >>>
>> >>> It's not just us and its not just this particular usage. Other CAs
>> have
>> >>> the same issue.
>> >>>
>> >>> -Rick
>> >>>
>> >>> On Jun 7, 2013, at 9:13 AM, "Phillip" <philliph at comodo.com> wrote:
>> >>>
>> >>>> I thought that the original point of the drop dead date was that
>> the
>> >>>> browsers are going to stop trusting 1024 bit certs at some point
>> in the
>> >>>> future.
>> >>>>
>> >>>> Ergo there should be no need for an exception. Mozilla, IE, Google
>> etc.
>> >>>> just turn off support for the 1024 bit certs in their browsers.
>> The Visa
>> >>>> certs are issued as before but the only devices that will accept
>> them are
>> >>>> the Visa POS terminals. (Point of Sale)
>> >>>>
>> >>>> So what is the problem?
>> >>>
>> >>> _______________________________________________
>> >>> 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
>> >>
>> >
>> > --
>> > Rob Stradling
>> > Senior Research & Development Scientist
>> > COMODO - Creating Trust Online
>> > Office Tel: +44.(0)1274.730505
>> > Office Fax: +44.(0)1274.730909
>> > www.comodo.com
>> >
>> > COMODO CA Limited, Registered in England No. 04058690
>> > Registered Office:
>> >   3rd Floor, 26 Office Village, Exchange Quay,
>> >   Trafford Road, Salford, Manchester M5 3EQ
>> >
>> > This e-mail and any files transmitted with it are confidential and
>> intended
>> > solely for the use of the individual or entity to whom they are
>> addressed.
>> > If you have received this email in error please notify the sender by
>> > replying to the e-mail containing this attachment. Replies to this
>> email may
>> > be monitored by COMODO for operational or business reasons. Whilst
>> every
>> > endeavour is taken to ensure that e-mails are free from viruses, no
>> > liability can be accepted and the recipient is requested to use their
>> own
>> > virus checking software.
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public


More information about the Public mailing list