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

[Ryan Sleevi]

On Thu, Dec 6, 2012 at 5:11 PM, Rick Andrews <Rick_Andrews at symantec.com>wrote:

>  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.
>
> 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
> *<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 #1
>
> The problem text is this:
> Section 10: “…the effective key strength of symmetric algorithms must be
> at least 128 bits…”
> Section 13: “The application should follow HTTP redirects and
> cache-refresh directives. Response time-out should not be less than three
> seconds”
>
> For EV certs, do browsers more strictly check DHE key sizes and policy
> OIDs in intermediate certificates?
>

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.

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.


>
> 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?
>

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"

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.

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".

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.

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.


>
> 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.
>

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.

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.
Windows' CryptNet/CryptoAPI respects HTTP caching directives for resource
fetches.
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.
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.


>
> -Rick
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121206/dbed8e92/attachment-0004.html>