Rick, 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 [mailto:[email protected]] Sent: Monday, September 29, 2014 3:01 PM To: Santosh Chokhani; Stephen Kent; [email protected] Subject: RE: [Trans] path validation Santosh, 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 http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx -Rick -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Santosh Chokhani Sent: Monday, September 29, 2014 11:28 AM To: Stephen Kent; [email protected] Subject: Re: [Trans] path validation <snip> 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 (4.2.1.12)), 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" _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
