[cabfpub] Ballot 89 Again (Publish Recommendations for the Processing of EV SSL Certificates v.2)

[Moudrick M. Dadashov]

Rick, I see here a problem that not all roots have policy OIDs. It's been common understanding that roots serve more like TA containers rather than certificates. Looks like this has changed, right?

Thanks,
M.D.

Rick Andrews <Rick_Andrews at symantec.com> wrote:

>Moudrick,
>
>I think it does. It says that whatever OID is assigned to the EV root must also appear in the end-entity cert. If a CA uses CABF or ETSI standard OIDs, that's fine as long as the OID corresponding to the root appears in the end-entity.
>
>-Rick
>
>> -----Original Message-----
>> From: Moudrick M. Dadashov [mailto:md at ssc.lt]
>> Sent: Thursday, November 21, 2013 4:31 PM
>> To: Rick Andrews
>> Cc: Sigbjørn Vik; ben at digicert.com ; public at cabforum.org
>> Subject: Re: [cabfpub] Ballot 89 Again (Publish Recommendations for the
>> Processing of EV SSL Certificates v.2)
>> 
>> Hi Rick,
>> 
>> Sorry, this Toshiba email client doesn't allow me to comment inline, so
>> I'll keep it brief.
>> 
>> RE: policy OIDs. The proposed wording seem doesn't cover the cases when
>> EVs are issued under corresponding CAB/Forum or ETSI OIDs, correct?
>> 
>> Thanks,
>> M.D.
>> 
>> Rick Andrews <Rick_Andrews at symantec.com> wrote:
>> 
>> >> > I re-read these carefully, and evaluated each section
>> independently:
>> >> >
>> >> > Section 9: I left it MUST: "User agents must not grant the EV
>> >> treatment to certificates that do not validate successfully."
>> >>
>> >> Sounds good, but note the ambiguity now inherent in the wording, as
>> >> "validate" means "path validation according to RFC 5280" in the
>> first
>> >> sentence, and "validation according to the certificate verification
>> >> software" in the second sentence. User agents might not be told
>> about
>> >> path mis-validation by the certificate verification software, and by
>> >> this sentence must take the gospel from such libraries, for any kind
>> of
>> >> validation errors, not just path validation. (Or else validate by
>> other
>> >> means.)
>> >
>> >How about if I change it to "The EV treatment must not be granted by
>> user agents to certificates for which the agent knows of any failure in
>> path validation."?
>> >
>> >> > Section 12, Policy Identifier: I changed both to MUST: "The
>> >> certificate verification software must verify that the EV
>> certificate
>> >> contains a value in its certificate policies extension that matches
>> the
>> >> distinct certificate policy identifier associated with the issuing
>> CSP
>> >> root certificate. The user agent must grant the EV treatment only to
>> >> certificates that contain the appropriate policy identifier." If
>> >> there's a browser that shows the EV treatment even for certs whose
>> >> policy OID doesn't match the root's EV OID, I think we'd all like to
>> >> know about it.
>> >>
>> >> This gets complicated with a must. There is no technical reason for
>> >> these OIDs, a CA might just as well just have an EV root, and
>> >> categorically state that anything chaining to it is EV. This might
>> be
>> >> sufficient in a lot of cases, so I'd recommend a should here. Also
>> note
>> >> that an EV root is not required to be issued by a public CA, it
>> could
>> >> also be a home grown intranet root, automatically installed by
>> >> sysadmin.
>> >
>> >I'm reluctant to change this. I was not in the CABF at its founding,
>> but AFAIK the group agreed that an EV cert would have to contain the
>> OID corresponding to the OID associated with the root that it chained
>> up to. I'd like to hear others' opinions on this. I believe there is
>> value in requiring the OID in the end-entity cert. It allows the CA to
>> issue non-EV certs from under the EV root, for example. Root store
>> managers have expressed a desire to maintain fewer roots, not more, so
>> I would expect that CAs that issue EV certs would also issue non-EV
>> certs from the same root. And the OID is what differentiates them.
>> >
>> >I'm not sure what home grown intranet EV roots have to do with this
>> discussion?
>> >
>> >> User agents might not check the certificate policy identifiers at
>> all
>> >> (leaving that entirely to the certificate verification software), so
>> it
>> >> might be impossible for user agents to live up to their part of the
>> >> bargain here, so I'd recommend a should for the second part too,
>> >> alternatively replacing user agents with certificate verification
>> >> software and rewriting. (Similar issue as in section 9, using "must"
>> >> for
>> >> something the user agent doesn't know about.)
>> >
>> >If you accept my argument above that CAs want to issue EV and non-EV
>> from the same root, then in cases where user agents are separate from
>> certificate verification software, someone has to check if the policy
>> identifier is correct. If it's the certificate verification software
>> that does that, it needs to return some flag to the user agent
>> indicating whether the test passed or failed. I feel that if I make
>> this a "should", everyone might just assume that the other guy is
>> checking, and we may have a case where no one checks.
>> >
>> >> > Section 13: I left it MUST, but clarified the wording: "User
>> agents
>> >> must not grant the EV treatment to EV Certificates that are known to
>> >> have been revoked."
>> >>
>> >> Sounds good. What about the second part, certificates "for which
>> >> confirmation has never been obtained", this originally used the same
>> >> verb?
>> >
>> >I removed it.
>> >
>> >> >> Nitpick now that I know what relying party means:
>> >> >>
>> >> >> Section 7.2: I am not sure I understand what protections
>> agreements
>> >> >> between root stores and CAs offer all end users (including end
>> users
>> >> >> not using that root store or CA).
>> >> >
>> >> > I asked Ben Wilson, and he said:
>> >> > "Browsers distribute software that includes the Root Certificate.
>> >> The
>> >> > software they distribute comes with an End User License Agreement.
>> >> An
>> >> > agreement between the CA and the Browser will often say, "2.
>> Grant
>> >> of
>> >> > License: Subject to the terms and conditions of this License, CA
>> >> hereby
>> >> > grants to Browser a non-exclusive, non-transferable license to
>> copy
>> >> and use
>> >> > one or more of CA's Root Certificates for the purpose of (i)
>> >> embedding such
>> >> > CA Root Certificates in Browser's Products, and (ii)
>> manufacturing,
>> >> > distributing and sublicensing, through multiple layers of
>> >> distribution, such
>> >> > Products.  Browser may sublicense to its End Users the right to
>> copy
>> >> and use
>> >> > the CA's Root Certificates, solely as such Root Certificates are
>> >> embedded in
>> >> > such Products, to (i) Browser's resellers and OEMs solely for the
>> >> purpose of
>> >> > licensing and distributing such Products and OEM Products, and
>> (ii)
>> >> to
>> >> > Browser's end users solely for the purpose of using such Products.
>> >> >
>> >> > "Some Root Agreements include End Users as intended third party
>> >> > beneficiaries.  For instance, an agreement might state, "
>> >> 'Certificate
>> >> > Beneficiaries' means, collectively, Subscribers, Subjects, ASVs
>> and
>> >> Relying
>> >> > Parties who actually rely on such Certificate during the period
>> when
>> >> it is
>> >> > Valid."  Then it will say, the CA shall ensure that every
>> Subscriber
>> >> enters
>> >> > into a binding agreement that includes the following covenants and
>> >> > warranties to all Certificate Beneficiaries, that the Subscriber
>> (i)
>> >> > provides complete and accurate information, (ii) protects its
>> Private
>> >> Key,
>> >> > (iii) accepts the Certificate as an accurate representation of
>> >> information,
>> >> > (iv) will use the Certificate and Key Pair appropriately, and (v)
>> >> will
>> >> > promptly report any key compromise to the CA."
>> >> >
>> >> > Let me know if you think that section should change.
>> >>
>> >> Hm, saying "Should [...] offer protections [which might be null]"
>> >> sounds
>> >> strange to me, and goes against the definition of should. They also
>> >> seem
>> >> to only apply to its relying parties, not all relying parties. I
>> also
>> >> expect such protections are not the same for all relying parties,
>> >> browser vendors and end users would quite possibly receive different
>> >> protections (e.g. emergency contacts).
>> >> Maybe the following would be sufficient: "These agreements, and any
>> >> protections offered by them to relying parties, should be
>> >> non-discriminatory."
>> >
>> >Since this is quasi-legal, I defer to Ben.
>> >
>> >> >> The following sentence in section 16 makes no sense:
>> >> >> "Historically, relying parties have been required to assess the
>> >> >> suitability of a CSP's policies and practices for the intended
>> >> usage."
>> >> >> As an end user relying on sites being secure, I have not once
>> looked
>> >> up
>> >> >> the CSP's policies, far less been required to do so by anyone...
>> >> >
>> >> > OK, I asked Ben Wilson and he started looking up legal documents
>> to
>> >> back this up. But what do you suggest? I think this sentence is an
>> >> introduction to the following idea that "Achieving the intended
>> level
>> >> of assurance also requires proper behavior by the relying
>> >> application.", and that's why we're publishing this document. I
>> suppose
>> >> we can remove the entire paragraph since it doesn't actually
>> recommend
>> >> anything. Is that what you suggest?
>> >>
>> >> Adding an "in order to" clause, stating that relying parties have
>> been
>> >> required to work "in order to" achieve some particular end result,
>> >> would
>> >> be one solution. E.g. "Historically, CSP's policies and practices
>> >> varied, and had to be assessed by relying agents in order to be
>> certain
>> >> of their suitability for the intended usage."
>> >>
>> >> Replacing "relying parties" with root store managers and application
>> >> software providers, would be another solution.
>> >> Removing the sentence would also work. Having some background
>> >> information is good though, so I don't recommend removing the
>> >> paragraph.
>> >
>> >I'll defer to Ben on this one too.
>> >
>> >-Rick
>> >_______________________________________________
>> >Public mailing list
>> >Public at cabforum.org
>> >https://cabforum.org/mailman/listinfo/public