]> Ericsson AB

goran.selander@ericsson.com

RISE

shahid.raza@ri.se

Nexus

martin.furuhed@nexusgroup.com

Inria

malisa.vucinic@inria.fr

timothy.claeys@gmail.com

Security ACE Working Group Internet-Draft Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS or CoAPs . This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in , which can be optionally used alongside X.509 certificates. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction One of the challenges with deploying a Public Key Infrastructure (PKI) for the Internet of Things (IoT) is certificate enrollment, because existing enrollment protocols are not optimized for constrained environments . One optimization of certificate enrollment targeting IoT deployments is specified in EST-coaps , which defines a version of Enrollment over Secure Transport for transporting EST payloads over CoAP and DTLS , instead of HTTP and TLS . This document describes a method for protecting EST payloads over CoAP with OSCORE . OSCORE specifies an extension to CoAP which protects messages at the application layer and can be applied independently of how CoAP messages are transported. OSCORE can also be applied to CoAP-mappable HTTP which enables end-to-end security for mixed CoAP and HTTP transfer of application layer data (see ). Hence EST payloads can be protected end-to-end independent of the underlying transport and through proxies translating between CoAP and HTTP. OSCORE is designed for constrained environments, building on IoT standards such as CoAP, CBOR , and COSE , and has in particular gained traction in settings where message sizes and the number of exchanged messages need to be kept at a minimum, such as 6TiSCH , or for securing CoAP group messages . Where OSCORE is implemented and used for communication security, the reuse of OSCORE for other purposes, such as enrollment, reduces the code footprint. Prior to running EST-oscore, the protocol defined in this specification, there must exist a trust relation between the EST-oscore client and the EST-oscore server. This trust relation may be based on the pre-shared OSCORE security context, or based on the common root of trust. In case there is a pre-shared OSCORE security context, the CoAP exchange carrying EST payloads can occur immediately. In case there is a common root of trust, a security handshake based on the Ephemeral Diffie-Hellman over COSE (EDHOC, ) protocol needs to occur prior to running CoAP. How this trust relation is established is out of scope of this document. How the EST-oscore server verifies the identity of the client prior to issuing a certificate is also out of scope of this specification. EST-oscore defines a number of optimizations with respect to EST-coaps:

• The DTLS record layer is replaced by OSCORE.
• The DTLS handshake is replaced by the lightweight authenticated key exchange protocol EDHOC .
• Compact CBOR representations of X.509 certificates and EST payloads (see ) are optionally used.
• Certificates by reference (see ) are optionally used.
• The EST payloads protected by OSCORE can be proxied between constrained networks supporting CoAP and non-constrained networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection without any security processing in the proxy (see ). The concept "Registrar" and its required trust relation with the EST server as described in Section 5 of is therefore not applicable.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses terminology from which in turn is based on and, in turn, on . The term "Trust Anchor" follows the terminology of : "A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." Apart from enrolling certificates with keys that are used for signing, this document also specifies how to enroll certificates with keys that are used for DH operations (static DH keys). Instead of signing, possession of the private static DH key may be proved by generating a MAC given the recipient's public DH key. Therefore this document extends the definition of the term "Trust Anchor": the corresponding public key can also be used for MAC generation for static DH proof of possession procedures.

Authentication This specification replaces the DTLS handshake in EST-coaps with the lightweight authenticated key exchange protocol EDHOC . The enrollment using EST-oscore is based on the existence of an OSCORE Security Context protecting the EST payloads. This Security Context is typically established through an EDHOC session preceding the initial enrollment. Re-enrollment does not require a new EDHOC session. The EST-oscore client MUST play the role of the EDHOC Initiator. The EST-oscore server MUST play the role of the EDHOC Responder. The EST-oscore clients and servers must perform mutual authentication. The EST server and EST client are responsible for ensuring that an acceptable cipher suite is negotiated. The client must authenticate the server before accepting any server response. The server must authenticate the client. These requirements are fullfilled when using EDHOC . The server must also provide relevant information to the CA to support its decision about issuing a certificate.

EDHOC EDHOC supports authentication with certificates or raw public keys (referred to as "credentials"), and the credentials may either be transported in the protocol, or referenced. This is determined by the identifier of the credential of the endpoint, ID_CRED_x for x= Initiator/Responder, which is transported in an EDHOC message. This identifier may be the credential itself (in which case the credential is transported), or a pointer such as a URI of the credential (e.g., x5u, see ) or some other identifier which enables the receiving endpoint to retrieve the credential.

