[cabfpub] Need exception to 1024-bit revocation requirement

[Ryan Sleevi]

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.