Re: [Trans] path validation

Rick Andrews <> Mon, 29 September 2014 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0BD2F1A9250 for <>; Mon, 29 Sep 2014 12:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.687
X-Spam-Status: No, score=-7.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XdEUDpuhYmEA for <>; Mon, 29 Sep 2014 12:26:53 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 695881A1BB4 for <>; Mon, 29 Sep 2014 12:26:53 -0700 (PDT)
X-AuditID: d80ac3f1-f791a6d0000069e3-17-5429b27c21bc
Received: from ( []) by (Symantec Brightmail Gateway out) with SMTP id 47.96.27107.C72B9245; Mon, 29 Sep 2014 20:26:52 +0100 (BST)
Received: from [] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by with esmtp (Exim 4.76) (envelope-from <>) id 1XYgaw-0002dU-LB; Mon, 29 Sep 2014 15:26:50 -0400
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([]) with mapi; Mon, 29 Sep 2014 12:26:49 -0700
From: Rick Andrews <>
To: Santosh Chokhani <>, Stephen Kent <>, "" <>
Date: Mon, 29 Sep 2014 12:26:47 -0700
Thread-Topic: [Trans] path validation
Thread-Index: AQHP2/OIMXe4GkeRfU2twSVntzsYm5wYYbDAgAATuQCAAAQLkIAAAucQ
Message-ID: <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <> <> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsVyg+vQb92aTZohBhPazSw2zma0mHmd22Lt 44ssDsweU8+HerRu/8XqsWTJT6YA5igum5TUnMyy1CJ9uwSujDnbL7EUfBap+H7hGmsD4zbB LkYODgkBE4m5PeVdjJxAppjEhXvr2boYuTiEBN4xSkyct48FwnnFKDGl6zkrhLOKUWJj21E2 kBY2AT2JLY+vsINMEhHIl9j0KQ8kzCKgKvH3XT8jSFhYQEXiyhcNkLAIUHjDzIcsELabROum 14wgNq9AlETv7R/MEOP/Mkrc778JNp5TwFfi7ZMJrCA2I9B130+tYQKxmQXEJW49mc8EcbWA xJI955khbFGJl4//QdWLStxpX88IUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCAtErKXFwxQ2W CYzis5CsmIWkfRaS9llI2hcwsqxilCkpLTYszi3JLy0pSK0wMNQrrsxNBMZbsl5yfu4mRnDM Hf64g/HoXsdDjAIcjEo8vLxrNUOEWBPLgCoPMUpwMCuJ8AYvBQrxpiRWVqUW5ccXleakFh9i lOZgURLn/RTCESIkkJ5YkpqdmlqQWgSTZeLglGpg5N11bZ/NtEuRd7d+bbbTmWqVUD379dz8 VqUd93wCBZ5sUV7EujBHrsC4O7q94wfPxE2FxYfP+v537knxPM6/i4fp2s5Nrv6eE5i9/3Vp FGkp96tdP5N6SXOFpTtn8e0ZS81Y7+fdj2na8mv5tekPN18MWH6zvNu+RuXP9lb5nnJemWCx 4PhSJZbijERDLeai4kQA3WTRMbUCAAA=
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:26:55 -0000


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"