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.