Certificate-based Authentication EST-oscore, like EST-coaps, supports certificate-based authentication between the EST client and server. The client MUST be configured with an Implicit or Explicit Trust Anchor (TA) database, enabling the client to authenticate the server. The requirements on managing the Implicit and Explicit TA databases are discussed in and and apply to EST-oscore. The EST client and EST server certificate SHOULD conform to . The EST client and/or EST server certificate MAY be a (natively signed) CBOR certificate . The EST client indicates its preference for the type of the certificate it supports through the Accept option included in the request to the EST server.

Channel Binding The specification describes proof-of-possession as the ability of a client to prove its possession of a private key which is linked to a certified public key. In case of a signature key, a proof-of-possession is generated by the client when it signs the PKCS#10 Request during the enrollment phase. In case of a static DH key, a proof-of-possession is generated by the client when it generates a MAC and includes it in the PKCS#10 request, as per . Connection-based channel binding refers to the security binding between the PKCS#10 object and the underlying secure transport layer. This is typically achieved by including the challengePassword attribute in the PKCS#10 object that is dependent on the underlying security session. Connection-based proof-of-possession using the challengePassword attribute of the PKCS#10 object is OPTIONAL, see .

Optimizations This section contains optional behavior that may be used to reduce message sizes or round trips based on the application configuration.

• The third message of the EDHOC protocol, message_3, MAY be combined with an OSCORE request, enabling authenticated Diffie-Hellman key exchange and a protected CoAP request/response (which may contain an enrollment request and response) in two round trips .
• The enrolled certificates MAY be the CBOR-encoded certificates defined in .
• The enrolled client certificate MAY be referenced instead of transported . The EST-oscore server MAY use information in the credential identifier field of the EDHOC message (ID_CRED_x) to access the EST-oscore client certificate, e.g., in a directory or database provided by the issuer. In this case the certificate may not need to be transported over a constrained link between EST client and server.
• Conversely, the response to the PKCS#10 request MAY specify a reference to the enrolled certificate rather than the certificate itself. The EST-oscore server MAY in the enrollment response to the EST-oscore client include a pointer to a directory or database where the certificate can be retrieved.
• The PKCS#10 object MAY request a certificate for a static DH key instead of a signature key. This may result in a more compact request because the use of static DH keys may imply a proof-of-posession using a MAC, which is shorter than a signature. Additionally, subsequent EDHOC sessions using static DH keys for authentication have less overhead than key exchange protocols using signature-based authentication credentials.
• When the EDHOC handshake precedes the enrollment request, it is RECOMMENDED for the EST-client to leverage the information from the EDHOC session on the negotiated cipher suite when making a decision on which type of credential to enroll.

Protocol Design and Layering EST-oscore uses CoAP and Block-Wise transfer to transfer EST messages in the same way as . Instead of DTLS record layer, OSCORE is used to protect the messages conveying the EST payloads. External Authorization Data (EAD) fields of EDHOC are intentionally not used to carry EST payloads because EDHOC needs not be executed in the case of re-enrollment. The DTLS handshake is replaced with EDHOC . below shows the layered EST-oscore architecture. Protocol design also allows that OSCORE and EDHOC messages are carried within the same CoAP message, as per .

The stack diagram of EST protected with OSCORE.

EST-oscore follows much of the EST-coaps and EST design. This includes the need to authenticate the EST-server before performing any request on the different EST endpoints specified in this document.

Discovery and URI The discovery of EST resources and the definition of the short EST-coaps URI paths specified in Section 4.1 of , as well as the new Resource Type defined in Section 8.2 of apply to EST-oscore. Support for OSCORE is indicated by the "osc" attribute defined in Section 9 of . Example: ; rt="ace.est.sen";osc ]]> The use of the "osc" attribute is REQUIRED.

Mandatory/optional EST Functions The EST-oscore specification has the same set of required-to-implement functions as EST-coaps. The content of is adapted from Section 4.2 in and uses the updated URI paths (see ). Mandatory and optional EST-oscore functions.

EST functions	EST-oscore implementation
/crts	MUST
/sen	MUST
/sren	MUST
/skg	OPTIONAL
/skc	OPTIONAL
/att	OPTIONAL

/crts EST-coaps provides the /crts operation. A successful request from the client to this resource will be answered with a bag of certificates which is subsequently installed in the TA database, resulting in Explicit TAs. A trust anchor is commonly a self-signed certificate of the CA public key, of the format indicated by the CoAP Accept option present in the request. In order to reduce transport overhead, the trust anchor could be a CBOR encoding of an X.509 certificate , or a CWT Claims Set (CCS) , containing the CA public key and associated data without a signature.

