<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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...<br>
<br>
On 03/06/2013 08:48 PM, From Ryan Hurst:
<blockquote
cite="mid:B765BBBE-436E-45EA-BCDC-3E51F1A4B05F@globalsign.com"
type="cite">
<pre wrap="">+1
Ryan Hurst
Chief Technology Officer
GMO Globalsign
twitter: @rmhrisk
email: <a class="moz-txt-link-abbreviated" href="mailto:ryan.hurst@globalsign.com">ryan.hurst@globalsign.com</a>
phone: 206-650-7926
Sent from my phone, please forgive the brevity.
On Mar 6, 2013, at 10:41 AM, Ryan Sleevi <a class="moz-txt-link-rfc2396E" href="mailto:sleevi@google.com"><sleevi@google.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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, <a class="moz-txt-link-abbreviated" href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:kirk_hall@trendmicro.com"><kirk_hall@trendmicro.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:questions-bounces@cabforum.org">questions-bounces@cabforum.org</a> [<a class="moz-txt-link-freetext" href="mailto:questions-bounces@cabforum.org">mailto:questions-bounces@cabforum.org</a>] On Behalf Of <a class="moz-txt-link-abbreviated" href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a>
Sent: Wednesday, March 06, 2013 12:23 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>; <a class="moz-txt-link-abbreviated" href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
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
<a class="moz-txt-link-abbreviated" href="mailto:i-barreira@izenpe.net">i-barreira@izenpe.net</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:questions-bounces@cabforum.org">questions-bounces@cabforum.org</a> [<a class="moz-txt-link-freetext" href="mailto:questions-bounces@cabforum.org">mailto:questions-bounces@cabforum.org</a>] En nombre de Jeremy Rowley Enviado el: martes, 05 de marzo de 2013 18:11
Para: 'Bruce Morton'
CC: <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:questions-bounces@cabforum.org">questions-bounces@cabforum.org</a> [<a class="moz-txt-link-freetext" href="mailto:questions-bounces@cabforum.org">mailto:questions-bounces@cabforum.org</a>]
On Behalf Of Bruce Morton
Sent: Tuesday, March 05, 2013 8:09 AM
To: Rick Andrews; Rob Stradling
Cc: <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
Subject: Re: [cabfquest] Key Size Exception
Agreed.
Bruce.
-----Original Message-----
From: Rick Andrews [<a class="moz-txt-link-freetext" href="mailto:Rick_Andrews@symantec.com">mailto:Rick_Andrews@symantec.com</a>]
Sent: Monday, March 04, 2013 5:17 PM
To: Bruce Morton; Rob Stradling
Cc: <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:questions-bounces@cabforum.org">questions-bounces@cabforum.org</a> [<a class="moz-txt-link-freetext" href="mailto:questions">mailto:questions</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@cabforum.org">bounces@cabforum.org</a>] On Behalf Of Bruce Morton
Sent: Monday, March 04, 2013 6:39 AM
To: Rob Stradling
Cc: <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
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 [<a class="moz-txt-link-freetext" href="mailto:rob.stradling@comodo.com">mailto:rob.stradling@comodo.com</a>]
Sent: Wednesday, February 27, 2013 9:32 AM
To: Bruce Morton
Cc: <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">root
</pre>
<blockquote type="cite">
<pre wrap="">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 [<a class="moz-txt-link-freetext" href="mailto:BTrzupek@trustwave.com">mailto:BTrzupek@trustwave.com</a>]
*Sent:* Tuesday, February 26, 2013 2:33 PM
*To:* Bruce Morton
*Cc:* <a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>
*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 <<a class="moz-txt-link-abbreviated" href="mailto:bruce.morton@entrust.com">bruce.morton@entrust.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:bruce.morton@entrust.com"><mailto:bruce.morton@entrust.com></a>> 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
</pre>
</blockquote>
<pre wrap="">phones
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
--
Rob Stradling
Senior Research & Development Scientist COMODO - Creating Trust Online
_______________________________________________
Questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Questions@cabforum.org">Questions@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/questions">https://cabforum.org/mailman/listinfo/questions</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Questions@cabforum.org">Questions@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/questions">https://cabforum.org/mailman/listinfo/questions</a>
_______________________________________________
Questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Questions@cabforum.org">Questions@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/questions">https://cabforum.org/mailman/listinfo/questions</a>
_______________________________________________
Questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Questions@cabforum.org">Questions@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/questions">https://cabforum.org/mailman/listinfo/questions</a>
<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
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>