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

[Rick Andrews]

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