Payload formats Similar to EST-coaps, EST-oscore allows transport of DER-encoded objects of a given Media-Type. When transporting DER-encoded objects, EST-oscore uses the same CoAP Content-Format identifiers as EST-coaps when transferring EST requests and responses. In addition, EST-oscore allows the transport of CBOR-encoded objects, signaled via their corresponding Media-Type. EST-oscore servers MUST support both the DER-encoded ASN.1 objects and the CBOR-encoded objects. This means supporting formats detailed in and . It is up to the client to support only DER-encoded ASN.1, CBOR encoding, or both. As a reminder, Content-Format negotiation happens through CoAP's Accept option present in the requests.

DER-encoded ASN.1 Objects summarizes the information from Section 4.3 in in what concerns the transport of DER-encoded ASN.1 objects. EST functions and the associated ASN.1 CoAP Content-Format identifiers.

URI	Media Type	Type	#IANA
/crts	N/A	req	-
	application/pkix-cert	res	287
	application/pkcs7-mime;smime-type=certs-only	res	281
/sen	application/pkcs10	req	286
	application/pkix-cert	res	287
	application/pkcs7-mime;smime-type=certs-only	res	281
/sren	application/pkcs10	req	286
	application/pkix-cert	res	287
	application/pkcs7-mime;smime-type=certs-only	res	281
/skg	application/pkcs10	req	286
	application/multipart-core	res	62
/skc	application/pkcs10	req	286
	application/multipart-core	res	62
/att	N/A	req	-
	application/csrattrs	res	285

