< draft-ietf-pkix-ipki-kea-01.txt		draft-ietf-pkix-ipki-kea-02.txt >
	PKIX Working Group R. Housley (SPYRUS)		PKIX Working Group R. Housley (SPYRUS)
	Internet Draft W. Polk (NIST)		Internet Draft W. Polk (NIST)
	expires in six months October 14, 1997		expires in six months August 5, 1998
	Internet Public Key Infrastructure		Internet X.509 Public Key Infrastructure
	Representation of Key Exchange Algorithm (KEA) Keys in		Representation of Key Exchange Algorithm (KEA) Keys in
	Internet Public Key Infrastructure Certificates		Internet X.509 Public Key Infrastructure Certificates
	<draft-ietf-pkix-ipki-kea-01.txt>		<draft-ietf-pkix-ipki-kea-02.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	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."
	To learn the current status of any Internet-Draft, please check the		To view the entire list of current Internet-Drafts, please check the
	"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or		Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
	ftp.isi.edu (US West Coast).		Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
			Copyright (C) The Internet Society (1998). All Rights Reserved.
			Representation of Key Exchange Algorithm (KEA) Keys in
			Internet X.509 Public Key Infrastructure Certificates
			Table of Contents
			Abstract .......................................................... 3
			1. Executive Summary ............................................. 3
			2. Requirements and Assumptions .................................. 3
			2.1. Communication and Topology .................................. 3
			2.2. Acceptability Criteria ...................................... 4
			2.3. User Expectations ........................................... 4
			2.4. Administrator Expectations .................................. 4
			3. KEA Algorithm Support ......................................... 5
			3.1. Subject Public Key Info ..................................... 5
			3.1.1. Algorithm Identifier and Parameters ....................... 5
			3.1.2. Encoding of KEA Public Keys ............................... 6
			3.2. Key Usage Extension in KEA certificates ..................... 6
			4. ASN.1 Modules .................................................. 7
			4.1 1988 Syntax ................................................... 7
			4.2 1993 Syntax ................................................... 7
			5. References ..................................................... 8
			6. Patent Statements .............................................. 8
			7. Security Considerations ........................................ 8
			8. Author Addresses ............................................... 9
	Abstract		Abstract
	This is the second draft of a profile for specification of Key		This is the third draft of a profile for specification of Key
	Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure		Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
	X.509 certificates. Please send comments on this document to the		X.509 certificates. There are only minor changes in content from the
	ietf-pkix@tandem.com mail list.		second draft. Several modifications are required now that KEA has
			been declassified. A patent statement is required, and a published
			reference for the KEA algorithm is required. After these modifica-
			tions, the document will be complete. Please send comments on this
			document to the ietf-pkix@imc.org mail list.
	1 Executive Summary		1. Executive Summary
	This specification contains guidance on the use of the Internet		This specification contains guidance on the use of the Internet Pub-
	Public Key Infrastructure certificates to convey Key Exchange		lic Key Infrastructure certificates to convey Key Exchange Algorithm
	Algorithm (KEA) keys. This specification is an addendum to RFC xxxx,		(KEA) keys. This specification is an addendum to RFC xxxx, "Internet
	"Internet Public Key Infrastructure: Certificate and CRL Profile".		X.509 Public Key Infrastructure: Certificate and CRL Profile".
	Implementations of this specification must also conform to RFC xxxx.		Implementations of this specification must also conform to RFC xxxx.
	Implementations of this specification are not required to conform to		Implementations of this specification are not required to conform to
	other parts from that series.		other parts from that series.
	The Key Exchange Algorithm (KEA) is a classified algorithm for		The Key Exchange Algorithm (KEA) is a classified algorithm for
	exchanging keys. This specification profiles the format and		exchanging keys. This specification profiles the format and seman-
	semantics of fields in X.509 V3 certificates containing KEA keys. The		tics of fields in X.509 V3 certificates containing KEA keys. The
	specification addresses the subjectPublicKeyInfo field and the		specification addresses the subjectPublicKeyInfo field and the
	keyUsage extension.		keyUsage extension.
	2 Requirements and Assumptions		2. Requirements and Assumptions
	The goal is to augment the X.509 certificate profile presented in		The goal is to augment the X.509 certificate profile presented in
	Part 1 to facilitate the management of KEA keys for those communities		Part 1 to facilitate the management of KEA keys for those communities
	which use this algorithm.		which use this algorithm.
	2.1 Communication and Topology		2.1. Communication and Topology
	This profile, as presented in Part 1 and augmented by this		This profile, as presented in Part 1 and augmented by this specifica-
	specification, supports users without high bandwidth, real-time IP		tion, supports users without high bandwidth, real-time IP connec-
	connectivity, or high connection availablity. In addition, the		tivity, or high connection availablity. In addition, the profile
	profile allows for the presence of firewall or other filtered		allows for the presence of firewall or other filtered communication.
	communication.
	This profile does not assume the deployment of an X.500 Directory		This profile does not assume the deployment of an X.500 Directory
	system. The profile does not prohibit the use of an X.500 Directory,		system. The profile does not prohibit the use of an X.500 Directory,
	but other means of distributing certificates and certificate		but other means of distributing certificates and certificate revoca-
	revocation lists (CRLs) are supported.		tion lists (CRLs) are supported.
	2.2 Acceptability Criteria		2.2. Acceptability Criteria
	The goal of the Internet Public Key Infrastructure (PKI) is to meet		The goal of the Internet Public Key Infrastructure (PKI) is to meet
	the needs of deterministic, automated identification, authentication,		the needs of deterministic, automated identification, authentication,
	access control, and authorization functions. Support for these		access control, and authorization functions. Support for these ser-
	services determines the attributes contained in the certificate as		vices determines the attributes contained in the certificate as well
	well as the ancillary control information in the certificate such as		as the ancillary control information in the certificate such as pol-
	policy data and certification path constraints.		icy data and certification path constraints.
	The goal of this document is to profile KEA certificates, specifying		The goal of this document is to profile KEA certificates, specifying
	the contants and semantics of attributes which were not fully		the contants and semantics of attributes which were not fully speci-
	specified by Part 1. If not specifically addressed by this document,		fied by Part 1. If not specifically addressed by this document, the
	the contents and semantics of the fields and extensions must be as		contents and semantics of the fields and extensions must be as
	described in Part 1.		described in Part 1.
	2.3 User Expectations		2.3. User Expectations
	Users of the Internet PKI are people and processes who use client		Users of the Internet PKI are people and processes who use client
	software and are the subjects named in certificates. These uses		software and are the subjects named in certificates. These uses
	include readers and writers of electronic mail, the clients for WWW		include readers and writers of electronic mail, the clients for WWW
	browsers, WWW servers, and the key manager for IPSEC within a router.		browsers, WWW servers, and the key manager for IPSEC within a router.
	This profile recognizes the limitations of the platforms these users		This profile recognizes the limitations of the platforms these users
	employ and the sophistication/attentiveness of the users themselves.		employ and the sophistication/attentiveness of the users themselves.
	This manifests itself in minimal user configuration responsibility		This manifests itself in minimal user configuration responsibility
	(e.g., root keys, rules), explicit platform usage constraints within		(e.g., root keys, rules), explicit platform usage constraints within
	the certificate, certification path constraints which shield the user		the certificate, certification path constraints which shield the user
	from many malicious actions, and applications which sensibly automate		from many malicious actions, and applications which sensibly automate
	validation functions.		validation functions.
	2.4 Administrator Expectations		2.4. Administrator Expectations
	As with users, the Internet PKI profile is structured to support the		As with users, the Internet PKI profile is structured to support the
	individuals who generally operate Certification Authorities (CAs).		individuals who generally operate Certification Authorities (CAs).
	Providing administrators with unbounded choices increases the chances		Providing administrators with unbounded choices increases the chances
	that a subtle CA administrator mistake will result in broad		that a subtle CA administrator mistake will result in broad comprom-
	compromise or unnecessarily limit interoperability. This profile		ise or unnecessarily limit interoperability. This profile defines
	defines the object identifiers and data formats that must be		the object identifiers and data formats that must be supported to
	supported to intepret KEA public keys.		intepret KEA public keys.
	3 KEA Algorithm Support		3. KEA Algorithm Support
	This section describes object identifiers and data formats which may		This section describes object identifiers and data formats which may
	be used with PKIX certicate profile to describe X.509 certificates		be used with PKIX certicate profile to describe X.509 certificates
	containing a KEA public key. Conforming CAs are required to use the		containing a KEA public key. Conforming CAs are required to use the
	object identifiers and data formats when issuing KEA certificates.		object identifiers and data formats when issuing KEA certificates.
	Conforming applications shall recognize the object identifiers and		Conforming applications shall recognize the object identifiers and
	process the data formats when processing such certificates.		process the data formats when processing such certificates.
	3.1 Subject Public Key Info		3.1. Subject Public Key Info
	The certificate identifies the KEA algorithm, conveys optional
	parameters, and specifies the KEA public key in the
	subjectPublicKeyInfo field. The subjectPublicKeyInfo field is a
	SEQUENCE of an algorithm identifier and the subjectPublicKey field.
	The certificate indicates the algorithm through an algorithm		The certificate identifies the KEA algorithm, conveys optional param-
	identifier. This algorithm identifier consists of an object		eters, and specifies the KEA public key in the subjectPublicKeyInfo
	identifier (OID) and optional associated parameters. Section 3.1.1		field. The subjectPublicKeyInfo field is a SEQUENCE of an algorithm
	identifies the preferred OID and parameters for the KEA algorithm.		identifier and the subjectPublicKey field.
	Conforming CAs shall use the identified OID when issuing certificates
	containing public keys for the KEA algorithm. Conforming applications
	supporting the KEA algorithm shall, at a minimum, recognize the OID
	identified in section 3.1.1.
	The certificate conveys the KEA public key through the		The certificate indicates the algorithm through an algorithm identif-
	subjectPublicKey field. This subjectPublicKey field is a BIT STRING.		ier. This algorithm identifier consists of an object identifier
	Section 3.1.2 specifies the method for encoding a KEA public key as a		(OID) and optional associated parameters. Section 3.1.1 identifies
	BIT STRING. Conforming CAs shall encode the KEA public key as		the preferred OID and parameters for the KEA algorithm. Conforming
	described in Section 3.1.2 when issuing certificates containing		CAs shall use the identified OID when issuing certificates containing
	public keys for the KEA algorithm. Conforming applications supporting		public keys for the KEA algorithm. Conforming applications supporting
	the KEA algorithm shall decode the subjectPublicKey as described in		the KEA algorithm shall, at a minimum, recognize the OID identified
	section 3.1.2 when the algorithm identifier is the one presented in		in section 3.1.1.
	3.1.1.
	3.1.1 Algorithm Identifier and Parameters		The certificate conveys the KEA public key through the subjectPub-
			licKey field. This subjectPublicKey field is a BIT STRING. Section
			3.1.2 specifies the method for encoding a KEA public key as a BIT
			STRING. Conforming CAs shall encode the KEA public key as described
			in Section 3.1.2 when issuing certificates containing public keys for
			the KEA algorithm. Conforming applications supporting the KEA algo-
			rithm shall decode the subjectPublicKey as described in section 3.1.2
			when the algorithm identifier is the one presented in 3.1.1.
			3.1.1. Algorithm Identifier and Parameters
	The Key Exchange Algorithm (KEA) is a classified algorithm for		The Key Exchange Algorithm (KEA) is a classified algorithm for
	exchanging keys. A KEA "pairwise key" may be generated between two		exchanging keys. A KEA "pairwise key" may be generated between two
	users if their KEA public keys were generated with the same KEA		users if their KEA public keys were generated with the same KEA
	parameters. The KEA parameters are not included in a certificate;		parameters. The KEA parameters are not included in a certificate;
	instead a "domain identifier" is supplied in the parameters field.		instead a "domain identifier" is supplied in the parameters field.
	When the subjectPublicKeyInfo field contains a KEA key, the algorithm		When the subjectPublicKeyInfo field contains a KEA key, the algorithm
	identifier and parameters shall be as defined in [sdn.701r]:		identifier and parameters shall be as defined in [sdn.701r]:
	skipping to change at page 4, line 37 ¶		skipping to change at page 6, line 23 ¶
	a KEA public key with an 80-bit parameter identifier (OCTET STRING),		a KEA public key with an 80-bit parameter identifier (OCTET STRING),
	also known as the domain identifier. The domain identifier will be		also known as the domain identifier. The domain identifier will be
	computed in three steps: (1) the KEA parameters are DER encoded using		computed in three steps: (1) the KEA parameters are DER encoded using
	the Dss-Parms structure; (2) a 160-bit SHA-1 hash is generated from		the Dss-Parms structure; (2) a 160-bit SHA-1 hash is generated from
	the parameters; and (3) the 160-bit hash is reduced to 80-bits by		the parameters; and (3) the 160-bit hash is reduced to 80-bits by
	performing an "exclusive or" of the 80 high order bits with the 80		performing an "exclusive or" of the 80 high order bits with the 80
	low order bits. The resulting value is encoded such that the most		low order bits. The resulting value is encoded such that the most
	significant byte of the 80-bit value is the first octet in the octet		significant byte of the 80-bit value is the first octet in the octet
	string.		string.
	The Dss-Parms is provided in [RFC xxx] and reproduced below for		The Dss-Parms is provided in [RFC xxx] and reproduced below for com-
	completeness.		pleteness.
	Dss-Parms ::= SEQUENCE {		Dss-Parms ::= SEQUENCE {
	p INTEGER,		p INTEGER,
	q INTEGER,		q INTEGER,
	g INTEGER }		g INTEGER }
	3.1.2 Encoding of KEA Public Keys		3.1.2. Encoding of KEA Public Keys
	A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING		A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
	such that the most significant bit (MSB) of y becomes the MSB of the		such that the most significant bit (MSB) of y becomes the MSB of the
	BIT STRING value field and the least significant bit (LSB) of y		BIT STRING value field and the least significant bit (LSB) of y
	becomes the LSB of the BIT STRING value field. This results in the		becomes the LSB of the BIT STRING value field. This results in the
	following encoding: BIT STRING tag, BIT STRING length, 0 (indicating		following encoding: BIT STRING tag, BIT STRING length, 0 (indicating
	that there are zero unused bits in the final octet of y), BIT STRING		that there are zero unused bits in the final octet of y), BIT STRING
	value field including y.		value field including y.
	3.2 Key Usage Extension in KEA certificates		3.2. Key Usage Extension in KEA certificates
	The key usage extension may optionally appear in a KEA certificate. If		The key usage extension may optionally appear in a KEA certificate. If
	a KEA certificate includes the keyUsage extension, only the following		a KEA certificate includes the keyUsage extension, only the following
	values may be asserted:		values may be asserted:
	keyAgreement;		keyAgreement;
	encipherOnly; and		encipherOnly; and
	decipherOnly.		decipherOnly.
	The encipherOnly and decipherOnly values may only be asserted if the		The encipherOnly and decipherOnly values may only be asserted if the
	keyAgreement value is also asserted. At most one of encipherOnly and		keyAgreement value is also asserted. At most one of encipherOnly and
	decipherOnly shall be asserted in keyUsage extension.		decipherOnly shall be asserted in keyUsage extension.
	References		4. ASN.1 Modules
			4.1 1988 Syntax
			PKIXkea88 {iso(1) identified-organization(3) dod(6) inter-
			net(1) security(5) mechanisms(5) pkix(7) id-mod(0) to be
			assigned(?) } BEGIN ::=
			-- EXPORTS ALL --
			-- IMPORTS NONE --
			id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
			{ 2 16 840 1 101 2 1 1 22 }
			KEA-Parms-Id ::= OCTET STRING
			END
			4.2 1993 Syntax
			PKIXkea93 {iso(1) identified-organization(3) dod(6) inter-
			net(1) security(5) mechanisms(5) pkix(7) id-mod(0) to be
			assigned(?) }
			BEGIN ::=
			-- EXPORTS ALL --
			IMPORTS ALGORITHM-ID
			FROM PKIX1Explicit93 {iso(1) identified-organization(3)
			dod(6) internet(1) security(5) mechanisms(5) pkix(7)
			id-mod(0) id-pkix1-explicit-93(3) }
			KeaPublicKey ALGORTHM-ID ::= { OID id-keyExchangeAlgorithm
			PARMS KEA-Parms-Id }
			id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
			{ 2 16 840 1 101 2 1 1 22 }
			KEA-Parms-Id ::= OCTET STRING
			END
			5. References
			[KEA] "Skipjack and KEA Algorithm Specification", Version 2.0,
			29 May 1998. available from
			http://csrc.nist.gov/encryption/skipjack-kea.htm
	[SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0		[SDN.701R] SDN.701, "Message Security Protocol", Revision 4.0
	1996-06-07 with "Corrections to Message Security Protocol,		1996-06-07 with "Corrections to Message Security Protocol,
	SDN.701, Rev 4.0, 96-06-07." August 30, 1996.		SDN.701, Rev 4.0, 96-06-07." August 30, 1996.
	[RFC xxxx] R. Housley, W. Ford, W. Polk and D. Solo "Internet Public		[RFC xxxx] R. Housley, W. Ford, W. Polk and D. Solo "Internet X.509
	Key Infrastructure: X.509 Certificate and CRL Profile",		Public Key Infrastructure: X.509 Certificate and CRL
	October 14, 1997.		Profile", July 28, 1998.
	Patent Statements		6. Patent Statements
	This specification references classified public key encryption		To be added.
	technology for provisioning key exchange services.
	Security Considerations		7. Security Considerations
	This entire memo is about security mechanisms.		This specification is devoted to the format and encoding of KEA keys
			in X.509 certificates. Since certificates are digitally signed, no
			additional integrity service is necessary. Certificates need not be
			kept secret, and unrestricted and anonymous access to certificates
			and CRLs has no security implications.
	Author Addresses:		However, security factors outside the scope of this specification
			will affect the assurance provided to certificate users. This sec-
			tion highlights critical issues that should be considered by imple-
			mentors, administrators, and users.
			The procedures performed by CAs and RAs to validate the binding of
			the subject's identity of their public key greatly affect the
			assurance that should be placed in the certificate. Relying parties
			may wish to review the CA's certificate practice statement.
			The protection afforded private keys is a critical factor in main-
			taining security. Failure of users to protect their KEA private keys
			will permit an attacker to masquerade as them, or decrypt their per-
			sonal information.
			The availability and freshness of revocation information will affect
			the degree of assurance that should be placed in a certificate.
			While certificates expire naturally, events may occur during its
			natural lifetime which negate the binding between the subject and
			public key. If revocation information is untimely or unavailable,
			the assurance associated with the binding is clearly reduced. Simi-
			larly, implementations of the Path Validation mechanism described in
			section 6 that omit revocation checking provide less assurance than
			those that support it.
			The path validation algorithm specified in [RFC xxxx] depends on the
			certain knowledge of the public keys (and other information) about
			one or more trusted CAs. The decision to trust a CA is an important
			decision as it ultimately determines the trust afforded a certifi-
			cate. The authenticated distribution of trusted CA public keys (usu-
			ally in the form of a "self-signed" certificate) is a security criti-
			cal out of band process that is beyond the scope of this specifica-
			tion.
			In addition, where a key compromise or CA failure occurs for a
			trusted CA, the user will need to modify the information provided to
			the path validation routine. Selection of too many trusted CAs will
			make the trusted CA information difficult to maintain. On the other
			hand, selection of only one trusted CA may limit users to a closed
			community of users until a global PKI emerges.
			The quality of implementations that process certificates may also
			affect the degree of assurance provided. The path validation algo-
			rithm described in section 6 relies upon the integrity of the trusted
			CA information, and especially the integrity of the public keys asso-
			ciated with the trusted CAs. By substituting public keys for which
			an attacker has the private key, an attacker could trick the user
			into accepting false certificates.
			The binding between a key and certificate subject cannot be stronger
			than the cryptographic module implementation and algorithms used to
			generate the signature.
			8. Author Addresses:
	Russell Housley		Russell Housley
	SPYRUS		SPYRUS
	PO Box 1198		PO Box 1198
	Herndon, VA 20172		Herndon, VA 20172
	USA		USA
	housley@spyrus.com		housley@spyrus.com
	Tim Polk		Tim Polk
	NIST		NIST
End of changes. 38 change blocks.
	81 lines changed or deleted		213 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/