< draft-housley-ct-keypackage-receipt-n-error-00.txt		draft-housley-ct-keypackage-receipt-n-error-01.txt >
	Internet Engineering Task Force (IETF) Russ Housley		Internet Engineering Task Force (IETF) Russ Housley
	Internet Draft Vigil Security		Internet-Draft Vigil Security
	Intended Status: Standards Track 17 April 2013		Intended Status: Standards Track 2 May 2013
	Expires: 19 October 2013		Expires: 2 November 2013
	Cryptographic Message Syntax (CMS)		Cryptographic Message Syntax (CMS)
	Key Package Receipt and Error Content Types		Key Package Receipt and Error Content Types
	draft-housley-ct-keypackage-receipt-n-error-00.txt		draft-housley-ct-keypackage-receipt-n-error-01.txt
	Abstract		Abstract
	This document defines the syntax for two Cryptographic Message Syntax		This document defines the syntax for two Cryptographic Message Syntax
	(CMS) content types, one for key package receipts, and another for		(CMS) content types, one for key package receipts, and another for
	key package errors. The key package receipt content type is used to		key package errors. The key package receipt content type is used to
	confirm receipt of an identified key package or collection of key		confirm receipt of an identified key package or collection of key
	packages. The key package error content type is used to indicate an		packages. The key package error content type is used to indicate an
	error occurred during the processing of a key package. CMS can be		error occurred during the processing of a key package. CMS can be
	used to digitally sign, digest, authenticate, or encrypt these		used to digitally sign, digest, authenticate, or encrypt these
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 2		1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 2
	1.2. ASN.1 Syntax Notation . . . . . . . . . . . . . . . . . . . 3		1.2. ASN.1 Syntax Notation . . . . . . . . . . . . . . . . . . . 3
	1.3. Processing Key Package Receipt Requests . . . . . . . . . . 3		1.3. Processing Key Package Receipt Requests . . . . . . . . . . 3
	1.4. Processing Key Packages with Errors . . . . . . . . . . . . 3		1.4. Processing Key Packages with Errors . . . . . . . . . . . . 3
	2. SIR Entity Name . . . . . . . . . . . . . . . . . . . . . . . . 3		2. SIR Entity Name . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Key Package Identifier and Receipt Request Attribute . . . . . 4		3. Key Package Identifier and Receipt Request Attribute . . . . . 4
	4. Key Package Receipt CMS Content Type . . . . . . . . . . . . . 5		4. Key Package Receipt CMS Content Type . . . . . . . . . . . . . 6
	5. Key Package Error CMS Content Type . . . . . . . . . . . . . . 7		5. Key Package Error CMS Content Type . . . . . . . . . . . . . . 8
	6. Protecting the KeyPackageReceipt and KeyPackageError . . . . . 16		6. Protecting the KeyPackageReceipt and KeyPackageError . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 19		Appendix A: ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	This document defines the syntax for two Cryptographic Message Syntax		This document defines the syntax for two Cryptographic Message Syntax
	(CMS) [RFC5652] content types, one for key package receipts, and		(CMS) [RFC5652] content types, one for key package receipts, and
	another for key package errors. The key package receipt content type		another for key package errors. The key package receipt content type
	is used to confirm receipt of an identified key package or collection		is used to confirm receipt of an identified key package or collection
	of key packages. The key package error content type is used to		of key packages. The key package error content type is used to
	indicate an error occurred during the processing of a key package.		indicate an error occurred during the processing of a key package.
	CMS can be used to digitally sign, digest, authenticate, or encrypt		CMS can be used to digitally sign, digest, authenticate, or encrypt
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	1.4. Processing Key Packages with Errors		1.4. Processing Key Packages with Errors
	The key package or collection of key packages [RFC4073] [RFC5958]		The key package or collection of key packages [RFC4073] [RFC5958]
	[RFC6031] [RFC6032] for which the error is being generated might be		[RFC6031] [RFC6032] for which the error is being generated might be
	signed. The key package can be identified by a key-package-		signed. The key package can be identified by a key-package-
	identifier-and-receipt-request attribute specified in Section 3.		identifier-and-receipt-request attribute specified in Section 3.
	2. SIR Entity Name		2. SIR Entity Name
	Within a key distribution system, the source, intermediary, and		Within a key distribution system, the source, intermediary, and
	receiver entities are identified by an SIR entity name. The syntax		receiver entities are identified by a Source Intermediary Recipient
	for the SIR entity name does not impose any particular structure, and		(SIR) entity name. The syntax for the SIR entity name does not
	it accommodates straightforward registration of additional SIR entity		impose any particular structure, and it accommodates straightforward
	name types.		registration of additional SIR entity name types.
	The inclusion of the nameType object identifier ensures that two		The inclusion of the nameType object identifier ensures that two
	identifiers of different types that happen to contain the same values		identifiers of different types that happen to contain the same values
	are not interpreted as equivalent. Additional SIR entity name types		are not interpreted as equivalent. Additional SIR entity name types
	are expected to be registered that represent different granularities.		are expected to be registered that represent different granularities.
	For example, one SIR entity name type might represent the receiver		For example, one SIR entity name type might represent the receiver
	organization, and at a finer granularity, another SIR entity name		organization, and at a finer granularity, another SIR entity name
	type might identify a specific device, perhaps using a manufacturer		type might identify a specific device, perhaps using a manufacturer
	identifier and serial number. The use of an object identifier avoids		identifier and serial number. The use of an object identifier avoids
	the need for a central registry of SIR entity name types.		the need for a central registry of SIR entity name types.
			The nameValue is an OCTET STRING, which allows the canonical form of
			any name to be carried. Two names of the same type are considered
			equal if the octet strings are the same length and contain the same
			string of octets.
	SIREntityNames and SIREntityName have the following syntax:		SIREntityNames and SIREntityName have the following syntax:
	SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName		SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName
	SIREntityName ::= SEQUENCE {		SIREntityName ::= SEQUENCE {
	nameType OBJECT IDENTIFIER,		nameType OBJECT IDENTIFIER,
	nameValue OCTET STRING }		nameValue OCTET STRING }
	This document defines one SIR entity name type: the DN type. The DN		This document defines one SIR entity name type: the DN type. The DN
	type uses a nameType of id-dn and a nameValue of a Distinguished		type uses a nameType of id-dn and a nameValue of a Distinguished
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	id-dn OBJECT IDENTIFER ::= {		id-dn OBJECT IDENTIFER ::= {
	joint-iso-ccitt(2) country(16) us(840) organization(1)		joint-iso-ccitt(2) country(16) us(840) organization(1)
	gov(101) dod(2) infosec(1) sir-name-types(16) 0 }		gov(101) dod(2) infosec(1) sir-name-types(16) 0 }
	3. Key Package Identifier and Receipt Request Attribute		3. Key Package Identifier and Receipt Request Attribute
	The key-package-identifier-and-receipt-request attribute, as its name		The key-package-identifier-and-receipt-request attribute, as its name
	implies, allows the originator to identify the key package and		implies, allows the originator to identify the key package and
	optionally request receipts. This attribute can appear as a signed,		optionally request receipts. This attribute can appear as a signed,
	authenticated, and content attribute.		authenticated, and content attribute. Signed attributes are carried
			in the CMS Signed-data content type described in Section 5 of
			[RFC5652]. Authenticated attributes are carried in the CMS
			Authenticated-data content type described in Section 9 of [RFC5652]
			or in the CMS Authenticated-enveloped-data content type described in
			Section 2 of [RFC5083]. Content attributes are carried in the
			Content-with-attributes content type described in Section 3 of
			[RFC4073].
	The key-package-identifier-and-receipt-request attribute has the		The key-package-identifier-and-receipt-request attribute has the
	following syntax:		following syntax:
	aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= {		aa-keyPackageIdentifierAndReceiptRequest ATTRIBUTE ::= {
	TYPE KeyPkgIdentifierAndReceiptReq		TYPE KeyPkgIdentifierAndReceiptReq
	IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq }		IDENTIFIED BY id-aa-KP-keyPkgIdAndReceiptReq }
	id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {		id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {
	joint-iso-itu-t(2) country(16) us(840) organization(1)		joint-iso-itu-t(2) country(16) us(840) organization(1)
	skipping to change at page 4, line 46 ¶		skipping to change at page 5, line 4 ¶
	id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {		id-aa-KP-keyPkgIdAndReceiptReq OBJECT IDENTIFIER ::= {
	joint-iso-itu-t(2) country(16) us(840) organization(1)		joint-iso-itu-t(2) country(16) us(840) organization(1)
	gov(101) dod(2) infosec(1) attributes(5) 65 }		gov(101) dod(2) infosec(1) attributes(5) 65 }
	KeyPkgIdentifierAndReceiptReq ::= SEQUENCE {		KeyPkgIdentifierAndReceiptReq ::= SEQUENCE {
	pkgID KeyPkgID,		pkgID KeyPkgID,
	receiptReq KeyPkgReceiptReq OPTIONAL }		receiptReq KeyPkgReceiptReq OPTIONAL }
	KeyPkgID ::= OCTET STRING		KeyPkgID ::= OCTET STRING
	KeyPkgReceiptReq ::= SEQUENCE {		KeyPkgReceiptReq ::= SEQUENCE {
	encryptReceipt BOOLEAN DEFAULT FALSE,		encryptReceipt BOOLEAN DEFAULT FALSE,
	receiptsFrom [0] SIREntityNames OPTIONAL,		receiptsFrom [0] SIREntityNames OPTIONAL,
	receiptsTo SIREntityNames }		receiptsTo SIREntityNames }
			Even though the ATTRIBUTE syntax is defined as a SET OF
			AttributeValue, a key-package-identifier-and-receipt-request
			attribute MUST have a single attribute value; zero or multiple
			instances of AttributeValue are not permitted.
	The fields in the key-package-identifier-and-receipt-request		The fields in the key-package-identifier-and-receipt-request
	attribute have the following semantics:		attribute have the following semantics:
	o pkgID contains an octet string, and this syntax does not impose		o pkgID contains an octet string, and this syntax does not impose
	any particular structure on the identifier.		any particular structure on the identifier.
	o receiptReq is OPTIONAL, and when it is present, it includes an		o receiptReq is OPTIONAL, and when it is present, it includes an
	encryption receipt flag, an OPTIONAL indication of which		encryption receipt flag, an OPTIONAL indication of which
	receivers should generate receipts, and an indication of where		receivers should generate receipts, and an indication of where
	skipping to change at page 6, line 21 ¶		skipping to change at page 7, line 21 ¶
	id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= {		id-ct-KP-keyPackageReceipt OBJECT IDENTIFIER ::= {
	iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) ct(1) TBD1 }		smime(16) ct(1) TBD1 }
	KeyPackageReceipt ::= SEQUENCE {		KeyPackageReceipt ::= SEQUENCE {
	version KeyPkgVersion DEFAULT v2,		version KeyPkgVersion DEFAULT v2,
	receiptOf KeyPkgIdentifier,		receiptOf KeyPkgIdentifier,
	receivedBy SIREntityName }		receivedBy SIREntityName }
	-- Revised definition of KeyPkgVersion from [RFC6031]		-- Revised definition of KeyPkgVersion from [RFC6031]
	KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. MAX)		KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)
	KeyPkgIdentifier ::= CHOICE {		KeyPkgIdentifier ::= CHOICE {
	pkgID KeyPkgID,		pkgID KeyPkgID,
	attribute SingleAttribute {{ KeyPkgIdentifiers }} }		attribute SingleAttribute {{ KeyPkgIdentifiers }} }
	KeyPkgID ::= OCTET STRING		KeyPkgID ::= OCTET STRING
	KeyPkgIdentifiers ATTRIBUTE ::= { ... }		KeyPkgIdentifiers ATTRIBUTE ::= { ... }
	The KeyPackageReceipt fields are used as follows:		The KeyPackageReceipt fields are used as follows:
	skipping to change at page 7, line 52 ¶		skipping to change at page 8, line 52 ¶
	id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= {		id-ct-KP-keyPackageError OBJECT IDENTIFIER ::= {
	iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)		iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) ct(1) TBD2 }		smime(16) ct(1) TBD2 }
	KeyPackageError ::= SEQUENCE {		KeyPackageError ::= SEQUENCE {
	version KeyPkgVersion DEFAULT v2,		version KeyPkgVersion DEFAULT v2,
	errorOf [0] KeyPkgIdentifier OPTIONAL,		errorOf [0] KeyPkgIdentifier OPTIONAL,
	errorBy SIREntityName,		errorBy SIREntityName,
	errorCode ErrorCodeChoice }		errorCode ErrorCodeChoice }
	KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. MAX)		KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)
	KeyPkgIdentifier ::= CHOICE {		KeyPkgIdentifier ::= CHOICE {
	pkgID KeyPkgID,		pkgID KeyPkgID,
	attribute SingleAttribute {{ KeyPkgIdentifiers }} }		attribute SingleAttribute {{ KeyPkgIdentifiers }} }
	KeyPkgID ::= OCTET STRING		KeyPkgID ::= OCTET STRING
	KeyPkgIdentifiers ATTRIBUTE ::= { ... }		KeyPkgIdentifiers ATTRIBUTE ::= { ... }
	ErrorCodeChoice ::= CHOICE {		ErrorCodeChoice ::= CHOICE {
	enum EnumeratedErrorCode,		enum EnumeratedErrorCode,
	skipping to change at page 9, line 27 ¶		skipping to change at page 10, line 27 ¶
	badMessageDigest (83),		badMessageDigest (83),
	badKeyPackage (84),		badKeyPackage (84),
	badAttributes (85),		badAttributes (85),
	attributeComparisonFailure (86),		attributeComparisonFailure (86),
	unsupportedSymmetricKeyPackage (87),		unsupportedSymmetricKeyPackage (87),
	unsupportedAsymmetricKeyPackage (88),		unsupportedAsymmetricKeyPackage (88),
	constraintViolation (89),		constraintViolation (89),
	ambiguousDefaultValue (90),		ambiguousDefaultValue (90),
	noMatchingReceipientInfo (91),		noMatchingReceipientInfo (91),
	unsupportedKeyWrapAlgorithm (92),		unsupportedKeyWrapAlgorithm (92),
			badKeyTransRecipientInfo (93),
	other (127),		other (127),
	... -- Expect additional error codes -- }		... -- Expect additional error codes -- }
	The KeyPackageError fields are used as follows:		The KeyPackageError fields are used as follows:
	o version identifies version of the key package error content		o version identifies version of the key package error content
	structure. For this version of the specification, the default		structure. For this version of the specification, the default
	value, v2, MUST be used. Note that v1 was defined in an earlier		value, v2, MUST be used. Note that v1 was defined in an earlier
	version, but the use of v1 is deprecated.		version, but the use of v1 is deprecated.
	skipping to change at page 11, line 4 ¶		skipping to change at page 12, line 7 ¶
	the value is malformed or internally inconsistent.		the value is malformed or internally inconsistent.
	* missingContent is used to indicate that the optional eContent		* missingContent is used to indicate that the optional eContent
	is missing in EncapsulatedContentInfo, which is required when		is missing in EncapsulatedContentInfo, which is required when
	including an asymmetric, a symmetric key package, and an		including an asymmetric, a symmetric key package, and an
	encrypted key package. This error can be generated due to		encrypted key package. This error can be generated due to
	problems located in SignedData or AuthenticatedData.		problems located in SignedData or AuthenticatedData.
	Note that CMS EncapsulatedContentInfo eContent field is		Note that CMS EncapsulatedContentInfo eContent field is
	optional [RFC5652]; however, [RFC5958], [RFC6031], and		optional [RFC5652]; however, [RFC5958], [RFC6031], and
	[RFC6032] require that the eContent be present.		[RFC6032] require that the eContent be present.
	* noTrustAnchor is used to indicate that the subjectKeyIdentifier		* noTrustAnchor is used to indicate that the subjectKeyIdentifier
	does not identify the public key of a trust anchor or a		does not identify the public key of a trust anchor or a
	certification path that terminates with an installed trust		certification path that terminates with an installed trust
	anchor.		anchor.
	* notAuthorized is used to indicate that the sid within		* notAuthorized is used to indicate that the sid within
	SignerInfo leads to an installed trust anchor, but that trust		SignerInfo leads to an installed trust anchor, but that trust
	anchor is not an authorized signer for the received content		anchor is not an authorized signer for the received content
	type.		type.
	* badDigestAlgorithm is used to indicate that the digestAlgorithm		* badDigestAlgorithm is used to indicate that the digestAlgorithm
	in either SignerInfo, SignedData, or AuthenticatedData is		in either SignerInfo, SignedData, or AuthenticatedData is
	unknown or unsupported.		unknown or unsupported.
	* badSignatureAlgorithm is used to indicate that the		* badSignatureAlgorithm is used to indicate that the
	signatureAlgorithm in SignerInfo is unknown or unsupported.		signatureAlgorithm in SignerInfo is unknown or unsupported.
	skipping to change at page 12, line 26 ¶		skipping to change at page 13, line 27 ¶
	* revokedCertificate indicates that one or more of the		* revokedCertificate indicates that one or more of the
	certificates needed to properly process the key package has		certificates needed to properly process the key package has
	been revoked.		been revoked.
	* ambiguousDecrypt indicates that the EncryptedData content type		* ambiguousDecrypt indicates that the EncryptedData content type
	was used, and the key package receiver could not determine the		was used, and the key package receiver could not determine the
	appropriate keying material to perform the decryption.		appropriate keying material to perform the decryption.
	* noDecryptKey indicates that the receiver does not have the key		* noDecryptKey indicates that the receiver does not have the key
	named in the content-decryption-key-identifier attribute.		named in the content-decryption-key-identifier attribute (see
			[RFC6032]).
	* badEncryptedData indicates that the EncryptedData syntax is		* badEncryptedData indicates that the EncryptedData syntax is
	invalid or the version is unknown or unsupported.		invalid or the version is unknown or unsupported.
	* badEnvelopedData indicates that the EnvelopedData syntax is		* badEnvelopedData indicates that the EnvelopedData syntax is
	invalid or the version is unknown or unsupported.		invalid or the version is unknown or unsupported.
	* badAuthenticatedData indicates that the AuthenticatedData		* badAuthenticatedData indicates that the AuthenticatedData
	syntax is invalid or the version is unknown or unsupported.		syntax is invalid or the version is unknown or unsupported.
	skipping to change at page 13, line 49 ¶		skipping to change at page 14, line 52 ¶
	match the digest algorithm used by the content signer.		match the digest algorithm used by the content signer.
	* missingCertificate indicates that a signature could not be		* missingCertificate indicates that a signature could not be
	verified using a trust anchor or a certificate from the		verified using a trust anchor or a certificate from the
	certificates field within SignedData. Similarly, this error		certificates field within SignedData. Similarly, this error
	code can indicate that a needed certificate is missing when		code can indicate that a needed certificate is missing when
	processing EnvelopedData, AuthEnvelopedData, or		processing EnvelopedData, AuthEnvelopedData, or
	AuthenticatedData.		AuthenticatedData.
	* tooManySigners indicates that a SignedData content contained		* tooManySigners indicates that a SignedData content contained
	more than one SignerInfo.		more than one SignerInfo for a content type that requires only
			one signer.
	* missingSignedAttributes indicates that a SignedInfo within a		* missingSignedAttributes indicates that a SignedInfo within a
	SignedData content did not contain any signed attributes; at a		SignedData content did not contain any signed attributes; at a
	minimum, the content-type and message-digest must be present,		minimum, the content-type and message-digest must be present,
	as per [RFC5652]. Similarly, this error code can indicate that		as per [RFC5652]. Similarly, this error code can indicate that
	required authenticated attributes are missing when processing		required authenticated attributes are missing when processing
	AuthEnvelopedData or AuthenticatedData.		AuthEnvelopedData or AuthenticatedData.
	* derEncodingNotUsed indicates that the content contained BER		* derEncodingNotUsed indicates that the content contained BER
	encoding, or some other encoding, where DER encoding was		encoding, or some other encoding, where DER encoding was
	skipping to change at page 14, line 32 ¶		skipping to change at page 15, line 35 ¶
	in an unacceptable location.		in an unacceptable location.
	* badMessageDigest indicates that the value of the message-digest		* badMessageDigest indicates that the value of the message-digest
	attribute [RFC5652] did not match the calculated value.		attribute [RFC5652] did not match the calculated value.
	* badKeyPackage indicates that the SymmetricKeyPackage [RFC6031]		* badKeyPackage indicates that the SymmetricKeyPackage [RFC6031]
	or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the		or AsymmetricKeyPackage [RFC5958] syntax is invalid or that the
	version is unknown.		version is unknown.
	* badAttributes indicates that an attribute collection contained		* badAttributes indicates that an attribute collection contained
	either multiple instances of the same attribute type or		either multiple instances of the same attribute type that
	contained an attribute instance with multiple values.		allows only one instance or contained an attribute instance
			with multiple values in an attribute that allows only one
			value.
	* attributeComparisonFailure indicates that multiple instances of		* attributeComparisonFailure indicates that multiple instances of
	an attribute failed the comparison rules for the type of		an attribute failed the comparison rules for the type of
	attribute.		attribute.
	* unsupportedSymmetricKeyPackage indicates that the		* unsupportedSymmetricKeyPackage indicates that the
	implementation is not prepared to process symmetric key		implementation does not support symmetric key packages
	packages [RFC6031].		[RFC6031].
	* unsupportedAsymmetricKeyPackage indicates that the		* unsupportedAsymmetricKeyPackage indicates that the
	implementation is not prepared to process asymmetric key		implementation does not support asymmetric key packages
	packages [RFC5958].		[RFC5958].
	* constraintViolation indicates that one or more of the		* constraintViolation indicates that one or more of the
	attributes has a value that is not in the authorized set of		attributes has a value that is not in the authorized set of
	values for the signer [RFC6010]. That is, the value is in		values for the signer [RFC6010]. That is, the value is in
	conflict with the constraints imposed on the signer.		conflict with the constraints imposed on the signer.
	* ambiguousDefaultValue indicates that one or more of the		* ambiguousDefaultValue indicates that one or more of the
	attributes that is part of the signer's constraints is omitted		attributes that is part of the signer's constraints is omitted
	from the key package, and the constraint permits more than one		from the key package, and the constraint permits more than one
	value, therefore the appropriate default value for that		value, therefore the appropriate default value for that
	attribute or attribute cannot be determined.		attribute or attribute cannot be determined.
	* noMatchingRecipientInfo indicates that a recipientInfo could		* noMatchingRecipientInfo indicates that a recipientInfo could
	not be found for the recipient. This can result from a keri or		not be found for the recipient. This can result from a keri or
	kari found in EncryptedData, EnvelopedData, or		kari found in EncryptedData, EnvelopedData, or
	AuthEnvelopedData.		AuthEnvelopedData.
	* unsupportedKeyWrapAlgorithm indicates that the key wrap		* unsupportedKeyWrapAlgorithm indicates that the key wrap
	algorithm is not supported.		algorithm is not supported.
			* badKeyTransRecipientInfo indicates that the
			KeyTransRecipientInfo syntax is invalid or the version is
			unknown or unsupported.
	* other indicates that the key package could not be processed,		* other indicates that the key package could not be processed,
	but the reason is not covered by any of the assigned status		but the reason is not covered by any of the assigned status
	codes. Use of this status code SHOULD be avoided.		codes. Use of this status code SHOULD be avoided.
	The key package error content type MUST be signed if the entity		The key package error content type MUST be signed if the entity
	generating it is capable of signing it. For example, a device will		generating it is capable of signing it. For example, a device will
	be incapable of signing when it is in early stages of deployment and		be incapable of signing when it is in early stages of deployment and
	it has not been configured with a private signing key or a device has		it has not been configured with a private signing key or a device has
	an internal error that prevents use of its private signing key. When		an internal error that prevents use of its private signing key. When
	it is signed, the key package error MUST be encapsulated in a CMS		it is signed, the key package error MUST be encapsulated in a CMS
	skipping to change at page 16, line 21 ¶		skipping to change at page 18, line 21 ¶
	o SignedData can be used to apply a digital signature.		o SignedData can be used to apply a digital signature.
	o EncryptedData can be used to encrypt the content type with simple		o EncryptedData can be used to encrypt the content type with simple
	symmetric encryption, where the sender and the receiver already		symmetric encryption, where the sender and the receiver already
	share the necessary encryption key.		share the necessary encryption key.
	o EnvelopedData can be used to encrypt the content type with		o EnvelopedData can be used to encrypt the content type with
	symmetric encryption, where the sender and the receiver do not		symmetric encryption, where the sender and the receiver do not
	already share the necessary encryption key.		already share the necessary encryption key.
			o AuthenticatedData can be used to integrity protect the content
			type with message authentication algorithms that support
			authenticated encryption, where key management information is
			handled in a manner similar to EnvelopedData.
	o AuthEnvelopedData can be used to protect the content types with		o AuthEnvelopedData can be used to protect the content types with
	algorithms that support authenticated encryption, where key		algorithms that support authenticated encryption, where key
	management information is handled in a manner similar to		management information is handled in a manner similar to
	EnvelopedData.		EnvelopedData.
	7. Security Considerations		7. Security Considerations
	The key package receipt and key package error contents are not		The key package receipt and key package error contents are not
	necessarily protected. These content types can be combined with a		necessarily protected. These content types can be combined with a
	security protocol to protect the contents of the package.		security protocol to protect the contents of the package.
			In some situations, returning very detailed error information can
			provide an attacker with insight into the security processing. Where
			this is a concern, the implementation should return the most generic
			error code that is appropriate. However, detailed error codes are
			very helpful during development, debugging, and interoperability
			testing. For this reason, implementations may want to have a way to
			configure the use of a generic error code or a detailed one.
	8. IANA Considerations		8. IANA Considerations
	None.		None.
	{RFC Editor: Please remove this section before publication.}		{RFC Editor: Please remove this section before publication.}
	9. Acknowledgements		9. Acknowledgements
			Thanks to Sean Turner and Jim Schaad for their insightful revie
	TBD
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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.
	[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",		[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
	RFC 2634, June 1999.		RFC 2634, June 1999.
	skipping to change at page 17, line 37 ¶		skipping to change at page 19, line 50 ¶
	2010.		2010.
	[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax		[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax
	(CMS) Symmetric Key Package Content Type", RFC 6031,		(CMS) Symmetric Key Package Content Type", RFC 6031,
	December 2010.		December 2010.
	[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax		[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax
	(CMS) Encrypted Key Package Content Type", RFC 6032,		(CMS) Encrypted Key Package Content Type", RFC 6032,
	December 2010.		December 2010.
	[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
	for the Cryptographic Message Syntax (CMS) and the Public
	Key Infrastructure Using X.509 (PKIX)", RFC 6268, July
	2011.
	[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.		[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
	Information Technology - Abstract Syntax Notation One.		Information Technology - Abstract Syntax Notation One.
	[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.		[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
	Information Technology - Abstract Syntax Notation One:		Information Technology - Abstract Syntax Notation One:
	Information Object Specification.		Information Object Specification.
	[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.		[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
	Information Technology - Abstract Syntax Notation One:		Information Technology - Abstract Syntax Notation One:
	Constraint Specification.		Constraint Specification.
	skipping to change at page 20, line 8 ¶		skipping to change at page 22, line 8 ¶
	ATTRIBUTE, SingleAttribute {}		ATTRIBUTE, SingleAttribute {}
	FROM PKIX-CommonTypes-2009		FROM PKIX-CommonTypes-2009
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkixCommon-02(57) }		id-mod-pkixCommon-02(57) }
	;		;
	---		---
	--- Key Package Version Number (revised from [RFC6031])		--- Key Package Version Number (revised from [RFC6031])
	---		---
	KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. MAX)		KeyPkgVersion ::= INTEGER { v1(1), v2(2) } (1 .. 65535)
	--		--
	-- SIR Entity Name		-- SIR Entity Name
	--		--
	SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName		SIREntityNames ::= SEQUENCE SIZE (1..MAX) OF SIREntityName
	SIREntityName ::= SEQUENCE {		SIREntityName ::= SEQUENCE {
	nameType OBJECT IDENTIFIER,		nameType OBJECT IDENTIFIER,
	nameValue OCTET STRING }		nameValue OCTET STRING }
	skipping to change at page 23, line 15 ¶		skipping to change at page 25, line 15 ¶
	badMessageDigest (83),		badMessageDigest (83),
	badKeyPackage (84),		badKeyPackage (84),
	badAttributes (85),		badAttributes (85),
	attributeComparisonFailure (86),		attributeComparisonFailure (86),
	unsupportedSymmetricKeyPackage (87),		unsupportedSymmetricKeyPackage (87),
	unsupportedAsymmetricKeyPackage (88),		unsupportedAsymmetricKeyPackage (88),
	constraintViolation (89),		constraintViolation (89),
	ambiguousDefaultValue (90),		ambiguousDefaultValue (90),
	noMatchingReceipientInfo (91),		noMatchingReceipientInfo (91),
	unsupportedKeyWrapAlgorithm (92),		unsupportedKeyWrapAlgorithm (92),
			badKeyTransRecipientInfo (93),
	other (127),		other (127),
	... -- Expect additional error codes -- }		... -- Expect additional error codes -- }
	END		END
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
End of changes. 26 change blocks.
	44 lines changed or deleted		75 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/