Subject: Name constraint question

From: [email-masked] (Peter Gutmann)
Date: Tue, 01 Jul 2008 23:21:15 +1200

Here's one: Say an issuing cert contains a name constraint for (just for
argument's sake) a URI, and the subject cert contais a URI.  The issuer cert's
URI is invalid.  Alternatively, the subject cert's URI is invalid.

What should happen?  Is the output for the check true or false?

NB: Just because a URI is malformed doesn't mean that the relying party
software won't accept it, there's so much broken stuff out there that much web
software bends over backwards to interpret almost anything URI-like.  So
saying "the RP should reject it" won't work, the cert processing software has
to make the decision.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 02 Jul 2008 03:07:15 +1200

Stephen Kent <[email-masked]> writes:

>Name constraints checking does not imply any form of external validation on
>the "validity" of the name, for any type of name. The purpose of the
>extension is to constrain the range of names asserted in subordinate certs,
>not to ensure that the names are "valid" in some larger context. It could be
>very difficult to establish validity for many types of names.  For example,
>if a DNS name does not resolve for me, does that make it invalid?  Is it more
>valid if resolved using DNESEC vs. vanilla DNS? What if the IP address
>returned is not reachable, at the time I check it, ...?

But the checking rules require parsing URIs in order to apply the checks.
Here's an example of a malformed URI being used to avoid name constraints:

CA cert: excluded subtree, example.com
Subject cert, altName: ftp:/example.com

(non-matched as "ftp:/example.com", processed as FTP -> "example.com").  If
it's OK to have syntactically invalid URIs then this (and a million variants)
can be used to escape excluded subtrees, thus making them essentially useless
(actually you can already do that with character-set encoding tricks and
whatnot so excluded subtrees have always been a no-hoper for security
purposes, I'll bet no implementation in existance can catch even the most
basic trick like using "ex%41mple.com", let alone "ex%u0041mple.com",
"ex&#x41;mple.com", or "ex%EF%BC%A1mpple.com").

Maybe the RFC should simply deprecate excluded subtrees to avoid giving RPs
the erroneous impression that they're effective for anything.

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2008 10:19:05 -0400

>saying "the RP should reject it" won't work, the cert processing software has

Peter,

Name constraints checking does not imply any form of external 
validation on the "validity" of the name, for any type of name. The 
purpose of the extension  is to constrain the range of names asserted 
in subordinate certs, not to ensure that the names are "valid" in 
some larger context. It could be very difficult to establish validity 
for many types of names.  For example, if a DNS name does not resolve 
for me, does that make it invalid?  Is it more valid if resolved 
using DNESEC vs. vanilla DNS? What if the IP address returned is not 
reachable, at the time I check it, ...?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2008 12:22:50 -0400

Peter,

Sorry that I misunderstood your use of the term "valid" here. I agree 
with you that any name form that is used in the name constraints 
extension MUST be syntactically valid.

Steve

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 01 Jul 2008 12:05:47 -0700

This thread is taking on a delightful "Alice Through the Looking 
Glass" quality...

I am reminded of a phrase my uncle would sometimes employ:

   "LOOK!" said the blind man, to his deaf son,
    as they walked off the edge of the cliff...

____tony____

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 1 Jul 2008 15:20:18 -0400

Does anyone see similar pitfalls in DN (Geopolitical or dc component
based) based names?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tony Bartoletti
Sent: Tuesday, July 01, 2008 3:06 PM
To: [email-masked]
Subject: Re: Name constraint question

____tony____