Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt
"Mattes, David" <david.mattes@boeing.com> Wed, 05 May 2010 21:36 UTC
Return-Path: <david.mattes@boeing.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7493A6D1A for <hipsec@core3.amsl.com>; Wed, 5 May 2010 14:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level:
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kevUJwoMm0R for <hipsec@core3.amsl.com>; Wed, 5 May 2010 14:36:15 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id ADA493A68EB for <hipsec@ietf.org>; Wed, 5 May 2010 14:36:11 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o45LZbm0011081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 May 2010 14:35:44 -0700 (PDT)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o45LZaaw005377; Wed, 5 May 2010 16:35:36 -0500 (CDT)
Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o45LZa0e005335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 5 May 2010 16:35:36 -0500 (CDT)
Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 5 May 2010 14:35:35 -0700
From: "Mattes, David" <david.mattes@boeing.com>
To: Samu Varjonen <samu.varjonen@hiit.fi>
Date: Wed, 05 May 2010 14:35:34 -0700
Thread-Topic: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt
Thread-Index: AcrqlIKCqOyyaqnoTN6fwJpux7lMhgCBhLNw
Message-ID: <E330FAC0AD42A34E90F3467F5A37AA37254A1F3F23@XCH-NW-11V.nw.nos.boeing.com>
References: <20100428084501.795053A6869@core3.amsl.com> <E330FAC0AD42A34E90F3467F5A37AA372549A239E2@XCH-NW-11V.nw.nos.boeing.com> <4BDE7EEB.6080103@hiit.fi>
In-Reply-To: <4BDE7EEB.6080103@hiit.fi>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hipsec@ietf.org" <hipsec@ietf.org>
Subject: Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 May 2010 21:36:16 -0000
> > Section 3, can we add another example that describes a managed PKI > environment? If you agree with my comment about HITs in the > certificate, I will write up an example for this case. > > > > This is one of the remaining items on the todo list and we would > appreciate your > contribution. > Here is proposed text for Section 3 and Section 4: 3. X.509.v3 Certificate Object and Host Identities When using X.509.v3 certificates to transmit information related to HIP hosts, HITs may be enclosed within the certificates. HITs can represent an issuer, a subject, or both. In X.509.v3 HITs are represented as issuer and subject alternative name extensions as defined in [RFC2459]. If only HIP information is presented as either the issuer or the subject the HIT is also placed into the respective entity's DNs Common Name (CN) section in a colon delimited presentation format. Inclusion of CN is not necessary if DN contains any other information. It is RECOMMENDED to use FQDN/NAI from the hosts HOST_ID parameter in DN if one exists. Full HIs are presented in the public key entries of X.509.v3 certificates. As an example, in a case where the issuer and the subject are both HIP enabled, the HITs are expressed as follows: Format: Issuer: CN=hit-of-host Subject: CN=hit-of-host X509v3 extensions: X509v3 Issuer Alternative Name: IP Address:HIT-OF-HOST X509v3 Subject Alternative Name: IP Address:HIT-OF-HOST Example: Issuer: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 Subject: CN=2001:14:6cf:fae7:bb79:bf78:7d64:c056 X509v3 extensions: X509v3 Issuer Alternative Name: IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 X509v3 Subject Alternative Name: IP Address:2001:14:6CF:FAE7:BB79:BF78:7D64:C056 Appendix B shows a full example X.509.v3 certificate with HIP content. As another example, consider a managed PKI environment in which the peers have certificates that are anchored in (potentially different) managed trust chains. In this scenario, the certificates issued to HIP hosts are signed by intermediate Certificate Authorities (CAs) up to a root CA. In this example, the managed PKI environment is neither HIP aware, nor can it be configured to compute HITs and include them in the certificates. In this scenario, it is recommended that the HIP peers have and use some mechanism of defining trusted root CAs for the purpose of establishing HIP communications. Furthermore it is recommended that the HIP peers have and use some mechanism of checking peer certificate validity for revocation, signature, minimum cryptographic strength, etc., up to the trusted root CA. When HIP communications are established, the HIP hosts not only need to send their identity certificates (or pointers to their certificates), but also the chain of intermediate CAs (or pointers to the CAs) up to the root CA, or to a CA that is trusted by the remote peer. This chain of certificates must be sent in a Cert group as specified in Section 2. The HIP peers validate each other's Certificates and compute peer HITs based on the Certificate public keys. 4. SPKI Cert Object and Host Identities When using SPKI certificates to transmit information related to HIP hosts, HITs need to be enclosed within the certificates. HITs can represent an issuer, a subject, or both. In the following we define the representation of those identifiers for SPKI given as S-expressions. Note that the S-expressions are only the human- readable representation of SPKI certificates. Full HIs are presented in the public key sequences of SPKI certificates. As an example the Host Identity Tag of a host is expressed as follows: Format: (hash hit hit-of-host) Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50) Appendix A shows a full example SPKI certificate with HIP content.
- [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt Internet-Drafts
- Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt Mattes, David
- Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt Samu Varjonen
- Re: [Hipsec] I-D Action:draft-ietf-hip-cert-03.txt Mattes, David