< draft-hoffman-pkcs-certif-req-01.txt		draft-hoffman-pkcs-certif-req-02.txt >
	Internet Draft RSA Laboratories		Internet Draft Burt Kaliski
	Expires 11/5/97		Expires March 16, 1998
	<draft-hoffman-pkcs-certif-req-01.txt>		<draft-hoffman-pkcs-certif-req-02.txt>
	PKCS #10: Certification Request Syntax		PKCS #10: Certification Request Syntax
	Version 1.5		Version 1.5
	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.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	To learn the current status of any Internet-Draft, please check the		To learn the current status of any Internet-Draft, 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), nic.nordu.net (Europe),
	munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or		munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
	ftp.isi.edu (US West Coast).		ftp.isi.edu (US West Coast).
	This memo provides information for the Internet community. This memo		This memo provides information for the Internet community. This memo
	does not specify an Internet standard of any kind. Distribution of		does not specify an Internet standard of any kind. Distribution of
	this memo is unlimited.		this memo is unlimited.
	Overview This standard describes a syntax for certification requests.		Overview
	Please note: The information in this document is historical material		This document describes a syntax for certification requests.
	being published for the public record. It is not an IETF standard.
	The use of the word "standard" in this document indicates a standard
	for RSA Laboratories and its customers, not an IETF standard.
	1. Scope		1. Scope
	A certification request consists of a distinguished name, a public		A certification request consists of a distinguished name, a public
	key, and optionally a set of attributes, collectively signed by the		key, and optionally a set of attributes, collectively signed by the
	entity requesting certification. Certification requests are sent to a		entity requesting certification. Certification requests are sent to a
	certification authority, who transforms the request to an X.509		certification authority, who transforms the request to an X.509
	public-key certificate, or a PKCS #6 extended certificate. (In what		public-key certificate, or a PKCS #6 extended certificate. (In what
	form the certification authority returns the newly signed certificate		form the certification authority returns the newly signed certificate
	is outside the scope of this document. A PKCS #7 message is one		is outside the scope of this document. A PKCS #7 message is one
	possibility.)		possibility.)
	PKCS #10: Certification Request Syntax
	The intention of including a set of attributes is twofold: to provide		The intention of including a set of attributes is twofold: to provide
	other information about a given entity, such as the postal address to		other information about a given entity, such as the postal address to
	which the signed certificate should be returned if electronic mail is		which the signed certificate should be returned if electronic mail is
	not available, or a "challenge password" by which the entity may		not available, or a "challenge password" by which the entity may
			RFC nnn PKCS #10: Certification Request Syntax November 1993
	later request certificate revocation; and to provide attributes for a		later request certificate revocation; and to provide attributes for a
	PKCS #6 extended certificate. A non-exhaustive list of attributes is		PKCS #6 extended certificate. A non-exhaustive list of attributes is
	given in PKCS #9.		given in PKCS #9.
	Certification authorities may also require non-electronic forms of		Certification authorities may also require non-electronic forms of
	request and may return non-electronic replies. It is expected that		request and may return non-electronic replies. It is expected that
	descriptions of such forms, which are outside the scope of this		descriptions of such forms, which are outside the scope of this
	document, will be available from the certification authority.		document, will be available from the certification authority.
	The preliminary intended application of this standard is to support		The preliminary intended application of this document is to support
	PKCS #7 cryptographic messages, but is expected that other		PKCS #7 cryptographic messages, but is expected that other
	applications will be developed.		applications will be developed.
	2. References		2. References
	PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption		PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption
	Standard. Version 1.5, November 1993.		Standard. Version 1.5, November 1993.
	PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate		PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate
	Syntax Standard. Version 1.5, November 1993.		Syntax. Version 1.5, November 1993.
	PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message		PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message
	Syntax Standard. Version 1.5, November 1993.		Syntax. Version 1.5, November 1993.
	PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute		PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute
	Types. Version 1.1, November 1993.		Types. Version 1.1, November 1993.
	RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for		RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for
	Internet Electronic Mail: Part IV: Key		Internet Electronic Mail: Part IV: Key
	Certification and Related Services. February 1993.		Certification and Related Services. February 1993.
	X.208 CCITT. Recommendation X.208: Specification of		X.208 CCITT. Recommendation X.208: Specification of
	Abstract Syntax Notation One (ASN.1). 1988.		Abstract Syntax Notation One (ASN.1). 1988.
	skipping to change at page 3, line 5 ¶		skipping to change at page 2, line 52 ¶
	Basic Encoding Rules for Abstract Syntax Notation		Basic Encoding Rules for Abstract Syntax Notation
	One (ASN.1). 1988.		One (ASN.1). 1988.
	X.500 CCITT. Recommendation X.500: The Directory--		X.500 CCITT. Recommendation X.500: The Directory--
	Overview of Concepts, Models and		Overview of Concepts, Models and
	Services. 1988.		Services. 1988.
	X.501 CCITT. Recommendation X.501: The Directory--		X.501 CCITT. Recommendation X.501: The Directory--
	Models. 1988.		Models. 1988.
	PKCS #10: Certification Request Syntax
	X.509 CCITT. Recommendation X.509: The Directory--		X.509 CCITT. Recommendation X.509: The Directory--
	Authentication Framework. 1988.		Authentication Framework. 1988.
			RFC nnn PKCS #10: Certification Request Syntax November 1993
	3. Definitions		3. Definitions
	For the purposes of this standard, the following definitions apply.		For the purposes of this document, the following definitions apply.
	AlgorithmIdentifier: A type that identifies an algorithm (by object		AlgorithmIdentifier: A type that identifies an algorithm (by object
	identifier) and any associated parameters. This type is defined in		identifier) and any associated parameters. This type is defined in
	X.509.		X.509.
	Attribute: A type that contains an attribute type (specified by		Attribute: A type that contains an attribute type (specified by
	object identifier) and one or more attribute values. This type is		object identifier) and one or more attribute values. This type is
	defined in X.501.		defined in X.501.
	ASN.1: Abstract Syntax Notation One, as defined in X.208.		ASN.1: Abstract Syntax Notation One, as defined in X.208.
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 39 ¶
	DER: Distinguished Encoding Rules for ASN.1, as defined in X.509,		DER: Distinguished Encoding Rules for ASN.1, as defined in X.509,
	Section 8.7.		Section 8.7.
	Name: A type that uniquely identifies or "distinguishes" objects in a		Name: A type that uniquely identifies or "distinguishes" objects in a
	X.500 directory. This type is defined in X.501. In an X.509		X.500 directory. This type is defined in X.501. In an X.509
	certificate, the type identifies the certificate issuer and the		certificate, the type identifies the certificate issuer and the
	entity whose public key is certified.		entity whose public key is certified.
	4. Symbols and abbreviations		4. Symbols and abbreviations
	No symbols or abbreviations are defined in this standard.		No symbols or abbreviations are defined in this document.
	5. General overview		5. General overview
	The next section specifies certification request syntax.		The next section specifies certification request syntax.
	This standard exports one type, CertificationRequest.		This document exports one type, CertificationRequest.
	6. Certification request syntax		6. Certification request syntax
	This section gives the syntax for certification requests.		This section gives the syntax for certification requests.
	A certification request consists of three parts: "certification		A certification request consists of three parts: "certification
	PKCS #10: Certification Request Syntax
	request information," a signature algorithm identifier, and a digital		request information," a signature algorithm identifier, and a digital
	signature on the certification request information. The certification		signature on the certification request information. The certification
	request information consists of the entity's distinguished name, the		request information consists of the entity's distinguished name, the
			RFC nnn PKCS #10: Certification Request Syntax November 1993
	entity's public key, and a set of attributes providing other		entity's public key, and a set of attributes providing other
	information about the entity.		information about the entity.
	The process by which a certification request is constructed involves		The process by which a certification request is constructed involves
	the following steps:		the following steps:
	1. A CertificationRequestInfo value containing a		1. A CertificationRequestInfo value containing a
	distinguished name, a public key, and optionally a		distinguished name, a public key, and optionally a
	set of attributes is constructed by an entity.		set of attributes is constructed by an entity.
	skipping to change at page 5, line 5 ¶		skipping to change at page 4, line 52 ¶
	helpful, and it may include certificate-revocation lists (CRLs).		helpful, and it may include certificate-revocation lists (CRLs).
	Another possibility is that the certification authority inserts the		Another possibility is that the certification authority inserts the
	new certificate into a central database.		new certificate into a central database.
	This section is divided into two parts. The first part describes the		This section is divided into two parts. The first part describes the
	certification-request-information type CertificationRequestInfo, and		certification-request-information type CertificationRequestInfo, and
	the second part describes the top-level type CertificationRequest.		the second part describes the top-level type CertificationRequest.
	Notes.		Notes.
	PKCS #10: Certification Request Syntax
	1. An entity would typically send a certification		1. An entity would typically send a certification
	request after generating a public-key/private-key		request after generating a public-key/private-key
			RFC nnn PKCS #10: Certification Request Syntax November 1993
	pair, but may also do so after a change in the		pair, but may also do so after a change in the
	entity's distinguished name.		entity's distinguished name.
	2. The signature on the certification request		2. The signature on the certification request
	prevents an entity from requesting a certificate		prevents an entity from requesting a certificate
	with another party's public key. Such an attack		with another party's public key. Such an attack
	would give the entity the minor ability to pretend		would give the entity the minor ability to pretend
	to be the originator of any message signed by the		to be the originator of any message signed by the
	other party. This attack is significant only if		other party. This attack is significant only if
	the entity does not know the message being signed,		the entity does not know the message being signed,
	and the signed part of the message does not		and the signed part of the message does not
	identify the signer. The entity would still not be		identify the signer. The entity would still not be
	able to decrypt messages intended for the other		able to decrypt messages intended for the other
	party, of course.		party, of course.
	3. How the entity sends the certification request to		3. How the entity sends the certification request to
	a certification authority is outside the scope of		a certification authority is outside the scope of
	this standard. Both paper and electronic forms are		this document. Both paper and electronic forms are
	possible.		possible.
	4. This standard is not compatible with the		4. This document is not compatible with the
	certification request syntax for Privacy-Enhanced		certification request syntax for Privacy-Enhanced
	Mail, as described in RFC 1424. The syntax in this		Mail, as described in RFC 1424. The syntax in this
	standard differs in three respects: It allows a		document differs in three respects: It allows a
	set of attributes; it does not include issuer		set of attributes; it does not include issuer
	name, serial number, or validity period; and it		name, serial number, or validity period; and it
	does not require an "innocuous" message to be		does not require an "innocuous" message to be
	signed. The syntax in this standard is designed to		signed. The syntax in this document is designed to
	minimize request size, an important constraint for		minimize request size, an important constraint for
	those certification authorities accepting requests		those certification authorities accepting requests
	on paper.		on paper.
	6.1 CertificationRequestInfo		6.1 CertificationRequestInfo
	Certification request information shall have ASN.1 type		Certification request information shall have ASN.1 type
	CertificationRequestInfo:		CertificationRequestInfo:
	CertificationRequestInfo ::= SEQUENCE {		CertificationRequestInfo ::= SEQUENCE {
	version Version,		version Version,
	subject Name,		subject Name,
	subjectPublicKeyInfo SubjectPublicKeyInfo,		subjectPublicKeyInfo SubjectPublicKeyInfo,
	attributes [0] IMPLICIT Attributes }		attributes [0] IMPLICIT Attributes }
	Version ::= INTEGER		Version ::= INTEGER
	Attributes ::= SET OF Attribute		Attributes ::= SET OF Attribute
	PKCS #10: Certification Request Syntax
	The fields of type CertificationRequestInfo have the following		The fields of type CertificationRequestInfo have the following
			RFC nnn PKCS #10: Certification Request Syntax November 1993
	meanings:		meanings:
	o version is the version number, for compatibility		o version is the version number, for compatibility
	with future revisions of this standard. It shall		with future revisions of this document. It shall
	be 0 for this version of the standard.		be 0 for this version of the document.
	o subject is the distinguished name of the		o subject is the distinguished name of the
	certificate subject (the entity whose public key		certificate subject (the entity whose public key
	is to be certified).		is to be certified).
	o subjectPublicKeyInfo contains information about		o subjectPublicKeyInfo contains information about
	the public key being certified. The information		the public key being certified. The information
	identifies the entity's public-key algorithm (and		identifies the entity's public-key algorithm (and
	any associated parameters); examples of public-key		any associated parameters); examples of public-key
	algorithms include X.509's rsa and PKCS #1's		algorithms include X.509's rsa and PKCS #1's
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 54 ¶
	certificationRequestInfo CertificationRequestInfo,		certificationRequestInfo CertificationRequestInfo,
	signatureAlgorithm SignatureAlgorithmIdentifier,		signatureAlgorithm SignatureAlgorithmIdentifier,
	signature Signature }		signature Signature }
	SignatureAlgorithmIdentifier ::= AlgorithmIdentifier		SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
	Signature ::= BIT STRING		Signature ::= BIT STRING
	The fields of type CertificationRequest have the following meanings:		The fields of type CertificationRequest have the following meanings:
	PKCS #10: Certification Request Syntax
	o certificateRequestInfo is the "certification		o certificateRequestInfo is the "certification
			RFC nnn PKCS #10: Certification Request Syntax November 1993
	request information." It is the value being		request information." It is the value being
	signed.		signed.
	o signatureAlgorithm identifies the signature		o signatureAlgorithm identifies the signature
	algorithm (and any associated parameters) under		algorithm (and any associated parameters) under
	which the certification-request information is		which the certification-request information is
	signed. Examples include PKCS #1's		signed. Examples include PKCS #1's
	md2WithRSAEncryption and md5WithRSAEncryption.		md2WithRSAEncryption and md5WithRSAEncryption.
	o signature is the result of signing the		o signature is the result of signing the
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 43 ¶
	CertificationRequest ::= SIGNED CertificateRequestInfo		CertificationRequest ::= SIGNED CertificateRequestInfo
	Revision history		Revision history
	Version 1.0		Version 1.0
	Version 1.0 is the initial version.		Version 1.0 is the initial version.
	Copyright		Copyright
	Copyright (C) 1991-1993 RSA Laboratories, a division of RSA Data		Copyright (c) 1991-1993 RSA Laboratories, a division of RSA Data
	Security, Inc. License to copy this document is granted provided that		Security, Inc. Any substantial use of the text from this document
	it is identified as "RSA Data Security, Inc. Public-Key Cryptography		must acknowledge RSA Data Security, Inc. RSA Data Security, Inc.
	Standards (PKCS)" in all material mentioning or referencing this		requests that all material mentioning or referencing this document
	document.		identify this as "RSA Data Security, Inc. PKCS #10".
	Author's Address		Author's Address
	RSA Laboratories		Burt Kaliski
	100 Marine Parkway		RSA Laboratories East
			20 Crosby Drive
	PKCS #10: Certification Request Syntax		RFC nnn PKCS #10: Certification Request Syntax November 1993
	Redwood City, CA 94065 USA		Bedford, MA 01730
	Tel: (415) 595-7703		(617) 687-7000
	Fax: (415) 595-4126		burt@rsa.com
	pkcs-editor@rsa.com
End of changes. 30 change blocks.
	41 lines changed or deleted		43 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/