[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Wed Nov 5 10:53:01 MST 2014

Thanks for the clarification, Ryan.

Not to argue, but I would point out that if a CA is discovered to be using an (unconstrained, unmarked) intermediate from a trusted root to issue SSL certs without subjecting that intermediate and cert to full WebTrust/ETSI audit coverage – that would be a major violation of the Chrome and Firefox root program rules.  True, you would only discover that violation after the fact – but that’s the same as if the CA marked the intermediate as “usable for SSL” and then failed to subject it and EE certs to CA’s audit regime.  In both cases, the browsers would find out about the violation long after the fact.

Given it’s a violation in both cases, and browsers will find out late in both cases – what is the advantage in requiring the intermediates to be marked?

It seems the browsers have to come up with effective sanctions or other measures against the non-complying CA in both cases…

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Wednesday, November 05, 2014 9:38 AM
To: Kirk Hall (RD-US)
Cc: Gervase Markham; CABFPub
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Under the current audit requirements, a CA can issue an intermediate that has full power and capability of issuing trusted TLS certs, and then declare it out of scope of audit, because they don't "intend" for it to issue TLS certs.

This hand-wave does not require disclosure to auditors, nor to root programs, and yet still provides the same risk profile as incidents such as DigiNotar or India CCA.

Gerv is proposing a technical means to express this intent, so that it is clear to all parties the risk profile involved. Gerv's proposal is "opt-in" - that is, by a certain timeframe, all CAs must reissue to conform to the scheme, and anyone not conforming to the scheme is out of scope, and UAs will be updated to require certs conform.

My proposal is "opt out" - by declaring every certificate transitively issued by a root to be in scope for the BRs, the burden is placed upon the CA to use technical means to exclude their "non-TLS" intermediates from being in scope. This is weaker in some ways (it lacks the hard enforcement on the client side that Gerv proposes), but as both schemes rely on auditors, I believe they represent the same effective risk profiles.
On Nov 5, 2014 9:29 AM, "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Gerv, I'm slow on this argument, but I'm trying to figure out why markers in intermediates are important.

Under the current scheme, it seems the trusted status of the root is what's important, not the status of intermediates.  CAs must get WebTrust/ ETSI audits covering their operations from those roots to be trusted and included in the browser root store.  The audits are supposed to cover all (SSL) operations from that root.  Ultimately, it's a binary yes/no decision on whether to keep the root in the root store based on audit results, plus compliance with other root program requirements.  I suppose rogue intermediates from the roots can also be explicitly untrusted by browsers if needed.

What are the objectives of the proposals to put markers (EKUs or OIDs) in intermediates?  Is it not possible to meet those objectives using the current system of trusted root / audit of all (SSL) operations from that root?

Just curious.

-----Original Message-----
From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>] On Behalf Of Gervase Markham
Sent: Monday, November 03, 2014 11:46 AM
To: CABFPub
Subject: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Hi everyone,

I wonder if the BRs should say that all non-root certs in a chain issued for SSL server use, which were issued after <date>, should have EKU id-kpServerAuth in them. Date would be, say, six months from now.

This is primarily aimed at intermediates; EE certs all currently have this anyway. It would mean that, over time (years) as intermediates got replaced, we could eventually move to a position where it was entirely clear what certs were intended for Web PKI SSL use and what certs were not.

Currently, any intermediate in the world issued by a publicly-trusted root can issue for SSL, even those intermediates which are not intended for such use. This leads to numerous problems, including the question of whether such intermediates need to be covered by a BR audit. Once this change had filtered through, it would be clear - they would not be.

AIUI, EKU "chaining" (i.e. requiring an EKU to be present all the way up the chain) is not standard, but is implemented in NSS and elsewhere.

I know this is a thing which only pays off in the long term, but I still think it's worth it. Does this make any sense, or have I missed something obvious? :-)

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>

_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141105/263aa319/attachment.html 