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

[Rick Andrews]

Sigbjørn,

Comments inline. No new doc attached; I'll wait until I get your responses to my questions.

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Sigbjørn Vik
> Sent: Wednesday, October 16, 2013 2:35 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Ballot 89, Again (Publish Recommendations for
> the Processing of EV SSL Certificates v.2)
> 
> New set of docs, new set of comments :)
> 
> "Relying party software" is still used in the foreword and the
> definition of Application Software Provider, and I still don't know
> what it means...

I added a definition to Section 4. I copied the definition from the BRs; that should be good enough.

> Nitpick: I think that the term "application software" is a superfluous
> term to start out with, but according to the common definition (user
> interacting software), verification libraries do not belong. Maybe call
> it "EV applications" instead?

I left this as is, because the BRs and EV Guidelines also use the term. Why create another term?

> Whenever "Root store manager" is mentioned, "or Application Software
> Provider" is also mentioned. Maybe update the definition to say what we
> really mean instead. E.g. "In some cases the application software
> supplier might perform some of the root store management, in which case
> it is to be considered as a root store manager for those purposes."

Before I change this, I ask for clarification: Google and now Opera don't manage their own root stores (except for Chrome on Android), but I think they are among the intended audience for this document. Do you agree? Do you think Opera or Google would assert that they're not root store managers?

> "User Agent Software" doesn't make sense. "User agent" means
> specialized software, so drop the last "Software" from all mentions.

Agreed; change made.

> I believe section 6 discusses root stores, not application software in
> general. E.g. it does not apply to Opera.

Wait a minute - I'm pretty sure that Chrome keeps its own list of EV-capable roots, over and above what the platform might have. And I would expect that Opera would work the same way. The way I understood it, Chrome could decide to untrust a root for EV (for example) even though the underlying platform trusted it for EV. If that's true for Chrome and Opera, then doesn't Section 6 apply? Shouldn't Chrome and Opera examine audit reports and maintain the EV OIDs for each EV root?

> Section 11, last sentence, should probably mention that it applies to
> all application software, not just verification libraries.

Good catch. I changed it to " Therefore, the Subject OU attribute should not be treated as trustworthy by any Application Software."

> Section 13, first paragraph. Verification libraries do not accept or
> reject certificates, they only validate/verify.

Changed to "Certificate verification software should confirm that the EV certificate has not been revoked as part of its verification process."

> Why is section 9 only a "should" on non-validating certificates, while
> section 13 is a "must" on non-revocation checked certificates? Surely a
> non-validating certificate is worse than one that hasn't been
> revocation checked?

Good point. I changed Section 9 to a "must". If the chain doesn't validate, I don't see any reason why a user agent should still show the EV treatment.

> I still think section 15.1 is contradictory. Imo, the word
> "incorporation"
> does not exist in the subset of English vocabulary called "human
> readable", so the section is impossible to fulfill. I also don't see
> how e.g. Opera can ensure that Microsoft's certificate viewer adhere to
> this section. Alternate (hopefully non-controversial) text:
> "Certificate viewers should provide text equivalents for any OIDs shown
> to end users."	

I guess Chrome and Opera are special cases in that they don't include their own certificate viewer functionality. I changed it to "Certificate Viewers should provide text equivalents for any OIDs shown to end users. For example, these EV-specific OIDs used in Subject Distinguished Name fields should be displayed as follows (translated accordingly):"

-Rick