draft-ietf-ace-coap-est-09.txt		draft-ietf-ace-coap-est-10.txt
	ACE P. van der Stok		ACE P. van der Stok
	Internet-Draft Consultant		Internet-Draft Consultant
	Intended status: Standards Track P. Kampanakis		Intended status: Standards Track P. Kampanakis
	Expires: August 31, 2019 Cisco Systems		Expires: September 9, 2019 Cisco Systems
	M. Richardson		M. Richardson
	SSW		SSW
	S. Raza		S. Raza
	RISE SICS		RISE SICS
	February 27, 2019		March 8, 2019
	EST over secure CoAP (EST-coaps)		EST over secure CoAP (EST-coaps)
	draft-ietf-ace-coap-est-09		draft-ietf-ace-coap-est-10
	Abstract		Abstract
	Enrollment over Secure Transport (EST) is used as a certificate		Enrollment over Secure Transport (EST) is used as a certificate
	provisioning protocol over HTTPS. Low-resource devices often use the		provisioning protocol over HTTPS. Low-resource devices often use the
	lightweight Constrained Application Protocol (CoAP) for message		lightweight Constrained Application Protocol (CoAP) for message
	exchanges. This document defines how to transport EST payloads over		exchanges. This document defines how to transport EST payloads over
	secure CoAP (EST-coaps), which allows constrained devices to use		secure CoAP (EST-coaps), which allows constrained devices to use
	existing EST functionality for provisioning certificates.		existing EST functionality for provisioning certificates.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 31, 2019.		This Internet-Draft will expire on September 9, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 6		4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7
	5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9		5. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9		5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 9
	5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 11		5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
	5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12		5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13		5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13
	5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14		5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14
	5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 14		5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15
	5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 15		5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16
	5.8. Server-side Key Generation . . . . . . . . . . . . . . . 17		5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18
	6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19		6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19
	7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 20		7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8. Deployment limitations . . . . . . . . . . . . . . . . . . . 21		8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 21		9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22
	9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22		9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 23		10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
	10.1. EST server considerations . . . . . . . . . . . . . . . 23		10.1. EST server considerations . . . . . . . . . . . . . . . 23
	10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 24		10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	13.1. Normative References . . . . . . . . . . . . . . . . . . 26		13.1. Normative References . . . . . . . . . . . . . . . . . . 26
	13.2. Informative References . . . . . . . . . . . . . . . . . 27		13.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30		Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30
	A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 30		A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31
	A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32		A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32
	A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34		A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34
	A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36		A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36
	Appendix B. EST-coaps Block message examples . . . . . . . . . . 37		Appendix B. EST-coaps Block message examples . . . . . . . . . . 37
	B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37		B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37
	B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41		B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41
	Appendix C. Message content breakdown . . . . . . . . . . . . . 42		Appendix C. Message content breakdown . . . . . . . . . . . . . 42
	C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42		C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42
	C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44		C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44
	C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45		C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Change Log		1. Change Log
	EDNOTE: Remove this section before publication		EDNOTE: Remove this section before publication
			-10
			Addressed WGLC comments
			More consistent request format in the examples.
			Explained root resource difference when there is resource
			discovery
			Clarified when the client is supposed to do discovery
			Fixed nits and minor Option length inaccurracies in the examples.
	-09		-09
	WGLC comments taken into account		WGLC comments taken into account
	consensus about discovery of content-format		consensus about discovery of content-format
	added additional path for content-format selection		added additional path for content-format selection
	merged DTLS sections		merged DTLS sections
	skipping to change at page 9, line 39 ¶		skipping to change at page 10, line 7 ¶
	o Server-side key generation messages to provide a private client		o Server-side key generation messages to provide a private client
	identity key when the client choses so.		identity key when the client choses so.
	5.1. Discovery and URIs		5.1. Discovery and URIs
	EST-coaps is targeted for low-resource networks with small packets.		EST-coaps is targeted for low-resource networks with small packets.
	Saving header space is important and short EST-coaps URIs are		Saving header space is important and short EST-coaps URIs are
	specified in this document. These URIs are shorter than the ones in		specified in this document. These URIs are shorter than the ones in
	[RFC7030]. Two example EST-coaps resource path names are:		[RFC7030]. Two example EST-coaps resource path names are:
	coaps://est-coaps.example.org:<port>/.well-known/est/<short-est>		coaps://example.com:<port>/.well-known/est/<short-est>
	coaps://est-coaps.example.org:<port>/.well-known/est/		coaps://example.com:<port>/.well-known/est/
	ArbitraryLabel/<short-est>		ArbitraryLabel/<short-est>
	The short-est strings are defined in Table 1. The ArbitraryLabel		The short-est strings are defined in Table 1. Arbitrary Labels are
	path-segment, if used, SHOULD be of the shortest length possible		usually defined and used by EST CAs in order to route client requests
	(Sections 3.1 and 3.2.2 of [RFC7030]. Arbitrary Labels are usually		to the appropriate certificate profile. Implementers should consider
	defined and used by EST CAs in order to route client requests to the		using short labels to minimize transmission overhead.
	appropriate certificate profile.
	The EST-coaps server URIs, obtained through discovery of the EST-		The EST-coaps server URIs, obtained through discovery of the EST-
	coaps root resource(s) as shown below, are of the form:		coaps resource(s) as shown below, are of the form:
	coaps://est-coaps.example.org:<port>/<root-resource>/<short-est>		coaps://example.com:<port>/<root-resource>/<short-est>
	coaps://est-coaps.example.org:<port>/<root-resource>/		coaps://example.com:<port>/<root-resource>/
	ArbitraryLabel/<short-est>		ArbitraryLabel/<short-est>
	Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and		Figure 5 in Section 3.2.2 of [RFC7030] enumerates the operations and
	corresponding paths which are supported by EST. Table 1 provides the		corresponding paths which are supported by EST. Table 1 provides the
	mapping from the EST URI path to the shorter EST-coaps URI path.		mapping from the EST URI path to the shorter EST-coaps URI path.
	+------------------+-------------------------------+		+------------------+-------------------------------+
	| EST | EST-coaps |		| EST | EST-coaps |
	+------------------+-------------------------------+		+------------------+-------------------------------+
	| /cacerts | /crts |		| /cacerts | /crts |
	skipping to change at page 10, line 31 ¶		skipping to change at page 10, line 45 ¶
	| /serverkeygen | /skc (application/pkix-cert) |		| /serverkeygen | /skc (application/pkix-cert) |
	+------------------+-------------------------------+		+------------------+-------------------------------+
	Table 1: Short EST-coaps URI path		Table 1: Short EST-coaps URI path
	The /skg message is the EST /serverkeygen equivalent where the client		The /skg message is the EST /serverkeygen equivalent where the client
	requests for a certificate in PKCS#7 format and a private key. If		requests for a certificate in PKCS#7 format and a private key. If
	the client prefers a single application/pkix-cert certificate instead		the client prefers a single application/pkix-cert certificate instead
	of PKCS#7, he will make an /skc request.		of PKCS#7, he will make an /skc request.
	Clients and servers MUST support the short resource URIs.		Clients and servers MUST support the short resource EST-coaps URIs.
	In the context of CoAP, the presence and location of (path to) the		In the context of CoAP, the presence and location of (path to) the
	management data are discovered by sending a GET request to "/.well-		management data are discovered by sending a GET request to "/.well-
	known/core" including a resource type (RT) parameter with the value		known/core" including a resource type (RT) parameter with the value
	"ace.est*" [RFC6690]. Upon success, the return payload will contain		"ace.est*" [RFC6690]. Upon success, the return payload will contain
	the root resource of the EST resources. The example below shows the		the root resource of the EST resources. The example below shows the
	discovery of the presence and location of EST-coaps resources.		discovery of the presence and location of EST-coaps resources.
	Linefeeds are included only for readability.		Linefeeds are included only for readability.
	REQ: GET /.well-known/core?rt=ace.est*		REQ: GET /.well-known/core?rt=ace.est*
	skipping to change at page 11, line 6 ¶		skipping to change at page 11, line 21 ¶
	</est/sen>;rt="ace.est.sen";ct="281 TBD287",		</est/sen>;rt="ace.est.sen";ct="281 TBD287",
	</est/sren>;rt="ace.est.sren";ct="281 TBD287",		</est/sren>;rt="ace.est.sren";ct="281 TBD287",
	</est/att>;rt="ace.est.att";ct=285,		</est/att>;rt="ace.est.att";ct=285,
	</est/skg>;rt="ace.est.skg";ct=62,		</est/skg>;rt="ace.est.skg";ct=62,
	</est/skc>;rt="ace.est.skc";ct=62		</est/skc>;rt="ace.est.skc";ct=62
	The first three lines of the discovery response above MUST be		The first three lines of the discovery response above MUST be
	returned if the server supports resource discovery. The last three		returned if the server supports resource discovery. The last three
	lines are only included if the corresponding EST functions are		lines are only included if the corresponding EST functions are
	implemented. The Content-Formats in the response allow the client to		implemented. The Content-Formats in the response allow the client to
	request one that is supported by the server.		request one that is supported by the server. These are the values
			that would be sent in the client request with an Accept option.
	Discoverable port numbers can be returned in the response payload.		Discoverable port numbers can be returned in the response payload.
	An example response payload for non-default CoAPS server port 61617		An example response payload for non-default CoAPS server port 61617
	follows below. Linefeeds were included only for readability.		follows below. Linefeeds were included only for readability.
	REQ: GET /.well-known/core?rt=ace.est*		REQ: GET /.well-known/core?rt=ace.est*
	RES: 2.05 Content		RES: 2.05 Content
	<coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts";		<coaps://[2001:db8:3::123]:61617/est/crts>;rt="ace.est.crts";
	ct="281 TBD287",		ct="281 TBD287",
	skipping to change at page 11, line 31 ¶		skipping to change at page 11, line 47 ¶
	<coaps://[2001:db8:3::123]:61617/est/att>;rt="ace.est.att";		<coaps://[2001:db8:3::123]:61617/est/att>;rt="ace.est.att";
	ct=285,		ct=285,
	<coaps://[2001:db8:3::123]:61617/est/skg>;rt="ace.est.skg";		<coaps://[2001:db8:3::123]:61617/est/skg>;rt="ace.est.skg";
	ct=62,		ct=62,
	<coaps://[2001:db8:3::123]:61617/est/skc>;rt="ace.est.skc";		<coaps://[2001:db8:3::123]:61617/est/skc>;rt="ace.est.skc";
	ct=62		ct=62
	The server MUST support the default /.well-known/est root resource.		The server MUST support the default /.well-known/est root resource.
	The server SHOULD support resource discovery when he supports non-		The server SHOULD support resource discovery when he supports non-
	default URIs (like /est or /est/ArbitraryLabel) or ports. The client		default URIs (like /est or /est/ArbitraryLabel) or ports. The client
	SHOULD use resource discovery when /.well-known/est fails or when the		SHOULD use resource discovery when he is unaware of the available
	client is unaware of the available EST-coaps resources.		EST-coaps resources.
	It is up to the implementation to choose its root resource;		It is up to the implementation to choose its resource paths;
	throughout this document the example root resource /est is used.		throughout this document the example root resource /est is used.
	5.2. Mandatory/optional EST Functions		5.2. Mandatory/optional EST Functions
	This specification contains a set of required-to-implement functions,		This specification contains a set of required-to-implement functions,
	optional functions, and not specified functions. The latter ones are		optional functions, and not specified functions. The latter ones are
	deemed too expensive for low-resource devices in payload and		deemed too expensive for low-resource devices in payload and
	calculation times.		calculation times.
	Table 2 specifies the mandatory-to-implement or optional		Table 2 specifies the mandatory-to-implement or optional
	skipping to change at page 13, line 39 ¶		skipping to change at page 13, line 49 ¶
	container) with Content-Format identifier TBD287 (0x011F) instead of		container) with Content-Format identifier TBD287 (0x011F) instead of
	281. In cases where the private key is encrypted with CMS (as		281. In cases where the private key is encrypted with CMS (as
	explained in Section 5.8) the Content-Format identifier is 280		explained in Section 5.8) the Content-Format identifier is 280
	(0x0118) instead of 284. The key and certificate representations are		(0x0118) instead of 284. The key and certificate representations are
	ASN.1 encoded in binary format. An example is shown in Appendix A.3.		ASN.1 encoded in binary format. An example is shown in Appendix A.3.
	5.4. Message Bindings		5.4. Message Bindings
	The general EST-coaps message characteristics are:		The general EST-coaps message characteristics are:
	o All EST-coaps request messages expect an acknowledgement (with a		o EST-coaps servers sometimes need to provide delayed responses
	response payload); EST-coaps requests are confirmable CON CoAP		which are conveyed with an empty ACK or an ACK containing response
	messages.		code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED
			for implementers to send EST-coaps requests in confirmable CON
			CoAP messages.
	o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-		o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
	Format, Block, Accept and Location-Path. These CoAP Options are		Format, Block, Accept and Location-Path. These CoAP Options are
	used to communicate the HTTP fields specified in the EST REST		used to communicate the HTTP fields specified in the EST REST
	messages. The URI-host and Uri-Port Options can be omitted from		messages. The Uri-host and Uri-Port Options can be omitted from
	the COAP message sent on the wire. When omitted, they are		the COAP message sent on the wire. When omitted, they are
	logically assumed to be the transport protocol destination address		logically assumed to be the transport protocol destination address
	and port respectively. Explicit Uri-Host and Uri-Port Options are		and port respectively. Explicit Uri-Host and Uri-Port Options are
	typically used when an endpoint hosts multiple virtual servers and		typically used when an endpoint hosts multiple virtual servers and
	uses the Options to route the requests accordingly. Other COAP		uses the Options to route the requests accordingly. Other COAP
	Options should be handled in accordance with [RFC7252].		Options should be handled in accordance with [RFC7252].
	o EST URLs are HTTPS based (https://), in CoAP these are assumed to		o EST URLs are HTTPS based (https://), in CoAP these are assumed to
	be translated to CoAPS (coaps://)		be translated to CoAPS (coaps://)
	skipping to change at page 20, line 48 ¶		skipping to change at page 21, line 29 ¶
	If necessary, the EST-coaps-to-HTTP Registrar will support resouce		If necessary, the EST-coaps-to-HTTP Registrar will support resouce
	discovery according to the rules in Section 5.1.		discovery according to the rules in Section 5.1.
	7. Parameters		7. Parameters
	This section addresses transmission parameters described in sections		This section addresses transmission parameters described in sections
	4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on		4.7 and 4.8 of [RFC7252]. EST does not impose any unique values on
	the CoAP parameters in [RFC7252], but the EST parameter values need		the CoAP parameters in [RFC7252], but the EST parameter values need
	to be tuned to the CoAP parameter values.		to be tuned to the CoAP parameter values.
	It is RECOMMENDED, based on experiments, to follow the default CoAP		It is recommended, based on experiments, to follow the default CoAP
	configuration parameters ([RFC7252]). However, depending on the		configuration parameters ([RFC7252]). However, depending on the
	implementation scenario, retransmissions and timeouts can also occur		implementation scenario, retransmissions and timeouts can also occur
	on other networking layers, governed by other configuration		on other networking layers, governed by other configuration
	parameters. A change in a server parameter MUST ensure the adjusted		parameters. A change in a server parameter MUST ensure the adjusted
	value is also available to all the endpoints with which these		value is also available to all the endpoints with which these
	adjusted values are to be used to communicate.		adjusted values are to be used to communicate.
	Some further comments about some specific parameters, mainly from		Some further comments about some specific parameters, mainly from
	Table 2 in [RFC7252]:		Table 2 in [RFC7252]:
	skipping to change at page 27, line 32 ¶		skipping to change at page 28, line 12 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	13.2. Informative References		13.2. Informative References
	[COREparams]		[COREparams]
	IANA, "Constrained RESTful Environments (CoRE)		"Constrained RESTful Environments (CoRE) Parameters",
	Parameters", <https://www.iana.org/assignments/core-		<https://www.iana.org/assignments/core-parameters/
	parameters/core-parameters.xhtml>.		core-parameters.xhtml>.
	[I-D.ietf-lamps-rfc5751-bis]		[I-D.ietf-lamps-rfc5751-bis]
	Schaad, J., Ramsdell, B., and S. Turner, "Secure/		Schaad, J., Ramsdell, B., and S. Turner, "Secure/
	Multipurpose Internet Mail Extensions (S/MIME) Version 4.0		Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
	Message Specification", draft-ietf-lamps-rfc5751-bis-12		Message Specification", draft-ietf-lamps-rfc5751-bis-12
	(work in progress), September 2018.		(work in progress), September 2018.
	[I-D.ietf-tls-dtls-connection-id]		[I-D.ietf-tls-dtls-connection-id]
	Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,		Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
	"Connection Identifiers for DTLS 1.2", draft-ietf-tls-		"Connection Identifiers for DTLS 1.2", draft-ietf-tls-
	skipping to change at page 28, line 11 ¶		skipping to change at page 28, line 38 ¶
	Josefsson, S., "Channel Bindings for TLS based on the		Josefsson, S., "Channel Bindings for TLS based on the
	PRF", draft-josefsson-sasl-tls-cb-03 (work in progress),		PRF", draft-josefsson-sasl-tls-cb-03 (work in progress),
	March 2015.		March 2015.
	[I-D.moskowitz-ecdsa-pki]		[I-D.moskowitz-ecdsa-pki]
	Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,		Moskowitz, R., Birkholz, H., Xia, L., and M. Richardson,
	"Guide for building an ECC pki", draft-moskowitz-ecdsa-		"Guide for building an ECC pki", draft-moskowitz-ecdsa-
	pki-04 (work in progress), September 2018.		pki-04 (work in progress), September 2018.
	[ieee802.15.4]		[ieee802.15.4]
	Institute of Electrical and Electronics Engineers, "IEEE		"IEEE Standard 802.15.4-2006", 2006.
	Standard 802.15.4-2006", 2006.
	[ieee802.1ar]		[ieee802.1ar]
	Institute of Electrical and Electronics Engineers, "IEEE		"IEEE 802.1AR Secure Device Identifier", December 2009.
	802.1AR Secure Device Identifier", December 2009.
	[PsQs] Nadia Heninger, Zakir Durumeric, Eric Wustrow, J. Alex		[PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys
	Halderman, "Mining Your Ps and Qs: Detection of Widespread		in Network Devices", USENIX Security Symposium 2012 ISBN
	Weak Keys in Network Devices", USENIX Security Symposium		978-931971-95-9, August 2012.
	2012 ISBN 978-931971-95-9, August 2012.
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals",		Overview, Assumptions, Problem Statement, and Goals",
	RFC 4919, DOI 10.17487/RFC4919, August 2007,		RFC 4919, DOI 10.17487/RFC4919, August 2007,
	<https://www.rfc-editor.org/info/rfc4919>.		<https://www.rfc-editor.org/info/rfc4919>.
	[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS		[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
	(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,		(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
	<https://www.rfc-editor.org/info/rfc5272>.		<https://www.rfc-editor.org/info/rfc5272>.
	skipping to change at page 29, line 38 ¶		skipping to change at page 30, line 17 ¶
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.		<https://www.rfc-editor.org/info/rfc7925>.
	[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic		[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
	Curve Cryptography (ECC) Cipher Suites for Transport Layer		Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier", RFC 8422,		Security (TLS) Versions 1.2 and Earlier", RFC 8422,
	DOI 10.17487/RFC8422, August 2018,		DOI 10.17487/RFC8422, August 2018,
	<https://www.rfc-editor.org/info/rfc8422>.		<https://www.rfc-editor.org/info/rfc8422>.
	[RSAorig] Petr Svenda, Matus Nemec, Peter Sekan, Rudolf Kvasnovsky,		[RSAorig] "The Million-Key Question - Investigating the Origins of
	David Formanek, David Komarek, Vashek Matyas, "The		RSA Public Keys", USENIX Security Symposium 2016 ISBN
	Million-Key Question - Investigating the Origins of RSA
	Public Keys", USENIX Security Symposium 2016 ISBN
	978-1-931971-32-4, August 2016.		978-1-931971-32-4, August 2016.
	[tripleshake]		[tripleshake]
	Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cedric		"Triple Handshakes and Cookie Cutters: Breaking and Fixing
	Fournet, Alfredo Pironti, Pierre-Yves Strub, "Triple
	Handshakes and Cookie Cutters: Breaking and Fixing
	Authentication over TLS", IEEE Security and Privacy ISBN		Authentication over TLS", IEEE Security and Privacy ISBN
	978-1-4799-4686-0, May 2014.		978-1-4799-4686-0, May 2014.
	Appendix A. EST messages to EST-coaps		Appendix A. EST messages to EST-coaps
	This section shows similar examples to the ones presented in		This section shows similar examples to the ones presented in
	Appendix A of [RFC7030]. The payloads in the examples are the hex		Appendix A of [RFC7030]. The payloads in the examples are the hex
	encoded binary, generated with 'xxd -p', of the PKI certificates		encoded binary, generated with 'xxd -p', of the PKI certificates
	created following [I-D.moskowitz-ecdsa-pki]. Hex is used for		created following [I-D.moskowitz-ecdsa-pki]. Hex is used for
	visualization purposes because a binary representation cannot be		visualization purposes because a binary representation cannot be
	rendered well in text. The hexadecimal representations would not be		rendered well in text. The hexadecimal representations would not be
	transported in hex, but in binary. The payloads are shown		transported in hex, but in binary. The payloads are shown
	unencrypted. In practice the message content would be transferred		unencrypted. In practice the message content would be transferred
	over an encrypted DTLS tunnel.		over an encrypted DTLS tunnel.
	The certificate responses included in the examples contain Content-		The certificate responses included in the examples contain Content-
	Format 281 (application/pkcs7). If the client had requested Content-		Format 281 (application/pkcs7). If the client had requested Content-
	Format TBD287 (application/pkix-cert) by querying /est/skc, the		Format TBD287 (application/pkix-cert) by querying /est/skc, the
	server would respond with a single DER binary certificate.		server would respond with a single DER binary certificate.
	These examples assume a short root resource path of "/est".		These examples assume a short resource path of "/est". Even though
			omitted from the examples for brevity, before making the EST-coaps
			requests, a client would learn about the server supported EST-coaps
			resources with a GET request for /.well-known/core?rt=ace.est* as
			explained in Section 5.1.
	The corresponding CoAP headers are only shown in Appendix A.1.		The corresponding CoAP headers are only shown in Appendix A.1.
	Creating CoAP headers is assumed to be generally understood.		Creating CoAP headers is assumed to be generally understood.
	The message content breakdown is presented in Appendix C.		The message content breakdown is presented in Appendix C.
	A.1. cacerts		A.1. cacerts
	In EST-coaps, a cacerts message can be:		In EST-coaps, a cacerts message can be:
	GET coaps://est-coaps.example.org:9085/est/crts		GET example.com:9085/est/crts
	(Accept: 281)		(Accept: 281)
	The corresponding CoAP header fields are shown below. The use of		The corresponding CoAP header fields are shown below. The use of
	block and DTLS are worked out in Appendix B.		block and DTLS are worked out in Appendix B.
	Ver = 1		Ver = 1
	T = 0 (CON)		T = 0 (CON)
	Code = 0x01 (0.01 is GET)		Code = 0x01 (0.01 is GET)
	Token = 0x9a (client generated)		Token = 0x9a (client generated)
	Options		Options
	Option (Uri-Host)		Option (Uri-Host)
	Option Delta = 0x3 (option# 3)		Option Delta = 0x3 (option# 3)
	Option Length = 0x9		Option Length = 0xD
	Option Value = est-coaps.example.org		Option Value = "example.com"
	Option (Uri-Port)		Option (Uri-Port)
	Option Delta = 0x4 (option# 3+4=7)		Option Delta = 0x4 (option# 3+4=7)
	Option Length = 0x4		Option Length = 0x4
	Option Value = 9085		Option Value = 9085
	Option (Uri-Path)		Option (Uri-Path)
	Option Delta = 0x4 (option# 7+4=11)		Option Delta = 0x4 (option# 7+4=11)
	Option Length = 0x5		Option Length = 0x5
	Option Value = "est"		Option Value = "est"
	Option (Uri-Path)		Option (Uri-Path)
	Option Delta = 0x0 (option# 11+0=11)		Option Delta = 0x0 (option# 11+0=11)
	skipping to change at page 33, line 5 ¶		skipping to change at page 33, line 8 ¶
	A.2. enroll / reenroll		A.2. enroll / reenroll
	During the (re-)enroll exchange the EST-coaps client uses a CSR		During the (re-)enroll exchange the EST-coaps client uses a CSR
	(Content-Format 286) request in the POST request payload. The Accept		(Content-Format 286) request in the POST request payload. The Accept
	option tells the server that the client is expecting Content-Format		option tells the server that the client is expecting Content-Format
	281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR		281 (PKCS#7) in the response. As shown in Appendix C.2, the CSR
	contains a ChallengePassword which is used for POP linking		contains a ChallengePassword which is used for POP linking
	(Section 4).		(Section 4).
	POST [2001:db8::2:1]:61616/est/sen		POST [2001:db8::2:321]:61616/est/sen
	(Token: 0x45)		(Token: 0x45)
	(Accept: 281)		(Accept: 281)
	(Content-Format: 286)		(Content-Format: 286)
	[ The hexadecimal representation below would NOT be transported		[ The hexadecimal representation below would NOT be transported
	in hex, but in binary. Hex is used because a binary representation		in hex, but in binary. Hex is used because a binary representation
	cannot be rendered well in text. ]		cannot be rendered well in text. ]
	3082018b30820131020100305c310b3009060355040613025553310b3009		3082018b30820131020100305c310b3009060355040613025553310b3009
	06035504080c024341310b300906035504070c024c413114301206035504		06035504080c024341310b300906035504070c024c413114301206035504
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 4 ¶
	05070804a013301106092b06010401b43b0a01040401020304300a06082a		05070804a013301106092b06010401b43b0a01040401020304300a06082a
	8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94		8648ce3d0403020349003046022100c0d81996d2507d693f3c48eaa5ee94
	91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d		91bda6db214099d98117c63b361374cd86022100a774989f4c321a5cf25d
	832a4d336a08ad67df20f1506421188a0ade6d349236a1003100		832a4d336a08ad67df20f1506421188a0ade6d349236a1003100
	The breakdown of the request and response is shown in Appendix C.2.		The breakdown of the request and response is shown in Appendix C.2.
	A.3. serverkeygen		A.3. serverkeygen
	In a serverkeygen exchange the CoAP POST request looks like		In a serverkeygen exchange the CoAP POST request looks like
	POST coaps://192.0.2.1:8085/est/skg		POST 192.0.2.1:8085/est/skg
	(Token: 0xa5)		(Token: 0xa5)
	(Accept: 62)		(Accept: 62)
	(Content-Format: 286)		(Content-Format: 286)
	[ The hexadecimal representation below would NOT be transported		[ The hexadecimal representation below would NOT be transported
	in hex, but in binary. Hex is used because a binary representation		in hex, but in binary. Hex is used because a binary representation
	cannot be rendered well in text. ]		cannot be rendered well in text. ]
	3081cf3078020100301631143012060355040a0c0b736b67206578616d70		3081cf3078020100301631143012060355040a0c0b736b67206578616d70
	6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b		6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b
	skipping to change at page 37, line 5 ¶		skipping to change at page 37, line 5 ¶
	The private key in the response above is without CMS EnvelopedData		The private key in the response above is without CMS EnvelopedData
	and has no additional encryption beyond DTLS (Section 5.8).		and has no additional encryption beyond DTLS (Section 5.8).
	The breakdown of the request and response is shown in Appendix C.3		The breakdown of the request and response is shown in Appendix C.3
	A.4. csrattrs		A.4. csrattrs
	Below is a csrattrs exchange		Below is a csrattrs exchange
	REQ:		REQ:
	GET coaps://[2001:db8::2:1]:61616/est/att		GET example.com:61616/est/att
	RES:		RES:
	2.05 Content		2.05 Content
	(Content-Format: 285)		(Content-Format: 285)
	[ The hexadecimal representation below would NOT be transported		[ The hexadecimal representation below would NOT be transported
	in hex, but in binary. Hex is used because a binary representation		in hex, but in binary. Hex is used because a binary representation
	cannot be rendered well in text. ]		cannot be rendered well in text. ]
	307c06072b06010101011630220603883701311b131950617273652053455		307c06072b06010101011630220603883701311b131950617273652053455
	skipping to change at page 38, line 25 ¶		skipping to change at page 38, line 25 ¶
	option:NUM/M/size) indicating the kind of Block Option (2 in this		option:NUM/M/size) indicating the kind of Block Option (2 in this
	case) followed by a colon, and then the block number (NUM), the more		case) followed by a colon, and then the block number (NUM), the more
	bit (M = 0 in Block2 response means it is last block), and block size		bit (M = 0 in Block2 response means it is last block), and block size
	with exponent (2**(SZX+4)) separated by slashes. The Length 64 is		with exponent (2**(SZX+4)) separated by slashes. The Length 64 is
	used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent		used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent
	confirmable (CON) and the Content-Format of the response, even though		confirmable (CON) and the Content-Format of the response, even though
	not shown, is 281 (application/pkcs7-mime; smime-type=certs-only).		not shown, is 281 (application/pkcs7-mime; smime-type=certs-only).
	The transfer of the 10 blocks with partially filled block NUM=9 is		The transfer of the 10 blocks with partially filled block NUM=9 is
	shown below		shown below
	GET coaps://est-coaps.example.org:9085/est/crts (2:0/0/64) -->		GET example.com:9085/est/crts (2:0/0/64) -->
	<-- (2:0/1/64) 2.05 Content		<-- (2:0/1/64) 2.05 Content
	GET coaps://est-coaps.example.org:9085/est/crts (2:1/0/64) -->		GET example.com:9085/est/crts (2:1/0/64) -->
	<-- (2:1/1/64) 2.05 Content		<-- (2:1/1/64) 2.05 Content
	|		|
	|		|
	|		|
	GET coaps://est-coaps.example.org:9085/est/crts (2:9/0/64) -->		GET example.com:9085/est/crts (2:9/0/64) -->
	<-- (2:9/0/64) 2.05 Content		<-- (2:9/0/64) 2.05 Content
	The header of the GET request looks like		The header of the GET request looks like
	Ver = 1		Ver = 1
	T = 0 (CON)		T = 0 (CON)
	Code = 0x01 (0.1 GET)		Code = 0x01 (0.1 GET)
	Token = 0x9a (client generated)		Token = 0x9a (client generated)
	Options		Options
	Option (Uri-Host)		Option (Uri-Host)
	Option Delta = 0x3 (option# 3)		Option Delta = 0x3 (option# 3)
	Option Length = 0x9		Option Length = 0xD
	Option Value = est-coaps.example.org		Option Value = "example.com"
	Option (Uri-Port)		Option (Uri-Port)
	Option Delta = 0x4 (option# 3+4=7)		Option Delta = 0x4 (option# 3+4=7)
	Option Length = 0x4		Option Length = 0x4
	Option Value = 9085		Option Value = 9085
	Option (Uri-Path)		Option (Uri-Path)
	Option Delta = 0x4 (option# 7+4=11)		Option Delta = 0x4 (option# 7+4=11)
	Option Length = 0x5		Option Length = 0x5
	Option Value = "est"		Option Value = "est"
	Option (Uri-Path)Uri-Path)		Option (Uri-Path)Uri-Path)
	Option Delta = 0x0 (option# 11+0=11)		Option Delta = 0x0 (option# 11+0=11)
	skipping to change at page 41, line 17 ¶		skipping to change at page 41, line 17 ¶
	T = 2 (means ACK)		T = 2 (means ACK)
	Code = 0x45 (2.05 Content)		Code = 0x45 (2.05 Content)
	Token = 0x9a (copied from request by server)		Token = 0x9a (copied from request by server)
	Options		Options
	Option		Option
	Option Delta = 0xC (option# 12 Content-Format)		Option Delta = 0xC (option# 12 Content-Format)
	Option Length = 0x2		Option Length = 0x2
	Option Value = 281		Option Value = 281
	Option		Option
	Option Delta = 0xB (option# 12+11=23 Block2 )		Option Delta = 0xB (option# 12+11=23 Block2 )
	Option Length = 0x2		Option Length = 0x1
	Option Value = 0x92 (block#=9, M=0, SZX=2)		Option Value = 0x92 (block#=9, M=0, SZX=2)
	[ The hexadecimal representation below would NOT be transported		[ The hexadecimal representation below would NOT be transported
	in hex, but in binary. Hex is used because a binary representation		in hex, but in binary. Hex is used because a binary representation
	cannot be rendered well in text. ]		cannot be rendered well in text. ]
	Payload =		Payload =
	2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a		2ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f1353272f022047a28a
	e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1		e5c7306163b3c3834bab3c103f743070594c089aaa0ac870cd13b902caa1
	003100		003100
	B.2. enroll / reenroll		B.2. enroll / reenroll
	In this example, the requested Block2 size of 256 bytes, required by		In this example, the requested Block2 size of 256 bytes, required by
	the client, is transferred to the server in the very first request		the client, is transferred to the server in the very first request
	message. The block size 256=(2**(SZX+4)) which gives SZX=4. The		message. The block size 256=(2**(SZX+4)) which gives SZX=4. The
	notation for block numbering is the same as in Appendix B.1. The		notation for block numbering is the same as in Appendix B.1. The
	header fields and the payload are omitted for brevity.		header fields and the payload are omitted for brevity.
	POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} -->		POST [2001:db8::2:321]:61616/est/sen (CON)(1:0/1/256) {CSR req} -->
	<-- (ACK) (1:0/1/256) (2.31 Continue)		<-- (ACK) (1:0/1/256) (2.31 Continue)
	POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} -->		POST [2001:db8::2:321]:61616/est/sen (CON)(1:1/1/256) {CSR req} -->
	<-- (ACK) (1:1/1/256) (2.31 Continue)		<-- (ACK) (1:1/1/256) (2.31 Continue)
	.		.
	.		.
	.		.
	POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} -->		POST [2001:db8::2:321]:61616/est/sen (CON)(1:N1/0/256){CSR req} -->
	<-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp}		<-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp}
	POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->		POST [2001:db8::2:321]:61616/est/sen (CON)(2:1/0/256) -->
	<-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp}		<-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp}
	.		.
	.		.
	.		.
	POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->		POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) -->
	<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp}		<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp}
	Figure 5: EST-COAP enrollment with multiple blocks		Figure 5: EST-COAP enrollment with multiple blocks
	N1+1 blocks have been transferred from client to the server and N2+1		N1+1 blocks have been transferred from client to the server and N2+1
	blocks have been transferred from server to client.		blocks have been transferred from server to client.
	Appendix C. Message content breakdown		Appendix C. Message content breakdown
	This appendix presents the breakdown of the hexadecimal dumps of the		This appendix presents the breakdown of the hexadecimal dumps of the
End of changes. 45 change blocks.
	75 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/