Content-Format 281 and Content-Format 287 MUST be supported by EST-oscore servers. It is up to the client to support only Content-Format 281, 287 or both. As indicated in , the client will use a CoAP Accept Option in the request to express the preferred response Content-Format. If an Accept Option is not included in the request, the client is not expressing any preference and the server SHOULD choose format 281. An exception to this "SHOULD" is in the case when the request contains a CBOR-encoded object (e.g. application/cose-c509-pkcs10), when the server SHOULD respond with a CBOR-encoded object (see ). The generated response for /skg and /skc requests contains two parts: certificate and the corresponding private key. specifies that the private key in response to /skc request may be either an encrypted (PKCS #7) or unencrypted (PKCS #8) key, depending on whether the CSR request included SMIMECapabilities. Due to the use of OSCORE, which protects the communication between the EST client and the EST server end-to-end, it is possible to return the private key to /skc or /skg as an unencrypted PKCS #8 object (Content-Format identifier 284). Therefore, when making the CSR to /skc or /skg, the EST client MUST NOT include SMIMECapabilities. As a consequence, the private key part of the response to /skc or /skg is an unencrypted PKCS #8 object. Response Content-Format identifiers for /skg and /skc in case of DER-encoded ASN.1 objects.

Function	DER-encoded ASN.1 Response, Part 1	DER-encoded ASN.1 Response, Part 2
/skg	284	281
/skc	284	287

CBOR-encoded Objects presents the equivalent information to when CBOR-encoded objects are in use. EST functions and the associated CBOR CoAP Content-Format identifiers.

URI	Media Type	Type	#IANA
/crts	N/A	req	-
	application/cose-c509-cert	res	TBD6
/sen	application/cose-c509-pkcs10	req	TBD7
	application/cose-c509-cert	res	TBD6
/sren	application/cose-c509-pkcs10	req	TBD7
	application/cose-c509-cert	res	TBD6
/skg	application/cose-c509-pkcs10	req	TBD7
	application/multipart-core	res	62
/skc	N/A	req	-
	N/A	res	-
/att	N/A	req	-
	application/csrattrs	res	TBD5

EDITOR NOTE: Specify the CDDL structure of /csrattrs and point to appropriate document for its semantics. In case of CBOR-encoded objects, there is a single Content-Format, TBD6, that MUST be supported by both the EST-oscore servers and clients. The EST-client indicates its preference for a CBOR-encoded object through the Accept option of CoAP (see ). A preference for any future Content-Format is to be expressed by the EST-client through the Accept option. If an Accept Option is not included in the request, the client is not expressing any preference and the server SHOULD choose format TBD6. An exception to this "SHOULD" is in the case when the request contains a DER-encoded ASN.1 object (e.g. application/pkcs10), when the server SHOULD respond with an appropriate ASN.1 object (see ). In the case of a request to /skg, the response contains two parts: certificate and the corresponding private key. The certificate part is encoded as the application/cose-c509-cert object (Content-Format identifier TBD6), while the corresponding private key is encoded as application/cose-c509-privkey (Content-Format identifier TBD10). The function /skc is not available when using CBOR-encoded objects, and for server-side generated keys, clients MUST use the /skg function. summarizes the Content-Format identifiers used in responses to the /skg function. Response Content-Format identifiers for /skg in case of CBOR-encoded objects.

Function	CBOR Response, Part 1	CBOR Response Part 2
/skg	TBD10	TBD6

Message Bindings Note that the EST-oscore message characteristics are identical to those specified in Section 4.4 of . It is therefore required that

• The EST-oscore endpoints support delayed responses (see )
• The endpoints supports the following CoAP options: OSCORE, Uri-Host, Uri-Path, Uri-Port, Content-Format, Block1, Block2, and Accept. EST-oscore servers MUST implement Block1 and Block2. EST-oscore clients MUST implement Block2 and MAY implement Block1.
• The EST-coaps URLs based on coaps:// are translated to coap://, but with mandatory use of the CoAP OSCORE option.

CoAP response codes See Section 4.5 in .

Message Fragmentation The EDHOC key exchange is optimized for message overhead, in particular the use of static DH keys instead of signature keys for authentication (e.g., method 3 of ). Together with various measures listed in this document such as CBOR-encoded payloads , CBOR certificates , certificates by reference (), and trust anchors without signature (), a significant reduction of message sizes can be achieved. Nevertheless, depending on the application, the protocol messages may become larger than the available frame size thus resulting in fragmentation and, in resource constrained networks such as IEEE 802.15.4 where throughput is limited, fragment loss can trigger costly retransmissions. It is recommended to prevent 6LoWPAN fragmentation, since it involves an error-prone datagram reassembly. To limit the size of the CoAP payload, this document specifies the requirements on implementing CoAP options Block1 and Block2 (see ).

Delayed Responses See .

Enrollment of Certificates with Static DH Keys This section specifies how the EST client enrolls a static DH key. In general, a given key pair should only be used for a single purpose, such as key establishment, digital signature, key transport. The EST client attempting to enroll a DH key for a key usage operation other than digital signature can use an alternative proof-of-possession algorithm: The EST client SHOULD prepare the PKCS#10 object and compute a MAC, replacing the signature, over the certification request information by following the steps in . The Key Derivation Function (KDF) and the MAC MUST be set to the HDKF and HMAC algorithms used by OSCORE. The KDF and MAC is thus defined by the hash algorithm used by OSCORE in HKDF and HMAC, which by default is SHA-256. When EDHOC is used, then the hash algorithm is the application hash algorithm of the selected cipher suite. In some cases, it may be beneficial to exceptionally use the static DH private key associated to the public key used in enrollment for a one-time signing operation of the CSR. While a key pair should only be used for a single purpose (e.g. key establishment or signing), this exceptional use for one-time signing of the CSR is allowed, as discussed in Section 5.6.3.2 of and Section 5.2 of . To generate a MAC according to the algorithm outlined in , the client needs to know the public DH key of the proof-of-possession recipient/verifier, i.e. the EST server. In the general case, the EST client MAY obtain the CA certs including the CA's DH certificate using the /crts function using an explicit request/response flow. The obtained certificate indicates the DH group parameters which MUST be respected by the EST client when generating its own DH key pair. As an optimization, when EDHOC precedes the enrollment and combined OSCORE-EDHOC flow is being used in EDHOC message_3 and message_4 per , the client MUST use the public ephemeral key of the EDHOC Responder, G_Y, as the recipient public key in the algorithm outlined in . When generating its DH key pair, the client uses the group parameters as indicated by the EDHOC cipher suite in use in the EDHOC session. Because the combined delivery is used per , the client has already in EDHOC message_2 obtained the ephemeral key G_Y of the server.

HTTP-CoAP Proxy As noted in Section 5 of , in real-world deployments, the EST server will not always reside within the CoAP boundary. The EST-server can exist outside the constrained network in a non-constrained network that supports HTTP but not CoAP, thus requiring an intermediary CoAP-to-HTTP proxy. Since OSCORE is applicable to CoAP-mappable HTTP (see ) the messages conveying the EST payloads can be protected end-to-end between the EST client and EST server, irrespective of transport protocol or potential transport layer security which may need to be terminated in the proxy, see . Therefore the concept "Registrar" and its required trust relation with EST server as described in Section 5 of is not applicable. The mappings between CoAP and HTTP referred to in Section 8.1 of apply, and additional mappings resulting from the use of OSCORE are specified in Section 11 of . OSCORE provides end-to-end security between EST Server and EST Client. If a secure association is needed between the EST Client and the CoAP-to-HTTP Proxy, this may also rely on OSCORE .

CoAP-to-HTTP proxy at the CoAP boundary. | CoAP-to-HTTP |<-------->| EST Client| | |Server| (TLS) | Proxy | '-----------' | '------' '-----------------' | | | <------------------------------------------------> | OSCORE | | | | '-----------------------------' ]]>

