Subject: [Trans] path validation

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Sep 2014 10:41:54 -0400

I realized, after I sent my reply, that Santosh's point wrt path validation
is important. I believe Ben indicated that he did not envision logs 
performing all
of the 5280 checks, just verifying the signatures in the path. So, I 
misspoke when
I noted that 6962-bis already called for path checking; it calls for it, 
but only
in a very superficial way.

Thus we need to decide if we believe that a sig-only check on a path 
consistent with
the CABF guidelines. I don't think it is. The Definitions section of the 
CABF guidelines
includes the following entry:

     Valid Certificate: A Certificate that passes the validation 
procedure specified in RFC 5280.

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 29 Sep 2014 18:28:26 +0000

Steve,

As I mentioned, I think log is a good place to ensure that hygiene of the path and not just the leaf certificate.

IMPLEMENTATION ISSUES
I do not know if an Appendix would help log operators with some of the past erroneous implementations or interpretations of RFC 5280.  I mention this if the log operators choose to use some of the existing platforms to implement path validation.  Newer versions may or may not have fixed some of these issues such as:

1.  Not enforcing name constraints on intermediate certificates in the path
2.  Interpreting name constraints as the only name forms allowed and rejecting certificates with other name forms.  For example, if the name constraints contain DN based names and SAN contain RFC 822 names, rejecting the certificates erroneously.
3. Misapplying name constraints on URI.  This has caused real problems in circles I work in.  Since not all URI schemes have authority component, the URI name constraint should not be applied to the ones that do not (e.g., even if URI name constraints are present, they do not apply to URN and certificates should not be rejected.

EKU PROCESSING
I went back to the CAB Forum document and it has no processing rules for EKU for the path.  But, based on their desire to constrain the path how some of the more popular implementation has done it, the following logic seems to make sense.

Assume n certificates in the certificate chain. Set the value of EKU for a certificate to Universal Set if the extension is absent or contains anyExtendedKeyUsage; otherwise set the value to the set of OIDs in the EKU extension.  Now, take the intersection of all n sets.  If the intersection is empty, the path validation fails.  If the intersection in Universal set, the end certificate can be used for any purpose.  Otherwise, the end certificate can be used for purpose(s) in the intersection.

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"

I only bring it up because 6962 seems to be using that as a baseline.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, September 29, 2014 10:42 AM
To: [email-masked]
Subject: [Trans] path validation

I realized, after I sent my reply, that Santosh's point wrt path validation is important. I believe Ben indicated that he did not envision logs performing all of the 5280 checks, just verifying the signatures in the path. So, I misspoke when I noted that 6962-bis already called for path checking; it calls for it, but only in a very superficial way.

Thus we need to decide if we believe that a sig-only check on a path consistent with the CABF guidelines. I don't think it is. The Definitions section of the CABF guidelines includes the following entry:

     Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.

Steve

_______________________________________________
Trans mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/trans

---

From: Rick Andrews <[email-masked]>
Date: Mon, 29 Sep 2014 12:00:51 -0700

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-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, September 29, 2014 11:28 AM
To: Stephen Kent; [email-masked]
Subject: Re: [Trans] path validation

<snip>

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 29 Sep 2014 19:13:27 +0000

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-masked]] 
Sent: Monday, September 29, 2014 3:01 PM
To: Santosh Chokhani; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Santosh,

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, September 29, 2014 11:28 AM
To: Stephen Kent; [email-masked]
Subject: Re: [Trans] path validation

<snip>

---

From: Rick Andrews <[email-masked]>
Date: Mon, 29 Sep 2014 12:26:47 -0700

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-masked]] 
Sent: Monday, September 29, 2014 12:13 PM
To: Rick Andrews; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Rick,

I thought so.  

-----Original Message-----
From: Rick Andrews [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 3:01 PM
To: Santosh Chokhani; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Santosh,

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, September 29, 2014 11:28 AM
To: Stephen Kent; [email-masked]
Subject: Re: [Trans] path validation

<snip>

---

From: David Leon Gil <[email-masked]>
Date: Mon, 29 Sep 2014 15:38:29 -0400

> 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.
>

We're talking about (non-normatively-specified) monitor servers here, right?

Log servers need to continue to accept based solely on signature validity;
otherwise they'll miss misissuance. (So *log* servers will necessarily be
agnostic about this.)

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 29 Sep 2014 19:43:57 +0000

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-masked]] 
Sent: Monday, September 29, 2014 3:27 PM
To: Santosh Chokhani; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Santosh,

-Rick

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

Rick,

I thought so.  

-----Original Message-----
From: Rick Andrews [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 3:01 PM
To: Santosh Chokhani; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Santosh,

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, September 29, 2014 11:28 AM
To: Stephen Kent; [email-masked]
Subject: Re: [Trans] path validation

<snip>

---

From: Rick Andrews <[email-masked]>
Date: Mon, 29 Sep 2014 13:02:06 -0700

Santosh,

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>.example.com), then any damage done by mis-issuance using that intermediate would be limited to that domain.

-Rick

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

Rick,

-----Original Message-----
From: Rick Andrews [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 3:27 PM
To: Santosh Chokhani; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Santosh,

-Rick

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

Rick,

I thought so.  

-----Original Message-----
From: Rick Andrews [mailto:[email-masked]] 
Sent: Monday, September 29, 2014 3:01 PM
To: Santosh Chokhani; Stephen Kent; [email-masked]
Subject: RE: [Trans] path validation

Santosh,

-Rick

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Monday, September 29, 2014 11:28 AM
To: Stephen Kent; [email-masked]
Subject: Re: [Trans] path validation

<snip>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 29 Sep 2014 12:34:19 -0800

On 9/29/14 11:26 AM, Rick Andrews wrote:
> 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.

We've received a reminder from our friendly area director not
to introduce any normative dependencies on CAB Forum documents
or processes, as well as a query about how much x.509 processing
should be specified, as well.

Melinda

---

From: Matt Palmer <[email-masked]>
Date: Tue, 30 Sep 2014 10:55:24 +1000

> enforce the use of technical constraints in intermediate CAs.

Logs shouldn't be enforcing *anything*.  A log isn't a judge, it's a record. 
The only constraints on what should be rejected from being accepted by a
log should be those things which prevent abuse sufficient to render a log
unusable.

- Matt

---

From: Jeremy Rowley <[email-masked]>
Date: Tue, 30 Sep 2014 01:17:42 +0000

+1. My thoughts exactly.

Matt Palmer <[email-masked]> wrote:

- Matt

---

From: Melinda Shore <[email-masked]>
Date: Mon, 29 Sep 2014 17:19:29 -0800

> Logs shouldn't be enforcing *anything*.  A log isn't a judge, it's a record. 

Thank you.

Melinda

---

From: Kyle Hamilton <[email-masked]>
Date: Mon, 29 Sep 2014 22:18:27 -0700

So, the CA is the executive, and the log is the public records clerk?

-Kyke H

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.