Re: Name constraint question
Stephen Kent <kent <at> bbn.com>
2008-07-01 16:22:50 GMT
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",
>"exAmple.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.