<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<meta name="robots" content="noindex,nofollow">
<title>89 - Adopt Guidelines for the Processing of EV SSL Certificates v.2 - CAB-forum Wiki</title>
<script type="text/javascript" src="/wiki/moin_static193/common/js/common.js"></script>
<script type="text/javascript">
<!-- // GUI edit link and i18n
var gui_editor_link_href = "/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=edit&editor=gui";
var gui_editor_link_text = "Edit (GUI)";
//-->
</script>
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/wiki/moin_static193/modern/css/common.css">
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/wiki/moin_static193/modern/css/print.css">
<!-- css only for MS IE6/IE7 browsers -->
<!--[if lt IE 8]>
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/wiki/moin_static193/modern/css/msie.css">
<![endif]-->
<link rel="alternate" type="application/wiki" title="Edit" href="/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=edit">
<link rel="Start" href="/wiki/FrontPage">
<link rel="Alternate" title="Wiki Markup" href="/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=raw">
<link rel="Alternate" media="print" title="Print View" href="/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=print">
<link rel="Appendix" title="Guidelines for the processing of EV SSL certificates.doc" href="/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=AttachFile&do=view&target=Guidelines+for+the+processing+of+EV+SSL+certificates.doc">
<link rel="Appendix" title="Guidelines for the processing of EV SSL certificates.pdf" href="/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=AttachFile&do=view&target=Guidelines+for+the+processing+of+EV+SSL+certificates.pdf">
<link rel="Search" href="/wiki/FindPage">
<link rel="Index" href="/wiki/TitleIndex">
<link rel="Glossary" href="/wiki/WordIndex">
<link rel="Help" href="/wiki/HelpOnFormatting">
</head>
<body lang="en" dir="ltr">
<div id="page" lang="en" dir="ltr">
<ul id="pagelocation">
<li><a class="backlink" href="/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2?action=fullsearch&context=180&value=linkto%3A%2289+-+Adopt+Guidelines+for+the+Processing+of+EV+SSL+Certificates+v.2%22" rel="nofollow" title="Click to do a full-text search for this title">89 - Adopt Guidelines for the Processing of EV SSL Certificates v.2</a></li>
</ul>
<div dir="ltr" id="content" lang="en"><span class="anchor" id="top"></span>
<span class="anchor" id="line-1"></span><span class="anchor" id="line-2"></span><span class="anchor" id="line-3"></span><span class="anchor" id="line-4"></span><span class="anchor" id="line-5"></span><p class="line874">The latest version of the document is attached to this wiki page (.doc and pdf formats) <span class="anchor" id="line-6"></span><span class="anchor" id="line-7"></span><p class="line874">Open Issues: <span class="anchor" id="line-8"></span><div><table><tbody><tr> <td><p class="line862"># </td>
<td><p class="line862">Raised by </td>
<td><p class="line862">Section </td>
<td><p class="line862">Relevant Language </td>
<td><p class="line862">Issue </td>
<td><p class="line862">Rick's response </td>
</tr>
<tr> <td><span class="anchor" id="line-9"></span><p class="line862">1 </td>
<td><p class="line862">Yngve Pettersen </td>
<td><p class="line862">3. Normative References </td>
<td><p class="line862">"Guidelines for the Issuance and Management of Extended Validation Certificates version 1.4", CABForum, May 29, 2012. </td>
<td><p class="line862">Yngve asked "Should the EVSSL reference be so specific about the version, or is it possible to reference the most recent version instead?" </td>
<td><p class="line862">What do others think? </td>
</tr>
<tr> <td><span class="anchor" id="line-10"></span><p class="line862">2 </td>
<td><p class="line862">Yngve Pettersen </td>
<td><p class="line862">5. Introduction </td>
<td><p class="line862">"The CA/Browser Forum has defined minimum requirements for the issuance and management of Extended Validation certificates [EVSSL]." </td>
<td><p class="line862">Yngve asked "Does minimum requirements refer to the BR or EV guidelines? EV was minimum requirements at the time of the first document, but we now have the BR as a new minimum. I would suggest clarifying this section." </td>
<td><p class="line862">The EV Guidelines say "These Guidelines incorporate the Baseline Requirements established by the CA/Browser Forum by reference." Do we need further clarification? </td>
</tr>
<tr> <td><span class="anchor" id="line-11"></span><p class="line862">3 </td>
<td><p class="line862">Yngve Pettersen </td>
<td><p class="line862">10. Cryptographic Algorithms and Minimum Key Sizes </td>
<td><p class="line862">"The relying application should be capable of processing the cryptographic algorithms and key sizes listed in [EVSSL], with the additional specification that the effective key strength of symmetric algorithms must be at least 128 bits." </td>
<td><p class="line862">Yngve said "Ephemeral Diffie-Hellman (DHE) cipher suites: Most servers use 1024 bit, but a large number use 768 bit (in particular captive portals; example iBahn). Should DHE keysize be included in the determination of EV? What should the client do if the DHE keysize is too low (at present Opera retries with reordered cipher suite sequence if the keysize is less than 1024, but disabling the cipher suites may be better, since some servers ignore the reordering; this could be done for EV with too weak DHE). If so, what is too low? (IMO either less than 2048 bit or less than the site certificate keysize). Of course, an issue here is that this key size may be controlled by the server's code, not the configuration." </td>
<td><p class="line862">Should we add a restriction on DHE keysize? </td>
</tr>
<tr> <td><span class="anchor" id="line-12"></span><p class="line862">4 </td>
<td><p class="line862">Yngve Pettersen </td>
<td><p class="line862">12. Policy Identifier </td>
<td><p class="line862">"The relying application should 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" </td>
<td><p class="line862">Yngve suggested "Perhaps it needs to be made clear that the policy identifier (EV-OID) does not match if the non-root issuing CA certificate(s) of the chain does not contain either the EV-OID itself, or the any-policy OID?" </td>
<td><p class="line862">What do other browser vendors think? </td>
</tr>
<tr> <td><span class="anchor" id="line-13"></span><p class="line862">5 </td>
<td><p class="line862">Yngve Pettersen </td>
<td><p class="line862">13. Revocation Checking </td>
<td><p class="line862">"The application should follow HTTP redirects and cache-refresh directives." </td>
<td><p class="line862">Yngve said "Following redirects can cause trouble when dealing with captive portals. Opera does follow redirects for CRLs, but not OCSP. I think "cache-refresh" should not be used, instead use "cache-expiration". Maybe it should be specified that the client should not send or accept HTTP cookies when retrieving revocation information? (Opera does not send or accept cookie for CRL/OCSP/AIA)" </td>
<td><p class="line862">Rick says that this language was in the original document. He'd like to hear from other browser vendors before modifying it. </td>
</tr>
<tr> <td><span class="anchor" id="line-14"></span><p class="line862">6 </td>
<td><p class="line862">Geoff Keating </td>
<td><p class="line862">11. Certificate Contents </td>
<td><p class="line862">"The relying application should be capable of processing the certificate fields and extensions containing subject attributes that are described in [EVSSL]." </td>
<td><p class="line862">Geoff said "I understand the word 'processing' to mean 'does not unduly reject the certificate or crash'. For example, an automated system might expect an EV certificate but only check the domain name and ignore all subject fields, or examine only the domain name plus the organization field." </td>
<td><p class="line862">Rick said "I agree; I think we basically mean that it will accept as valid any certificate that conforms to the EV Guidelines." How much detail should we add? </td>
</tr>
<tr> <td><span class="anchor" id="line-15"></span><p class="line862">7 </td>
<td><p class="line862">Geoff Keating, Yngve Pettersen </td>
<td><p class="line862">10. Cryptographic Algorithms and Minimum Key Sizes </td>
<td><p class="line862">"The relying application should be capable of processing the cryptographic algorithms and key sizes listed in [EVSSL], with the additional specification that the effective key strength of symmetric algorithms must be at least 128 bits." </td>
<td><p class="line862">Geoff asked "did you intend to prohibit use of 3DES? 3DES has an effective key strength of 112 bits. (Maybe a bit less depending on how you define 'effective'.)" Likewise, Yngve said "What about Triple-DES? It may have 168 bit key material, but as far as I know it can be argued that its real strength is 112 bit, when a meet-in-the-middle brute force attack is used." </td>
<td><p class="line862">Rick said "I did not intend to prohibit 3DES. This Section is basically unchanged from the original. What do others think?" </td>
</tr>
<tr> <td><span class="anchor" id="line-16"></span><p class="line862">8 </td>
<td><p class="line862">Geoff Keating </td>
<td><p class="line862">6.1 Identifying an EV CSP </td>
<td><p class="line862">"An Application Software Supplier shall recognize a CSP that is qualified to issue EV SSL certificates by means of the CSP's audit report..." </td>
<td><p class="line862">Geoff said "This is not a close fit to what we actually do with audit reports. For example, although we require an initial audit report before accepting a CA, the timing of releases may mean that the CA becomes EV-enabled after that report expires. I understand what you mean, and it'd be nice to have better guidance on how to handle audit reports, but I'm not sure this section as written is a good idea." </td>
<td><p class="line862">Rick said "Would you be willing to suggest alternate wording? Not being an App Developer who manages a trust store, I don't have the background for this." </td>
</tr>
<tr> <td><span class="anchor" id="line-17"></span><p class="line862">9 </td>
<td><p class="line862">Ryan Sleevi </td>
<td><p class="line862">9. Certificate Path Validation </td>
<td><p class="line862">"The relying application shall validate the certificate in accordance with [RFC 5280] Section 6." </td>
<td><p class="line862">Ryan wondered what this would mean for DANE Type 3 Validation (no PKIX validation) </td>
<td><p class="line862">We had a big side discussion on DANE that went off for a while. Rick suggests we either say nothing about DANE, or debate this as a Forum. </td>
</tr>
<tr> <td><span class="anchor" id="line-18"></span><p class="line862">10 </td>
<td><p class="line862">Iñigo </td>
<td><p class="line862">n/a </td>
<td><p class="line862">n/a </td>
<td><p class="line862">Iñigo suggested I use "ETSI rules" which suggest "shall" and "shall not", and say 'Do not use "must" as an alternative for "shall"'. (This will avoid any confusion between the requirements of a document and external statutory obligations.)" </td>
<td><p class="line862">Rick is concerned that this doesn't agree with RFC 2119, which allows MUST. </td>
</tr>
<tr> <td><span class="anchor" id="line-19"></span><p class="line862">11 </td>
<td><p class="line862">Rick </td>
<td><p class="line862">n/a </td>
<td><p class="line862">n/a </td>
<td><p class="line862">Rick asked "Would there be value in adding a section documenting the complete set of EV roots along with the EV OIDs associated with them? I think that this document is the right place for that info." </td>
<td><p class="line862"> </td>
</tr>
<tr> <td><span class="anchor" id="line-20"></span><p class="line862">12 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Certificates for which confirmation cannot be obtained...should not be treated as trusted certificates." </td>
<td><p class="line862">Brian said "IMO, it would be better to say something like "Certificates for which confirmation has never been obtained must not be granted the EV treatment, and applications should check for revocation of EV certificates at least as frequently as they check for non-EV certificate revocation." </td>
<td><p class="line862">Rick thinks that this language is good, but wants to hear from other browser vendors. Yngve said +1 to the language in the document. </td>
</tr>
<tr> <td><span class="anchor" id="line-21"></span><p class="line862">13 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Certificates for which confirmation cannot be obtained...should not be treated as trusted certificates." </td>
<td><p class="line862">Brian points out that this mandates hard-fail. He also 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." </td>
<td><p class="line862">Rick thinks that if it were made a requirement, no browser would be at a disadvantage. He feels strongly that browsers should be free to innovate on GUI and other features, not on security-related actions. </td>
</tr>
<tr> <td><span class="anchor" id="line-22"></span><p class="line862">14 </td>
<td><p class="line862">Brian Smith, Gerv Markham </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Certificates for which confirmation cannot be obtained...should not be treated as trusted certificates." </td>
<td><p class="line862">Brian said "I think that in order to get the type of agreement between vendors that we need for that, we need to have a completely open standard for revocation checking behavior in an open, nearly-universally-respected forum like IETF, W3C, and/or WHATWG, that has well-established IPR rules. Then we probably need to get explicit sponsorship/endorsement of that standard from a significant plurality of key implementers. I think attempting such agreement within CABForum is counter-productive. CABForum is too-frequently perceived as a "cartel" or similar; even though such characterizations of CABForum may be completely wrong, IMO it is not worth the effort and time needed to correct them when there are already alternative standards bodies. Also, 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. Accordingly, I would really like CABForum to avoid making recommendations about revocation checking (in particular) any more than necessary, beyond referring to appropriate standards/recommendations from the aforementioned organizations." </td>
<td><p class="line862">Rick thinks that those other organizations take much more time to come to agreement, and that the CAB Forum has just the right participants in it. </td>
</tr>
<tr> <td><span class="anchor" id="line-23"></span><p class="line862">15 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Certificates for which confirmation cannot be obtained should not be granted the EV treatment" </td>
<td><p class="line862">Brian raised concerns about offline behavior (he wants Firefox to show the EV Treatment in that case). </td>
<td><p class="line862">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. </td>
</tr>
<tr> <td><span class="anchor" id="line-24"></span><p class="line862">16 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Certificates for which confirmation cannot be obtained should not be granted the EV treatment" </td>
<td><p class="line862">Brian raised concerns about the EV indicator switching on and off and confusing users. </td>
<td><p class="line862">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? </td>
</tr>
<tr> <td><span class="anchor" id="line-25"></span><p class="line862">17 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">n/a </td>
<td><p class="line862">n/a </td>
<td><p class="line862">Brian said that this document should have a section that defined requirements for servers. </td>
<td><p class="line862">Rick feels this document should be limited to app developers in the interest of keeping it simple. Also Rick argued that the intent of the doc has always been to provide guidance for browsers and other SSL clients, not servers. </td>
</tr>
<tr> <td><span class="anchor" id="line-26"></span><p class="line862">18 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">n/a </td>
<td><p class="line862">n/a </td>
<td><p class="line862">Brian said "it is important that we make corresponding changes to the baseline requirements to add something like the following: "CAs must advise their customers that they implement the TLS Certificate Status Request Extension (better known as OCSP Stapling)" </td>
<td><p class="line862">Since this is about BR, not this doc, Rick suggested that Brian start another thread. </td>
</tr>
<tr> <td><span class="anchor" id="line-27"></span><p class="line862">19 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">n/a </td>
<td><p class="line862">n/a </td>
<td><p class="line862">Brian would like the document to state that if the app uses OCSP, it should support stapling. </td>
<td><p class="line862">Rick believes that's orthogonal to this document. OCSP Stapling is being pushed elsewhere, and why add it if it's not a MUST? </td>
</tr>
<tr> <td><span class="anchor" id="line-28"></span><p class="line862">20 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Applications should confirm that the EV certificate has not been revoked before accepting it." </td>
<td><p class="line862">Brian stated "I think it is important to have latitude in how long we accept a stale OCSP response." </td>
<td><p class="line862">Rick thinks that browsers should never accept a stale OCSP response, especially for an EV cert. </td>
</tr>
<tr> <td><span class="anchor" id="line-29"></span><p class="line862">21 </td>
<td><p class="line862">Brian Smith </td>
<td><p class="line862">13. Revocation Requirements </td>
<td><p class="line862">"Applications should confirm that the EV certificate has not been revoked before accepting it. This includes verifying the revocation status of any intermediate CA certificates, in conformance with [RFC 5280] Section 6.1.3." </td>
<td><p class="line862">Brian pointed out that the RFC allows for the use of "out-of-band" mechanisms to determine a cert's status, and Mozilla relies on CAs contacting them if an intermediate is revoked. </td>
<td><p class="line862">Rick says that CAs have built large infrastructures for transmitting cert status; he doesn't want to also have to deal with an insecure out-of-band mechanism and one that might be different for every browser. Also, he believes the EV should represent stronger revocation checking as well as strong authentication procedures. </td>
</tr>
</tbody></table></div><span class="anchor" id="line-30"></span><span class="anchor" id="line-31"></span><span class="anchor" id="line-32"></span><span class="anchor" id="bottom"></span></div><p id="pageinfo" class="info" lang="en" dir="ltr">89 - Adopt Guidelines for the Processing of EV SSL Certificates v.2 (last edited 2012-12-04 18:31:49 by <span title="RickAndrews @ 198.6.50.15[198.6.50.15]"><a class="nonexistent" href="/wiki/RickAndrews" title="RickAndrews @ 198.6.50.15[198.6.50.15]">RickAndrews</a></span>)</p>
<div id="pagebottom"></div>
</div>
</body>
</html>