Re: [Trans] path validation

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37DEB1A9250 for <>; Mon, 29 Sep 2014 12:13:32 -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 Z4_iB2de20ig for <>; Mon, 29 Sep 2014 12:13:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17A5F1A9248 for <>; Mon, 29 Sep 2014 12:13:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.04,622,1406606400"; d="scan'208";a="4259837"
Received: from unknown (HELO ([]) by with ESMTP; 29 Sep 2014 15:13:30 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0195.001; Mon, 29 Sep 2014 15:13:28 -0400
From: Santosh Chokhani <>
To: Rick Andrews <>, Stephen Kent <>, "" <>
Thread-Topic: [Trans] path validation
Thread-Index: AQHP2/OIMXe4GkeRfU2twSVntzsYm5wYYbDAgAATuQCAAAQLkA==
Date: Mon, 29 Sep 2014 19:13:27 +0000
Message-ID: <>
References: <> <> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607D1629838@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:13:32 -0000


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"