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
- RFC 3280bis and URI schemes without hostname Sam Hartman
- Re: RFC 3280bis and URI schemes without hostname Stephen Farrell
- Re: RFC 3280bis and URI schemes without hostname Paul Hoffman
- Re: RFC 3280bis and URI schemes without hostname Paul Hoffman
- Re: RFC 3280bis and URI schemes without hostname Sam Hartman
- Re: RFC 3280bis and URI schemes without hostname David A. Cooper
- Re: RFC 3280bis and URI schemes without hostname Stephen Farrell
- Re: RFC 3280bis and URI schemes without hostname Stephen Kent
- Re: RFC 3280bis and URI schemes without hostname David A. Cooper
- Re: RFC 3280bis and URI schemes without hostname David A. Cooper
- Re: RFC 3280bis and URI schemes without hostname David A. Cooper