draft-ietf-csi-send-name-type-registry-02.txt		draft-ietf-csi-send-name-type-registry-03.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: September 7, 2010 A. Kukec		Expires: October 10, 2010 A. Kukec
	University of Zagreb		University of Zagreb
	March 06, 2010		April 08, 2010
	SEND Name Type field Registry		SEND Name Type field Registry
	draft-ietf-csi-send-name-type-registry-02		draft-ietf-csi-send-name-type-registry-03
	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 requests 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 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
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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		This Internet-Draft will expire on October 10, 2010.
	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 September 7, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. SEND SKI trust anchor option Name Type field . . . . . . . . . 5		3. SEND SKI trust anchor option Name Type field. . . . . . . . . . 5
	3.1. Processing Rules for Router . . . . . . . . . . . . . . . . 5		3.1. Processing Rules for Routers . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 8		6. Normative References . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 6, line 5		skipping to change at page 5, line 5
	[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 in the certificates are declared to be meaningless		the Subject field in the certificates are declared to be meaningless
	and 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 option Name Type field		3. SEND SKI trust anchor option Name Type field.
	Name Type		Name Type
	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 Routers
	As specified in [RFC3971] , a TA is identified by the SEND TA option.		As specified 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 extension in the trust anchor's certificate		equal to the SKI extension in the trust anchor's certificate
	calculated as described in [draft-ietf-sidr-res-certs-17]. The		calculated as described in [draft-ietf-sidr-res-certs-17]. The
	router SHOULD include the TA option(s) in the advertisement for which		router SHOULD include the TA option(s) in the advertisement for which
	the certification path was found. Also, following [RFC3971]		the certification path was found. Also, following [RFC3971]
	specification, if the router is unable to find a path to the		specification, if the router is unable to find a path to the
	requested anchor, it SHOULD send an advertisement without any		requested anchor, it SHOULD send an advertisement without any
	certificate. In this case, the router SHOULD include the TA options		certificate. In this case, the router SHOULD include the TA options
	that were solicited.		that were solicited.
	4. IANA Considerations		4. IANA Considerations
	IANA will maintains the registry of Name Type field in the ICMP Trust		IANA is requested to create and maintain a new registry entitled
	Anchor option. The registry records Name Type fields for the ICMP		"SEND Name Type field in ICMP TA option". This registry records Name
	Trust Anchor option (15) defined in the RFC 3971.		Type fields for the ICMP Trust Anchor option (15) defined in the RFC
			3971.
	The following Name Type fields are defined:
	1 DER Encoded X.501 Name (RFC 3971).		The initial values for the "SEND Name Type field in ICMP TA option"
			registry are:
	2 FQDN (RFC 3971)		+---------+------------------------------------------------+
			| Value | Description |
			+---------+------------------------------------------------+
			| 0 | Reserved |
			| | |
			| 1 | DER Encoded X.501 Name (RFC 3971) |
			| | |
			| 2 | FQDN (RFC 3971) |
			| | |
			| 3 | SHA-1 Subject Key Identifier (SKI) (Section 3) |
			| | |
			| 253-254 | Experimental use |
			| | |
			| 255 | Reserved |
			+---------+------------------------------------------------+
	3 SHA-1 Subject Key Identifier (SKI) (Section 3)		Table 1: Initial SEND Name Type field ICMP TA option registry.
	New assignments of Name Type field is through Standards Action.		New assignments of Name Type field is through Standards Action.
	5. Security Considerations		5. Security Considerations
	No security considerations.		No security considerations.
	6. Normative References		6. Normative References
	[I-D.ietf-csi-send-cert]		[I-D.ietf-csi-send-cert]
	Krishnan, S., Kukec, A., and R. Gagliano, "Certificate		Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
	profile and certificate management for SEND",		profile and certificate management for SEND",
	draft-ietf-csi-send-cert-00 (work in progress), July 2009.		draft-ietf-csi-send-cert-03 (work in progress),
			March 2010.
	[I-D.ietf-sidr-res-certs]		[I-D.ietf-sidr-res-certs]
	Huston, G., Michaelson, G., and R. Loomans, "A Profile for		Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates",		X.509 PKIX Resource Certificates",
	draft-ietf-sidr-res-certs-17 (work in progress),		draft-ietf-sidr-res-certs-17 (work in progress),
	September 2009.		September 2009.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
End of changes. 18 change blocks.
	43 lines changed or deleted		40 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/