Diff: draft-ietf-keyprov-dskpp-10.txt - draft-ietf-keyprov-dskpp-11.txt

draft-ietf-keyprov-dskpp-10.txt	draft-ietf-keyprov-dskpp-11.txt
KEYPROV Working Group A. Doherty	KEYPROV Working Group A. Doherty
Internet-Draft RSA, The Security Division of EMC	Internet-Draft RSA, The Security Division of EMC
Intended status: Standards Track M. Pei	Intended status: Standards Track M. Pei
Expires: October 10, 2010 Verisign, Inc.	Expires: November 14, 2010 Verisign, Inc.
S. Machani	S. Machani
Diversinet Corp.	Diversinet Corp.
M. Nystrom	M. Nystrom
Microsoft Corp.	Microsoft Corp.
April 8, 2010	May 13, 2010
Dynamic Symmetric Key Provisioning Protocol (DSKPP)	Dynamic Symmetric Key Provisioning Protocol (DSKPP)
draft-ietf-keyprov-dskpp-10.txt	draft-ietf-keyprov-dskpp-11.txt
Abstract	Abstract
DSKPP is a client-server protocol for initialization (and	DSKPP is a client-server protocol for initialization (and
configuration) of symmetric keys to locally and remotely accessible	configuration) of symmetric keys to locally and remotely accessible
cryptographic modules. The protocol can be run with or without	cryptographic modules. The protocol can be run with or without
private-key capabilities in the cryptographic modules, and with or	private-key capabilities in the cryptographic modules, and with or
without an established public-key infrastructure.	without an established public-key infrastructure.
Two variations of the protocol support multiple usage scenarios.	Two variations of the protocol support multiple usage scenarios.
skipping to change at page 2, line 4 ¶	skipping to change at page 2, line 4 ¶
Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.	Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."	material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2010.	This Internet-Draft will expire on November 14, 2010.
Copyright Notice	Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the	Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.	document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of	(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents	publication of this document. Please review these documents
skipping to change at page 3, line 16 ¶	skipping to change at page 3, line 16 ¶
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6	1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 6	1.2. Versions . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 7	1.3. Namespace Identifiers . . . . . . . . . . . . . . . . . . 7
1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 7	1.3.1. Defined Identifiers . . . . . . . . . . . . . . . . . 7
1.3.2. Identifiers Defined in Related Specifications . . . . 7	1.3.2. Identifiers Defined in Related Specifications . . . . 7
1.3.3. Referenced Identifiers . . . . . . . . . . . . . . . . 7	1.3.3. Referenced Identifiers . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7	2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 9	2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10	2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 10
3. DSKPP Overview . . . . . . . . . . . . . . . . . . . . . . . . 11	3. DSKPP Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Protocol Entities . . . . . . . . . . . . . . . . . . . . 11	3.1. Protocol Entities . . . . . . . . . . . . . . . . . . . . 11
3.2. Basic DSKPP Exchange . . . . . . . . . . . . . . . . . . . 12	3.2. Basic DSKPP Exchange . . . . . . . . . . . . . . . . . . . 12
3.2.1. User Authentication . . . . . . . . . . . . . . . . . 12	3.2.1. User Authentication . . . . . . . . . . . . . . . . . 12
3.2.2. Protocol Initiated by the DSKPP Client . . . . . . . . 12	3.2.2. Protocol Initiated by the DSKPP Client . . . . . . . . 12
3.2.3. Protocol Triggered by the DSKPP Server . . . . . . . . 15	3.2.3. Protocol Triggered by the DSKPP Server . . . . . . . . 15
3.2.4. Variants . . . . . . . . . . . . . . . . . . . . . . . 16	3.2.4. Variants . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 17	3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Basic Constructs . . . . . . . . . . . . . . . . . . . . . 18	3.4. Basic Constructs . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 37 ¶	skipping to change at page 4, line 37 ¶
10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 58	10.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 58
10.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 58	10.4. Cryptographic Attacks . . . . . . . . . . . . . . . . . . 58
10.5. Attacks on the Interaction between DSKPP and User	10.5. Attacks on the Interaction between DSKPP and User
Authentication . . . . . . . . . . . . . . . . . . . . . . 58	Authentication . . . . . . . . . . . . . . . . . . . . . . 58
10.6. Miscellaneous Considerations . . . . . . . . . . . . . . . 59	10.6. Miscellaneous Considerations . . . . . . . . . . . . . . . 59
10.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 59	10.6.1. Client Contributions to K_TOKEN Entropy . . . . . . . 59
10.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . . 59	10.6.2. Key Confirmation . . . . . . . . . . . . . . . . . . . 59
10.6.3. Server Authentication . . . . . . . . . . . . . . . . 60	10.6.3. Server Authentication . . . . . . . . . . . . . . . . 60
10.6.4. User Authentication . . . . . . . . . . . . . . . . . 60	10.6.4. User Authentication . . . . . . . . . . . . . . . . . 60
10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . . 60	10.6.5. Key Protection in Two-Pass DSKPP . . . . . . . . . . . 60
11. Internationalization Considerations . . . . . . . . . . . . . 61	10.6.6. Algorithm Agility . . . . . . . . . . . . . . . . . . 61
11. Internationalization Considerations . . . . . . . . . . . . . 62
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 62	12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 62
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 62	12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 63
12.3. MIME Media Type Registration . . . . . . . . . . . . . . . 63	12.3. MIME Media Type Registration . . . . . . . . . . . . . . . 63
12.4. Status Code Registry . . . . . . . . . . . . . . . . . . . 63	12.4. Status Code Registry . . . . . . . . . . . . . . . . . . . 64
13. Intellectual Property Considerations . . . . . . . . . . . . . 64	13. Intellectual Property Considerations . . . . . . . . . . . . . 64
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 64	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 64
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65	16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
16.1. Normative references . . . . . . . . . . . . . . . . . . . 65	16.1. Normative references . . . . . . . . . . . . . . . . . . . 66
16.2. Informative references . . . . . . . . . . . . . . . . . . 67	16.2. Informative references . . . . . . . . . . . . . . . . . . 67
Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . . 68	Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . . 69
A.1. Single Key Request . . . . . . . . . . . . . . . . . . . . 69	A.1. Single Key Request . . . . . . . . . . . . . . . . . . . . 69
A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 69	A.2. Multiple Key Requests . . . . . . . . . . . . . . . . . . 69
A.3. User Authentication . . . . . . . . . . . . . . . . . . . 69	A.3. User Authentication . . . . . . . . . . . . . . . . . . . 69
A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . . 69	A.4. Provisioning Time-Out Policy . . . . . . . . . . . . . . . 70
A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 69	A.5. Key Renewal . . . . . . . . . . . . . . . . . . . . . . . 70
A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . . 70	A.6. Pre-Loaded Key Replacement . . . . . . . . . . . . . . . . 70
A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . . 70	A.7. Pre-Shared Manufacturing Key . . . . . . . . . . . . . . . 70
A.8. End-to-End Protection of Key Material . . . . . . . . . . 70	A.8. End-to-End Protection of Key Material . . . . . . . . . . 71
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 71	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 71
B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 71	B.1. Trigger Message . . . . . . . . . . . . . . . . . . . . . 72
B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . . 71	B.2. Four-Pass Protocol . . . . . . . . . . . . . . . . . . . . 72
B.2.1. <KeyProvClientHello> Without a Preceding Trigger . . . 71	B.2.1. <KeyProvClientHello> Without a Preceding Trigger . . . 72
B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 72	B.2.2. <KeyProvClientHello> Assuming a Preceding Trigger . . 73
B.2.3. <KeyProvServerHello> Without a Preceding Trigger . . . 74	B.2.3. <KeyProvServerHello> Without a Preceding Trigger . . . 75
B.2.4. <KeyProvServerHello> Assuming Key Renewal . . . . . . 75	B.2.4. <KeyProvServerHello> Assuming Key Renewal . . . . . . 76
B.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 75	B.2.5. <KeyProvClientNonce> Using Default Encryption . . . . 76
B.2.6. <KeyProvServerFinished> Using Default Encryption . . . 76	B.2.6. <KeyProvServerFinished> Using Default Encryption . . . 77
B.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 78	B.3. Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . 79
B.3.1. Example Using the Key Transport Method . . . . . . . . 78	B.3.1. Example Using the Key Transport Method . . . . . . . . 79
B.3.2. Example Using the Key Wrap Method . . . . . . . . . . 81	B.3.2. Example Using the Key Wrap Method . . . . . . . . . . 82
B.3.3. Example Using the Passphrase-Based Key Wrap Method . . 84	B.3.3. Example Using the Passphrase-Based Key Wrap Method . . 85
Appendix C. Integration with PKCS #11 . . . . . . . . . . . . . . 88	Appendix C. Integration with PKCS #11 . . . . . . . . . . . . . . 89
C.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . . 88	C.1. The 4-pass Variant . . . . . . . . . . . . . . . . . . . . 89
C.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . . 88	C.2. The 2-pass Variant . . . . . . . . . . . . . . . . . . . . 89
Appendix D. Example of DSKPP-PRF Realizations . . . . . . . . . . 91	Appendix D. Example of DSKPP-PRF Realizations . . . . . . . . . . 92
D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 91	D.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 92
D.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 91	D.2. DSKPP-PRF-AES . . . . . . . . . . . . . . . . . . . . . . 92
D.2.1. Identification . . . . . . . . . . . . . . . . . . . . 91	D.2.1. Identification . . . . . . . . . . . . . . . . . . . . 92
D.2.2. Definition . . . . . . . . . . . . . . . . . . . . . . 91	D.2.2. Definition . . . . . . . . . . . . . . . . . . . . . . 92
D.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 93	D.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 94
D.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . . 93	D.3. DSKPP-PRF-SHA256 . . . . . . . . . . . . . . . . . . . . . 94
D.3.1. Identification . . . . . . . . . . . . . . . . . . . . 93	D.3.1. Identification . . . . . . . . . . . . . . . . . . . . 94
D.3.2. Definition . . . . . . . . . . . . . . . . . . . . . . 93	D.3.2. Definition . . . . . . . . . . . . . . . . . . . . . . 94
D.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 94	D.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction	1. Introduction
Symmetric key based cryptographic systems (e.g., those providing	Symmetric key based cryptographic systems (e.g., those providing
authentication mechanisms such as one-time passwords and challenge-	authentication mechanisms such as one-time passwords and challenge-
response) offer performance and operational advantages over public	response) offer performance and operational advantages over public
key schemes. Such use requires a mechanism for provisioning of	key schemes. Such use requires a mechanism for provisioning of
symmetric keys providing equivalent functionality to mechanisms such	symmetric keys providing equivalent functionality to mechanisms such
as CMP [RFC4210] and CMC [RFC5272] in a Public Key Infrastructure.	as CMP [RFC4210] and CMC [RFC5272] in a Public Key Infrastructure.
skipping to change at page 7, line 5 ¶	skipping to change at page 6, line 50 ¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].	document are to be interpreted as described in [RFC2119].
1.2. Versions	1.2. Versions
There is a provision made in the syntax for an explicit version	There is a provision made in the syntax for an explicit version
number. Only version "1.0" is currently specified.	number. Only version "1.0" is currently specified.
The purpose for versioning the protocol is to provide a mechanism by
which changes to required cryptographic algorithms (e.g., SHA-256)
and attributes (e.g., key size) can be deployed without disrupting
existing implementations; likewise, out-dated implementations can be
de-commissioned without disrupting operations involving newer
protocol versions.
1.3. Namespace Identifiers	1.3. Namespace Identifiers
This document uses Uniform Resource Identifiers [RFC2396] to identify	This document uses Uniform Resource Identifiers [RFC2396] to identify
resources, algorithms, and semantics.	resources, algorithms, and semantics.
1.3.1. Defined Identifiers	1.3.1. Defined Identifiers
The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:	The XML namespace [XMLNS] URI for Version 1.0 of DSKPP protocol is:
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"	xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
skipping to change at page 58, line 52 ¶	skipping to change at page 58, line 52 ¶
implementations.	implementations.
10.5. Attacks on the Interaction between DSKPP and User Authentication	10.5. Attacks on the Interaction between DSKPP and User Authentication
If keys generated in DSKPP will be associated with a particular user	If keys generated in DSKPP will be associated with a particular user
at the DSKPP server (or a server trusted by, and communicating with	at the DSKPP server (or a server trusted by, and communicating with
the DSKPP server), then in order to protect against threats where an	the DSKPP server), then in order to protect against threats where an
attacker replaces a client-provided encrypted R_C with his own R'C	attacker replaces a client-provided encrypted R_C with his own R'C
(regardless of whether the public-key variation or the shared-secret	(regardless of whether the public-key variation or the shared-secret
variation of DSKPP is employed to encrypt the client nonce), the	variation of DSKPP is employed to encrypt the client nonce), the
server SHOULD not commit to associate a generated K_TOKEN with the	server SHOULD NOT commit to associate a generated K_TOKEN with the
given cryptographic module until the user simultaneously has proven	given cryptographic module until the user simultaneously has proven
both possession of the device that hosts the cryptographic module	both possession of the device that hosts the cryptographic module
containing K_TOKEN and some out-of-band provided authenticating	containing K_TOKEN and some out-of-band provided authenticating
information (e.g., an authentication code). For example, if the	information (e.g., an authentication code). For example, if the
cryptographic module is a one-time password token, the user could be	cryptographic module is a one-time password token, the user could be
required to authenticate with both a one-time password generated by	required to authenticate with both a one-time password generated by
the cryptographic module and an out-of-band provided authentication	the cryptographic module and an out-of-band provided authentication
code in order to have the server "commit" to the generated OTP value	code in order to have the server "commit" to the generated OTP value
for the given user. Preferably, the user SHOULD perform this	for the given user. Preferably, the user SHOULD perform this
operation from another host than the one used to initialize keys on	operation from another host than the one used to initialize keys on
skipping to change at page 61, line 41 ¶	skipping to change at page 61, line 41 ¶
module to decrypt the newly delivered K_TOKEN. Servers MAY use	module to decrypt the newly delivered K_TOKEN. Servers MAY use
relatively low iteration counts to accommodate devices with	relatively low iteration counts to accommodate devices with
limited processing power such as some PDA and cell phones when	limited processing power such as some PDA and cell phones when
other security measures are implemented and the security of the	other security measures are implemented and the security of the
passphrase-based key wrap method is not weakened.	passphrase-based key wrap method is not weakened.
o Transport level security (e.g. TLS) SHOULD be used where possible	o Transport level security (e.g. TLS) SHOULD be used where possible
to protect a two-pass protocol run. Transport level security	to protect a two-pass protocol run. Transport level security
provides a second layer of protection for the newly generated	provides a second layer of protection for the newly generated
K_TOKEN.	K_TOKEN.
10.6.6. Algorithm Agility
Many protocols need to be algorithm agile. One reason for this is
that in the past many protocols had fixed sized fields for
information such as hash outputs, keys, etc. This is not the case
for DSKPP, except for the key size in the computation of DSKPP-PRF.
Another reason was that protocols did not support algorithm
negotiation. This is also not the case for DSKPP, except for the use
of SHA-256 in the MAC confirmation message. Updating the key size
for DSKPP-PRF or the MAC confirmation message algorithm will require
a new version of the protocol, which is supported with the Version
attribute.
11. Internationalization Considerations	11. Internationalization Considerations
The DSKPP protocol is mostly meant for machine-to-machine	The DSKPP protocol is mostly meant for machine-to-machine
communications; as such, most of its elements are tokens not meant	communications; as such, most of its elements are tokens not meant
for direct human consumption. If these tokens are presented to the	for direct human consumption. If these tokens are presented to the
end user, some localization may need to occur. DSKPP exchanges	end user, some localization may need to occur. DSKPP exchanges
information using XML. All XML processors are required to understand	information using XML. All XML processors are required to understand
UTF-8 and UTF-16 encoding, and therefore all DSKPP clients and	UTF-8 [RFC3629] and UTF-16 [RFC2781] encoding, and therefore all
servers MUST understand UTF-8 and UTF-16 encoded XML. Additionally,	DSKPP clients and servers MUST understand UTF-8 and UTF-16 encoded
DSKPP servers and clients MUST NOT encode XML with encodings other	XML. Additionally, DSKPP servers and clients MUST NOT encode XML
than UTF-8 or UTF-16.	with encodings other than UTF-8 or UTF-16.
12. IANA Considerations	12. IANA Considerations
This document requires several IANA registrations, detailed below.	This document requires several IANA registrations, detailed below.
12.1. URN Sub-Namespace Registration	12.1. URN Sub-Namespace Registration
This section registers a new XML namespace,	This section registers a new XML namespace,
"urn:ietf:params:xml:ns:keyprov:dskpp" per the guidelines in	"urn:ietf:params:xml:ns:keyprov:dskpp" per the guidelines in
[RFC3688]:	[RFC3688]:
skipping to change at page 66, line 29 ¶	skipping to change at page 66, line 44 ¶
03.txt>.	03.txt>.
[RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-	[RFC2104] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,	Hashing for Message Authentication", RFC 2104,
February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.	February 1997, <http://www.ietf.org/rfc/rfc2104.txt>.
[RFC2119] "Key words for use in RFCs to Indicate Requirement	[RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997,	Levels", BCP 14, RFC 2119, March 1997,
<http://www.ietf.org/rfc/rfc2119.txt>.	<http://www.ietf.org/rfc/rfc2119.txt>.
[RFC3629] "UTF-8, a transformation format of ISO10646", STD 63,	[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
RFC 3629, November 2003,	10646", February 2000,
<http://www.ietf.org/rfc/rfc2781.txt>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO10646",
STD 63, RFC 3629, November 2003,
<http://www.ietf.org/rfc/rfc3629.txt>.	<http://www.ietf.org/rfc/rfc3629.txt>.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,	[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate	"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005,	Management Protocol (CMP)", RFC 4210, September 2005,
<http://www.ietf.org/rfc/rfc4210.txt>.	<http://www.ietf.org/rfc/rfc4210.txt>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS	[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008,	(CMC)", RFC 5272, June 2008,
<http://www.ietf.org/rfc/rfc5272.txt>.	<http://www.ietf.org/rfc/rfc5272.txt>.
End of changes. 18 change blocks.
48 lines changed or deleted		73 lines changed or added
This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff