Re: [Trans] path validation

Santosh Chokhani <> Mon, 29 September 2014 19:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6C3011ABD3B for <>; Mon, 29 Sep 2014 12:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.687
X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d3mDD4c74-YV for <>; Mon, 29 Sep 2014 12:43:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 582E31A9252 for <>; Mon, 29 Sep 2014 12:43:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,622,1406606400"; d="scan'208";a="2158424"
Received: from unknown (HELO ([]) by with ESMTP; 29 Sep 2014 15:43:58 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 15:43:58 -0400
From: Santosh Chokhani <>
To: Rick Andrews <>, Stephen Kent <>, "" <>
Thread-Topic: [Trans] path validation
Date: Mon, 29 Sep 2014 19:43:57 +0000
Message-ID: <>
References: <> <> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Trans] path validation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Sep 2014 19:44:01 -0000


Are you saying that the presence of EKU in CA certificates is simply gratuitous?

And how does technical constraining the CA without enforcement on the other end help relieve one of audit requirements?

To me, this all sounds like putting head in the sand and inviting the problems all over again that CT is supposed to solve.  If the CA goes rogue or is hacked, the only way to detect and reject such mis-issued certificates is to see if they were in compliance with EKUs CA was constrained for.  

May be that is not what you mean.  May be you mean not all CAs need to be technically constrained.  If so, the logic at the start of this mail thread is fine since the EKU constraint is only invoked when present.

Separately, in light of how some of most commonly used platforms view absence on EKU or presence of anyExtendedKeyUsage as legitimate code signing certificate, and not all parties agreeing on how to mitigate this concern, I see good security value in departure from 5280 by asserting (and more importantly enforcing) EKU in certification path. 

-----Original Message-----
From: Rick Andrews [] 
Sent: Monday, September 29, 2014 3:27 PM
To: Santosh Chokhani; Stephen Kent;
Subject: RE: [Trans] path validation


The CABF Baseline Requirements don't require the intermediate to be technically constrained, and most are not. The language about technical constraints is there to address Mozilla's CA policy ( which waives the audit and disclosure requirements for intermediates ("subordinates" in Mozilla's language) that are technically constrained. 

Since it's not an absolute requirement at this point (either from CABF or from individual browsers' policies) I suggest that log servers cannot enforce the use of technical constraints in intermediate CAs.


-----Original Message-----
From: Santosh Chokhani [] 
Sent: Monday, September 29, 2014 12:13 PM
To: Rick Andrews; Stephen Kent;
Subject: RE: [Trans] path validation


I thought so.  

But, the reason I made the comment is that the CABF document requires the CA to be "technically" constrained by using the EKU in the CA certificate.  To me that is the same as what Microsoft says.  Am I missing something?  Besides, the only way I see enforcement of this "technical constraint" coming is either the SCT provider doing the check or the relying party or both perform the check listed at the bottom of this mail thread.

-----Original Message-----
From: Rick Andrews [] 
Sent: Monday, September 29, 2014 3:01 PM
To: Santosh Chokhani; Stephen Kent;
Subject: RE: [Trans] path validation


I believe that text is there because Microsoft has been advocating the use of EKUs in intermediate certificates to limit their scope, and they've built nested EKU checking into their chain validation code. See


-----Original Message-----
From: Trans [] On Behalf Of Santosh Chokhani
Sent: Monday, September 29, 2014 11:28 AM
To: Stephen Kent;
Subject: Re: [Trans] path validation


BTW, I am confused by what the CABF document says in Appendix B item:
"Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (, however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide"