Rick, 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 [mailto:[email protected]] Sent: Monday, September 29, 2014 3:27 PM To: Santosh Chokhani; Stephen Kent; [email protected] Subject: RE: [Trans] path validation Santosh, 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 (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/) 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. -Rick -----Original Message----- From: Santosh Chokhani [mailto:[email protected]] Sent: Monday, September 29, 2014 12:13 PM To: Rick Andrews; Stephen Kent; [email protected] Subject: RE: [Trans] path validation 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
