<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><br><br><div class="gmail_quote">On Thu, Dec 6, 2012 at 5:11 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">






<div>
<font face="Calibri, sans-serif">
<div>As suggested on the call today, 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 first.</div>

<div> </div>
<div>The issues list and the doc itself can be found on the wiki at <a href="https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2" target="_blank"><font color="#0000FF"><u>https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2</u></font></a></div>

<div> </div>
<div>NOTE that I especially need input from browser vendors. This is your document. </div>
<div> </div>
<div>Meta-Issue #1</div>
<div> </div>
<div>The problem text is this:</div>
<div>Section 10: “…the effective key strength of symmetric algorithms must be at least 128 bits…”</div>
<div>Section 13: “The application should follow HTTP redirects and cache-refresh directives. Response time-out should not be less than three seconds”</div>
<div> </div>
<div>For EV certs, do browsers more strictly check DHE key sizes and policy OIDs in intermediate certificates?</div></font></div></blockquote><div><br></div><div>In my examination of the implementation of Google Chrome, Mozilla Firefox, and Apple's Security Framework, I have not seen any more-stringent checks upon EV, nor upon the ciphersuites negotiated with servers that assert EV certificates. While each of the aforementioned applications do include checks on basic cryptographic sanity and minimum strengths, they do not, to my knowledge, differentiate between EV and non-EV for purposes of TLS.</div>
<div><br></div><div>In my examinations of Microsoft Windows RTM & SPs for versions of XP - 7, this is also true. However, there may have been post-SP updates that have changed this behaviour since I last tested. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font face="Calibri, sans-serif"><div> </div>
<div> </div>
<div>Also, 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?" What do other browser
vendors think? Do you do any such checks today?</div></font></div></blockquote><div><br></div><div>I would hope that all implementations are performing the 'sane' validation process and validating the valid_policy_tree of the validated chain contains the EV-OID - either through supplying the EV OID as part of the user-initial-policy-set [RFC 5280 6.1.1.c ] or by examining the X.509 "authorities-constrained-policy-set"</div>
<div><br></div><div>Microsoft, Apple, Google, and Mozilla all implement this check in some form. From my research, Microsoft, Google, and Mozilla do so via supplying the EV policy via the user-initial-policy-set (which means policyMappings and such MAY be used). This primarily is to permit the path discovery (not validation) algorithm to select and order appropriate candidate chains, in the event there exist versions of intermediates that do assert the EV OID and versions of intermediates that do not. Apple simply validates that the chain terminates in an EV-enabled root and then examines each intermediate certificate in the validated chain for the asserted OID. For cases where multiple copies of intermediates exist, Apple includes the 'preferred' version (asserting the EV OID) and manipulate the chain-to-be-validated to ensure these certificates are preferred over any client/user-supplied intermediates.</div>
<div><br></div><div>It appears the linguistic ambiguity was introduced when EV 1.1 was updated to EV 1.2. EV 1.1, Appendix B, Section 2 required certificatePolicies be present, and in textual form, listed "anyPolicy if subordinate CA is controlled by root, explicit EV policy if it is not". When 1.2 was released, the language was changed to explicitly state "Otherwise, it MAY contain the anyPolicy identifier".</div>
<div><br></div><div>While this change makes sense when considering the intent - that is, to allow subordinate CAs which are operated by the entity that controls the root CA to assert policies other than anyPolicy, I believe the intent was that by not asserting anyPolicy, they would be asserting whatever *other* policies AND the EV policy OID. That's certainly how I interpreted the change.</div>
<div><br></div><div>It seems to me that this language/ambiguity SHOULD be first remedied in the EV Guidelines themselves, but I do agree with Yngve that the guidelines should provide guidance to ensure that applications are respecting RFC 5280's & X.509's treatment of policy OIDs.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font face="Calibri, sans-serif"><div> </div>
<div> </div>
<div>For EV certs, do browsers specifically follow HTTP redirects and comply with cache directives? I would only add these items if there is consensus to do so among the browser vendors.</div></font></div></blockquote><div>
<br></div><div>Respectfully, on the topic of redirects, I believe the language should be that servers/CAs SHOULD NOT use HTTP redirects. Ideally this would be MUST NOT if there was consensus, but I suspect for now, it remains a way for CAs to differentiate themselves and their performance characteristics to clients. However, I do not believe clients MUST support redirects, on the basis that for performance reasons, a client may determine that CAs participating in their program MUST NOT use them.</div>
<div><br></div><div>With respect to cache directives, Google Chrome (when used on Linux, ChromeOS, iOS, or Windows) does respect the server caching directives for fetching resources like AIA, CRLs, or OCSP responses.</div>
<div>Windows' CryptNet/CryptoAPI respects HTTP caching directives for resource fetches.</div><div>If I recall correctly, OS X through 10.8 does not support the HTTP caching directives, but does maintain an internal cache for OCSP, AIA, and CRLs. Geoff can confirm this better though.</div>
<div>If I recall correctly, only Mozilla Firefox's code for OCSP fetching (for EV certs) respect the HTTP caching directives, but that may be incorrect. I don't know if the HTTP callbacks are actually glued up to any persistent user cache, so it may only be in memory.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font face="Calibri, sans-serif"><span class="HOEnZb"><font color="#888888">
<div> </div>
<div>-Rick</div>
<div> </div>
</font></span></font>
</div>

<br>_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div>