draft-ietf-ace-coap-est-12.txt   draft-ietf-ace-coap-est-13.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: December 7, 2019 Cisco Systems Expires: March 13, 2020 Cisco Systems
M. Richardson M. Richardson
SSW SSW
S. Raza S. Raza
RISE SICS RISE SICS
June 5, 2019 September 10, 2019
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-12 draft-ietf-ace-coap-est-13
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 December 7, 2019. This Internet-Draft will expire on March 13, 2020.
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 23 skipping to change at page 2, line 23
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 5.1. Discovery and URIs . . . . . . . . . . . . . . . . . . . 10
5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12 5.2. Mandatory/optional EST Functions . . . . . . . . . . . . 12
5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13 5.3. Payload formats . . . . . . . . . . . . . . . . . . . . . 13
5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14 5.4. Message Bindings . . . . . . . . . . . . . . . . . . . . 14
5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15 5.5. CoAP response codes . . . . . . . . . . . . . . . . . . . 15
5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 15 5.6. Message fragmentation . . . . . . . . . . . . . . . . . . 16
5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 16 5.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 17
5.8. Server-side Key Generation . . . . . . . . . . . . . . . 18 5.8. Server-side Key Generation . . . . . . . . . . . . . . . 19
6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 20 6. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 21
7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Deployment limitations . . . . . . . . . . . . . . . . . . . 22 8. Deployment limitations . . . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 23 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 24
9.2. Resource Type registry . . . . . . . . . . . . . . . . . 23 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. EST server considerations . . . . . . . . . . . . . . . 24 10.1. EST server considerations . . . . . . . . . . . . . . . 25
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 26 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 31 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 32
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 33 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 34
A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 35 A.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 36
A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 37 A.4. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix B. EST-coaps Block message examples . . . . . . . . . . 38 Appendix B. EST-coaps Block message examples . . . . . . . . . . 39
B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 42 B.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 43
Appendix C. Message content breakdown . . . . . . . . . . . . . 43 Appendix C. Message content breakdown . . . . . . . . . . . . . 44
C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 43 C.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45 C.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 45
C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 46 C.3. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Change Log 1. Change Log
EDNOTE: Remove this section before publication EDNOTE: Remove this section before publication
-13
Updates based on AD's review and discussions
Examples redone without password
-12 -12
Updated section 5 based on Esko's comments and nits identified. 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/21/2019.
Nits and some clarifications for Esko's new review from 5/28/2019. Nits and some clarifications for Esko's new review from 5/28/2019.
-11 -11
skipping to change at page 7, line 18 skipping to change at page 7, line 20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Many of the concepts in this document are taken from [RFC7030]. Many of the concepts in this document are taken from [RFC7030].
Consequently, much text is directly traceable to [RFC7030]. Consequently, much text is directly traceable to [RFC7030].
4. DTLS and conformance to RFC7925 profiles 4. DTLS and conformance to RFC7925 profiles
This section describes how EST-coaps fits into the profiles of low- This section describes how EST-coaps conforms to the profiles of low-
resource devices described in [RFC7925]. EST-coaps can transport resource devices described in [RFC7925]. EST-coaps can transport
certificates and private keys. Certificates are responses to certificates and private keys. Certificates are responses to
(re-)enrollment requests or requests for a trusted certificate list. (re-)enrollment requests or requests a trusted certificate list.
Private keys can be transported as responses to a server-side key Private keys can be transported as responses to a server-side key
generation request as described in Section 4.4 of [RFC7030] and generation request as described in Section 4.4 of [RFC7030] and
discussed in Section 5.8 of this document. discussed in Section 5.8 of this document.
EST-coaps depends on a secure transport mechanism that secures the EST-coaps depends on a secure transport mechanism that secures the
exchanged CoAP messages. DTLS is one such secure protocol. No other exchanged CoAP messages. DTLS is one such secure protocol. No other
changes are necessary regarding the secure transport of EST messages. changes are necessary regarding the secure transport of EST messages.
+------------------------------------------------+ +------------------------------------------------+
| EST request/response messages | | EST request/response messages |
+------------------------------------------------+ +------------------------------------------------+
| CoAP for message transfer and signaling | | CoAP for message transfer and signaling |
+------------------------------------------------+ +------------------------------------------------+
| Secure Transport | | Secure Transport |
+------------------------------------------------+ +------------------------------------------------+
Figure 1: EST-coaps protocol layers Figure 1: EST-coaps protocol layers
As per sections 3.3 and 4.4 of [RFC7925], the mandatory cipher suite In accordance with sections 3.3 and 4.4 of [RFC7925], the mandatory
for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite for DTLS in EST-coaps is
[RFC7251]. Curve secp256r1 MUST be supported [RFC8422]; this curve TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. Curve secp256r1 MUST
is equivalent to the NIST P-256 curve. Additionally, crypto agility be supported [RFC8422]; this curve is equivalent to the NIST P-256
is important, and the recommendations in Section 4.4 of [RFC7925] and curve. Additionally, crypto agility is important, and the
any updates to it concerning Curve25519 and other curves also apply. recommendations in Section 4.4 of [RFC7925] and any updates to it
concerning Curve25519 and other curves also apply.
DTLS 1.2 implementations must use the Supported Elliptic Curves and DTLS 1.2 implementations must use the Supported Elliptic Curves and
Supported Point Formats Extensions in [RFC8422]. Uncompressed point Supported Point Formats Extensions in [RFC8422]. Uncompressed point
format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13] format must also be supported. DTLS 1.3 [I-D.ietf-tls-dtls13]
implementations differ from DTLS 1.2 because they do not support implementations differ from DTLS 1.2 because they do not support
point format negotiation in favor of a single point format for each point format negotiation in favor of a single point format for each
curve. Thus, support for DTLS 1.3 does not mandate point format curve. Thus, support for DTLS 1.3 does not mandate point format
extensions and negotiation. extensions and negotiation. In addition, DTLS 1.3 uses the
"supported_groups" extension in contrast to Supported Elliptic Curves
used by DTLS 1.2
CoAP was designed to avoid IP fragmentation. DTLS is used to secure CoAP was designed to avoid IP fragmentation. DTLS is used to secure
CoAP messages. However, fragmentation is still possible at the DTLS CoAP messages. However, fragmentation is still possible at the DTLS
layer during the DTLS handshake when using ECC ciphersuites. If layer during the DTLS handshake when using ECC ciphersuites. If
fragmentation is necessary, "DTLS provides a mechanism for fragmentation is necessary, "DTLS provides a mechanism for
fragmenting a handshake message over several records, each of which fragmenting a handshake message over several records, each of which
can be transmitted separately, thus avoiding IP fragmentation" can be transmitted separately, thus avoiding IP fragmentation"
[RFC6347]. [RFC6347].
The authentication of the EST-coaps server by the EST-coaps client is The authentication of the EST-coaps server by the EST-coaps client is
skipping to change at page 8, line 29 skipping to change at page 8, line 34
before updating its trust anchor (Explicit TA) [RFC7030]. before updating its trust anchor (Explicit TA) [RFC7030].
The authentication of the EST-coaps client MUST be with a client The authentication of the EST-coaps client MUST be with a client
certificate in the DTLS handshake. This can either be certificate in the DTLS handshake. This can either be
o a previously issued client certificate (e.g., an existing o a previously issued client certificate (e.g., an existing
certificate issued by the EST CA); this could be a common case for certificate issued by the EST CA); this could be a common case for
simple re-enrollment of clients. simple re-enrollment of clients.
o a previously installed certificate (e.g., manufacturer IDevID o a previously installed certificate (e.g., manufacturer IDevID
[ieee802.1ar] or a certificate issued by some other party); the [ieee802.1ar] or a certificate issued by some other party).
server is expected to trust that certificate. IDevID's are IDevID's are expected to have a very long life, as long as the
expected to have a very long life, as long as the device, but device, but under some conditions could expire. In that case, the
under some conditions could expire. In that case, the server MAY server MAY want to authenticate a client certificate against its
want to authenticate a client certificate against its trust store 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].
As described in Section 2.1 of [RFC5272] proof-of-identity refers to As described in Section 2.1 of [RFC5272] proof-of-identity refers to
a value that can be used to prove that the private key corresponding a value that can be used to prove that the private key corresponding
to the public key is in the possession of and can be used by an end- to the certified public key is in the possession of and can be used
entity or client. Additionally, channel-binding information can link by an end-entity or client. Additionally, channel-binding
proof-of-identity with an established connetion. Connection-based information can link proof-of-identity with an established connetion.
proof-of-possession is OPTIONAL for EST-coaps clients and servers. Connection-based proof-of-possession is OPTIONAL for EST-coaps
When proof-of-possession is desired, a set of actions are required clients and servers. When proof-of-possession is desired, a set of
regarding the use of tls-unique, described in Section 3.5 in actions are required regarding the use of tls-unique, described in
[RFC7030]. The tls-unique information consists of the contents of Section 3.5 in [RFC7030]. The tls-unique information consists of the
the first "Finished" message in the (D)TLS handshake between server contents of the first "Finished" message in the (D)TLS handshake
and client [RFC5929]. The client adds the "Finished" message as a between server and client [RFC5929]. The client adds the "Finished"
ChallengePassword in the attributes section of the PKCS#10 Request message as a ChallengePassword in the attributes section of the
PKCS#10 Request [RFC5967] to prove that the client is indeed in
[RFC5967] to prove that the client is indeed in control of the control of the private key at the time of the (D)TLS session
private key at the time of the (D)TLS session establishment. 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
message must be computed as if each handshake message had been sent message must be computed as if each handshake message had been sent
as a single fragment (Section 5.8 of [I-D.ietf-tls-dtls13]) following as a single fragment (Section 5.8 of [I-D.ietf-tls-dtls13]) following
skipping to change at page 9, line 38 skipping to change at page 9, line 41
security considerations apply regarding the use of the Implicit and security considerations apply regarding the use of the Implicit and
Explicit TA database as explained in Section 10.1. Explicit TA database as explained in Section 10.1.
Given that after a successful enrollment, it is more likely that a Given that after a successful enrollment, it is more likely that a
new EST transaction will take place after a significant amount of new EST transaction will take place after a significant amount of
time, the DTLS connections SHOULD only be kept alive for EST messages time, the DTLS connections SHOULD only be kept alive for EST messages
that are relatively close to each other. In some cases, like NAT that are relatively close to each other. In some cases, like NAT
rebinding, keeping the state of a connection is not possible when rebinding, keeping the state of a connection is not possible when
devices sleep for extended periods of time. In such occasions, devices sleep for extended periods of time. In such occasions,
[I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can [I-D.ietf-tls-dtls-connection-id] negotiates a connection ID that can
eliminate the need for new handshake and its additional cost. eliminate the need for new handshake and its additional cost; or DTLS
1.3 session resumption provides a less costly alternative than re-
doing a full DTLS handshake.
5. Protocol Design 5. Protocol Design
EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise
Transfer [RFC7959] to avoid IP fragmentation. The use of Blocks for Transfer [RFC7959] to avoid IP fragmentation. The use of Blocks for
the transfer of larger EST messages is specified in Section 5.6. the transfer of larger EST messages is specified in Section 5.6.
Figure 1 shows the layered EST-coaps architecture. Figure 1 shows the layered EST-coaps architecture.
The EST-coaps protocol design follows closely the EST design. The The EST-coaps protocol design follows closely the EST design. The
supported message types in EST-coaps are: supported message types in EST-coaps are:
o CA certificate retrieval needed to receive the complete set of CA o CA certificate retrieval needed to receive the complete set of CA
certificates. certificates.
o Simple enroll and re-enroll for a CA to sign public client o Simple enroll and re-enroll for a CA to sign client identity
identity key. public key.
o Certificate Signing Request (CSR) attribute messages that inform o Certificate Signing Request (CSR) attribute messages that informs
the client of the fields to include in a CSR. the client of the fields to include in a CSR.
o Server-side key generation messages to provide a private client o Server-side key generation messages to provide a client identity
identity key when the client choses so. private key when the client chooses so.
While [RFC7030] permits a number of the EST functions to be used
without authentication, this specification requires that the client
MUST be authenticated for all functions.
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 Two types of installations are possible (1)rigid ones where the
specified in this document. These URIs are shorter than the ones in address and the supported functions of the EST server(s) are known,
[RFC7030]. Two example EST-coaps resource path names are: and (2) flexible one where the EST server and it supported functions
need to be discovered.
For both types of installations, saving header space is important and
short EST-coaps URIs are specified in this document. These URIs are
shorter than the ones in [RFC7030]. Two example EST-coaps resource
path names are:
coaps://example.com:<port>/.well-known/est/<short-est> coaps://example.com:<port>/.well-known/est/<short-est>
coaps://example.com:<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. Arbitrary Labels are The short-est strings are defined in Table 1. Arbitrary Labels are
usually defined and used by EST CAs in order to route client requests usually defined and used by EST CAs in order to route client requests
to the appropriate certificate profile. Implementers should consider to the appropriate certificate profile. Implementers should consider
using short labels to minimize transmission overhead. using short labels to minimize transmission overhead.
skipping to change at page 10, line 41 skipping to change at page 11, line 9
coaps resource(s) as shown below, are of the form: coaps resource(s) as shown below, are of the form:
coaps://example.com:<port>/<root-resource>/<short-est> coaps://example.com:<port>/<root-resource>/<short-est>
coaps://example.com:<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 |
| /simpleenroll | /sen | | /simpleenroll | /sen |
| /simplereenroll | /sren | | /simplereenroll | /sren |
| /csrattrs | /att | | /serverkeygen | /skg (PKCS#7) |
| /serverkeygen | /skg (PKCS#7) | | /serverkeygen | /skc (application/pkix-cert) |
| /serverkeygen | /skc (application/pkix-cert) | | /csrattrs | /att |
+------------------+-------------------------------+ +------------------+------------------------------+
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 a certificate in PKCS#7 format and a private key. If the
the client prefers a single application/pkix-cert certificate instead client prefers a single application/pkix-cert certificate instead of
of PKCS#7, she will make an /skc request. PKCS#7, she will make an /skc request. In both cases a private key
MUST be returned
Clients and servers MUST support the short resource EST-coaps URIs. Clients and servers MUST support the short resource EST-coaps URIs.
The corresponding longer URIs from [RFC7030] MAY be supported.
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
EST resources 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]. The example below shows the discovery over "ace.est*" [RFC6690]. The example below shows the discovery over
CoAPS of the presence and location of EST-coaps resources. Linefeeds CoAPS of the presence and location of EST-coaps resources. Linefeeds
are included only for readability. 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, describing ace.est.crts, ace.est.sen, and
returned if the server supports resource discovery. The last three ace.est.sren, of the discovery response above MUST be returned if the
lines are only included if the corresponding EST functions are server supports resource discovery. The last three lines are only
implemented. The Content-Formats in the response allow the client to included if the corresponding EST functions are implemented (see
Table 2). 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. This
approach allows future servers to incorporate currently not specified
content-formats and resources.
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 are 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",
skipping to change at page 12, line 46 skipping to change at page 13, line 11
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
existence of optional functions is described in Section 5.1. existence of optional functions is described in Section 5.1.
+------------------+--------------------------+ +------------------+--------------------------+
| EST Functions | EST-coaps implementation | | EST Functions | EST-coaps implementation |
+------------------+--------------------------+ +------------------+--------------------------+
| /cacerts | MUST | | /cacerts | MUST |
| /simpleenroll | MUST | | /simpleenroll | MUST |
| /simplereenroll | MUST | | /simplereenroll | MUST |
| /fullcmc | Not specified |
| /csrattrs | OPTIONAL | | /csrattrs | OPTIONAL |
| /serverkeygen | OPTIONAL | | /serverkeygen | OPTIONAL |
| /fullcmc | Not specified |
+------------------+--------------------------+ +------------------+--------------------------+
Table 2: List of EST-coaps functions Table 2: List of EST-coaps functions
While [RFC7030] permits a number of these functions to be used
without authentication, this specification requires that the client
MUST be authenticated for all functions.
5.3. Payload formats 5.3. Payload formats
EST-coaps is designed for low-resource devices and hence does not EST-coaps is designed for low-resource devices and hence does not
need to send Base64-encoded data. Simple binary is more efficient need to send Base64-encoded data. Simple binary is more efficient
(30% smaller payload) and well supported by CoAP. Thus, the payload (30% smaller payload for DER-encoded ASN.1) and well supported by
for a given Media-Type follows the ASN.1 structure of the Media-Type CoAP. Thus, the payload for a given Media-Type follows the ASN.1
and is transported in binary format. structure of the Media-Type and is transported in binary format.
The Content-Format (HTTP Media-Type equivalent) of the CoAP message The Content-Format (HTTP Media-Type equivalent) of the CoAP message
determines which EST message is transported in the CoAP payload. The determines which EST message is transported in the CoAP payload. The
Media-Types specified in the HTTP Content-Type header (Section 3.2.2 Media-Types specified in the HTTP Content-Type header (Section 3.2.2
of [RFC7030]) are specified by the Content-Format Option (12) of of [RFC7030]) are specified by the Content-Format Option (12) of
CoAP. The combination of URI-Path and Content-Format in EST-coaps CoAP. The combination of URI-Path and Content-Format in EST-coaps
MUST map to an allowed combination of URI and Media-Type in EST. The MUST map to an allowed combination of URI and Media-Type in EST. The
required Content-Formats for these requests and response messages are required Content-Formats for these requests and response messages are
defined in Section 9.1. The CoAP response codes are defined in defined in Section 9.1. The CoAP response codes are defined in
Section 5.5. Section 5.5.
skipping to change at page 14, line 19 skipping to change at page 14, line 27
48 # bytes(8) 48 # bytes(8)
FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10" FEDCBA9876543210 # "\xFE\xDC\xBA\x98vT2\x10"
Multipart /skg response serialization Multipart /skg response serialization
When the client makes an /skc request the certificate returned with When the client makes an /skc request the certificate returned with
the private key is a single X.509 certificate (not a PKCS#7 the private key is a single X.509 certificate (not a PKCS#7
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 content format used in the response is
ASN.1 encoded in binary format. An example is shown in Appendix A.3. summarized in Table 3.
+----------+-----------------+-----------------+
| Function | Response part 1 | Response part 2 |
+----------+-----------------+-----------------+
| /skg | 284 | 281 |
| /skc | 280 | TBD287 |
+----------+-----------------+-----------------+
Table 3: response content formats for skg and skc
The key and certificate representations are 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 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 preceded by an immediately returned empty ACK or an ACK
code 5.03 as explained in Section 5.7. Thus, it is RECOMMENDED containing response code 5.03 as explained in Section 5.7. Thus,
for implementers to send EST-coaps requests in confirmable CON it is RECOMMENDED for implementers to send EST-coaps requests in
CoAP messages. 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, Block1, Block2, and Accept. These CoAP Options are used Format, Block1, Block2, and Accept. These CoAP Options are used
to communicate the HTTP fields specified in the EST REST messages. to communicate the HTTP fields specified in the EST REST messages.
The Uri-host and Uri-Port Options can be omitted from the COAP The Uri-host and Uri-Port Options can be omitted from the COAP
message sent on the wire. When omitted, they are logically message sent on the wire. When omitted, they are logically
assumed to be the transport protocol destination address and port assumed to be the transport protocol destination address 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
skipping to change at page 15, line 25 skipping to change at page 15, line 43
POST (/sen, /sren, /skg, /skc). 4.04 is used when the resource is not POST (/sen, /sren, /skg, /skc). 4.04 is used when the resource is not
available for the client. 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. HTTP 202 with Retry-After is used in EST for equivalent in CoAP. HTTP 202 with Retry-After is used in EST for
delayed server responses. Section 5.7 specifies how EST-coaps delayed server responses. Section 5.7 specifies how EST-coaps
handles delayed messages with 5.03 responses with a Max-Age Option. handles delayed messages with 5.03 responses with a Max-Age Option.
Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes have Additionally, EST's HTTP 400, 401, 403, 404 and 503 status codes have
their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes their equivalent CoAP 4.00, 4.01, 4.03, 4.04 and 5.03 response codes
in EST-coaps. Table 3 summarizes the EST-coaps response codes. in EST-coaps. Table 4 summarizes the EST-coaps response codes.
+-----------------+-----------------+-------------------------------+ +-----------------+-----------------+-------------------------------+
| operation | EST-coaps | Description | | operation | EST-coaps | Description |
| | response code | | | | response code | |
+-----------------+-----------------+-------------------------------+ +-----------------+-----------------+-------------------------------+
| /crts, /att | 2.05 | Success. Certs included in | | /crts, /att | 2.05 | Success. Certs included in |
| | | the response payload. | | | | the response payload. |
| | 4.xx / 5.xx | Failure. | | | 4.xx / 5.xx | Failure. |
| /sen, /skg, | 2.04 | Success. Cert included in the | | /sen, /skg, | 2.04 | Success. Cert included in the |
| /sren, /skc | | response payload. | | /sren, /skc | | response payload. |
| | 5.03 | Retry in Max-Age Option time. | | | 5.03 | Retry in Max-Age Option time. |
| | 4.xx / 5.xx | Failure. | | | 4.xx / 5.xx | Failure. |
+-----------------+-----------------+-------------------------------+ +-----------------+-----------------+-------------------------------+
Table 3: EST-coaps response codes Table 4: 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 are recommended to size CoAP messages
such that each DTLS record will fit within one or two IEEE 802.15.4 such that each DTLS record will fit within one or two IEEE 802.15.4
frames. frames.
That is not always possible in EST-coaps. Even though ECC That is not always possible in EST-coaps. Even though ECC
certificates are small in size, they can vary greatly based on certificates are small in size, they can vary greatly based on
signature algorithms, key sizes, and Object Identifier (OID) fields signature algorithms, key sizes, and Object Identifier (OID) fields
used. For 256-bit curves, common ECDSA cert sizes are 500-1000 bytes used. For 256-bit curves, common ECDSA cert sizes are 500-1000 bytes
which could fluctuate further based on the algorithms, OIDs, Subject which could fluctuate further based on the algorithms, OIDs, Subject
Alternative Names (SAN) and cert fields. For 384-bit curves, ECDSA Alternative Names (SAN) and cert fields. For 384-bit curves, ECDSA
certificates increase in size and can sometimes reach 1.5KB. certificates increase in size and can sometimes reach 1.5KB.
skipping to change at page 16, line 48 skipping to change at page 17, line 26
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
Section 5.2.2 of [RFC7252], a slow server can acknowledge the request Section 5.2.2 of [RFC7252], a slow server can acknowledge the request
and respond later with the requested resource representation. In and respond later with the requested resource representation. In
particular, a slow server can respond to an EST-coaps enrollment particular, a slow server can respond to an EST-coaps enrollment
request with an empty ACK with code 0.00, before sending the request with an empty ACK with code 0.00, before sending the
certificate to the client after a short delay. If the certificate certificate to the client after a short delay. If the certificate
response is large, the server will need more than one Block2 blocks response is large, the server will need more than one Block2 block to
to transfer it. transfer it.
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.
The notation of Figure 2 is explained in Appendix B.1.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> 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 (frag# 2)} --> 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 (frag# N1+1)}--> 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)
| |
skipping to change at page 17, line 36 skipping to change at page 18, line 29
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 (frag# 2)} <-- (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 (frag# N2+1)} <-- (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
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 the request for
reasons. other 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 Option. The client waits for a period of Max-Age as many times as
she receives the same 5.03 response and retransmits the enrollment she receives the same 5.03 response and retransmits the enrollment
request until she receives a certificate in a fragmented 2.04 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 client asks again for a decrease in the
when acknowledging the first Block2. block size when acknowledging the first Block2.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR (frag# 1)} --> 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 (frag# 2)} --> 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 (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
<-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age) <-- (ACK) (1:N1/0/256) (5.03 Service Unavailable) (Max-Age)
skipping to change at page 18, line 34 skipping to change at page 19, line 27
| |
| |
POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# 1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/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 (frag# 2)} --> 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 (frag# N1+1)}--> POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}-->
|
... Immediate response when certificate is ready ...
|
<-- (ACK) (1:N1/0/256) (2:0/1/128) (2.04 Changed){Cert resp (frag# 1)} <-- (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) --> 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)} <-- (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 (frag# N2+1)} <-- (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 is available. Such scenarios
scenarios could be when it is considered more secure to generate at could be when it is considered more secure to generate at the server
the server the long-lived random private key that identifies the the long-lived random private key that identifies the client, or when
client, or when the resources spent to generate a random private key the resources spent to generate a random private key at the client
at the client are considered scarce, or when the security policy are considered scarce, or when the security policy requires that the
requires that the certificate public and corresponding private keys certificate public and corresponding private keys are centrally
are centrally generated and controlled. Of course, that does not generated and controlled. Of course, that does not eliminate the
eliminate the need for proper random numbers in various protocols need for proper random numbers in various protocols like (D)TLS
like (D)TLS (Section 10.1). (Section 10.1).
When requesting server-side key generation, the client asks for the When requesting server-side key generation, the client asks for the
server or proxy to generate the private key and the certificate which server or proxy to generate the private key and the certificate which
are transferred back to the client in the server-side key generation are transferred back to the client in the server-side key generation
response. In all respects, the server SHOULD treat the CSR as it response. In all respects, the server treats the CSR as it would
would treat any enroll or re-enroll CSR; the only distinction here is treat any enroll or re-enroll CSR; the only distinction here is that
that the server MUST ignore the public key values and signature in the server MUST ignore the public key values and signature in the
the CSR. These are included in the request only to allow re-use of CSR. These are included in the request only to allow re-use of
existing codebases for generating and parsing such requests. existing codebases for generating and parsing such requests.
The client /skg request is for a certificate in a PKCS#7 container The client /skg request is for a certificate in a PKCS#7 container
and private key in two application/multipart-core elements. and private key in two application/multipart-core elements.
Respectively, an /skc request is for a single application/pkix-cert Respectively, an /skc request is for a single application/pkix-cert
certificate and a private key. The private key Content-Format certificate and a private key. The private key Content-Format
requested by the client is depicted in the PKCS#10 CSR request. If requested by the client is indicated in the PKCS#10 CSR request. If
the request contains SMIMECapabilities and DecryptKeyIdentifier or the request contains SMIMECapabilities and DecryptKeyIdentifier or
AsymmetricDecryptKeyIdentifier the client is expecting Content-Format AsymmetricDecryptKeyIdentifier the client is expecting Content-Format
280 for the private key. Then the private key is encrypted 280 for the private key. Then the private key is encrypted
symmetrically or asymmetrically as per [RFC7030]. The symmetric key symmetrically or asymmetrically as per [RFC7030]. The symmetric key
or the asymmetric keypair establishment method is out of scope of the or the asymmetric keypair establishment method is out of scope of the
specification. A /skg or /skc request with a CSR without specification. A /skg or /skc request with a CSR without
SMIMECapabilities expects an application/multipart-core with an SMIMECapabilities expects an application/multipart-core with an
unencrypted PKCS#8 private key with Content-Format 284. unencrypted PKCS#8 private key with Content-Format 284.
The EST-coaps server-side key generation response is returned with The EST-coaps server-side key generation response is returned with
Content-Format application/multipart-core Content-Format application/multipart-core
[I-D.ietf-core-multipart-ct] containing a CBOR array with four items [I-D.ietf-core-multipart-ct] containing a CBOR array with four items
(Section 5.3) . The two representations (each consisting of two CBOR (Section 5.3) . The two representations (each consisting of two CBOR
array items) do not have to be in a particular order since each array items) are preceded by its Content-Format ID. Dependent on the
representation is preceded by its Content-Format ID. The private key contents of the CSR, the private key can be in unprotected PKCS#8
can be in unprotected PKCS#8 [RFC5958] format (Content-Format 284) or [RFC5958] format (Content-Format 284) or protected inside of CMS
protected inside of CMS SignedData (Content-Format 280). The SignedData (Content-Format 280). The SignedData, placed in the
SignedData is signed by the party that generated the private key, outermost container, is signed by the party that generated the
which may be the EST server or the EST CA. The SignedData is further private key, which may be the EST server or the EST CA. SignedData
protected by placing it inside of a CMS EnvelopedData as explained in placed within the Enveloped Data does not need additional signing as
Section 4.4.2 of [RFC7030]. In summary, the symmetrically encrypted explained in Section 4.4.2 of [RFC7030]. In summary, the
key is included in the encryptedKey attribute in a KEKRecipientInfo symmetrically encrypted key is included in the encryptedKey attribute
structure. In the case where the asymmetric encryption key is in a KEKRecipientInfo structure. In the case where the asymmetric
suitable for transport key operations the generated private key is encryption key is suitable for transport key operations the generated
encrypted with a symmetric key which is encrypted by the client private key is encrypted with a symmetric key which is encrypted by
defined (in the CSR) asymmetric public key and is carried in an the client-defined (in the CSR) asymmetric public key and is carried
encryptedKey attribute in a KeyTransRecipientInfo structure. in an encryptedKey attribute in a KeyTransRecipientInfo structure.
Finally, if the asymmetric encryption key is suitable for key Finally, if the asymmetric encryption key is suitable for key
agreement, the generated private key is encrypted with a symmetric agreement, the generated private key is encrypted with a symmetric
key which is encrypted by the client defined (in the CSR) asymmetric key which is encrypted by the client defined (in the CSR) asymmetric
public key and is carried in an recipientEncryptedKeys attribute in a public key and is carried in an recipientEncryptedKeys attribute in a
KeyAgreeRecipientInfo. KeyAgreeRecipientInfo.
[RFC7030] recommends the use of additional encryption of the returned [RFC7030] recommends the use of additional encryption of the returned
private key. For the context of this specification, clients and private key. For the context of this specification, clients and
servers that choose to support server-side key generation MUST servers that choose to support server-side key generation MUST
support unprotected (PKCS#8) private keys (Content-Format 284). support unprotected (PKCS#8) private keys (Content-Format 284).
Symmetric or asymmetric encryption of the private key (CMS Symmetric or asymmetric encryption of the private key (CMS
EnvelopedData, Content-Format 280) SHOULD be supported for EnvelopedData, Content-Format 280) SHOULD be supported for
deployments where end-to-end encryption needs to be provided between deployments where end-to-end encryption needs to be provided between
the client and a server. Such cases could include architectures the client and a server. Such cases could include architectures
where an entity between the client and the CA terminates the DTLS where an entity between the client and the CA terminates the DTLS
connection (Registrar in Figure 4). connection (Registrar in Figure 4).
Following [RFC7030]: "It is strongly RECOMMENDED that the clients
request that the returned private key be afforded the additional
security of the Cryptographic Message Syntax (CMS) EnvelopedData in
addition to the TLS-provided security to protect against unauthorized
disclosure."
6. HTTPS-CoAPS Registrar 6. HTTPS-CoAPS Registrar
In real-world deployments, the EST server will not always reside In real-world deployments, the EST server will not always reside
within the CoAP boundary. The EST server can exist outside the within the CoAP boundary. The EST server can exist outside the
constrained network in which case it will support TLS/HTTP instead of constrained network in which case it will support TLS/HTTP instead of
CoAPS. In such environments EST-coaps is used by the client within CoAPS. In such environments EST-coaps is used by the client within
the CoAP boundary and TLS is used to transport the EST messages the CoAP boundary and TLS is used to transport the EST messages
outside the CoAP boundary. A Registrar at the edge is required to outside the CoAP boundary. A Registrar at the edge is required to
operate between the CoAP environment and the external HTTP network as operate between the CoAP environment and the external HTTP network as
shown in Figure 4. shown in Figure 4.
skipping to change at page 20, line 48 skipping to change at page 21, line 50
|Server|over TLS | Registrar | '-----------' || |Server|over TLS | Registrar | '-----------' ||
'------' '-----------------' || '------' '-----------------' ||
|| || || ||
|'--------------------------'| |'--------------------------'|
'----------------------------' '----------------------------'
Figure 4: EST-coaps-to-HTTPS Registrar at the CoAP boundary. Figure 4: EST-coaps-to-HTTPS Registrar at the CoAP boundary.
The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream
and initiate EST connections over TLS upstream. The Registrar MUST and initiate EST connections over TLS upstream. The Registrar MUST
authenticate and OPTIONALLY authorize the clients and it MUST be authenticate and optionally authorize the client requests while it
authenticated by the EST server or CA. The trust relationship MUST be authenticated by the EST server or CA. The trust
between the Registrar and the EST server SHOULD be pre-established relationship between the Registrar and the EST server SHOULD be pre-
for the Registrar to proxy these connections on behalf of various established for the Registrar to proxy these connections on behalf of
clients. various clients.
When enforcing Proof-of-Possession (POP) linking, the DTLS tls-unique When enforcing Proof-of-Possession (PoP) linking, the DTLS tls-unique
value of the (D)TLS session is used to prove that the private key value of the (D)TLS session is used to prove that the private key
corresponding to the public key is in the possession of the client corresponding to the public key is in the possession of the client
and was used to establish the connection as explained in Section 4. and was used to establish the connection as explained in Section 4.
The POP linking information is lost between the EST-coaps client and The PoP linking information is lost between the EST-coaps client and
the EST server when a Registrar is present. The EST server becomes the EST server when a Registrar is present. The EST server becomes
aware of the presence of a Registrar from its TLS client certificate aware of the presence of a Registrar from its TLS client certificate
that includes id-kp-cmcRA [RFC6402] extended key usage extension that includes id-kp-cmcRA [RFC6402] extended key usage extension
(EKU). As explained in Section 3.7 of [RFC7030], the EST server (EKU). As explained in Section 3.7 of [RFC7030], the "EST server
SHOULD apply an authorization policy consistent with a Registrar SHOULD apply an authorization policy consistent with a Registrar
client. For example, it could be configured to accept POP linking client. For example, it could be configured to accept PoP linking
information that does not match the current TLS session because the information that does not match the current TLS session because the
authenticated EST client Registrar has verified this information when authenticated EST client Registrar has verified this information when
acting as an EST server. acting as an EST server".
For some use cases, clients that leverage server-side key generation For some use cases, clients that leverage server-side key generation
might prefer for the enrolled keys to be generated by the Registrar might prefer for the enrolled keys to be generated by the Registrar
if the CA does not support server-side key generation. Such if the CA does not support server-side key generation. Such a
Registrar is responsible for generating a new CSR signed by a new key Registrar is responsible for generating a new CSR signed by a new key
which will be returned to the client along with the certificate from which will be returned to the client along with the certificate from
the CA. In these cases, the Registrar MUST support random number the CA. In these cases, the Registrar MUST use random number
generation using proper entropy. generation with proper entropy.
Table 1 contains the URI mappings between EST-coaps and EST that the Table 1 contains the URI mappings between EST-coaps and EST that the
Registrar MUST adhere to. Section 5.5 of this specification and Registrar MUST adhere to. Section 5.5 of this specification and
Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP Section 7 of [RFC8075] define the mappings between EST-coaps and HTTP
response codes, that determine how the Registrar MUST translate CoAP response codes, that determine how the Registrar MUST translate CoAP
response codes from/to HTTP status codes. The mapping from CoAP response codes from/to HTTP status codes. The mapping from CoAP
Content-Format to HTTP Media-Type is defined in Section 9.1. Content-Format to HTTP Media-Type is defined in Section 9.1.
Additionally, a conversion from CBOR major type 2 to Base64 encoding Additionally, a conversion from CBOR major type 2 to Base64 encoding
MUST take place at the Registrar when server-side key generation is MUST take place at the Registrar. If CMS end-to-end encryption is
supported. If CMS end-to-end encryption is employed for the private employed for the private key, the encrypted CMS EnvelopedData blob
key, the encrypted CMS EnvelopedData blob MUST be converted to binary MUST be converted at the Registrar to binary CBOR type 2 downstream
in CBOR type 2 downstream to the client. 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.
The EST-coaps-to-HTTP Registrar MUST support resource discovery The EST-coaps-to-HTTP Registrar MUST support resource discovery
according to the rules in Section 5.1. Section 5.1. 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 setting of the CoAP
to be tuned to the CoAP parameter values. parameter values may have consequence for the setting of the EST
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. When a change in a server parameter has been
value is also available to all the endpoints with which these effectuated, the parameter values in the communicating endpoints MUST
adjusted values are to be used to communicate. be adjusted when necessary.
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]:
o NSTART: A parameter that controls the number of simultaneous o NSTART: A parameter that controls the number of simultaneous
outstanding interactions that a client maintains to a given outstanding interactions that a client maintains to a given
server. An EST-coaps client is not expected to interact with more server. An EST-coaps client is expected to control at most one
than one servers at the same time, which is the default NSTART interaction with a given server, which is the default NSTART value
value defined in [RFC7252]. defined in [RFC7252].
o DEFAULT_LEISURE: This setting is only relevant in multicast o DEFAULT_LEISURE: This setting is only relevant in multicast
scenarios, outside the scope of EST-coaps. scenarios, outside the scope of EST-coaps.
o PROBING_RATE: A parameter which specifies the rate of re-sending o PROBING_RATE: A parameter which specifies the rate of re-sending
non-confirmable messages. The EST messages are defined to be sent non-confirmable messages. In the rare situations that non-
as CoAP confirmable messages, hence this setting is not confirmable messages are used, the default PROBING_RATE value
applicable. defined in [RFC7252] applies.
Finally, the Table 3 parameters in [RFC7252] are mainly derived from Finally, the Table 3 parameters in [RFC7252] are mainly derived from
Table 2. Directly changing parameters on one table would affect Table 2. Directly changing parameters on one table would affect
parameters on the other. parameters on the other.
8. Deployment limitations 8. Deployment limitations
Although EST-coaps paves the way for the utilization of EST by Although EST-coaps paves the way for the utilization of EST by
constrained devices in constrained networks, some classes of devices constrained devices in constrained networks, some classes of devices
[RFC7228] will not have enough resources to handle the payloads that [RFC7228] will not have enough resources to handle the payloads that
skipping to change at page 23, line 10 skipping to change at page 24, 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 4. "CoRE Parameters" registry [COREparams] are specified in Table 5.
These have been registered provisionally in the IETF Review or IESG These have been registered provisionally in the IETF Review or IESG
Approval range (256-9999). 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] [ThisRFC] |
| 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] [ThisRFC] |
| application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- | | application/pkcs8 | 284 | [RFC5958] [I-D.ietf-lamps- |
| | | rfc5751-bis] | | | | rfc5751-bis] [ThisRFC] |
| application/csrattrs | 285 | [RFC7030] [RFC7231] | | application/csrattrs | 285 | [RFC7030] |
| application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- | | application/pkcs10 | 286 | [RFC5967] [I-D.ietf-lamps- |
| | | rfc5751-bis] | | | | rfc5751-bis] [ThisRFC] |
| application/pkix-cert | TBD28 | [RFC2585] | | application/pkix-cert | TBD28 | [RFC2585] [ThisRFC] |
| | 7 | | | | 7 | |
+------------------------------+-------+----------------------------+ +------------------------------+-------+----------------------------+
Table 4: New CoAP Content-Formats Table 5: 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.
o rt="ace.est.crts". This resource depicts the support of EST get o rt="ace.est.crts". This resource depicts the support of EST get
cacerts. cacerts.
o rt="ace.est.sen". This resource depicts the support of EST simple o rt="ace.est.sen". This resource depicts the support of EST simple
enroll. enroll.
o rt="ace.est.sren". This resource depicts the support of EST o rt="ace.est.sren". This resource depicts the support of EST
simple reenroll. simple reenroll.
o rt="ace.est.att". This resource depicts the support of EST CSR o rt="ace.est.att". This resource depicts the support of EST get
attributes. CSR attributes.
o rt="ace.est.skg". This resource depicts the support of EST o rt="ace.est.skg". This resource depicts the support of EST
server-side key generation with the returned certificate in a server-side key generation with the returned certificate in a
PKCS#7 container. PKCS#7 container.
o rt="ace.est.skc". This resource depicts the support of EST o rt="ace.est.skc". This resource depicts the support of EST
server-side key generation with the returned certificate in server-side key generation with the returned certificate in
application/pkix-cert format. application/pkix-cert format.
10. Security Considerations 10. Security Considerations
10.1. EST server considerations 10.1. EST server considerations
The security considerations of Section 6 of [RFC7030] are only The security considerations of Section 6 of [RFC7030] are only
partially valid for the purposes of this document. As HTTP Basic partially valid for the purposes of this document. As HTTP Basic
Authentication is not supported, the considerations expressed for Authentication is not supported, the considerations expressed for
using passwords do not apply. using passwords do not apply. The other portions of the security
considerations of [RFC7030] continue to apply.
Modern security protocols require random numbers to be available Modern security protocols require random numbers to be available
during the protocol run, for example for nonces, ephemeral (EC) during the protocol run, for example for nonces and ephemeral (EC)
Diffie-Hellman key generation. This capability to generate random Diffie-Hellman key generation. This capability to generate random
numbers is also needed when the constrained device generates the numbers is also needed when the constrained device generates the
private key (that corresponds to the public key enrolled in the CSR). private key (that corresponds to the public key enrolled in the CSR).
When server-side key generation is used, the constrained device When server-side key generation is used, the constrained device
depends on the server to generate the private key randomly, but it depends on the server to generate the private key randomly, but it
still needs locally generated random numbers for use in security still needs locally generated random numbers for use in security
protocols, as explained in Section 12 of [RFC7925]. Additionally, protocols, as explained in Section 12 of [RFC7925]. Additionally,
the transport of keys generated at the server is inherently risky. the transport of keys generated at the server is inherently risky.
Analysis SHOULD be done to establish whether server-side key For those deploying server-side key generation, analysis SHOULD be
generation increases or decreases the probability of digital identity done to establish whether server-side key generation increases or
theft. decreases the probability of digital identity theft.
It is important to note that sources contributing to the randomness It is important to note that sources contributing to the randomness
pool used to generate random numbers on laptops or desktop PCs are pool used to generate random numbers on laptops or desktop PCs are
not available on many constrained devices, such as mouse movement, not available on many constrained devices, such as mouse movement,
timing of keystrokes, air turbulence on the movement of hard drive timing of keystrokes, or air turbulence on the movement of hard drive
heads, as pointed out in [PsQs]. Other sources have to be used or heads, as pointed out in [PsQs]. Other sources have to be used or
dedicated hardware has to be added. Selecting hardware for an IoT dedicated hardware has to be added. Selecting hardware for an IoT
device that is capable of producing high-quality random numbers is device that is capable of producing high-quality random numbers is
therefore important [RSAfact]. therefore important [RSAfact].
It is also RECOMMENDED that the Implicit Trust Anchor database used It is also RECOMMENDED that the Implicit Trust Anchor database used
for EST server authentication is carefully managed to reduce the for EST server authentication is carefully managed to reduce the
chance of a third-party CA with poor certification practices chance of a third-party CA with poor certification practices
jeopardizing authentication. Disabling the Implicit Trust Anchor jeopardizing authentication. Disabling the Implicit Trust Anchor
database after successfully receiving the Distribution of CA database after successfully receiving the Distribution of CA
certificates response (Section 4.1.3 of [RFC7030]) limits any risk to certificates response (Section 4.1.3 of [RFC7030]) limits any risk to
the first DTLS exchange. Alternatively, in a case where a /sen the first DTLS exchange. Alternatively, in a case where a /sen
request immediately follows a /crts, a client MAY choose to keep the request immediately follows a /crts, a client MAY choose to keep the
connection authenticated by the Implicit TA open for efficiency connection authenticated by the Implicit TA open for efficiency
reasons (Section 4). A client that pipelines EST-coaps /crts request reasons (Section 4). A client that interleaves EST-coaps /crts
with other requests in the same DTLS connection SHOULD revalidate the request with other requests in the same DTLS connection SHOULD
server certificate chain against the updated Explicit TA from the revalidate the server certificate chain against the updated Explicit
/crts response before proceeding with the subsequent requests. If TA from the /crts response before proceeding with the subsequent
the server certificate chain does not authenticate against the requests. If the server certificate chain does not authenticate
database, the client SHOULD close the connection without completing against the database, the client SHOULD close the connection without
the rest of the requests. The updated Explicit TA MUST continue to completing the rest of the requests. The updated Explicit TA MUST
be used in new DTLS connections. continue to be used in new DTLS connections.
In cases where the IDevID used to authenticate the client is expired In cases where the IDevID used to authenticate the client is expired
the server MAY still authenticate the client because IDevIDs are the server MAY still authenticate the client because IDevIDs are
expected to live as long as the device itself (Section 4). In such expected to live as long as the device itself (Section 4). In such
occasions, checking the certificate revocation status or authorizing occasions, checking the certificate revocation status or authorizing
the client using another method is important for the server to ensure the client using another method is important for the server to ensure
that the client is to be trusted. that the client is to be trusted.
In accordance with [RFC7030], TLS cipher suites that include In accordance with [RFC7030], TLS cipher suites that include
"_EXPORT_" and "_DES_" in their names MUST NOT be used. More "_EXPORT_" and "_DES_" in their names MUST NOT be used. More
information about recommendations of TLS and DTLS are included in information about recommendations of TLS and DTLS are included in
[RFC7525]. [RFC7525].
As described in CMC, Section 6.7 of [RFC5272], "For keys that can be As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
used as signature keys, signing the certification request with the used as signature keys, signing the certification request with the
private key serves as a POP on that key pair". The inclusion of tls- private key serves as a PoP on that key pair". The inclusion of tls-
unique in the certificate request links the proof-of-possession to unique in the certificate request links the proof-of-possession to
the TLS proof-of-identity. This implies but does not prove that only the TLS proof-of-identity. This implies but does not prove that only
the authenticated client currently has access to the private key. the authenticated client currently has access to the private key.
What's more, POP linking uses tls-unique as it is defined in What's more, CMC PoP linking uses tls-unique as it is defined in
[RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing [RFC5929]. The 3SHAKE attack [tripleshake] poses a risk by allowing
a man-in-the-middle to leverage session resumption and renegotiation a man-in-the-middle to leverage session resumption and renegotiation
to inject himself between a client and server even when channel to inject himself between a client and server even when channel
binding is in use. The attack was possible because of certain (D)TLS binding is in use. In the context of this specification, an attacker
implementation imperfections. In the context of this specification, could invalidate the purpose of the PoP linking ChallengePassword in
an attacker could invalidate the purpose of the POP linking the client request by resuming an EST-coaps connection. Even though
ChallengePassword in the client request by resuming an EST-coaps the practical risk of such an attack to EST-coaps is not devastating,
connection. Even though the practical risk of such an attack to EST- we would rather use a more secure channel binding mechanism. Such a
coaps is not devastating, we would rather use a more secure channel mechanism could include an updated tls-unique value generation like
binding mechanism. Such a mechanism could include an updated tls- the tls-unique-prf defined in [I-D.josefsson-sasl-tls-cb] by using a
unique value generation like the tls-unique-prf defined in TLS exporter [RFC5705] in TLS 1.2 or TLS 1.3's updated exporter
[I-D.josefsson-sasl-tls-cb] by using a TLS exporter [RFC5705] in TLS (Section 7.5 of [RFC8446]) value in place of the tls-unique value in
1.2 or TLS 1.3's updated exporter (Section 7.5 of [RFC8446]). Such the CSR. Such mechanism has not been standardized yet. Adopting a
mechanism has not been standardized yet. Adopting a channel binding channel binding value generated from an exporter would break
value generated from an exporter would break backwards compatibility. backwards compatibility for an RA that proxies through to a classic
Thus, in this specification we still depend on the tls-unique EST server. Thus, in this specification we still depend on the tls-
mechanism defined in [RFC5929], especially since a 3SHAKE attack does unique mechanism defined in [RFC5929], especially since a 3SHAKE
not expose messages exchanged with EST-coaps. attack does not expose messages exchanged with EST-coaps.
Regarding the Certificate Signing Request (CSR), an EST-coaps server Regarding the Certificate Signing Request (CSR), an EST-coaps server
is expected to be able to recover from improper CSR requests. is expected to be able 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 direct client-server connections are not possible. When
linking is used the Registrar terminating the TLS connection PoP linking is used the Registrar terminating the DTLS connection
establishes a new one with the upstream CA. Thus, it is impossible establishes a new TLS connection with the upstream CA. Thus, it is
for POP linking to be enforced end-to-end for the EST transaction. impossible for PoP linking to be enforced end-to-end for the EST
The EST server could be configured to accept POP linking information transaction. The EST server could be configured to accept PoP
that does not match the current TLS session because the authenticated linking information that does not match the current TLS session
EST Registrar client has verified this information when acting as an because the authenticated EST Registrar is assumed to have verified
EST server. PoP linking downstream to the client.
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 authenticate the Registrar using its implicit or explicit TA
It also assumes the Registrar has a trust relationship with the database. It also assumes the Registrar has a trust relationship
upstream EST server in order to act on behalf of the clients. When a with the upstream EST server in order to act on behalf of the
client uses the Implicit TA database for certificate validation, she clients. When a client uses the Implicit TA database for certificate
SHOULD confirm if the server is acting as an RA by the presence of validation, she SHOULD confirm if the server is acting as an RA by
the id-kp-cmcRA EKU [RFC6402] in the server certificate. the presence of 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
Registrar will be generating the private key and enrolling the Registrar will be generating the private key and enrolling the
certificates with the CA or if the CA will be responsible for certificates with the CA or if the CA will be responsible for
generating the key. In such cases, the existence of a Registrar generating the key. In such cases, the existence of a Registrar
requires the client to put its trust on the registrar doing the right requires the client to put its trust on the registrar when it is
thing if it is generating the private key. generating the private key.
11. Contributors 11. Contributors
Martin Furuhed contributed to the EST-coaps specification by Martin Furuhed contributed to the EST-coaps specification by
providing feedback based on the Nexus EST over CoAPS server providing feedback based on the Nexus EST over CoAPS server
implementation that started in 2015. Sandeep Kumar kick-started this implementation that started in 2015. Sandeep Kumar kick-started this
specification and was instrumental in drawing attention to the specification and was instrumental in drawing attention to the
importance of the subject. importance of the subject.
12. Acknowledgements 12. Acknowledgements
skipping to change at page 27, line 28 skipping to change at page 28, line 36
Camezind, Bjorn Elmers and Joel Hoglund. Camezind, Bjorn Elmers and Joel Hoglund.
Robert Moskowitz provided code to create the examples. Robert Moskowitz provided code to create the examples.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-multipart-ct] [I-D.ietf-core-multipart-ct]
Fossati, T., Hartke, K., and C. Bormann, "Multipart Fossati, T., Hartke, K., and C. Bormann, "Multipart
Content-Format for CoAP", draft-ietf-core-multipart-ct-03 Content-Format for CoAP", draft-ietf-core-multipart-ct-04
(work in progress), March 2019. (work in progress), August 2019.
[I-D.ietf-lamps-rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-12
(work in progress), September 2018.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-31 (work in progress), March 1.3", draft-ietf-tls-dtls13-32 (work in progress), July
2019. 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, RFC 2585, DOI 10.17487/RFC2585, May 1999,
<https://www.rfc-editor.org/info/rfc2585>. <https://www.rfc-editor.org/info/rfc2585>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
DOI 10.17487/RFC5967, August 2010, DOI 10.17487/RFC5967, August 2010,
<https://www.rfc-editor.org/info/rfc5967>. <https://www.rfc-editor.org/info/rfc5967>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
skipping to change at page 28, line 27 skipping to change at page 29, line 46
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[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>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[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>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>.
[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]
"Constrained RESTful Environments (CoRE) Parameters", "Constrained RESTful Environments (CoRE) Parameters",
<https://www.iana.org/assignments/core-parameters/ <https://www.iana.org/assignments/core-parameters/core-
core-parameters.xhtml>. parameters.xhtml>.
[I-D.ietf-lamps-rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-12
(work in progress), September 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-05 (work in progress), May 2019. id-06 (work in progress), July 2019.
[I-D.josefsson-sasl-tls-cb] [I-D.josefsson-sasl-tls-cb]
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-05 (work in progress), March 2019. pki-07 (work in progress), August 2019.
[ieee802.15.4] [ieee802.15.4]
"IEEE Standard 802.15.4-2006", 2006. "IEEE Standard 802.15.4-2006", 2006.
[ieee802.1ar] [ieee802.1ar]
"IEEE 802.1AR Secure Device Identifier", December 2009. "IEEE 802.1AR Secure Device Identifier", December 2009.
[PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys [PsQs] "Mining Your Ps and Qs: Detection of Widespread Weak Keys
in Network Devices", USENIX Security Symposium 2012 ISBN in Network Devices", USENIX Security Symposium 2012 ISBN
978-931971-95-9, August 2012. 978-931971-95-9, August 2012.
skipping to change at page 29, line 48 skipping to change at page 31, line 33
<https://www.rfc-editor.org/info/rfc5272>. <https://www.rfc-editor.org/info/rfc5272>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<https://www.rfc-editor.org/info/rfc5929>. <https://www.rfc-editor.org/info/rfc5929>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/info/rfc5958>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC) [RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/info/rfc6402>. <https://www.rfc-editor.org/info/rfc6402>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
<https://www.rfc-editor.org/info/rfc7251>. <https://www.rfc-editor.org/info/rfc7251>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<https://www.rfc-editor.org/info/rfc7299>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
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
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<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
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<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.
[tripleshake] [tripleshake]
"Triple Handshakes and Cookie Cutters: Breaking and Fixing "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 channel.
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 in the
multipart-core container.
These examples assume a short resource path of "/est". Even though These examples assume a short resource path of "/est". Even though
omitted from the examples for brevity, before making the EST-coaps omitted from the examples for brevity, before making the EST-coaps
requests, a client would learn about the server supported 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 resources with a GET request for /.well-known/core?rt=ace.est* as
explained in Section 5.1. 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.
skipping to change at page 32, line 12 skipping to change at page 33, line 22
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 = 0xD Option Length = 0xB
Option Value = "example.com" 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 = 0x2
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 = 0x3
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)
Option Length = 0x6 Option Length = 0x4
Option Value = "crts" Option Value = "crts"
Option (Accept) Option (Accept)
Option Delta = 0x6 (option# 11+6=17) Option Delta = 0x6 (option# 11+6=17)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Payload = [Empty] Payload = [Empty]
The Uri-Host and Uri-Port Options can be omitted if they coincide The Uri-Host and Uri-Port Options can be omitted if they coincide
with the transport protocol destination address and port with the transport protocol destination address and port
respectively. Explicit Uri-Host and Uri-Port Options are typically respectively. Explicit Uri-Host and Uri-Port Options are typically
skipping to change at page 33, line 19 skipping to change at page 34, line 22
Option (Content-Format) Option (Content-Format)
Option Delta = 0xC (option# 12) Option Delta = 0xC (option# 12)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 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. ]
Payload = Payload =
3082027b06092a864886f70d010702a082026c308202680201013100300b 3082027a06092a864886f70d010702a082026b308202670201013100300b
06092a864886f70d010701a082024e3082024a308201f0a0030201020209 06092a864886f70d010701a082024d30820249308201efa0030201020208
009189bcdf9c99244b300a06082a8648ce3d0403023067310b3009060355 0b8bb0fe604f6a1e300a06082a8648ce3d0403023067310b300906035504
040613025553310b300906035504080c024341310b300906035504070c02 0613025553310b300906035504080c024341310b300906035504070c024c
4c4131143012060355040a0c0b4578616d706c6520496e63311630140603 4131143012060355040a0c0b4578616d706c6520496e6331163014060355
55040b0c0d63657274696669636174696f6e3110300e06035504030c0752 040b0c0d63657274696669636174696f6e3110300e06035504030c07526f
6f6f74204341301e170d3139303130373130343034315a170d3339303130 6f74204341301e170d3139303133313131323730335a170d333930313236
323130343034315a3067310b3009060355040613025553310b3009060355 3131323730335a3067310b3009060355040613025553310b300906035504
04080c024341310b300906035504070c024c4131143012060355040a0c0b 080c024341310b300906035504070c024c4131143012060355040a0c0b45
4578616d706c6520496e6331163014060355040b0c0d6365727469666963 78616d706c6520496e6331163014060355040b0c0d636572746966696361
6174696f6e3110300e06035504030c07526f6f742043413059301306072a 74696f6e3110300e06035504030c07526f6f742043413059301306072a86
8648ce3d020106082a8648ce3d03010703420004814994082b6e8185f3df 48ce3d020106082a8648ce3d030107034200040c1b1e82ba8cc72680973f
53f5e0bee698973335200023ddf78cd17a443ffd8ddd40908769c55652ac 97edb8a0c72ab0d405f05d4fe29b997a14ccce89008313d09666b6ce375c
2ccb75c4a50a7c7ddb7c22dae6c85cca538209fdbbf104c9a38184308181 595fcc8e37f8e4354497011be90e56794bd91ad951ab45a3818430818130
301d0603551d0e041604142495e816ef6ffcaaf356ce4adffe33cf492abb 1d0603551d0e041604141df1208944d77b5f1d9dcb51ee244a523f3ef5de
a8301f0603551d230418301680142495e816ef6ffcaaf356ce4adffe33cf 301f0603551d230418301680141df1208944d77b5f1d9dcb51ee244a523f
492abba8300f0603551d130101ff040530030101ff300e0603551d0f0101 3ef5de300f0603551d130101ff040530030101ff300e0603551d0f0101ff
ff040403020106301e0603551d1104173015811363657274696679406578 040403020106301e0603551d110417301581136365727469667940657861
616d706c652e636f6d300a06082a8648ce3d0403020348003045022100da 6d706c652e636f6d300a06082a8648ce3d040302034800304502202b891d
e37c96f154c32ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f135327 d411d07a6d6f621947635ba4c43165296b3f633726f02e51ecf464bd4002
2f022047a28ae5c7306163b3c3834bab3c103f743070594c089aaa0ac870 2100b4be8a80d08675f041fbc719acf3b39dedc85dc92b3035868cb2daa8
cd13b902caa1003100 f05db196a1003100
The breakdown of the payload is shown in Appendix C.1. The breakdown of the payload is shown in Appendix C.1.
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:321]: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. ]
skipping to change at page 36, line 13 skipping to change at page 37, line 13
In a serverkeygen exchange the CoAP POST request looks like In a serverkeygen exchange the CoAP POST request looks like
POST 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 3081d03078020100301631143012060355040a0c0b736b67206578616d70
6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b 6c653059301306072a8648ce3d020106082a8648ce3d03010703420004c8
b8c1117896f98e4506c03d70efbe820d8e38ea97e9d65d52c8460c5852c5 b421f11c25e47e3ac57123bf2d9fdc494f028bc351cc80c03f150bf50cff
1dd89a61370a2843760fc859799d78cd33f3c1846e304f1717f8123f1a28 958d75419d81a6a245dffae790be95cf75f602f9152618f816a2b23b5638
4cc99fa000300a06082a8648ce3d04030203470030440220387cd4e9cf62 e59fd9a000300a06082a8648ce3d040302034800304502207c553981b1fe
8d4af77f92ebed4890d9d141dca86cd2757dd14cbd59cdf6961802202f24 349249d8a3f50a0346336b7dfaa099cf74e1ec7a37a0a760485902210084
5e828c77754378b66660a4977f113cacdaa0cc7bad7d1474a7fd155d090d 79295398774b2ff8e7e82abb0c17eaef344a5088fa69fd63ee611850c34b
0a
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.04 Changed 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)
308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30
6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 6b020101042061336a86ac6e7af4a96f632830ad4e6aa0837679206094d7
45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 679a01ca8c6f0c37a14403420004c8b421f11c25e47e3ac57123bf2d9fdc
0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 494f028bc351cc80c03f150bf50cff958d75419d81a6a245dffae790be95
cd33f3c1846e304f1717f8123f1a284cc99f cf75f602f9152618f816a2b23b5638e59fd9
19 0119 # unsigned(281) 19 0119 # unsigned(281)
59 01D3 # bytes(467) 59 01D3 # bytes(467)
308201cf06092a864886f70d010702a08201c0308201bc0201013100300b 308201cf06092a864886f70d010702a08201c0308201bc0201013100300b
06092a864886f70d010701a08201a23082019e30820143a0030201020208 06092a864886f70d010701a08201a23082019e30820144a0030201020209
126de8571518524b300a06082a8648ce3d04030230163114301206035504 00b3313e8f3fc9538e300a06082a8648ce3d040302301631143012060355
0a0c0b736b67206578616d706c65301e170d313930313039303835373038 040a0c0b736b67206578616d706c65301e170d3139303930343037343430
5a170d3339303130343038353730385a301631143012060355040a0c0b73 335a170d3339303833303037343430335a301631143012060355040a0c0b
6b67206578616d706c653059301306072a8648ce3d020106082a8648ce3d 736b67206578616d706c653059301306072a8648ce3d020106082a8648ce
030107034200041bb8c1117896f98e4506c03d70efbe820d8e38ea97e9d6 3d03010703420004c8b421f11c25e47e3ac57123bf2d9fdc494f028bc351
5d52c8460c5852c51dd89a61370a2843760fc859799d78cd33f3c1846e30 cc80c03f150bf50cff958d75419d81a6a245dffae790be95cf75f602f915
4f1717f8123f1a284cc99fa37b307930090603551d1304023000302c0609 2618f816a2b23b5638e59fd9a37b307930090603551d1304023000302c06
6086480186f842010d041f161d4f70656e53534c2047656e657261746564 096086480186f842010d041f161d4f70656e53534c2047656e6572617465
204365727469666963617465301d0603551d0e04160414494be598dc8dbc 64204365727469666963617465301d0603551d0e0416041496600d8716bf
0dbc071c486b777460e5cce621301f0603551d23041830168014494be598 7fd0e752d0ac760777ad665d02a0301f0603551d2304183016801496600d
dc8dbc0dbc071c486b777460e5cce621300a06082a8648ce3d0403020349 8716bf7fd0e752d0ac760777ad665d02a0300a06082a8648ce3d04030203
003046022100a4b167d0f9add9202810e6bf6a290b8cfdfc9b9c9fea2cc1 48003045022100e95bfa25a08976652246f2d96143da39fce0dc4c9b26b9
c8fc3a464f79f2c202210081d31ba142751a7b4a34fd1a01fcfb08716b9e cce1f24164cc2b12b602201351fd8eea65764e3459d324e4345ff5b2a915
b53bdaadc9ae60b08f52429c0fa1003100 38c04976111796b3698bf6379ca1003100
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:
skipping to change at page 38, line 46 skipping to change at page 39, line 46
The payloads are shown unencrypted. In practice the message contents The payloads are shown unencrypted. In practice the message contents
would be binary formatted and transferred over an encrypted DTLS would be binary formatted and transferred over an encrypted DTLS
tunnel. The corresponding CoAP headers are only shown in tunnel. The corresponding CoAP headers are only shown in
Appendix B.1. Creating CoAP headers is assumed to be generally Appendix B.1. Creating CoAP headers is assumed to be generally
known. known.
B.1. cacerts B.1. cacerts
This section provides a detailed example of the messages using DTLS This section provides a detailed example of the messages using DTLS
and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is and BLOCK option Block2. The example block length is taken as 64
the example value assumed for the DTLS datagram size. The example which gives an SZX value of 2.
block length is taken as 64 which gives an SZX value of 2.
The following is an example of a cacerts exchange over DTLS. The The following is an example of a cacerts exchange over DTLS. The
content length of the cacerts response in appendix A.1 of [RFC7030] content length of the cacerts response in appendix A.1 of [RFC7030]
contains 639 bytes in binary. The CoAP message adds around 10 bytes, contains 639 bytes in binary in this example. The CoAP message adds
the DTLS record 29 bytes. To avoid IP fragmentation, the CoAP Block around 10 bytes in this exmple, the DTLS record around 29 bytes. To
Option is used and an MTU of 127 is assumed to stay within one IEEE avoid IP fragmentation, the CoAP Block Option is used and an MTU of
802.15.4 packet. To stay below the MTU of 127, the payload is split 127 is assumed to stay within one IEEE 802.15.4 packet. To stay
in 9 packets with a payload of 64 bytes each, followed by a last below the MTU of 127, the payload is split in 9 packets with a
tenth packet of 63 bytes. The client sends an IPv6 packet containing payload of 64 bytes each, followed by a last tenth packet of 63
the UDP datagram with the DTLS record that encapsulates the CoAP bytes. The client sends an IPv6 packet containing a UDP datagram
request 10 times. The server returns an IPv6 packet containing the with the DTLS record that encapsulates a CoAP request 10 times. The
UDP datagram with the DTLS record that encapsulates the CoAP server returns an IPv6 packet containing a UDP datagram with a DTLS
response. The CoAP request-response exchange with block option is record that encapsulates the CoAP response. The CoAP request-
shown below. Block Option is shown in a decomposed way (block- response exchange with block option is shown below. Block Option is
option:NUM/M/size) indicating the kind of Block Option (2 in this shown in a decomposed way (block-option:NUM/M/size) indicating the
case) followed by a colon, and then the block number (NUM), the more kind of Block Option (2 in this case) followed by a colon, and then
bit (M = 0 in Block2 response means it is last block), and block size the block number (NUM), the more bit (M = 0 in Block2 response means
with exponent (2**(SZX+4)) separated by slashes. The Length 64 is it is last block), and block size with exponent (2**(SZX+4))
used with SZX=2 to avoid IP fragmentation. The CoAP Request is sent separated by slashes. The Length 64 is used with SZX=2. The CoAP
confirmable (CON) and the Content-Format of the response, even though Request is sent confirmable (CON) and the Content-Format of the
not shown, is 281 (application/pkcs7-mime; smime-type=certs-only). response, even though not shown, is 281 (application/pkcs7-mime;
The transfer of the 10 blocks with partially filled block NUM=9 is smime-type=certs-only). The transfer of the 10 blocks with partially
shown below filled block NUM=9 is shown below
GET example.com: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 example.com: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 example.com: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 = 0xD Option Length = 0xB
Option Value = "example.com" 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 = 0x2
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 = 0x3
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)
Option Length = 0x6 Option Length = 0x4
Option Value = "crts" Option Value = "crts"
Option (Accept) Option (Accept)
Option Delta = 0x6 (option# 11+6=17) Option Delta = 0x6 (option# 11+6=17)
Option Length = 0x2 Option Length = 0x2
Option Value = 281 Option Value = 281
Payload = [Empty] Payload = [Empty]
The Uri-Host and Uri-Port Options can be omitted if they coincide The Uri-Host and Uri-Port Options can be omitted if they coincide
with the transport protocol destination address and port with the transport protocol destination address and port
respectively. Explicit Uri-Host and Uri-Port Options are typically respectively. Explicit Uri-Host and Uri-Port Options are typically
skipping to change at page 43, line 5 skipping to change at page 44, line 5
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:321]: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)
POST [2001:db8::2:321]:61616/est/sen (CON)(1:1/1/256) {CSR req} --> <-- (ACK) (1:0/1/256) (2.31 Continue)
<-- (ACK) (1:1/1/256) (2.31 Continue) POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR (frag# 2)} -->
. <-- (ACK) (1:1/1/256) (2.31 Continue)
. .
. .
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} POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR(frag# N1+1)}-->
POST [2001:db8::2:321]:61616/est/sen (CON)(2:1/0/256) --> |
<-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp} ...........Immediate response .........
. |
. <-- (ACK) (1:N1/0/256)(2:0/1/256)(2.04 Changed){Cert resp (frag# 1)}
. POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) --> <-- (ACK) (2:1/1/256)(2.04 Changed) {Cert resp (frag# 2)}
<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp} .
.
.
POST [2001:db8::2:321]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) {Cert resp (frag# N2+1)}
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
binary payloads shown in Appendix A. binary payloads shown in Appendix A.
C.1. cacerts C.1. cacerts
The breakdown of cacerts response containing one root CA certificate The breakdown of cacerts response containing one root CA certificate
is is
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number: 831953162763987486 (0xb8bb0fe604f6a1e)
91:89:bc:df:9c:99:24:4b
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=CA, L=LA, O=Example Inc, Issuer: C=US, ST=CA, L=LA, O=Example Inc,
OU=certification, CN=Root CA OU=certification, CN=Root CA
Validity Validity
Not Before: Jan 7 10:40:41 2019 GMT Not Before: Jan 31 11:27:03 2019 GMT
Not After : Jan 2 10:40:41 2039 GMT Not After : Jan 26 11:27:03 2039 GMT
Subject: C=US, ST=CA, L=LA, O=Example Inc, Subject: C=US, ST=CA, L=LA, O=Example Inc,
OU=certification, CN=Root CA OU=certification, CN=Root CA
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:81:49:94:08:2b:6e:81:85:f3:df:53:f5:e0:be: 04:0c:1b:1e:82:ba:8c:c7:26:80:97:3f:97:ed:b8:
e6:98:97:33:35:20:00:23:dd:f7:8c:d1:7a:44:3f: a0:c7:2a:b0:d4:05:f0:5d:4f:e2:9b:99:7a:14:cc:
fd:8d:dd:40:90:87:69:c5:56:52:ac:2c:cb:75:c4: ce:89:00:83:13:d0:96:66:b6:ce:37:5c:59:5f:cc:
a5:0a:7c:7d:db:7c:22:da:e6:c8:5c:ca:53:82:09: 8e:37:f8:e4:35:44:97:01:1b:e9:0e:56:79:4b:d9:
fd:bb:f1:04:c9 1a:d9:51:ab:45
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
24:95:E8:16:EF:6F:FC:AA:F3:56:CE:4A:DF:FE:33:CF:49:2A:BB:A8 1D:F1:20:89:44:D7:7B:5F:1D:9D:CB:51:EE:24:4A:52:3F:3E:F5:DE
X509v3 Authority Key Identifier: X509v3 Authority Key Identifier:
keyid: keyid:
24:95:E8:16:EF:6F:FC:AA:F3:56:CE:4A:DF:FE:33:CF:49:2A:BB:A8 1D:F1:20:89:44:D7:7B:5F:1D:9D:CB:51:EE:24:4A:52:3F:3E:F5:DE
X509v3 Basic Constraints: critical X509v3 Basic Constraints: critical
CA:TRUE CA:TRUE
X509v3 Key Usage: critical X509v3 Key Usage: critical
Certificate Sign, CRL Sign Certificate Sign, CRL Sign
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
email:certify@example.com email:certify@example.com
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:da:e3:7c:96:f1:54:c3:2e:c0:b4:af:52:d4: 30:45:02:20:2b:89:1d:d4:11:d0:7a:6d:6f:62:19:47:63:5b:
6f:3b:7e:cc:96:87:dd:f2:67:bc:ec:36:8f:7b:7f:13:53:27: a4:c4:31:65:29:6b:3f:63:37:26:f0:2e:51:ec:f4:64:bd:40:
2f:02:20:47:a2:8a:e5:c7:30:61:63:b3:c3:83:4b:ab:3c:10: 02:21:00:b4:be:8a:80:d0:86:75:f0:41:fb:c7:19:ac:f3:b3:
3f:74:30:70:59:4c:08:9a:aa:0a:c8:70:cd:13:b9:02:ca 9d:ed:c8:5d:c9:2b:30:35:86:8c:b2:da:a8:f0:5d:b1:96
C.2. enroll / reenroll C.2. enroll / reenroll
The breakdown of the enrollment request is The breakdown of the enrollment request is
Certificate Request: Certificate Request:
Data: Data:
Version: 0 (0x0) Version: 0 (0x0)
Subject: C=US, ST=CA, L=LA, O=example Inc, Subject: C=US, ST=CA, L=LA, O=example Inc,
OU=IoT/serialNumber=Wt1234 OU=IoT/serialNumber=Wt1234
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
56:38:e5:9f:d9 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
Attributes: Attributes:
challengePassword : <256-bit POP linking value> challengePassword: <256-bit PoP linking value>
Requested Extensions: Requested Extensions:
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
othername:<unsupported> othername:<unsupported>
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd: 30:45:02:21:00:92:56:3a:54:64:63:bd:9e:cf:f1:70:d0:fd:
1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38: 1f:2e:f0:d3:d0:12:16:0e:5e:e9:0c:ff:ed:ab:ec:9b:9a:38:
92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b: 92:02:20:17:9f:10:a3:43:61:09:05:1a:ba:d1:75:90:a0:9b:
c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77 c8:7c:4d:ce:54:53:a6:fc:11:35:a1:e8:4e:ed:75:43:77
The CSR contained a ChallengePassword which is used for POP linking The CSR contains a ChallengePassword which is used for PoP linking
(Section 4). (Section 4). The CSR also contains an id-on-hardwareModuleName
hardware identifier to customize the returned certificate to the
requesting device (See [RFC7299] and [I-D.moskowitz-ecdsa-pki]).
The breakdown of the issued certificate is The breakdown of the issued certificate is
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 9112578475118446130 (0x7e7661d7b54e4632) Serial Number: 9112578475118446130 (0x7e7661d7b54e4632)
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=CA, O=Example Inc, OU=certification, Issuer: C=US, ST=CA, O=Example Inc,
CN=802.1AR CA OU=certification, CN=802.1AR CA
Validity Validity
Not Before: Jan 31 11:29:16 2019 GMT Not Before: Jan 31 11:29:16 2019 GMT
Not After : Dec 31 23:59:59 9999 GMT Not After : Dec 31 23:59:59 9999 GMT
Subject: C=US, ST=CA, L=LA, O=example Inc, Subject: C=US, ST=CA, L=LA, O=example Inc,
OU=IoT/serialNumber=Wt1234 OU=IoT/serialNumber=Wt1234
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
56:38:e5:9f:d9 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
skipping to change at page 47, line 13 skipping to change at page 48, line 13
request. request.
Certificate Request: Certificate Request:
Data: Data:
Version: 0 (0x0) Version: 0 (0x0)
Subject: O=skg example Subject: O=skg example
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:1b:b8:c1:11:78:96:f9:8e:45:06:c0:3d:70:ef: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
be:82:0d:8e:38:ea:97:e9:d6:5d:52:c8:46:0c:58: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
52:c5:1d:d8:9a:61:37:0a:28:43:76:0f:c8:59:79: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
9d:78:cd:33:f3:c1:84:6e:30:4f:17:17:f8:12:3f: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
1a:28:4c:c9:9f 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
Attributes: Attributes:
a0:00 a0:00
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:38:7c:d4:e9:cf:62:8d:4a:f7:7f:92:eb:ed:48: 30:45:02:20:7c:55:39:81:b1:fe:34:92:49:d8:a3:f5:0a:03:
90:d9:d1:41:dc:a8:6c:d2:75:7d:d1:4c:bd:59:cd:f6:96:18: 46:33:6b:7d:fa:a0:99:cf:74:e1:ec:7a:37:a0:a7:60:48:59:
02:20:2f:24:5e:82:8c:77:75:43:78:b6:66:60:a4:97:7f:11: 02:21:00:84:79:29:53:98:77:4b:2f:f8:e7:e8:2a:bb:0c:17:
3c:ac:da:a0:cc:7b:ad:7d:14:74:a7:fd:15:5d:09:0d ea:ef:34:4a:50:88:fa:69:fd:63:ee:61:18:50:c3:4b:0a
Following is the breakdown of the private key content of the server- Following is the breakdown of the private key content of the server-
side key generation response. side key generation response.
Private-Key: (256 bit) Private-Key: (256 bit)
priv: priv:
0b:9a:67:78:5b:65:e0:73:60:b6:d2:8c:fc:1d:3f: 61:33:6a:86:ac:6e:7a:f4:a9:6f:63:28:30:ad:4e:
39:25:c0:75:57:99:de:ec:a7:45:37:2b:01:69:7b: 6a:a0:83:76:79:20:60:94:d7:67:9a:01:ca:8c:6f:
d8:a6 0c:37
pub: pub:
04:1b:b8:c1:11:78:96:f9:8e:45:06:c0:3d:70:ef: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
be:82:0d:8e:38:ea:97:e9:d6:5d:52:c8:46:0c:58: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
52:c5:1d:d8:9a:61:37:0a:28:43:76:0f:c8:59:79: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
9d:78:cd:33:f3:c1:84:6e:30:4f:17:17:f8:12:3f: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
1a:28:4c:c9:9f 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
The following is the breakdown of the certificate in the server-side The following is the breakdown of the certificate in the server-side
key generation response payload. key generation response payload.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 1327972925857878603 (0x126de8571518524b) Serial Number:
b3:31:3e:8f:3f:c9:53:8e
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
Issuer: O=skg example Issuer: O=skg example
Validity Validity
Not Before: Jan 9 08:57:08 2019 GMT Not Before: Sep 4 07:44:03 2019 GMT
Not After : Jan 4 08:57:08 2039 GMT Not After : Aug 30 07:44:03 2039 GMT
Subject: O=skg example Subject: O=skg example
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit) Public-Key: (256 bit)
pub: pub:
04:1b:b8:c1:11:78:96:f9:8e:45:06:c0:3d:70:ef: 04:c8:b4:21:f1:1c:25:e4:7e:3a:c5:71:23:bf:2d:
be:82:0d:8e:38:ea:97:e9:d6:5d:52:c8:46:0c:58: 9f:dc:49:4f:02:8b:c3:51:cc:80:c0:3f:15:0b:f5:
52:c5:1d:d8:9a:61:37:0a:28:43:76:0f:c8:59:79: 0c:ff:95:8d:75:41:9d:81:a6:a2:45:df:fa:e7:90:
9d:78:cd:33:f3:c1:84:6e:30:4f:17:17:f8:12:3f: be:95:cf:75:f6:02:f9:15:26:18:f8:16:a2:b2:3b:
1a:28:4c:c9:9f 56:38:e5:9f:d9
ASN1 OID: prime256v1 ASN1 OID: prime256v1
NIST CURVE: P-256 NIST CURVE: P-256
X509v3 extensions: X509v3 extensions:
X509v3 Basic Constraints: X509v3 Basic Constraints:
CA:FALSE CA:FALSE
Netscape Comment: Netscape Comment:
OpenSSL Generated Certificate OpenSSL Generated Certificate
X509v3 Subject Key Identifier: X509v3 Subject Key Identifier:
49:4B:E5:98:DC:8D:BC:0D:BC:07:1C:48:6B:77:74:60:E5:CC:E6:21 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0
X509v3 Authority Key Identifier: X509v3 Authority Key Identifier:
keyid: keyid:
49:4B:E5:98:DC:8D:BC:0D:BC:07:1C:48:6B:77:74:60:E5:CC:E6:21 96:60:0D:87:16:BF:7F:D0:E7:52:D0:AC:76:07:77:AD:66:5D:02:A0
Signature Algorithm: ecdsa-with-SHA256 Signature Algorithm: ecdsa-with-SHA256
30:46:02:21:00:a4:b1:67:d0:f9:ad:d9:20:28:10:e6:bf:6a: 30:45:02:21:00:e9:5b:fa:25:a0:89:76:65:22:46:f2:d9:61:
29:0b:8c:fd:fc:9b:9c:9f:ea:2c:c1:c8:fc:3a:46:4f:79:f2: 43:da:39:fc:e0:dc:4c:9b:26:b9:cc:e1:f2:41:64:cc:2b:12:
c2:02:21:00:81:d3:1b:a1:42:75:1a:7b:4a:34:fd:1a:01:fc: b6:02:20:13:51:fd:8e:ea:65:76:4e:34:59:d3:24:e4:34:5f:
fb:08:71:6b:9e:b5:3b:da:ad:c9:ae:60:b0:8f:52:42:9c:0f f5:b2:a9:15:38:c0:49:76:11:17:96:b3:69:8b:f6:37:9c
Authors' Addresses Authors' Addresses
Peter van der Stok Peter van der Stok
Consultant Consultant
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
Panos Kampanakis Panos Kampanakis
Cisco Systems Cisco Systems
 End of changes. 133 change blocks. 
425 lines changed or deleted 476 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/