[cabfpub] FW: [cabfquest] Key Size Exception

Eddy Nigg (StartCom Ltd.) eddy_nigg at startcom.org
Wed Mar 6 20:31:54 UTC 2013


Another +1 from me .... what me concerns the CAs interested can keep 
stripping in front of the public, but then we'd better cancel this whole 
BR thing and admit defeat. And with it probably look for alternatives...

On 03/06/2013 08:48 PM, From Ryan Hurst:
> +1
>
> Ryan Hurst
> Chief Technology Officer
> GMO Globalsign
>
> twitter: @rmhrisk
> email: ryan.hurst at globalsign.com
> phone: 206-650-7926
>
> Sent from my phone, please forgive the brevity.
>
> On Mar 6, 2013, at 10:41 AM, Ryan Sleevi<sleevi at google.com>  wrote:
>
>> As a browser, I think we'd have concerns with adding further
>> exceptions to the *Baseline* Requirements - regardless of whether or
>> not the audit framework was capable for them.
>>
>> The point of the Baselines is to raise trust in the overall ecosystem
>> of publicly trusted anchors, by reducing the risks to end users of
>> both malicious or mistaken misissuance or compromise.
>>
>> While browsers can take preventative measures to reduce these risks -
>> as we've seen, with the move to no longer trust MD5 in signatures, or
>> to trust<  1024-bit certificates - it's also incumbent on CAs to
>> improve the processes.
>>
>> For issuance of certificates that are not meant to be part of this
>> public trust ecosystem, the recommendation is to not issue them from
>> underneath the PKI that is publicly trusted - since doing so
>> inevitably puts such issuance in scope and concern for the public at
>> large.
>>
>> I don't think this is an issue that can/should be solved through
>> exceptions in the BRs - it's something that should be worked out with
>> the root programs that are requiring the BRs as part of their
>> issuance. While changes to the BR may assist in the auditing
>> framework, the acceptance or rejection of those exceptions ultimately
>> falls to the root programs. Some may accept the audited assertions at
>> face value, others may require explicit revocation (through
>> non-CRL/OCSP means) of those non-BR intermediates, and others may
>> choose to not accept them at all.
>>
>> I think before we worry about rewriting the BRs, more comments from
>> other root store operators would be beneficial.
>>
>> On Wed, Mar 6, 2013 at 10:25 AM, kirk_hall at trendmicro.com
>> <kirk_hall at trendmicro.com>  wrote:
>>> Well, to introduce a new concern, I'm not very comfortable with Forum members themselves sitting as judges of a request by a competitor for a specific exception.
>>>
>>> I can see the member providing details of the need and the request, then being asked question after question that potentially gets into the relationship with the customer and even the customer's systems, security needs and decisions, etc., requiring even more disclosure of information that should not be circulated.  Then the Forum members would vote on whether or not to grant the exemption?  We would (1) be too deep into the confidential information and the business of the requesting CA and its customer, and (2) be making a security judgment for the customer in the particular case -- what if there is a later problem?  Are we all responsible for authorizing the customer to proceed?
>>>
>>> In my view, a better approach is to create a list of criteria for exceptions to the rule (like we have today with BR 9.4 - Validity Period), then requiring the CA and its customer to formally determine if the exception request falls within the criteria, and then having that exception audited by the auditor.  If the CA and customer make a bad decision in a particular case, the fault is theirs, not the Forum's.  Plus I don't want to receive all the details from another CA's customer in every case.
>>>
>>> -----Original Message-----
>>> From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] On Behalf Of i-barreira at izenpe.net
>>> Sent: Wednesday, March 06, 2013 12:23 AM
>>> To: jeremy.rowley at digicert.com; bruce.morton at entrust.com
>>> Cc: questions at cabforum.org
>>> Subject: Re: [cabfquest] Key Size Exception
>>>
>>> +1 except that the " The forum should evaluate each exception on a case-by-case basis." This could drive us into several issues depending which CA to which customer.
>>>
>>>
>>> Iñigo Barreira
>>> Responsable del Área técnica
>>> i-barreira at izenpe.net
>>> 945067705
>>>
>>>
>>> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
>>> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.
>>>
>>> -----Mensaje original-----
>>> De: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org] En nombre de Jeremy Rowley Enviado el: martes, 05 de marzo de 2013 18:11
>>> Para: 'Bruce Morton'
>>> CC: questions at cabforum.org
>>> Asunto: Re: [cabfquest] Key Size Exception
>>>
>>> Although I recognize that CAs might occasionally require an exception to baseline requirements in odd circumstances (such as the one presented by Bruce), I worry that other CAs will use these exceptions to justify non-compliance.  We start down a slippery slope when the Forum starts granting exceptions to minimum standards for SSL .  This slope that can quickly turn into favoritism in rule interpretations that benefit CAs who are members of the CAB Forum and exceptions that benefit only established CAs, giving them a significant advantage over new market entrants.
>>>
>>> I dislike the idea of CAs issuing SSL certificates that do not comply with the baseline requirements, since the baseline requirements were intended, in part, to provide relying parties with a reliable standard in the security behind an SSL certificate. Since Entrust's issuance of these certs lacks a relying party, I do not object to proposition that these certificates are outside the baseline requirements.  However, the Forum's grant of this particular exception to the minimum standards should not be construed as approval of all similar practices.  The forum should evaluate each exception on a case-by-case basis.
>>>
>>> Jeremy
>>>
>>> -----Original Message-----
>>> From: questions-bounces at cabforum.org [mailto:questions-bounces at cabforum.org]
>>> On Behalf Of Bruce Morton
>>> Sent: Tuesday, March 05, 2013 8:09 AM
>>> To: Rick Andrews; Rob Stradling
>>> Cc: questions at cabforum.org
>>> Subject: Re: [cabfquest] Key Size Exception
>>>
>>> Agreed.
>>>
>>> Bruce.
>>>
>>> -----Original Message-----
>>> From: Rick Andrews [mailto:Rick_Andrews at symantec.com]
>>> Sent: Monday, March 04, 2013 5:17 PM
>>> To: Bruce Morton; Rob Stradling
>>> Cc: questions at cabforum.org
>>> Subject: RE: [cabfquest] Key Size Exception
>>>
>>> Bruce,
>>>
>>> Since these certs will not be BR-compliant, I suggest you omit the BR OID from them so as not to mislead relying parties.
>>>
>>> -Rick
>>>
>>>> -----Original Message-----
>>>> From: questions-bounces at cabforum.org [mailto:questions-
>>>> bounces at cabforum.org] On Behalf Of Bruce Morton
>>>> Sent: Monday, March 04, 2013 6:39 AM
>>>> To: Rob Stradling
>>>> Cc: questions at cabforum.org
>>>> Subject: Re: [cabfquest] Key Size Exception
>>>>
>>>> Hi Rob,
>>>>
>>>> Thank you for the input. I even read the Scope upfront and missed the
>>>> interpretation.
>>>>
>>>> The certificates do have CNs that could be interpreted as internet
>>>> names. We have tested and are unable to resolve the names. Although
>>>> the names are possible to be used through the internet, they are not,
>>>> which is the condition the customer has already agreed to.
>>>>
>>>> Bruce.
>>>>
>>>> -----Original Message-----
>>>> From: Rob Stradling [mailto:rob.stradling at comodo.com]
>>>> Sent: Wednesday, February 27, 2013 9:32 AM
>>>> To: Bruce Morton
>>>> Cc: questions at cabforum.org
>>>> Subject: Re: [cabfquest] Key Size Exception
>>>>
>>>> Hi Bruce.
>>>>
>>>> Section "1. Scope" of the BRs says:
>>>>    "This version of the Requirements only addresses Certificates
>>>> intended to be used for authenticating servers accessible through the
>>>> Internet."
>>>>
>>>> You wrote:
>>>>    "The servers...are not exposed to the internet"
>>>>
>>>> Depending on how "intended to be used" is interpreted, this could mean
>>>> that the BRs don't apply in this case.
>>>>
>>>> Do these device certificates contain Subject->CNs or SAN->dNSNames
>>>> that are (or could become) Internet domain names?
>>>> (If yes, then arguably this shows an intention to use the certs on the
>>>> Internet; if no, then IMHO the BRs don't apply).
>>>>
>>>> On 27/02/13 13:55, Bruce Morton wrote:
>>>>> Hi Brian,
>>>>>
>>>>> The devices are supplied by multiple vendors and the customer has
>>>>> not tested for expired certificates. Also, they do not have their
>>>>> own
>>>> root
>>>>> embedded.
>>>>>
>>>>> They advise the following:
>>>>>
>>>>> *The servers on closed CDMA networks. Not Internet or even
>>>>> accessible from a laptop on our internal employee network.
>>>>>
>>>>> *The ssl utilization drom the devices is on the CDMA data portion
>>>>> after CDMA encryption is in place. So two layers there.
>>>>>
>>>>> *The newer devices point to a newer service  for these
>>>>> communications that does use certs from the 2048 root.
>>>>>
>>>>> Bruce.
>>>>>
>>>>> *From:*Brian Trzupek [mailto:BTrzupek at trustwave.com]
>>>>> *Sent:* Tuesday, February 26, 2013 2:33 PM
>>>>> *To:* Bruce Morton
>>>>> *Cc:* questions at cabforum.org
>>>>> *Subject:* Re: [cabfquest] Key Size Exception
>>>>>
>>>>> Bruce,
>>>>>
>>>>> Will the devices continue to 'work' with expired certificates? (i.e.:
>>>>> do new certificate need to be issued)
>>>>>
>>>>> Is there a self signed option for the devices? (do they include a
>>>>> customer root)
>>>>>
>>>>> Thanks,
>>>>>
>>>>> brian
>>>>>
>>>>> On Feb 26, 2013, at 12:38 PM, Bruce Morton<bruce.morton at entrust.com
>>>>> <mailto:bruce.morton at entrust.com>>  wrote:
>>>>>
>>>>>
>>>>>
>>>>> We have a requirement with a customer which requires 1024-bit
>>>>> certificates issued directly from a 1024-bit Root.
>>>>>
>>>>> The issue is as follows:
>>>>>
>>>>> -The customer is a large US telecommunications provider
>>>>>
>>>>> -The customer embedded our 1024-bit root certificate into their
>>>> phones
>>>>> and antennas
>>>>>
>>>>> -The phones and antennas do not support 2048-bit certificate and do
>>>>> not support intermediate certificates
>>>>>
>>>>> -There are more than 1 million phones still in service
>>>>>
>>>>> -The phones and antennas will connect to servers which are only
>>>>> configured to support these devices
>>>>>
>>>>> -The servers using 1024-bit certificates are not exposed to the
>>>>> internet
>>>>>
>>>>> The Baseline Requirements section 12 allows us to issue certificates
>>>>> directly from a 1024-bit. The Baseline Requirements Appendix A
>>>>> requires minimum 2048-bit keys after 2013.
>>>>>
>>>>> We are not aware of a method for asking the CA/Browser Forum for an
>>>>> exception, but are doing so anyways. We ask for an exception to
>>>>> allow 1024-bit keys within SSL certificates past 2103. I justify the
>>>>> exception to the requirements as follows:
>>>>>
>>>>> -The customer is an embedding partner that has their own SSL
>>>>> requirements that have not been considered by the forum
>>>>>
>>>>> -The 1024-bit certificates will not expose risk to any of the
>>>>> browser users
>>>>>
>>>>> -The 1024-bit certificates will only expose risk to the customer and
>>>>> to their users
>>>>>
>>>>> -The CA/Browser forum already has CAs which are supporting 1024-bit
>>>>> certificates past 2013.
>>>>>
>>>>> I than you in advance for considering this request.
>>>>>
>>>>> All the best,
>>>>>
>>>>> Bruce Morton
>>>>>
>>>>> Entrust
>>>>>
>>>>> +1 613.270.3743
>>>> --
>>>> Rob Stradling
>>>> Senior Research&  Development Scientist COMODO - Creating Trust Online
>>>>
>>>> _______________________________________________
>>>> Questions mailing list
>>>> Questions at cabforum.org
>>>> https://cabforum.org/mailman/listinfo/questions
>>> _______________________________________________
>>> Questions mailing list
>>> Questions at cabforum.org
>>> https://cabforum.org/mailman/listinfo/questions
>>>
>>> _______________________________________________
>>> Questions mailing list
>>> Questions at cabforum.org
>>> https://cabforum.org/mailman/listinfo/questions
>>> _______________________________________________
>>> Questions mailing list
>>> Questions at cabforum.org
>>> https://cabforum.org/mailman/listinfo/questions
>>> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
>>> TREND MICRO EMAIL NOTICE
>>> The information contained in this email and any attachments is confidential
>>> and may be subject to copyright or other intellectual property protection.
>>> If you are not the intended recipient, you are not authorized to use or
>>> disclose this information, and we request that you notify us by reply mail or
>>> telephone and delete the original message from your mail system.
>>> </pre></td></tr></table>
>>>
>>> _______________________________________________
>>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130306/232b29b9/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130306/232b29b9/attachment-0001.p7s>


More information about the Public mailing list