]> Ericsson AB

goran.selander@ericsson.com

University of Glasgow

shahid.raza@glasgow.ac.uk

IN Groupe

martin.furuhed@ingroupe.com

Inria

malisa.vucinic@inria.fr

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 that 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 relationship between the EST-oscore client and the EST-oscore server. This trust relationship may be based on the pre-shared OSCORE security context, or 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 EST-oscore. How this trust relationship is established is out of the scope of this document. How the EST-oscore server verifies the identity of the client prior to issuing a certificate is also out of the 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, through a CoAP-HTTP proxy without any security processing at the proxy (see ). The concept "Registrar" and its required trust relationship with the EST server as described in 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 Diffie-Hellman (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 messages conveying 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 perform mutual authentication. The EST server and EST client are responsible for ensuring that an acceptable cipher suite is negotiated. The client authenticates the server before accepting any server response. These requirements are fulfilled 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., c5u, 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 CoAP 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-protected 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 client certificate MAY be the CBOR-encoded certificates defined in .
• The enrolled client certificate MAY be referenced instead of transported . The response to the PKCS#10 request MAY specify a reference to the enrolled certificate rather than the certificate itself (see ).
• 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-possession 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 selected 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 the DTLS record layer, OSCORE is used to protect the messages conveying the EST payloads. External Authorization Data (EAD) fields of EDHOC messages 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 , as well as the new Resource Type defined in apply to EST-oscore. In a web link targeting a resource for EST-oscore, it is REQUIRED to indicate that the resource is only accessible using OSCORE, by means of the "osc" target attribute defined in . Example: ;rt=ace.est.sen;osc ]]>

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 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-oscore provides the /crts operation. A successful request from the client to this resource will be answered with one or more trust anchors, which are subsequently installed in the TA database (once the server is authenticated), 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 instead be a CBOR encoding of an X.509 certificate . The content of the response to a /crts request depends on the CoAP Accept option present in the request, as specified below. If the /crts request does not include a CoAP Accept option, the server SHOULD respond with application/pkcs7-mime;smime-type=certs-only (see ). Since a /crts request carries no payload, the server cannot infer a preference for CBOR-encoded objects from the encoding of the request, and the exception for CBOR-encoded requests in does not apply. An EST-oscore client that prefers a CBOR-encoded response MUST include a CoAP Accept option in the request. When the EST-oscore server receives a /crts request with a CoAP Accept option indicating application/pkix-cert or application/cose-c509-cert+cbor, it MUST return only the single CA certificate of the CA that has issued, or will issue, the certificate of the current, authenticated EST-oscore client making the request. An exception to this rule is when the server has been configured to operate exclusively with multiple CA trust anchors: then the server MUST respond with a 4.06 (Not Acceptable) error, to signal to the client that it needs to request another Content-Format that supports retrieval of multiple CA certificates, i.e., application/pkcs7-mime;smime-type=certs-only or application/cose-c509+cbor. When the EST-oscore server receives a /crts request with a CoAP Accept option indicating application/pkcs7-mime;smime-type=certs-only or application/cose-c509+cbor without the "usage" parameter, it MUST return all the CA certificates that the client is expected to install as Explicit TAs. The order of the certificates carries no meaning. When the EST-oscore server receives a /crts request with a CoAP Accept option indicating application/cose-c509+cbor; usage=chain, it MUST return the chain of CA certificates of the CA that has issued, or will issue, the certificate of the current, authenticated EST-oscore client making the request. The chain is ordered starting with the certificate of that CA and ending with the certificate of the root CA, i.e., the trust anchor. If the CA that has issued, or will issue, the certificate of the client is itself the root CA, the chain consists of a single certificate.

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, as indicated by their corresponding Media-Type. EST-oscore servers MUST support both the DER-encoded ASN.1 objects and the CBOR-encoded objects, i.e., they MUST support formats detailed in and . It is up to the client to support only DER-encoded ASN.1, only CBOR encoding, or both. Based on the client encoding of the CSR (DER encoding or CBOR encoding), the server is able to tell whether the client prefers a DER-encoded object () or a CBOR-encoded object () in response. In addition, Content-Format negotiation for specific objects happens through the CoAP Accept option present in the requests. The CoAP Accept option may not be present; this is a case which carries special semantics, see , , and .

DER-encoded ASN.1 Objects summarizes the information from for 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, only Content-Format 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+cbor), when the server SHOULD respond with a CBOR-encoded object (see ). The generated response for /skg and /skc requests is an application/multipart-core object with two parts: the private key and the corresponding certificate. As specified in , the parts of the application/multipart-core response do not have to be in a particular order, since each part is preceded by its Content-Format identifier; the order in is the one used in . specifies that the private key in response to /skg or /skc requests 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+cbor	res	TBD21
	application/cose-c509+cbor	res	TBD3
	application/cose-c509+cbor; usage=chain	res	TBD15
