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

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/