< draft-housley-cms-mix-with-psk-03.txt		draft-housley-cms-mix-with-psk-04.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Intended Status: Proposed Standard Vigil Security		Intended Status: Proposed Standard Vigil Security
	Expires: 5 September 2018 5 March 2018		Expires: 3 October 2018 3 April 2018
	Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)		Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
	<draft-housley-cms-mix-with-psk-03.txt>		<draft-housley-cms-mix-with-psk-04.txt>
	Abstract		Abstract
	The invention of a large-scale quantum computer would pose a serious		The invention of a large-scale quantum computer would pose a serious
	challenge for the cryptographic algorithms that are widely deployed		challenge for the cryptographic algorithms that are widely deployed
	today. The Cryptographic Message Syntax (CMS) supports key transport		today. The Cryptographic Message Syntax (CMS) supports key transport
	and key agreement algorithms that could be broken by the invention of		and key agreement algorithms that could be broken by the invention of
	such a quantum computer. By storing communications that are		such a quantum computer. By storing communications that are
	protected with the CMS today, someone could decrypt them in the		protected with the CMS today, someone could decrypt them in the
	future when a large-scale quantum computer becomes available. Once		future when a large-scale quantum computer becomes available. Once
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 3		1.3. Version Numbers . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5		3. KeyTransPSKRecipientInfo . . . . . . . . . . . . . . . . . . . 5
	4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 6		4. KeyAgreePSKRecipientInfo . . . . . . . . . . . . . . . . . . . 7
	5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Normative References . . . . . . . . . . . . . . . . . . . . . 12		8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
	9. Informative References . . . . . . . . . . . . . . . . . . . . 12		9. Informative References . . . . . . . . . . . . . . . . . . . . 13
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The invention of a large-scale quantum computer would pose a serious		The invention of a large-scale quantum computer would pose a serious
	challenge for the cryptographic algorithms that are widely deployed		challenge for the cryptographic algorithms that are widely deployed
	today. It is an open question whether or not it is feasible to build		today. It is an open question whether or not it is feasible to build
	a large-scale quantum computer, and if so, when that might happen.		a large-scale quantum computer, and if so, when that might happen.
	However, if such a quantum computer is invented, many of the		However, if such a quantum computer is invented, many of the
	cryptographic algorithms and the security protocols that use them		cryptographic algorithms and the security protocols that use them
	would become vulnerable.		would become vulnerable.
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 22 ¶
	the output of an existing key transport algorithm, like RSA, or an		the output of an existing key transport algorithm, like RSA, or an
	existing key agreement algorithm, like Diffie-Hellman [RFC2631] or		existing key agreement algorithm, like Diffie-Hellman [RFC2631] or
	Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is		Elliptic Curve Diffie-Hellman [RFC5753]. A security solution that is
	believed to be quantum resistant can be achieved by using a PSK with		believed to be quantum resistant can be achieved by using a PSK with
	sufficient entropy along with a quantum resistant key derivation		sufficient entropy along with a quantum resistant key derivation
	function (KDF), like HKDF [RFC5869], and a quantum resistant		function (KDF), like HKDF [RFC5869], and a quantum resistant
	encryption algorithm, like 256-bit AES [AES]. In this way, today's		encryption algorithm, like 256-bit AES [AES]. In this way, today's
	CMS-protected communication can be invulnerable to an attacker with a		CMS-protected communication can be invulnerable to an attacker with a
	large-scale quantum computer.		large-scale quantum computer.
			Note that the CMS also supports key management techniques based on
			symmetric key-encryption keys and passwords, but they are not
			discussed in this document because they are already quantum
			resistant. The symmetric key-encryption key technique is quantum
			resistant when used with an adequate key size. The password
			technique is quantum resistant when used with a quantum-resistant key
			derivation function and a sufficiently large password.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. ASN.1		1.2. ASN.1
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 19 ¶
	version number is only used when the new syntax feature is employed.		version number is only used when the new syntax feature is employed.
	That is, the lowest version number that supports the generated syntax		That is, the lowest version number that supports the generated syntax
	is used.		is used.
	2. Overview		2. Overview
	The CMS enveloped-data content type [RFC5652] and the CMS		The CMS enveloped-data content type [RFC5652] and the CMS
	authenticated-enveloped-data content type [RFC5083] support both key		authenticated-enveloped-data content type [RFC5083] support both key
	transport and key agreement public-key algorithms to establish the		transport and key agreement public-key algorithms to establish the
	key used to encrypt the content. In both cases, the sender randomly		key used to encrypt the content. In both cases, the sender randomly
	generates the key, and then all recipient obtain that key. For		generates the key, and then all recipients obtain that key. For
	enveloped-data, a content-encryption key is established. For		enveloped-data, a content-encryption key is established. For
	authenticated-enveloped-data, a content-authenticated-encryption key		authenticated-enveloped-data, a content-authenticated-encryption key
	is established. All recipients use the sender-generated key for		is established. All recipients use the sender-generated key for
	decryption.		decryption.
	This specification defines two quantum-resistant ways to establish		This specification defines two quantum-resistant ways to establish
	these keys. In both cases, a PSK MUST be distributed to the sender		these keys. In both cases, a PSK MUST be distributed to the sender
	and all of the recipients by some out-of-band means that does not		and all of the recipients by some out-of-band means that does not
	make it vulnerable to the future invention of a large-scale quantum		make it vulnerable to the future invention of a large-scale quantum
	computer, and an identifier MUST be assigned to the PSK.		computer, and an identifier MUST be assigned to the PSK.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 14 ¶
	4. The key-encryption key is used to encrypt the content-encryption		4. The key-encryption key is used to encrypt the content-encryption
	key or content-authenticated-encryption key.		key or content-authenticated-encryption key.
	As specified in Section 6.2.5 of [RFC5652], recipient information for		As specified in Section 6.2.5 of [RFC5652], recipient information for
	additional key management techniques are represented in the		additional key management techniques are represented in the
	OtherRecipientInfo type. Two key management techniques are specified		OtherRecipientInfo type. Two key management techniques are specified
	in this document. Each of these is identified by a unique ASN.1		in this document. Each of these is identified by a unique ASN.1
	object identifier.		object identifier.
	The first key management technique, called keyTransPSK, see Section		The first key management technique, called keyTransPSK, see
	3, uses a key transport algorithm to transfer the key-derivation key		Section 3, uses a key transport algorithm to transfer the key-
	from the sender to the recipient, and then key-derivation key is		derivation key from the sender to the recipient, and then the key-
	mixed with the PSK using a KDF. The output of the KDF is the key-		derivation key is mixed with the PSK using a KDF. The output of the
	encryption key for the encryption of the content-encryption key or		KDF is the key-encryption key for the encryption of the content-
	content-authenticated-encryption key.		encryption key or content-authenticated-encryption key.
	The second key management technique, called keyAgreePSK, see Section		The second key management technique, called keyAgreePSK, see
	4, uses a key agreement algorithm to establish a pairwise key-		Section 4, uses a key agreement algorithm to establish a pairwise
	encryption key, which is used to encrypt the key-derivation key, and		key-encryption key, which is used to encrypt the key-derivation key,
	then key-derivation key is mixed with the PSK using a KDF. The		and the then key-derivation key is mixed with the PSK using a KDF.
	output of the KDF is the key-encryption key for the encryption of the		The output of the KDF is the key-encryption key for the encryption of
	content-encryption key or content-authenticated-encryption key.		the content-encryption key or content-authenticated-encryption key.
	3. KeyTransPSKRecipientInfo		3. KeyTransPSKRecipientInfo
	Per-recipient information using keyTransPSK is represented in the		Per-recipient information using keyTransPSK is represented in the
	KeyTransPSKRecipientInfo type, and its use is indicated by the id-		KeyTransPSKRecipientInfo type, and its use is indicated by the id-
	ori-keyTransPSK object identifier. Each instance of		ori-keyTransPSK object identifier. Each instance of
	KeyTransPSKRecipientInfo establishes the content-encryption key or		KeyTransPSKRecipientInfo establishes the content-encryption key or
	content-authenticated-encryption key for one or more recipients that		content-authenticated-encryption key for one or more recipients that
	have access to the same PSK.		have access to the same PSK.
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 37 ¶
	The RecipientEncryptedKeys type is defined in Section 6.2.2 of		The RecipientEncryptedKeys type is defined in Section 6.2.2 of
	[RFC5652].		[RFC5652].
	5. ASN.1 Module		5. ASN.1 Module
	This section contains the ASN.1 module for the two key management		This section contains the ASN.1 module for the two key management
	techniques defined in this document. This module imports types from		techniques defined in this document. This module imports types from
	other ASN.1 modules that are defined in [RFC5911] and [RFC5912].		other ASN.1 modules that are defined in [RFC5911] and [RFC5912].
	CMSORIforPSK-2017		CMSORIforPSK-2017
	{ iso(1) member-body(2) us(840) rsadsi(113549)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	pkcs(1) pkcs-9(9) smime(16) modules(0)		smime(16) modules(0) id-mod-cms-ori-psk-2017(TBD0) }
	id-mod-cms-ori-psk-2017(TBD0) }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS All		-- EXPORTS All
	IMPORTS		IMPORTS
	AlgorithmIdentifier{}, KEY-DERIVATION		AlgorithmIdentifier{}, KEY-DERIVATION
	FROM AlgorithmInformation-2009 -- [RFC5912]		FROM AlgorithmInformation-2009 -- [RFC5912]
	skipping to change at page 9, line 37 ¶		skipping to change at page 10, line 4 ¶
	version CMSVersion, -- always set to 0		version CMSVersion, -- always set to 0
	pskid PreSharedKeyIdentifier,		pskid PreSharedKeyIdentifier,
	kdfAlgorithm KeyDerivationAlgorithmIdentifier,		kdfAlgorithm KeyDerivationAlgorithmIdentifier,
	keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,		keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
	ktris KeyTransRecipientInfos,		ktris KeyTransRecipientInfos,
	encryptedKey EncryptedKey }		encryptedKey EncryptedKey }
	PreSharedKeyIdentifier ::= OCTET STRING		PreSharedKeyIdentifier ::= OCTET STRING
	KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo		KeyTransRecipientInfos ::= SEQUENCE OF KeyTransRecipientInfo
	--		--
	-- Key Agreement with Pre-Shared Key		-- Key Agreement with Pre-Shared Key
	--		--
	ori-keyAgreePSK ORI-TYPE ::= {		ori-keyAgreePSK ORI-TYPE ::= {
	KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK }		KeyAgreePSKRecipientInfo IDENTIFIED BY id-ori-keyAgreePSK }
	id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 }		id-ori-keyAgreePSK OBJECT IDENTIFIER ::= { id-ori 2 }
	KeyAgreePSKRecipientInfo ::= SEQUENCE {		KeyAgreePSKRecipientInfo ::= SEQUENCE {
	version CMSVersion, -- always set to 0		version CMSVersion, -- always set to 0
	pskid PreSharedKeyIdentifier,		pskid PreSharedKeyIdentifier,
	originator [0] EXPLICIT OriginatorIdentifierOrKey,		originator [0] EXPLICIT OriginatorIdentifierOrKey,
	ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,		ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
	kdfAlgorithm KeyDerivationAlgorithmIdentifier,		kdfAlgorithm KeyDerivationAlgorithmIdentifier,
	keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,		keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
	recipientEncryptedKeys RecipientEncryptedKeys }		recipientEncryptedKeys RecipientEncryptedKeys }
	END		END
	6. Security Considerations		6. Security Considerations
	Implementations must protect the pre-shared key (PSK), key transport		Implementations must protect the pre-shared key (PSK), key transport
	private key, the agreement private key, the key-derivation key, and		private key, the agreement private key, the key-derivation key, and
	the key-encryption key. Compromise of the PSK will make the		the key-encryption key. Compromise of the PSK will make the
	encrypted content vulnerable to the future invention of a large-scale		encrypted content vulnerable to the future invention of a large-scale
	quantum computer. Compromise of the key transport private key or the		quantum computer. Compromise of the PSK and either the key transport
	agreement private key may result in the disclosure of all contents		private key or the agreement private key may result in the disclosure
	protected with that key. Compromise of the key-derivation key that		of all contents protected with that combination of keying material.
	is established with the key transport private key or the agreement		Compromise of the PSK and the key-derivation key may result in
	private key may result in disclosure of the associated encrypted		disclosure of all contents protected with that combination of keying
	content. Compromise of the key-encryption key may result in the		material. Compromise of the key-encryption key may result in the
	disclosure of all content-encryption keys or content-authenticated-		disclosure of all content-encryption keys or content-authenticated-
	encryption keys that were protected with that key, which in turn may		encryption keys that were protected with that keying materail, which
	result in the disclosure of the content.		in turn may result in the disclosure of the content.
	A large-scale quantum computer will effectively cut the security		A large-scale quantum computer will essentially negate the security
	provided by a symmetric key algorithm in half. As a result, the PSK,		provided by the key transport algorithm or the key agreement
	the key-derivation key, and the key-encryption key need at least 256		algorithm, which means that the attacker with a large-scale quantum
	bits of entropy to provide 128 bits of security. For this reason,		computer can discover the key-derivation key. In addition a large-
	these symmetric keys SHOULD be at least 256 bits in length.		scale quantum computer effectively cuts the security provided by a
			symmetric key algorithm in half. Therefore, the PSK needs at least
			256 bits of entropy to provide 128 bits of security. To match that
			same level of security, the key derivation function needs to be
			quantum-resistant and produce a key-encryption key that is at least
			256 bits in length. Similarly, the content-encryption key or
			content-authenticated-encryption key needs to be at least 256 bits in
			length.
	Implementations must randomly generate key-derivation key as well as		Implementations must randomly generate key-derivation keys as well as
	the content-encryption key or content-authenticated-encryption key.		the content-encryption keys or content-authenticated-encryption keys.
	Also, the generation of public/private key pairs for the key		Also, the generation of public/private key pairs for the key
	transport and key agreement algorithms rely on a random numbers. The		transport and key agreement algorithms rely on a random numbers. The
	use of inadequate pseudo-random number generators (PRNGs) to generate		use of inadequate pseudo-random number generators (PRNGs) to generate
	cryptographic keys can result in little or no security. An attacker		cryptographic keys can result in little or no security. An attacker
	may find it much easier to reproduce the PRNG environment that		may find it much easier to reproduce the PRNG environment that
	produced the keys, searching the resulting small set of		produced the keys, searching the resulting small set of
	possibilities, rather than brute force searching the whole key space.		possibilities, rather than brute force searching the whole key space.
	The generation of quality random numbers is difficult. [RFC4086]		The generation of quality random numbers is difficult. [RFC4086]
	offers important guidance in this area.		offers important guidance in this area.
	When using a key agreement algorithm, a key-encryption key is		When using a PSK with a key transport or a key agreement algorithm, a
	produced to encrypt the content-encryption key or content-		key-encryption key is produced to encrypt the content-encryption key
	authenticated-encryption key. If the key-encryption algorithm is		or content-authenticated-encryption key. If the key-encryption
	different that the algorithm used to protect the content, then the		algorithm is different than the algorithm used to protect the
	effective security is determined by the weaker of the two algorithms.		content, then the effective security is determined by the weaker of
	If, for example, content is encrypted with 256-bit AES, and the key		the two algorithms. If, for example, content is encrypted with
	is wrapped with 128-bit AES, then at most 128 bits of protection is		256-bit AES, and the key is wrapped with 128-bit AES, then at most
	provided. Implementers must ensure that the key-encryption algorithm		128 bits of protection is provided. Implementers must ensure that
	is as strong or stronger than the content-encryption algorithm or		the key-encryption algorithm is as strong or stronger than the
	content-authenticated-encryption algorithm.		content-encryption algorithm or content-authenticated-encryption
			algorithm.
	Implementers should not mix the quantum-resistant key management		Implementers SHOULD NOT mix quantum-resistant key management
	algorithms with their non-quantum-resistant counterparts. That is,		algorithms with their non-quantum-resistant counterparts. For
	the same content should not be protected with KeyTransRecipientInfo		example, the same content should not be protected with
	and KeyTransPSKRecipientInfo, and the same content should not be		KeyTransRecipientInfo and KeyTransPSKRecipientInfo. Likewise, the
	protected with KeyAgreeRecipientInfo and KeyAgreePSKRecipientInfo.		same content should not be protected with KeyAgreeRecipientInfo and
	Doing so would make the content vulnerable to the future invention of		KeyAgreePSKRecipientInfo. Doing so would make the content vulnerable
	a large-scale quantum computer.		to the future invention of a large-scale quantum computer.
	Implementer should not send the same content in different in separate		Implementers should not send the same content in different messages,
	messages, one using a quantum-resistant key management algorithm and		one using a quantum-resistant key management algorithm and the other
	the other using a non-quantum-resistant key management algorithm,		using a non-quantum-resistant key management algorithm, even if the
	even if the content-encryption key is generated independently. Doing		content-encryption key is generated independently. Doing so may
	so may allow an eavesdropper to correlate the messages, making the		allow an eavesdropper to correlate the messages, making the content
	content vulnerable to the future invention of a large-scale quantum		vulnerable to the future invention of a large-scale quantum computer.
	computer.
	Implementers should be aware that cryptographic algorithms become		Implementers should be aware that cryptographic algorithms become
	weaker with time. As new cryptoanalysis techniques are developed and		weaker with time. As new cryptoanalysis techniques are developed and
	computing performance improves, the work factor to break a particular		computing performance improves, the work factor to break a particular
	cryptographic algorithm will be reduced. Therefore, cryptographic		cryptographic algorithm will be reduced. Therefore, cryptographic
	algorithm implementations should be modular, allowing new algorithms		algorithm implementations should be modular, allowing new algorithms
	to be readily inserted. That is, implementors should be prepared for		to be readily inserted. That is, implementors should be prepared for
	the set of supported algorithms to change over time.		the set of supported algorithms to change over time.
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 12, line 48 ¶		skipping to change at page 13, line 17 ¶
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, 2015.		(DER)", ITU-T Recommendation X.690, 2015.
	9. Informative References		9. Informative References
	[AES] National Institute of Standards and Technology, FIPS Pub		[AES] National Institute of Standards and Technology, FIPS Pub
	197: Advanced Encryption Standard (AES), 26 November 2001.		197: Advanced Encryption Standard (AES), 26 November 2001.
	[C2PQ] Hoffman, P., "The Transition from Classical to Post-		[C2PQ] Hoffman, P., "The Transition from Classical to Post-
	Quantum Cryptography", work-in-progress, draft-hoffman-		Quantum Cryptography", work-in-progress, draft-hoffman-
	c2pq-02, August 2017.		c2pq-03, February 2018.
	[IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi-		[IANA-MOD] https://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#security-smime-0.		numbers.xhtml#security-smime-0.
	[IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi-		[IANA-SMIME] https://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#security-smime.		numbers.xhtml#security-smime.
	[IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi-		[IANA-ORI] https://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#security-smime-13.		numbers.xhtml#security-smime-13.
	skipping to change at page 13, line 40 ¶		skipping to change at page 14, line 11 ¶
	[RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for		[RFC5911] Hoffman, P., and J. Schaad, "New ASN.1 Modules for
	Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,		Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
	June 2010.		June 2010.
	[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the		[RFC5912] Hoffman, P., and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)" RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)" RFC 5912,
	June 2010.		June 2010.
	Acknowledgements		Acknowledgements
	Many thanks to Burt Kaliski, Jim Schaad, and Sean Turner for their		Many thanks to Burt Kaliski, Panos Kampanakis, Jim Schaad, Sean
	review and insightful comments. They have greatly improved the		Turner, and Daniel Van Geest for their review and insightful
	design.		comments. They have greatly improved the design and implementation
			guidance.
	Author's Address		Author's Address
	Russell Housley		Russell Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
End of changes. 21 change blocks.
	67 lines changed or deleted		82 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/