/sen	application/cose-c509-pkcs10+cbor	req	TBD4
	application/cose-c509-cert+cbor	res	TBD21
	application/multipart-core	res	62
/sren	application/cose-c509-pkcs10+cbor	req	TBD4
	application/cose-c509-cert+cbor	res	TBD21
	application/multipart-core	res	62
/skg	application/cose-c509-pkcs10+cbor	req	TBD4
	application/cose-c509-pem+cbor	res	TBD11
/skc	N/A	req	-
	N/A	res	-
/att	N/A	req	-
	application/cose-c509-crtemplate+cbor	res	TBD19

Please note that defines the format and the semantics of the response to /att. Content-Format TBD21 MUST be supported by EST-oscore servers, and by EST-oscore clients that support CBOR-encoded objects. A preference for any (future) Content-Format is to be expressed by the EST-client through the Accept option. If a CoAP Accept option is not included in a request to /sen or /sren, the client is not expressing preference and the server SHOULD respond with a response application/multipart-core that includes the reference(s) to the enrolled certificate (e.g., c5t, c5u). The application/multipart-core response MUST include the reference(s) to the enrolled certificate which allows the client or any other party to retrieve it (e.g., through a coap URI secured with OSCORE). The application/multipart-core response MAY also include the actual certificate. The exact contents of the application/multipart-core response are dependent on the application policy. Because x5u and c5u references are of the same type application/cbor and the corresponding CoAP Content Format (60), mixing them in the same application/multipart-core response is not supported. An exception to the "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 is an application/cose-c509-pem+cbor object (Content-Format identifier TBD11), i.e., a C509PEM structure () containing the generated private key and the corresponding certificate. The second element of the C509PEM structure MUST NOT be null and MUST contain the certificate enrolled for the generated private key. If the second element contains more than one certificate, the first certificate MUST be the enrolled certificate. The function /skc is not available when using CBOR-encoded objects, and clients MUST use the /skg function for server-side generated keys.

Message Bindings The EST-oscore message characteristics are based on those specified in . The following applies:

• EST-oscore endpoints MUST support delayed responses (see ).
• EST-oscore endpoints MUST support the following CoAP options: OSCORE, Uri-Host, Uri-Path, Uri-Port, Content-Format, 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 .

Message Fragmentation The EDHOC key exchange is optimized for low message overhead, in particular when using 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 , and certificates by reference (), 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 those based on 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 the 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, or 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 HKDF 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 with 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 the optimized workflow based on the EDHOC + OSCORE combined request is being used as per , the client MUST use the ephemeral public 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 selected cipher suite used in the EDHOC session.

Enrollment of Certificates by Reference The EST client may indicate preference for enrolling a certificate by reference. There are two cases to distinguish: 1) any certificate reference, or 2) a specific Content-Format. In the first case, the EST client indicates preference for receiving any certificate by reference by sending a CBOR-encoded request without the CoAP Accept option. In the second case, the EST client includes a Content-Format identifier in the CoAP Accept option indicating preference for receiving a specific reference (e.g., application/cose-certhash+cbor, application/cose-certhash+cbor;usage=c509, application/cbor containing a URI ). It is out of the scope of this specification how the certificate by reference gets resolved to the actual certificate by other parties participating in the communication with the EST client.

HTTP-CoAP Proxy As noted in , in real-world deployments, the EST server will not always reside within the CoAP boundary. The EST-server can be 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 the transport protocol or potential transport layer security that may need to be terminated at the proxy, see . Therefore, the concept "Registrar" and its required trust relationship with EST server as described in is not applicable. The mappings between CoAP and HTTP referred to in apply, and additional mappings resulting from the use of OSCORE are specified in . OSCORE provides end-to-end security between the 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 the 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 the 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 security contexts to be used for authentication, meaning that EDHOC may not necessarily be present 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, when used with EDHOC for the enrollment of static DH keys, this specification achieves connection-based channel binding by using the EDHOC ephemeral public key of the Responder as the public key in the proof-of-possession algorithm that 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 security contexts and the case where the signature key used for signing the CSR is different from the key used in the EDHOC session. 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 security contexts and of 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 policy.

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. 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. This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO Inc. 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 common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. 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 messages exchanged with the Constrained Application Protocol (CoAP) 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 each 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 When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), 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 rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries.

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+cbor, and the Accept option set to the value application/cose-c509-cert+cbor, indicating the support for CBOR-encoded objects. In response, the client receives the application/cose-c509-cert+cbor object that 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: TBD21 | | Content-Format: TBD4 | | Payload: cose-c509-pkcs10+cbor| | | | OSCORE response | |<------------------------------------+ | 2.04 Changed | | Content-Format: TBD21 | | Payload: cose-c509-cert+cbor | ]]>

Acknowledgments The authors would like to thank Timothy Claeys for his work on the initial versions of this document. The authors would also like to thank , , and for providing a review of the document. Work on this document has in part been supported by the Horizon Europe Framework Programme project OpenSwarm (grant agreement No. 101093046).