[cabfpub] Meta-Issues for EV App Dev Guidelines document (Meta Issue 2)

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Wed Dec 12 19:33:30 UTC 2012


Rick - would it be fair to say that the EV App Dev Guidelines are "aspirational" only, meaning that no one is mandated to follow the recommendations - just strongly recommended to follow them?

If that's true, then I think it is appropriate to include requirements like what you included below - meaning no OCSP or CRL response for an EV cert means the cert "should" be treated as untrusted.  I think we should include that in the Guidelines.

If an application (including browser) doesn't want to comply with that recommendation, it will not be required to - there is no mandate to comply.  Correct?

Assuming I'm reading this all correctly, I would say we should not water down our recommendations.  It's up to others (browsers and applications) to decide whether they want to comply or not.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Tuesday, December 11, 2012 5:06 PM
To: public at cabforum.org
Subject: [cabfpub] Meta-Issues for EV App Dev Guidelines document (Meta Issue 2)

As suggested on the last call, I've handled a lot of the minor issues in this doc and grouped the remaining ones into meta-issues (five of them). I'll send out emails periodically to have discussion on each. This is the second.

The issues list and the doc itself can be found on the wiki at https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2

NOTE that I especially need input from browser vendors. This is your document.

Meta-Issue #2

The problem text is this:
"Certificates for which confirmation (read: revocation status) cannot be obtained...should not be treated as trusted certificates."

Brian Smith points out that this mandates hard-fail. I agree, but think that might be appropriate for EV certs. I also realize that mandating hard-fail is a non-starter for many, but without this sentence, we're saying that if you can't get revocation status for an EV cert, it's acceptable to drop it down to an ordinary trusted cert. I strongly disagree with that. EV should stand for something more than just slower vetting.

Brian said "Practically speaking, I think it would be bad for us to support standards/recommendations/guidelines that, if we implemented them, would result in us failing to load websites more frequently than other browsers do and/or if it means we would not be able to be as fast as browsers that do not implement the standards/recommendations/guidelines." But if all browsers agree to do this, then none will be at a disadvantage compared to the others. I think that browsers should be free to innovate and compete on features, but should be held to the same security standards.

Brian also feels that the CAB Forum is the wrong place to come to agreement on this. He said "it seems much better for us to use the well-established W3C and IETF IPR rules rather than spending time on IPR rules for CABForum technical specifications." I strongly disagree - CAB Forum has the right participants in it, can move more quickly than standards bodies, and CAB Forum created EV in the first place.

I welcome your comments.

-Rick


<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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121212/e9d8ea27/attachment-0004.html>


More information about the Public mailing list