Re: RFC 3280bis and URI schemes without hostname

"David A. Cooper" <david.cooper@nist.gov> Wed, 05 December 2007 02:00 UTC

Return-path: <owner-ietf-pkix@mail.imc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjYo-0002YG-KS for pkix-archive@lists.ietf.org; Tue, 04 Dec 2007 21:00:26 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzjYm-0007S2-TV for pkix-archive@lists.ietf.org; Tue, 04 Dec 2007 21:00:26 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB51Cj6i061610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 18:12:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB51Cjsx061609; Tue, 4 Dec 2007 18:12:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB51Chg0061600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Tue, 4 Dec 2007 18:12:44 -0700 (MST) (envelope-from david.cooper@nist.gov)
Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id lB51BqkW022392 for <ietf-pkix@imc.org>; Tue, 4 Dec 2007 20:11:52 -0500
Received: from dhcp-13fa.ietf70.org ([129.6.222.41]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id lB51COvo002995 for <ietf-pkix@imc.org>; Tue, 4 Dec 2007 20:12:28 -0500
Message-ID: <4755FACF.6000403@nist.gov>
Date: Tue, 04 Dec 2007 17:11:43 -0800
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: ietf-pkix@imc.org
Subject: Re: RFC 3280bis and URI schemes without hostname
References: <tslwss04z9g.fsf@mit.edu> <474FF00E.3080305@cs.tcd.ie> <47509061.40402@nist.gov> <47517A07.2030205@cs.tcd.ie> <p06240515c37b41b90a81@[130.129.65.93]>
In-Reply-To: <p06240515c37b41b90a81@[130.129.65.93]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.cooper@nist.gov
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c

All,

During the PKIX meeting yesterday, there did not seem to be any 
objection to allowing subjectAltName extensions to include URIs, in the 
uniformResourceIdentifier field, that do not include fully qualified 
domain names.  I would propose the following text for section 4.2.1.6, 
which is a slight modification to Stephen's proposal:

   When the subjectAltName extension contains a URI, the name MUST be
   stored in the uniformResourceIdentifier (an IA5String).  The name
   MUST NOT be a relative URI, and it MUST follow the URI syntax and
   encoding rules specified in [RFC 3986].  The name MUST include both a
   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  URIs that
   include an authority ([RFC 3986], section 3.2) MUST include a fully
   qualified domain name or IP address as the host.  Rules for encoding
   internationalized resource identifiers (IRIs) are specified in 
section 7.4.

   As specified in [RFC 3986], the scheme name is not case-sensitive
   (e.g., "http" is equivalent to "HTTP").  The host part, if present, is
   also not case-sensitive, but other components of the scheme-specific-part
   may be case-sensitive.  Rules for comparing URIs are specified in 
section 7.4.


If this change is adopted, then as I read RFC 3986, we need to consider 
three types of URIs that may appear in the uniformResourceIdentifier field:

1) URIs that include an authority component in which the host is 
specified as a fully qualified domain name.

2) URIs that include an authority component in which the host is 
specified as an IP address.

3) URIs that do not include an authority component.

At the moment, the name constraints section of 3280bis only addresses 
the first case.  While I don't like the idea of applying different 
matching rules depending on whether the constraint is specified as an 
excludedSubtree or as a permittedSubtree, that seems to be the best 
option in this case.  The question then becomes, if name constraints 
extension specifies a constraint on URIs, how should URIs in the 
subjectAltName extension of type 2) or 3) be treated?  Should such names 
be ignored or should the presence of such names cause the certification 
path to be rejected.

I am inclined to think that URIs that do not include an authority should 
be ignored.  That is, they should be treated just as if they had been 
included in a different name form for which name constraints have not 
been defined.

For URIs that include an authority with the host specified as an IP 
address, I think 3280bis should that that they should be ignored, unless 
3280bis specifies how to apply IP address based constraints on URIs.


What do others think?  What should the name constraints section of 
3280bis state about the treatment of URIs that do not include an 
authority or that use an IP address for the host?  I'd be particularly 
interested in knowing how current implementations process name 
constraints on URIs when the host in the subject name is specified using 
an IP address.

Dave