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

[Rick Andrews]

Kirk,

Yes, I’d say they’re aspirational in that they’re guidelines and not requirements, but I hope to achieve consensus on what the Forum thinks makes sense to add. I could add lots of other suggestions but I won’t unless most of us agree that they make sense.

-Rick

From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com]
Sent: Wednesday, December 12, 2012 11:34 AM
To: Rick Andrews; public at cabforum.org
Subject: RE: [cabfpub] Meta-Issues for EV App Dev Guidelines document (Meta Issue 2)

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




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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121212/5f9cdaba/attachment-0004.html>