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

Ben Wilson ben at digicert.com
Sun Jan 27 21:25:32 UTC 2013


Thanks, Rick.  I totally agree that we cannot allow EV display unless some
validity checking has occurred.  

 

I do not see any problems with the first issue regarding caching and/or
responding where a full handshake is not needed-that should continue to
display EV, but in response to your following paragraph, we definitely don't
want EV switching on and off over a short time frame.  I don't understand
why you are concerned about a subsequent MITM or if the attacker otherwise
changes the certificate to a different one.  How would a hacker break into
the connection and still get EV treatment?  Isn't this a totally different
issue not related to short-term caching?  (Is it related to a generic
vulnerability if SSL/TLS is incorrectly implemented by the client?)  

 

The only vulnerability I see is based on the TTL that the browser sets for
the cached response.   So overall, what is the reasonable period of time to
set for this situation?  Are there three or four use cases that would
require us to recommend different durations?

 

Thanks,

 

Ben

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rick Andrews
Sent: Tuesday, January 22, 2013 12:22 PM
To: public at cabforum.org
Subject: [cabfpub] Meta-Issues for EV App Dev Guidelines document (Meta
Issue 3)

 

As suggested on an earlier 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%20Proc
essing%20of%20EV%20SSL%20Certificates%20v.2

 

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

 

 

Meta-Issue #3: The document currently states: "Certificates for which
confirmation cannot be obtained should not be granted the EV treatment"

        

Brian Smith raised concerns about offline behavior (he wants Firefox to show
the EV Treatment in that case). Rick stated that this applies whenever a
full SSL handshake is performed. Since no SSL is done in offline mode, the
browser should rely on cached info. If it has cached the certificate and an
OCSP response, then it should be able to display the EV Treatment.

 

Brian also raised concerns about the EV indicator switching on and off and
confusing users. Rick agrees that it might be confusing, but asked what
should happen if a later OCSP fetch failed because an attacker was in the
middle or had otherwise changed the certificate to a different one? 

 

 

I welcome your comments.

 

-Rick

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130127/271a5f8f/attachment-0004.html>


More information about the Public mailing list