Name constraint question

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.

Re: Name constraint question

At 11:21 PM +1200 7/1/08, Peter Gutmann wrote:
>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.

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

Re: Comments on draft-ietf-pkix-tac-00.txt

At 12:02 PM +0200 7/1/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m61A2c5J025564
>
>Steve,
>
>It looks like the main motivation is to (finally) find an 
>application for the split key and blind signing mechanism.
>
>The crypto security should be not the central point.

I think it's fair to say that these crypto security mechanisms (split 
key signing and blind signatures) offer greater security than what is 
available from relying only on procedural security promises.

>  There is no way proposed in the draft so that a RP can know that 
>the split key and blind signing aspects occurred or not.

True. it is invisible to RPs.

>If the draft goes along, I would see the place for two schemes:
>
>a) a simpler scheme without the split key and blind signing aspects 
>of the design,
>b) a more complex scheme with the split key and blind signing 
>aspects of the design.
>

Re: Name constraint question

Stephen Kent <kent <at> bbn.com> 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.

Re: Name constraint question

At 3:07 AM +1200 7/2/08, Peter Gutmann wrote:
>Stephen Kent <kent <at> bbn.com> 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.

Re: Name constraint question

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____

RE: Name constraint question

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

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Tony Bartoletti
Sent: Tuesday, July 01, 2008 3:06 PM
To: ietf-pkix <at> imc.org
Subject: Re: Name constraint question

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____

Re: Comments on draft-ietf-pkix-tac-00.txt

RE: "other certs" extension straw poll

Re: Comments on draft-ietf-pkix-tac-00.txt

At 2:11 PM +0200 7/2/08, Denis Pinkas wrote:
>Content-Type: text/html
>X-MIME-Autoconverted: from 8bit to quoted-printable by 
>balder-227.proper.com id m62CBX9E005364
>
>Steve,
>
>In response to your question:
>
>Obviously,  I am NOT in favor of it, since it appears that there is 
>no intent to pass major change controls to the WG.
>Authors may submit Informational RFCs without the support of the WG.
>
>Denis
>

Denis,

The authors will abide by the same rules as anyone who submits a 
document to a WG.

Some but not ALL of your suggested design changes were accepted. That 
hardly seems unreasonable at this stage of the discussion. If we 
rejected every I-D that had not incorporated EVERY change that you 
unilaterally proposed, I'm not sure that PKIK would have published 
any RFCs .

Steve