[cabfpub] FW: [cabfquest] Key Size Exception

Ryan Sleevi sleevi at google.com
Wed Mar 6 19:14:04 UTC 2013


And that's why I suggested there many be acceptable alternatives for
root stores; eg: the application-local revocation of a series of
intermediates, while still permitting the existing root. This is
because using CRLs/OCSPs may affect all applications - including the
private applications.

Those are the sorts of details that have to be worked out on a
per-root-store basis, since each may have different means and
different concerns.

In the end, the decisions made by the CAs affect each application
individually, even though collectively it affects the global trust in
the ecosystem. While I'd much rather a system that "fails closed,
selectively opens", I'm pragmatic in recognizing that's not realistic
for many of these exceptional cases - which is why we find ourselves
in this problem.

On Wed, Mar 6, 2013 at 11:10 AM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> Ryan S said: "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."
>
> If we could turn back the clock, I think all CAs would use private roots for these exceptional cases, so as not to endanger their public roots. Moving forward, I hope all CAs consider doing that. None of us did that in the past, and as a result these exceptional cases rely on public roots. So while I agree with the sentiment in Ryan's statement, I don't think it's practical at the moment.
>
> -Rick
>
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Ryan Sleevi
>> Sent: Wednesday, March 06, 2013 11:04 AM
>> To: kirk_hall at trendmicro.com
>> Cc: CABFPub (public at cabforum.org)
>> Subject: Re: [cabfpub] FW: [cabfquest] Key Size Exception
>>
>> All of the root stores requesting/requiring BR compliance.
>>
>> As has been shown in past discussions, not every root store has
>> immediately adopted the BRs - an understandable point of concern for
>> some members. However, once a root store has, that's an independent
>> action by that root store operator as to what CAs they
>> accept/recognize.
>>
>> We can play a thought experiment, and pretend this requirement was
>> never introduced into the BRs. You'd still likely end up where a
>> number of root stores end up requiring the BRs + (X, Y, Z) - where
>> X/Y/Z may be the cessation of issuance of particular types of certs
>> that may present risks to users/operators. The CA would still need to
>> work with those root stores to find out what the root store requires,
>> if the root store permits exceptions to these rules, if their
>> particular use case/need is permissible, etc. In the end, the CA would
>> ultimately be effectively constrained by the most restrictive root
>> program, but the work would be no different than if (X, Y, Z) was
>> incorporated into the BRs and normatively referenced by the root
>> program.
>>
>> We have in this Forum the ability to effectively communicate with many
>> (but hardly all) CAs and many (but hardly all) root
>> programs/browsers/applications. The result of this communication
>> channel is the ability for root store operators to coordinate and
>> better understand the needs of CAs and industry when designing their
>> root store program requirements, in the hope of ultimately reaching
>> better consistency in these requirements. However, it ultimately
>> remains that each root store is a unique program, and any acceptance
>> or rejection of certs remains with individual root stores.
>>
>> We've seen in the past communications regarding exceptions to the BRs
>> - both Microsoft and Mozilla have provided some of the criteria they
>> use and examine in determining exceptions, based on feedback from
>> their program members. I don't see why this (or any other exceptions)
>> should be treated differently.
>>
>> On Wed, Mar 6, 2013 at 10:47 AM, kirk_hall at trendmicro.com
>> <kirk_hall at trendmicro.com> wrote:
>> > Ryan, just one question on your posting -- if we leave exceptions as
>> an issue for a CA to take up with the browsers each time -- which
>> browsers?  How many have to be consulted to get an exception?  All of
>> them?  Many of us have our roots in 20-30 browsers and applications, or
>> more.
>> >
>> > -----Original Message-----
>> > From: Ryan Sleevi [mailto:sleevi at google.com]
>> > Sent: Wednesday, March 06, 2013 10:42 AM
>> > To: Kirk Hall (RD-US)
>> > Cc: CABFPub (public at cabforum.org)
>> > Subject: Re: [cabfpub] FW: [cabfquest] Key Size Exception
>> >
>> > 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
>> > <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



More information about the Public mailing list