Security Considerations

Server-generated Private Keys This document enables the EST client to request generation of private keys and the enrollment of the corresponding public key through /skg and /skc functions. As discussed in , the transport of private keys generated at EST-server is inherently risky. The use of server-generated private keys may lead to the increased probability of digital identity theft. Therefore, implementations SHOULD NOT use server-generated private key EST functions. A cryptographically secure pseudo-random number generator is required to be available to generate good quality private keys on EST-clients. A cryptographically secure pseudo-random number generator is also a dependency of many security protocols. This includes the EDHOC protocol, which EST-oscore uses for the mutual authentication of EST-client and EST-server. If EDHOC is used and a secure pseudo-random number generator is available, the EST-client MUST NOT use server-generated private key EST functions. However, EST-oscore also allows pre-shared OSCORE contexts to be used for authentication, meaning that EDHOC may not necessarily be required in the protocol stack of an EST-client. If EDHOC is not used for authentication, and the EST-client device does not have a cryptographically secure pseudo-random number generator, then the EST-client MAY use the server-generated private key functions. Although hardware random number generators are becoming dominantly present in modern IoT devices, it has been shown that many available hardware modules contain vulnerabilities and do not produce cryptographically secure random numbers. It is therefore important to use multiple randomness sources to seed the cryptographically secure pseudo-random number generator.

Considerations on Channel Binding specifies that the use of connection-based channel binding is optional, and achieves it by including the tls-unique value in the CSR. As a special case, this specification when used with EDHOC for the enrollment of static DH keys achieves connection-based channel binding by using the EDHOC ephemeral key of the responder as the public key in the proof-of-possession algorithm which generates a PKCS#10 MAC. Therefore, connection-based channel binding is in this case achieved without any additional overhead. Other cases include pre-shared OSCORE contexts and the case where the signature key used for signing the CSR is different from the key used in the EDHOC run. In these other cases, this specification makes explicit channel binding based on the challengePassword attribute in PKCS#10 requests OPTIONAL. For example, the challengePassword attribute could be used for freshness in the case of pre-shared OSCORE contexts and a re-enrollment request. EST-servers MUST support the challengePassword attribute in PKCS#10 requests. How challengePassword is processed is outside of the scope of this specification and can be specified by an application profile.

IANA Considerations This document does not require any IANA registrations.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm. This document obsoletes RFC 2875. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK] A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes. The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with any other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP-mappable HTTP. RISE AB RISE AB Object Security for Constrained RESTful Environments (OSCORE) can be used to protect CoAP messages end-to-end between two endpoints at the application layer, also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints, as well as between an application endpoint and an intermediary or between two intermediaries. Thus, this document updates RFC 8613. The same approach can be seamlessly used with Group OSCORE, for protecting CoAP messages when group communication with intermediaries is used.

Example Enrollment With Optimizations The message flow starts with the EST client sending EDHOC message_1. The EDHOC handshake follows and concludes with the EDHOC message_3. EDHOC message_3 is carried in the same message as the OSCORE enrollment request, as specified in . The OSCORE enrollment request contains a CoAP POST to the /sen endpoint. This POST request includes the Content-Format option set to the value application/cose-c509-pkcs10, and the Accept option set to the value application/cose-c509-cert, indicating the support for CBOR-encoded objects. In response, the client receives the application/cose-c509-cert object which contains the certificate.

Enrollment EST-oscore flow with optimizations. | | EDHOC message_2 | |<------------------------------------+ | EDHOC message_3 | | + | | OSCORE request to /sen | +------------------------------------>| | POST /.well-known/est/sen | | Accept: TBD6 | | Content-Format: TBD7 | | Payload: Serialized TBD7 | | | | OSCORE response | |<------------------------------------+ | 2.04 Changed | | Content-Format: TBD6 | | Payload: Serialized TBD6 | ]]>

Acknowledgments The authors would like to thank , and for providing a review of the document.