draft-ietf-ace-coap-est-11.txt   draft-ietf-ace-coap-est-12.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: November 18, 2019 Cisco Systems Expires: December 7, 2019 Cisco Systems
M. Richardson M. Richardson
SSW SSW
S. Raza S. Raza
RISE SICS RISE SICS
May 17, 2019 June 5, 2019
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-11 draft-ietf-ace-coap-est-12
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 November 18, 2019. This Internet-Draft will expire on December 7, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. DTLS and conformance to RFC7925 profiles . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10
5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 12 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13
5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 13 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14
5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 14 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15
5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15
5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16
5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18
6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 19 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 20
7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Deployment limitations . . . . . . . . . . . . . . . . . . . 21 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 22 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 23
9.2. Resource Type registry . . . . . . . . . . . . . . . . . 22 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10.1. EST server considerations . . . . . . . . . . . . . . . 23 10.1. EST server considerations . . . . . . . . . . . . . . . 24
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 25 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 26
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 30 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 31
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 32 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 33
A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 34 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 35
A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 36 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix B. EST-coaps Block message examples . . . . . . . . . . 37 Appendix B. EST-coaps Block message examples . . . . . . . . . . 38
B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 37 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 41 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 42
Appendix C. Message content breakdown . . . . . . . . . . . . . 42 Appendix C. Message content breakdown . . . . . . . . . . . . . 43
C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 44 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45
C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 45 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Change Log 1. Change Log
EDNOTE: Remove this section before publication EDNOTE: Remove this section before publication
-12
Updated section 5 based on Esko's comments and nits identified.
Nits and some clarifications for Esko's new review from 5/21/2019.
Nits and some clarifications for Esko's new review from 5/28/2019.
-11 -11
Updated Server-side keygen to simplify motivation and added Updated Server-side keygen to simplify motivation and added
paragraphs in Security considerations to point out that random paragraphs in Security considerations to point out that random
numbers are still needed (feedback from Hannes). numbers are still needed (feedback from Hannes).
-10 -10
Addressed WGLC comments Addressed WGLC comments
skipping to change at page 8, line 29 skipping to change at page 8, line 39
[ieee802.1ar] or a certificate issued by some other party); the [ieee802.1ar] or a certificate issued by some other party); the
server is expected to trust that certificate. IDevID's are server is expected to trust that certificate. IDevID's are
expected to have a very long life, as long as the device, but expected to have a very long life, as long as the device, but
under some conditions could expire. In that case, the server MAY under some conditions could expire. In that case, the server MAY
want to authenticate a client certificate against its trust store want to authenticate a client certificate against its trust store
although the certificate is expired (Section 10). although the certificate is expired (Section 10).
EST-coaps supports the certificate types and Trust Anchors (TA) that EST-coaps supports the certificate types and Trust Anchors (TA) that
are specified for EST in Section 3 of [RFC7030]. are specified for EST in Section 3 of [RFC7030].
CoAP and DTLS can provide proof-of-identity for EST-coaps clients and As described in Section 2.1 of [RFC5272] proof-of-identity refers to
servers with simple PKI messages as described in Section 3.1 of a value that can be used to prove that the private key corresponding
[RFC5272]. Moreover, channel-binding information for linking proof- to the public key is in the possession of and can be used by an end-
of-identity with connection-based proof-of-possession is OPTIONAL for entity or client. Additionally, channel-binding information can link
EST-coaps. When proof-of-possession is desired, a set of actions are proof-of-identity with an established connetion. Connection-based
required regarding the use of tls-unique, described in Section 3.5 in proof-of-possession is OPTIONAL for EST-coaps clients and servers.
When proof-of-possession is desired, a set of actions are required
regarding the use of tls-unique, described in Section 3.5 in
[RFC7030]. The tls-unique information consists of the contents of [RFC7030]. The tls-unique information consists of the contents of
the first "Finished" message in the (D)TLS handshake between server the first "Finished" message in the (D)TLS handshake between server
and client [RFC5929]. The client adds the "Finished" message as a and client [RFC5929]. The client adds the "Finished" message as a
ChallengePassword in the attributes section of the PKCS#10 Request ChallengePassword in the attributes section of the PKCS#10 Request
[RFC5967] to prove that the client is indeed in control of the [RFC5967] to prove that the client is indeed in control of the
private key at the time of the (D)TLS session establishment. private key at the time of the (D)TLS session establishment.
In the case of EST-coaps, the same operations can be performed during In the case of EST-coaps, the same operations can be performed during
the DTLS handshake. For DTLS 1.2, in the event of handshake message the DTLS handshake. For DTLS 1.2, in the event of handshake message
fragmentation, the Hash of the handshake messages used in the MAC fragmentation, the Hash of the handshake messages used in the MAC
calculation of the Finished message must be computed as if each calculation of the Finished message must be computed as if each
handshake message had been sent as a single fragment (Section 4.2.6 handshake message had been sent as a single fragment (Section 4.2.6
of [RFC6347]). The Finished message is calculated as shown in of [RFC6347]). The Finished message is calculated as shown in
Section 7.4.9 of [RFC5246]. Similarly, for DTLS 1.3, the Finished Section 7.4.9 of [RFC5246]. Similarly, for DTLS 1.3, the Finished
skipping to change at page 10, line 43 skipping to change at page 11, line 8
| /csrattrs | /att | | /csrattrs | /att |
| /serverkeygen | /skg (PKCS#7) | | /serverkeygen | /skg (PKCS#7) |
| /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, she will make an /skc request.
Clients and servers MUST support the short resource EST-coaps 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- EST resources 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]. The example below shows the discovery over
the root resource of the EST resources. The example below shows the CoAPS of the presence and location of EST-coaps resources. Linefeeds
discovery of the presence and location of EST-coaps resources. 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*
RES: 2.05 Content RES: 2.05 Content
</est/crts>;rt="ace.est.crts";ct="281 TBD287", </est/crts>;rt="ace.est.crts";ct="281 TBD287",
</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. These are the values request one that is supported by the server. These are the values
that would be sent in the client request with an Accept option. 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 are 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",
<coaps://[2001:db8:3::123]:61617/est/sen>;rt="ace.est.sen"; <coaps://[2001:db8:3::123]:61617/est/sen>;rt="ace.est.sen";
ct="281 TBD287", ct="281 TBD287",
<coaps://[2001:db8:3::123]:61617/est/sren>;rt="ace.est.sren"; <coaps://[2001:db8:3::123]:61617/est/sren>;rt="ace.est.sren";
ct="281 TBD287", ct="281 TBD287",
<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 he is unaware of the available SHOULD use resource discovery when she is unaware of the available
EST-coaps resources. EST-coaps resources.
It is up to the implementation to choose its resource paths; Throughout this document the example root resource of /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
implementation of the EST-coaps functions. Discovery of the implementation of the EST-coaps functions. Discovery of the
skipping to change at page 14, line 9 skipping to change at page 14, line 33
The general EST-coaps message characteristics are: The general EST-coaps message characteristics are:
o EST-coaps servers sometimes need to provide delayed responses o EST-coaps servers sometimes need to provide delayed responses
which are conveyed with an empty ACK or an ACK containing response which are conveyed with an empty ACK or an ACK containing response
code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED
for implementers to send EST-coaps requests in confirmable CON for implementers to send EST-coaps requests in confirmable CON
CoAP messages. 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, Block1, Block2, and Accept. These CoAP Options are used
used to communicate the HTTP fields specified in the EST REST to communicate the HTTP fields specified in the EST REST messages.
messages. The Uri-host and Uri-Port Options can be omitted from The Uri-host and Uri-Port Options can be omitted from the COAP
the COAP message sent on the wire. When omitted, they are message sent on the wire. When omitted, they are logically
logically assumed to be the transport protocol destination address assumed to be the transport protocol destination address and port
and port respectively. Explicit Uri-Host and Uri-Port Options are 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://)
Table 1 provides the mapping from the EST URI path to the EST-coaps Table 1 provides the mapping from the EST URI path to the EST-coaps
URI path. Appendix A includes some practical examples of EST URI path. Appendix A includes some practical examples of EST
messages translated to CoAP. messages translated to CoAP.
5.5. CoAP response codes 5.5. CoAP response codes
Section 5.9 of [RFC7252] and Section 7 of [RFC8075] specify the Section 5.9 of [RFC7252] and Section 7 of [RFC8075] specify the
mapping of HTTP response codes to CoAP response codes. Every time mapping of HTTP response codes to CoAP response codes. The success
the HTTP response code 200 is specified in [RFC7030] in response to a code in response to an EST-coaps GET request (/crts, /att), is 2.05.
GET request (/cacerts, /csrattrs), the equivalent CoAP response code Similarly, 2.04 is used in successfull response to EST-coaps POST
2.05 or 2.03 MUST be used in EST-coaps. Similarly, 2.01, 2.02 or requests (/sen, /sren, /skg, /skc).
2.04 MUST be used in response to EST POST requests (/simpleenroll,
/simplereenroll, /serverkeygen). EST makes use of HTTP 204 or 404 responses when a resource is not
available for the client. In EST-coaps 2.04 is used in response to a
POST (/sen, /sren, /skg, /skc). 4.04 is used when the resource is not
available for the client.
HTTP response code 202 with a Retry-After header in [RFC7030] has no HTTP response code 202 with a Retry-After header in [RFC7030] has no
equivalent in CoAP. Retry-After is used in EST for delayed server equivalent in CoAP. HTTP 202 with Retry-After is used in EST for
responses. Section 5.7 specifies how EST-coaps handles delayed delayed server responses. Section 5.7 specifies how EST-coaps
messages. handles delayed messages with 5.03 responses with a Max-Age Option.
EST makes use of HTTP 204 and 404 responses when a resource is not Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes have
available for the client. The equivalent CoAP codes to use in an their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes
EST-coaps responses are 2.04 and 4.04. Additionally, EST's HTTP 401 in EST-coaps. Table 3 summarizes the EST-coaps response codes.
error translates to 4.01 in EST-coaps. Other EST HTTP error messages
are 400, 423 and 503. Their equivalent CoAP errors are 4.00, 4.03 +-----------------+-----------------+-------------------------------+
and 5.03 respectively. In case a CoAP Option is unrecognized and | operation | EST-coaps | Description |
critical, the server is expected to return a 4.02 (Bad Option). | | response code | |
+-----------------+-----------------+-------------------------------+
| /crts, /att | 2.05 | Success. Certs included in |
| | | the response payload. |
| | 4.xx / 5.xx | Failure. |
| /sen, /skg, | 2.04 | Success. Cert included in the |
| /sren, /skc | | response payload. |
| | 5.03 | Retry in Max-Age Option time. |
| | 4.xx / 5.xx | Failure. |
+-----------------+-----------------+-------------------------------+
Table 3: EST-coaps response codes
5.6. Message fragmentation 5.6. Message fragmentation
DTLS defines fragmentation only for the handshake and not for secure DTLS defines fragmentation only for the handshake and not for secure
data exchange (DTLS records). [RFC6347] states that to avoid using data exchange (DTLS records). [RFC6347] states that to avoid using
IP fragmentation, which involves error-prone datagram reconstitution, IP fragmentation, which involves error-prone datagram reconstitution,
invokers of the DTLS record layer should size DTLS records so that invokers of the DTLS record layer should size DTLS records so that
they fit within any Path MTU estimates obtained from the record they fit within any Path MTU estimates obtained from the record
layer. In addition, invokers residing on a 6LoWPAN over IEEE layer. In addition, invokers residing on a 6LoWPAN over IEEE
802.15.4 [ieee802.15.4] network should attempt to size CoAP messages 802.15.4 [ieee802.15.4] network should attempt to size CoAP messages
skipping to change at page 15, line 41 skipping to change at page 16, line 29
conservative IPv4 datagram sizes such as 576 bytes. Even with ECC, conservative IPv4 datagram sizes such as 576 bytes. Even with ECC,
EST-coaps messages can still exceed MTU sizes on the Internet or EST-coaps messages can still exceed MTU sizes on the Internet or
6LoWPAN [RFC4919] (Section 2 of [RFC7959]). EST-coaps needs to be 6LoWPAN [RFC4919] (Section 2 of [RFC7959]). EST-coaps needs to be
able to fragment messages into multiple DTLS datagrams. able to fragment messages into multiple DTLS datagrams.
To perform fragmentation in CoAP, [RFC7959] specifies the Block1 To perform fragmentation in CoAP, [RFC7959] specifies the Block1
Option for fragmentation of the request payload and the Block2 Option Option for fragmentation of the request payload and the Block2 Option
for fragmentation of the return payload of a CoAP flow. As explained for fragmentation of the return payload of a CoAP flow. As explained
in Section 1 of [RFC7959], block-wise transfers should be used in in Section 1 of [RFC7959], block-wise transfers should be used in
Confirmable CoAP messages to avoid the exacerbation of lost blocks. Confirmable CoAP messages to avoid the exacerbation of lost blocks.
The EST-coaps client and server MUST support Block2. Block1 MUST be Both EST-coaps clients and servers MUST support Block2. EST-coaps
supported for EST-coaps enrollment requests that exceed the Path MTU. servers MUST also support Block1. The EST-coaps client MUST support
Block1 only if it sends EST-coaps requests with an IP packet size
that exceeds the Path MTU.
[RFC7959] also defines Size1 and Size2 Options to provide size [RFC7959] also defines Size1 and Size2 Options to provide size
information about the resource representation in a request and information about the resource representation in a request and
response. EST-client and server MAY support Size1 and Size2 Options. response. EST-client and server MAY support Size1 and Size2 Options.
Examples of fragmented EST-coaps messages are shown in Appendix B. Examples of fragmented EST-coaps messages are shown in Appendix B.
5.7. Delayed Responses 5.7. Delayed Responses
Server responses can sometimes be delayed. According to Server responses can sometimes be delayed. According to
skipping to change at page 16, line 26 skipping to change at page 17, line 12
This situation is shown in Figure 2. The client sends an enrollment This situation is shown in Figure 2. The client sends an enrollment
request that uses N1+1 Block1 blocks. The server uses an empty 0.00 request that uses N1+1 Block1 blocks. The server uses an empty 0.00
ACK to announce the delayed response which is provided later with ACK to announce the delayed response which is provided later with
2.04 messages containing N2+1 Block2 Options. The first 2.04 is a 2.04 messages containing N2+1 Block2 Options. The first 2.04 is a
confirmable message that is acknowledged by the client. Onwards, confirmable message that is acknowledged by the client. Onwards,
having received the first 256 bytes in the first Block2 block, the having received the first 256 bytes in the first Block2 block, the
client asks for a block reduction to 128 bytes in a confirmable client asks for a block reduction to 128 bytes in a confirmable
enrollment request and acknowledges the Block2 blocks sent up to that enrollment request and acknowledges the Block2 blocks sent up to that
point. point.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
<-- (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:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (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:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
<-- (0.00 empty ACK) <-- (0.00 empty ACK)
| |
...... short delay before certificate is ready ...... ... Short delay before the certificate is ready ...
| |
<-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp} <-- (CON) (1:N1/0/256)(2:0/1/256)(2.04 Changed) {Cert resp (frag# 1)}
(ACK) --> (ACK) -->
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp} <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->
<-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp} <-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)}
Figure 2: EST-COAP enrollment with short wait Figure 2: EST-COAP enrollment with short wait
If the server is very slow (i.e. minutes) in providing the response If the server is very slow (i.e. minutes) in providing the response
(i.e. when a manual intervention is needed), he SHOULD respond with (i.e. when a manual intervention is needed), he SHOULD respond with
an ACK containing response code 5.03 (Service unavailable) and a Max- an ACK containing response code 5.03 (Service unavailable) and a Max-
Age Option to indicate the time the client SHOULD wait to request the Age Option to indicate the time the client SHOULD wait to request the
content later. After a delay of Max-Age, the client SHOULD resend content later. After a delay of Max-Age, the client SHOULD resend
the identical CSR to the server. As long as the server responds with the identical CSR to the server. As long as the server responds with
response code 5.03 (Service Unavailable) with a Max-Age Option, the response code 5.03 (Service Unavailable) with a Max-Age Option, the
skipping to change at page 17, line 17 skipping to change at page 18, line 4
the identical CSR to the server. As long as the server responds with the identical CSR to the server. As long as the server responds with
response code 5.03 (Service Unavailable) with a Max-Age Option, the response code 5.03 (Service Unavailable) with a Max-Age Option, the
client SHOULD keep resending the enrollment request until the server client SHOULD keep resending the enrollment request until the server
responds with the certificate or the client abandons for other responds with the certificate or the client abandons for other
reasons. reasons.
To demonstrate this scenario, Figure 3 shows a client sending an To demonstrate this scenario, Figure 3 shows a client sending an
enrollment request that uses N1+1 Block1 blocks to send the CSR to enrollment request that uses N1+1 Block1 blocks to send the CSR to
the server. The server needs N2+1 Block2 blocks to respond, but also the server. The server needs N2+1 Block2 blocks to respond, but also
needs to take a long delay (minutes) to provide the response. needs to take a long delay (minutes) to provide the response.
Consequently, the server uses a 5.03 ACK response with a Max-Age Consequently, the server uses a 5.03 ACK response with a Max-Age
Option. The client waits for a period of Max-Age as many times as he Option. The client waits for a period of Max-Age as many times as
receives the same 5.03 response and retransmits the enrollment she receives the same 5.03 response and retransmits the enrollment
request until he receives a certificate in a fragmented 2.01 request until she receives a certificate in a fragmented 2.04
response. Note that the server asks for a decrease in the block size response. Note that the server asks for a decrease in the block size
when acknowledging the first Block2. when acknowledging the first Block2.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} -->
<-- (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:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (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} --> .
<-- (ACK) (1:N1/0/256) (2:0/0/128)(5.03 Service Unavailable) POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
(Max-Age) <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age)
| |
| |
Client tries one or more times after Max-Age with identical payload ... Client tries again after Max-Age with identical payload ...
| |
| |
POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} --> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}-->
<-- (ACK) (1:N1/0/256) (2:0/1/128) (2.01 Created){Cert resp} <-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
<-- (ACK) (2:1/1/128) (2.01 Created) {Cert resp} <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
. .
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) --> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
<-- (ACK) (2:N2/0/128) (2.01 Created) {Cert resp} <-- (ACK) (1:N1/0/256) (2:0/1/128) (2.04 Changed){Cert resp (frag# 1)}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) -->
<-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)}
.
.
.
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/128) -->
<-- (ACK) (2:N2/0/128) (2.04 Changed) {Cert resp (frag# N2+1)}
Figure 3: EST-COAP enrollment with long wait Figure 3: EST-COAP enrollment with long wait
5.8. Server-side Key Generation 5.8. Server-side Key Generation
In scenarios where it is desirable that the server generates the In scenarios where it is desirable that the server generates the
private key, server-side key generation should be used. Such private key, server-side key generation should be used. Such
scenarios could be when it is considered more secure to generate at scenarios could be when it is considered more secure to generate at
the server the long-lived random private key that identifies the the server the long-lived random private key that identifies the
client, or when the resources spent to generate a random private key client, or when the resources spent to generate a random private key
skipping to change at page 21, line 5 skipping to change at page 21, line 47
MUST take place at the Registrar when server-side key generation is MUST take place at the Registrar when server-side key generation is
supported. If CMS end-to-end encryption is employed for the private supported. If CMS end-to-end encryption is employed for the private
key, the encrypted CMS EnvelopedData blob MUST be converted to binary key, the encrypted CMS EnvelopedData blob MUST be converted to binary
in CBOR type 2 downstream to the client. in CBOR type 2 downstream to the client.
Due to fragmentation of large messages into blocks, an EST-coaps-to- Due to fragmentation of large messages into blocks, an EST-coaps-to-
HTTP Registrar MUST reassemble the BLOCKs before translating the HTTP Registrar MUST reassemble the BLOCKs before translating the
binary content to Base64, and consecutively relay the message binary content to Base64, and consecutively relay the message
upstream. upstream.
If necessary, the EST-coaps-to-HTTP Registrar will support resouce The EST-coaps-to-HTTP Registrar MUST support resource discovery
discovery according to the rules in Section 5.1. according to the rules in Section 5.1. 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
skipping to change at page 22, line 12 skipping to change at page 23, line 10
ensure that EST works for networks of constrained devices that choose ensure that EST works for networks of constrained devices that choose
to limit their communications stack to DTLS/CoAP. It is up to the to limit their communications stack to DTLS/CoAP. It is up to the
network designer to decide which devices execute the EST protocol and network designer to decide which devices execute the EST protocol and
which do not. which do not.
9. IANA Considerations 9. IANA Considerations
9.1. Content-Format Registry 9.1. Content-Format Registry
Additions to the sub-registry "CoAP Content-Formats", within the Additions to the sub-registry "CoAP Content-Formats", within the
"CoRE Parameters" registry [COREparams] are specified in Table 3. "CoRE Parameters" registry [COREparams] are specified in Table 4.
These have been registered provisionally in the Expert Review range These have been registered provisionally in the IETF Review or IESG
(0-255). Approval range (256-9999).
+------------------------------+-------+----------------------------+ +------------------------------+-------+----------------------------+
| HTTP Media-Type | ID | Reference | | HTTP Media-Type | ID | Reference |
+------------------------------+-------+----------------------------+ +------------------------------+-------+----------------------------+
| application/pkcs7-mime; | 280 | [RFC7030] [I-D.ietf-lamps- | | application/pkcs7-mime; | 280 | [RFC7030] [I-D.ietf-lamps- |
| smime-type=server-generated- | | rfc5751-bis] | | smime-type=server-generated- | | rfc5751-bis] |
| key | | | | key | | |
| application/pkcs7-mime; | 281 | [I-D.ietf-lamps-rfc5751-bi | | application/pkcs7-mime; | 281 | [I-D.ietf-lamps-rfc5751-bi |
| smime-type=certs-only | | s] | | smime-type=certs-only | | s] |
| application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- | | application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- |
| | | rfc5751-bis] | | | | rfc5751-bis] |
| application/csrattrs | 285 | [RFC7030] [RFC7231] | | application/csrattrs | 285 | [RFC7030] [RFC7231] |
| application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- | | application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- |
| | | rfc5751-bis] | | | | rfc5751-bis] |
| application/pkix-cert | TBD28 | [RFC2585] | | application/pkix-cert | TBD28 | [RFC2585] |
| | 7 | | | | 7 | |
+------------------------------+-------+----------------------------+ +------------------------------+-------+----------------------------+
Table 3: New CoAP Content-Formats Table 4: New CoAP Content-Formats
It is suggested that 287 is allocated to TBD287. It is suggested that 287 is allocated to TBD287.
9.2. Resource Type registry 9.2. Resource Type registry
This memo registers new Resource Type (rt=) Link Target Attributes in This memo registers new Resource Type (rt=) Link Target Attributes in
the "Resource Type (rt=) Link Target Attribute Values" subregistry the "Resource Type (rt=) Link Target Attribute Values" subregistry
under the "Constrained RESTful Environments (CoRE) Parameters" under the "Constrained RESTful Environments (CoRE) Parameters"
registry. registry.
skipping to change at page 25, line 4 skipping to change at page 25, line 49
an attacker could invalidate the purpose of the POP linking an attacker could invalidate the purpose of the POP linking
ChallengePassword in the client request by resuming an EST-coaps ChallengePassword in the client request by resuming an EST-coaps
connection. Even though the practical risk of such an attack to EST- connection. Even though the practical risk of such an attack to EST-
coaps is not devastating, we would rather use a more secure channel coaps is not devastating, we would rather use a more secure channel
binding mechanism. Such a mechanism could include an updated tls- binding mechanism. Such a mechanism could include an updated tls-
unique value generation like the tls-unique-prf defined in unique value generation like the tls-unique-prf defined in
[I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS [I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS
1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such 1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such
mechanism has not been standardized yet. Adopting a channel binding mechanism has not been standardized yet. Adopting a channel binding
value generated from an exporter would break backwards compatibility. value generated from an exporter would break backwards compatibility.
Thus, in this specification we still depend on the tls-unique
mechanism defined in [RFC5929], especially since a 3SHAKE attack does
not expose messages exchanged with EST-coaps.
Thus, in this specification we still depend in the tls-unique Regarding the Certificate Signing Request (CSR), an EST-coaps server
mechanism defined in [RFC5929], especially since the practicality of is expected to be able to recover from improper CSR requests.
such an attack would not expose any messages exchanged with EST-
coaps.
Regarding the Certificate Signing Request (CSR), a CA is expected to
be able to enforce policies to recover from improper CSR requests.
Interpreters of ASN.1 structures should be aware of the use of Interpreters of ASN.1 structures should be aware of the use of
invalid ASN.1 length fields and should take appropriate measures to invalid ASN.1 length fields and should take appropriate measures to
guard against buffer overflows, stack overruns in particular, and guard against buffer overflows, stack overruns in particular, and
malicious content in general. malicious content in general.
10.2. HTTPS-CoAPS Registrar considerations 10.2. HTTPS-CoAPS Registrar considerations
The Registrar proposed in Section 6 must be deployed with care, and The Registrar proposed in Section 6 must be deployed with care, and
only when the recommended connections are impossible. When POP only when the recommended connections are impossible. When POP
skipping to change at page 25, line 34 skipping to change at page 26, line 29
for POP linking to be enforced end-to-end for the EST transaction. for POP linking to be enforced end-to-end for the EST transaction.
The EST server could be configured to accept POP linking information The EST server could be configured to accept POP linking information
that does not match the current TLS session because the authenticated that does not match the current TLS session because the authenticated
EST Registrar client has verified this information when acting as an EST Registrar client has verified this information when acting as an
EST server. EST server.
The introduction of an EST-coaps-to-HTTP Registrar assumes the client The introduction of an EST-coaps-to-HTTP Registrar assumes the client
can trust the registrar using its implicit or explicit TA database. can trust the registrar using its implicit or explicit TA database.
It also assumes the Registrar has a trust relationship with the It also assumes the Registrar has a trust relationship with the
upstream EST server in order to act on behalf of the clients. When a upstream EST server in order to act on behalf of the clients. When a
client uses the Implicit TA database for certificate validation, he client uses the Implicit TA database for certificate validation, she
SHOULD confirm if the server is acting as an RA by the presence of SHOULD confirm if the server is acting as an RA by the presence of
the id-kp-cmcRA EKU [RFC6402] in the server certificate. the id-kp-cmcRA EKU [RFC6402] in the server certificate.
In a server-side key generation case, if no end-to-end encryption is In a server-side key generation case, if no end-to-end encryption is
used, the Registrar may be able see the private key as it acts as a used, the Registrar may be able see the private key as it acts as a
man-in-the-middle. Thus, the client puts its trust on the Registrar man-in-the-middle. Thus, the client puts its trust on the Registrar
not exposing the private key. not exposing the private key.
Clients that leverage server-side key generation without end-to-end Clients that leverage server-side key generation without end-to-end
encryption of the private key (Section 5.8) have no knowledge if the encryption of the private key (Section 5.8) have no knowledge if the
skipping to change at page 27, line 42 skipping to change at page 28, line 32
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017,
<https://www.rfc-editor.org/info/rfc8075>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
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
skipping to change at page 30, line 11 skipping to change at page 30, line 41
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
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>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017,
<https://www.rfc-editor.org/info/rfc8075>.
[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>.
[RSAfact] "Factoring RSA keys from certified smart cards: [RSAfact] "Factoring RSA keys from certified smart cards:
Coppersmith in the wild", Advances in Cryptology - Coppersmith in the wild", Advances in Cryptology -
ASIACRYPT 2013, August 2013. ASIACRYPT 2013, August 2013.
skipping to change at page 33, line 32 skipping to change at page 34, line 29
028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75 028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75
f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109 f602f9152618f816a2b23b5638e59fd9a073303406092a864886f70d0109
0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e 0731270c2576437630292a264a4b4a3bc3a2c280c2992f3e3c2e2c3d6b6e
7634332323403d204e787e60303b06092a864886f70d01090e312e302c30 7634332323403d204e787e60303b06092a864886f70d01090e312e302c30
2a0603551d1104233021a01f06082b06010505070804a013301106092b06 2a0603551d1104233021a01f06082b06010505070804a013301106092b06
010401b43b0a01040401020304300a06082a8648ce3d0403020348003045 010401b43b0a01040401020304300a06082a8648ce3d0403020348003045
02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab 02210092563a546463bd9ecff170d0fd1f2ef0d3d012160e5ee90cffedab
ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc ec9b9a38920220179f10a3436109051abad17590a09bc87c4dce5453a6fc
1135a1e84eed754377 1135a1e84eed754377
After verification of the CSR by the server, a 2.01 Content response After verification of the CSR by the server, a 2.04 Changed response
with the issued certificate will be returned to the client. with the issued certificate will be returned to the client.
2.01 Created 2.04 Changed
(Token: 0x45) (Token: 0x45)
(Content-Format: 281) (Content-Format: 281)
[ 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. ]
3082026e06092a864886f70d010702a082025f3082025b0201013100300b 3082026e06092a864886f70d010702a082025f3082025b0201013100300b
06092a864886f70d010701a08202413082023d308201e2a0030201020208 06092a864886f70d010701a08202413082023d308201e2a0030201020208
7e7661d7b54e4632300a06082a8648ce3d040302305d310b300906035504 7e7661d7b54e4632300a06082a8648ce3d040302305d310b300906035504
skipping to change at page 36, line 4 skipping to change at page 37, line 4
3081cf3078020100301631143012060355040a0c0b736b67206578616d70 3081cf3078020100301631143012060355040a0c0b736b67206578616d70
6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b 6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b
b8c1117896f98e4506c03d70efbe820d8e38ea97e9d65d52c8460c5852c5 b8c1117896f98e4506c03d70efbe820d8e38ea97e9d65d52c8460c5852c5
1dd89a61370a2843760fc859799d78cd33f3c1846e304f1717f8123f1a28 1dd89a61370a2843760fc859799d78cd33f3c1846e304f1717f8123f1a28
4cc99fa000300a06082a8648ce3d04030203470030440220387cd4e9cf62 4cc99fa000300a06082a8648ce3d04030203470030440220387cd4e9cf62
8d4af77f92ebed4890d9d141dca86cd2757dd14cbd59cdf6961802202f24 8d4af77f92ebed4890d9d141dca86cd2757dd14cbd59cdf6961802202f24
5e828c77754378b66660a4977f113cacdaa0cc7bad7d1474a7fd155d090d 5e828c77754378b66660a4977f113cacdaa0cc7bad7d1474a7fd155d090d
The response would follow [I-D.ietf-core-multipart-ct] and could look The response would follow [I-D.ietf-core-multipart-ct] and could look
like like
2.01 Content 2.04 Changed
(Token: 0xa5) (Token: 0xa5)
(Content-Format: 62) (Content-Format: 62)
[ The hexadecimal representations below would NOT be transported [ The hexadecimal representations 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. ]
84 # array(4) 84 # array(4)
19 011C # unsigned(284) 19 011C # unsigned(284)
58 8A # bytes(138) 58 8A # bytes(138)
 End of changes. 41 change blocks. 
143 lines changed or deleted 174 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/