Re: [Trans] path validation

Rick Andrews <> Mon, 29 September 2014 20:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 93EE11ABD3C for <>; Mon, 29 Sep 2014 13:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jLB_3tFcLos5 for <>; Mon, 29 Sep 2014 13:02:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 565081ABD36 for <>; Mon, 29 Sep 2014 13:02:10 -0700 (PDT)
X-AuditID: a66201d2-f79186d0000034ee-04-5429bac09e1f
Received: from ( []) by (Symantec Brightmail Gateway out) with SMTP id C9.DC.13550.0CAB9245; Mon, 29 Sep 2014 20:02:09 +0000 (GMT)
Received: from [] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by with esmtp (Exim 4.76) (envelope-from <>) id 1XYh96-0006rp-H4; Mon, 29 Sep 2014 20:02:08 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([]) with mapi; Mon, 29 Sep 2014 13:02:08 -0700
From: Rick Andrews <>
To: Santosh Chokhani <>, Stephen Kent <>, "" <>
Date: Mon, 29 Sep 2014 13:02:06 -0700
Thread-Topic: [Trans] path validation
Message-ID: <544B0DD62A64C1448B2DA253C011414607D1629904@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <> <> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <> <544B0DD62A64C1448B2DA253C011414607D162989C@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+NgFlrAIsWRmVeSWpSXmKPExsWyLInRTffgLs0Qg30/2Cw2zma0mHmd22Lt 44ssDsweU8+HerRu/8XqsWTJT6YA5igum5TUnMyy1CJ9uwSujE2b0gp2q1UcmnuMvYHxmnwX IyeHhICJxJUJG9khbDGJC/fWs3UxcnEICXxglLg9+w4jSEJI4BWjxOUFTBCJVYwS7xYeA0uw CehJbHl8Baibg0NEIF9i06c8kDCLgKrEvU09TCBhYQEViStfNEDCIkDhDTMfskDYYRLPDvwC s3kFoiS+7XvEArFqIrPEzIvxIDangK/E5e9tYJsYgW77fmoNE4jNLCAucevJfCaImwUkluw5 zwxhi0q8fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTFoheSYmDK26wTGAU n4VkxSwk7bOQtM9C0r6AkWUVo0xqco5hbklifmlJQWqFgZFecWVuIjDWkvWS83M3MULi7dIO xvuHdQ8xCnAwKvHwzl+tGSLEmlgGVHmIUYKDWUmEV24HUIg3JbGyKrUoP76oNCe1+BCjNAeL kjhvSghHiJBAemJJanZqakFqEUyWiYNTqoFxyYLWJ/ebVZxfCjid2iv57kWUlcHhFRNLzizb FXG5OVbM0NP34xeDuDtsjOJncr4s6eGfvadFa6OV1ULh3L87GHbPuryA61naR/X+NYIPTV5d iFr5PX0zb4jUDj0Jr9w1j00DErZLlK4JPMB5YW7J3Q3XWKRi+++KzGj57Pa3586HC/2L1PxP K7EUZyQaajEXFScCAEPVwACzAgAA
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 20:02:12 -0000


I'm making no judgments at all. I'm just trying to report the facts as I know them, to help explain why certain language is in the CABF Baseline Requirements.

Your second question needs to be directed to someone from Mozilla. I will point out, however, that Mozilla's policy is that technical constraints include not just EKUs but name constraints in the intermediate. Mozilla would probably say that if the proper name constraints are in the intermediate (limiting the intermediate, for example, to signing only certs for <something>, then any damage done by mis-issuance using that intermediate would be limited to that domain.


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


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"