--- 1/draft-ietf-csi-send-name-type-registry-00.txt 2010-02-04 18:10:44.000000000 +0100 +++ 2/draft-ietf-csi-send-name-type-registry-01.txt 2010-02-04 18:10:44.000000000 +0100 @@ -1,26 +1,26 @@ Network Working Group R. Gagliano Internet-Draft LACNIC Updates: 3971 (if approved) S. Krishnan Intended status: Standards Track Ericsson -Expires: May 28, 2010 A. Kukec +Expires: August 8, 2010 A. Kukec University of Zagreb - November 24, 2009 + February 04, 2010 SEND Name Type field Registry - draft-ietf-csi-send-name-type-registry-00 + draft-ietf-csi-send-name-type-registry-01 Abstract SEcure Neighbor Discovery (SEND) defines the Name Type field in the - Trust Anchor option. This document requesto to IANA the creation and + Trust Anchor option. This document request to IANA the creation and management of a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering @@ -32,25 +32,25 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on May 28, 2010. + This Internet-Draft will expire on August 8, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -87,31 +87,31 @@ 2. Introduction SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 certificates that include [RFC3779] extension for IPv6 addresses to certify a router authority over an IPv6 prefix for NDP (Neighbor Discovery Protocol). The Trust Anchor Option in section 6.4.3 of RFC 3971 allows the identification of the Trust Anchor (TA) selected by the host. In that section, two name types were defined, the DER Encoded X.501 Name and a Fully Qualified Domain Name (FQDN). This - document requesto to IANA the creation and management of a registry + document request to IANA the creation and management of a registry for this field. In any Public Key Infrastructure, the subject name of a certificate - is only unique within each CA. A new option to identify TAs across - CAs is needed. + is only unique within each CA. Consequently, a new option to + identify TAs across CAs is needed. In [I-D.ietf-csi-send-cert] the certificate profile described in [I-D.ietf-sidr-res-certs] is adopted for SEND. In these documents, - the Subject field the certificates are declared to be meaningless and - the subjectAltName field is not allowed. On the other hand, the + the Subject field in the certificates are declared to be meaningless + and the subjectAltName field is not allowed. On the other hand, the Subject Key Identifier (SKI) extension for the X.509 certificates is defined as mandatory and non-critical. This document specifies a new Name Type field in the SEND TA option that allows to use of the SKI X.509 extension to identify TA X.509 certificates. 3. SEND SKI trust anchor Name Type field. Name Type @@ -119,24 +119,24 @@ 3 SHA-1 Subject Key Identifier (SKI) The Key Identifier used here is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the subject public key, as described in Section 4.2.1.2 of [RFC5280]. 3.1. Processing Rules for Router As described in RFC 3971, a TA is identified by the SEND TA option. If the TA option is represented as a SHA-1 SKI, then the SKI must be - equal to the SKI in the anchor's certificate calculated as described - in [draft-ietf-sidr-res-certs-17]. The router SHOULD include the TA - option(s) in the advertisement for which the certification path was - found. + equal to the SKI extension in the trust anchor's certificate + calculated as described in [draft-ietf-sidr-res-certs-17]. The + router SHOULD include the TA option(s) in the advertisement for which + the certification path was found. If the router is unable to find a path to the requested anchor, it SHOULD send an advertisement without any certificate. In this case, the router SHOULD include the TA options that were solicited. 4. IANA Considerations IANA will maintains the registry of Name Type field in the ICMP Trust Anchor option. The registry records Name Type fields for the ICMP Trust Anchor option (15) defined in the RFC 3971.