title: Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) abbrev: Constrained BRSKI (cBRSKI) docname: draft-ietf-anima-constrained-voucher-25
stand_alone: true
ipr: trust200902 area: Internet wg: anima Working Group kw: Internet-Draft cat: std stream: IETF consensus: true updates: 8995, 9148
pi: # can use array (if all yes) or hash here toc: yes sortrefs: # defaults to yes symrefs: yes
author:
-
ins: M. Richardson name: Michael Richardson org: Sandelman Software Works email: [email protected]
-
ins: P. van der Stok name: Peter van der Stok org: vanderstok consultancy email: [email protected]
-
ins: P. Kampanakis name: Panos Kampanakis org: Cisco Systems email: [email protected]
-
ins: E. Dijk name: Esko Dijk org: IoTconsultancy.nl email: [email protected]
normative:
RFC4193: RFC4210: RFC5280: RFC5652: RFC6066: RFC6347: RFC6762: RFC7250: RFC7252: RFC7950: RFC7959: RFC8366bis: I-D.ietf-anima-rfc8366bis RFC8446: RFC8449: RFC8610: RFC8710: RFC8949: RFC8995: RFC9031: minimal-security RFC9032: RFC9052: RFC9147: RFC9148: RFC9360: RFC9525: ieee802-1AR: target: "http://standards.ieee.org/findstds/standard/802.1AR-2009.html" title: "IEEE 802.1AR Secure Device Identifier" author: ins: "IEEE Standard" date: 2009
informative: RFC4443: RFC6282: RFC6690: RFC6838: RFC7030: RFC7228: RFC8366: RFC8990: RFC9053: I-D.ietf-core-sid: I-D.ietf-6lo-mesh-link-establishment: I-D.richardson-anima-masa-considerations: I-D.ietf-anima-constrained-join-proxy: I-D.ietf-lake-edhoc: EDHOC I-D.ietf-anima-jws-voucher: I-D.ietf-cbor-edn-literals: I-D.eckert-anima-brski-discovery: I-D.ietf-cose-cbor-encoded-cert: COSE-registry: title: "CBOR Object Signing and Encryption (COSE) registry" target: "https://www.iana.org/assignments/cose/cose.xhtml" author: ins: "IANA" date: 2017 Thread: title: "Thread support page, White Papers" target: "https://www.threadgroup.org/support#Whitepapers" author: ins: "Thread Group, Inc." date: "accessed 2023-11-21"
venue: mail: [email protected] github: anima-wg/constrained-voucher
--- abstract
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over-CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148.
--- middle
Secure enrollment of new nodes into constrained networks with constrained nodes presents unique challenges. As explained in {{RFC7228}}, such networks may have limited data throughput or may experience frequent packet loss. In addition, its nodes may be constrained by energy availability, memory space, and code size.
The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol described in {{RFC8995}} provides a solution for secure zero-touch (automated) onboarding of new (unconfigured) devices. In it, these new devices are called "pledges", equipped with a factory-installed Initial Device Identifier (IDevID) (see {{ieee802-1AR}}). Using the IDevID the pledges are securely enrolled into a network.
The BRSKI solution described in {{RFC8995}} was designed to be modular, and this document describes a version scaled to the constraints of IoT deployments.
Therefore, this document uses the constrained voucher artifact and voucher request artifact defined in {{RFC8366bis}} and specifies a constrained version of the BRSKI protocol: cBRSKI. The cBRSKI protocol uses the CoAP-based version of EST (EST-coaps from {{RFC9148}}) rather than the EST over HTTPS {{RFC7030}}. cBRSKI is itself scalable to multiple resource levels through the definition of optional functions. {{appendix-pledge-profiles}} illustrates this.
In BRSKI, the {{RFC8366}} voucher data is by default serialized to JSON with a signature in CMS {{RFC5652}}. This document uses the new CBOR {{RFC8949}} voucher data serialization, as defined by {{RFC8366bis}}, and applies a new COSE {{RFC9052}} signature format as defined in {{artifacts}}.
This COSE-signed CBOR-encoded voucher is transported using both secured CoAP {{RFC7252}} and HTTPS. The CoAP connection (between Pledge and Registrar) is to be protected by DTLS (CoAPS). The HTTP connection (between Registrar and MASA) is to be protected using TLS (HTTPS).
{{overview}} to {{discovery}} define the default cBRSKI protocol, by means of additions to and modifications of regular BRSKI. {{discovery-considerations}} considers some variations of the protocol, specific to particular deployments or IoT networking technologies. Next in {{design-considerations}}, some considerations for the design and implementation of cBRSKI components are provided.
{{rpk-considerations}} introduces a variant of cBRSKI for the most-constrained Pledges: the use of Raw Public Keys (RPK). This variant achieves smaller sizes of data objects and avoids doing certain costly PKIX verification operations on the Pledge.
{{pledge-discovery-on-registrar}} provides more details on how a Pledge may discover the various onboarding/enrollment options that a Registrar provides. Implementing these methods is optional for a Pledge.
The following terms are defined in {{RFC8366bis}}, and are used identically as in that document: artifact, domain, Join Registrar/Coordinator (JRC), malicious Registrar, Manufacturer Authorized Signing Authority (MASA), Pledge, Registrar, Onboarding, Owner, Voucher Data and Voucher.
The protocol described in this document is referred to as cBRSKI where the constrained version must be constrasted with the non-constrained version described in {{RFC8995}}.
The following terms from {{RFC8995}} are used identically as in that document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, manufacturer, nonced, nonceless, PKIX.
The following terms from {{RFC7030}} are used identically as in that document: Explicit Trust Anchor (TA), Explicit TA database, Third-party TA.
The term Pledge Voucher Request, or acronym PVR, is introduced to refer to the voucher request between the Pledge and the Registrar.
The term Registrar Voucher Request, or acronym RVR, is introduced to refer to the voucher request between the Registrar and the MASA.
This document uses the term "PKIX Certificate" to refer to the X.509v3 profile described in {{RFC5280}}.
In code examples, the string "<CODE BEGINS>" denotes the start of a code example and "<CODE ENDS>" the end of the code example. The ellipsis ("...") in a CBOR diagnostic notation byte string denotes a further sequence of bytes that is not shown for brevity. This notation is defined in {{I-D.ietf-cbor-edn-literals}}.
{::boilerplate bcp14}
{{RFC8366bis}} defines a voucher that can assert proximity, authenticates the Registrar, and can offer varying levels of anti-replay protection. The proximity proof provided by a voucher is an assertion that the Pledge and the Registrar are believed to be close together, from a network topology point of view. Similar to BRSKI {{RFC8995}}, proximity is proven by making a DTLS connection between a Pledge and a Registrar. The Pledge initiates this connection using a link-local source address.
The secure DTLS connection is then used by the Pledge to make a Pledge Voucher Request (PVR). The Registrar then includes the PVR into its own Registrar Voucher Request (RVR), sent to an agent (MASA) of the Pledge's manufacturer. The MASA verifies the PVR and RVR and issues a signed voucher. The voucher provides an authorization statement from the manufacturer indicating that the Registrar is the intended owner of the Pledge. The voucher refers to the Registrar through pinning of the Registrar's identity.
After verification of the voucher, the Pledge enrolls into the Registrar's domain by obtaining a certificate using the EST-coaps {{RFC9148}} protocol, suitable for constrained devices. Once the Pledge has obtained its domain identity (LDevID) in this manner, it can use this identity to obtain network access credentials, to join the local IP network. The method to obtain such credentials depends on the particular network technology used and is outside the scope of this document.
This document does not make any extensions to the semantic meaning of vouchers, though a new signature method based on COSE {{RFC9052}} is defined to optimize for constrained devices and networks.
The two main parts of the BRSKI protocol are named separately in this document: BRSKI-EST ({{brski-est}}) for the protocol between Pledge and Registrar, and BRSKI-MASA ({{brski-masa}}) for the protocol between the Registrar and the MASA.
Time-based vouchers are supported, but given that constrained devices are unlikely to have accurate time, their use will be uncommon. Most Pledges using constrained vouchers will be online during enrollment and will use live nonces to provide anti-replay protection rather than expiry times.
{{RFC8366bis}} defines the CBOR voucher data encoding for the constrained voucher and the constrained voucher request, which are used by cBRSKI.
The constrained voucher request MUST be signed by the Pledge. COSE {{RFC9052}} is used for signing as defined in {{VR-COSE}}. It signs using the private key associated with its IDevID certificate.
The constrained voucher MUST be signed by the MASA. Also in this case, COSE is used for signing.
For the constrained voucher request (PVR) the default method for the Pledge to identify the Registrar is using the Registrar's full PKIX certificate. But when operating PKIX-less as described in {{rpk-considerations}}, the Registrar's Raw Public Key (RPK) is used for this.
For the constrained voucher the default method to indicate ("pin") a trusted domain identity is the domain's PKIX CA certificate, but when operating PKIX-less instead the RPK of the Registrar is pinned.
For certificates, cBRSKI currently uses the X.509 format, like BRSKI. The protocol and data formats are defined such that future extension to other certificate formats is enabled. For example, CBOR-encoded and COSE-signed C509 certificates ({{I-D.ietf-cose-cbor-encoded-cert}}) may provide data size savings as well as code sharing benefits with CBOR/COSE libraries, when applied to cBRSKI.
The BRSKI architecture mandates that the MASA be aware of the capabilities of the Pledge. This is not a drawback as a Pledge is constructed by a manufacturer which also arranges for the MASA to be aware of the inventory of devices. The MASA therefore knows if the Pledge supports PKIX operations, or if it is limited to RPK operations only. Based upon this, the MASA can select which attributes to use in the voucher data for certain operations, like the pinning of the Registrar or domain identity.
This section details the ways in which this document updates other RFCs.
This document Updates {{RFC8995}} because it:
-
clarifies how pinning in vouchers is done ({{pinning}}),
-
adopts clearer explanation of the use of TLS Server Name Indicator (SNI) ({{sni}}, {{sni-masa}}),
-
clarifies when new trust anchors should be retrieved by a Pledge ({{brski-est-extensions-pledge}}),
-
clarifies what kinds of Extended Key Usage attributes are appropriate for each certificate ({{registrar-certificate-requirement-server}}, {{registrar-certificate-requirement-client}}).
-
extends BRSKI with the use of CoAP,
-
makes some BRSKI messages optional if the results can be inferred from other validations ({{brski-est-extensions}}),
-
extends the BRSKI-EST protocol ({{brski-est}}, {{VR-COSE}}) to carry the new "application/voucher+cose" format.
-
extends the BRSKI-MASA protocol ({{brski-masa}}, {{VR-COSE}}) to carry the new "application/voucher+cose" format.
This document Updates {{RFC9148}} because it:
-
defines stricter DTLS requirements ({{brski-est-dtls}})),
-
details how an EST-coaps client handles certificate renewal and re-enrollment ({{brski-est-extensions}}),
-
details how an EST-coaps server processes a "CA certificates" request for content format 287 ("application/pkix-cert") ({{brski-extensions-registrar}}).
-
adds enrollment status telemetry to the certificate renewal procedure ({{est-reenrollment}}),
-
adds a new media type for the CA certificates (/crts) resource ({{multipart-core}}).
This section describes the extensions to both BRSKI {{RFC8995}} and EST-coaps {{RFC9148}} protocol operations between Pledge and Registrar. The extensions are targeting low-resource networks with small packets, based on CoAP and DTLS.
A DTLS connection is established between the Pledge and the Registrar, similar to the TLS connection described in {{Section 5.1 of RFC8995}}. This may occur via a Join Proxy as described in {{joinproxy}}. Regardless of the Join Proxy presence or particular mechanism used, the DTLS connection should operate identically. The cBRSKI and EST-coaps requests and responses for onboarding are carried over this DTLS connection.
DTLS version 1.3 {{RFC9147}} SHOULD be used in any implementation of this specification. An exception case where DTLS 1.2 {{RFC6347}} MAY be used is in a Pledge that uses a software platform where a DTLS 1.3 client is not available (yet). This may occur for example if a legacy device gets software-upgraded to support cBRSKI. For this reason, a Registrar MUST by default support both DTLS 1.3 and DTLS 1.2 client connections. However, for security reasons the Registrar MAY be administratively configured to support only a particular DTLS version or higher.
An EST-coaps server {{RFC9148}} (as a separate entity from above Registrar) that implements this specification also MUST support both DTLS 1.3 and DTLS 1.2 client connections by default. However, for security reasons the EST-coaps server MAY be administratively configured to support only a particular DTLS version or higher.
As described in {{Section 5.1 of RFC8995}}, the Pledge makes a connection to the Registrar using a TLS Client Certificate for authentication. This is the Pledge's IDevID certificate.
Subsequently the Pledge will send a Pledge Voucher Request (PVR). Further elements of Pledge authentication may be present in the PVR, as detailed in {{VR-COSE}}.
DTLS includes a mechanism to fragment handshake messages. This is described in {{Section 4.4 of RFC9147}}. cBRSKI will often be used with a Join Proxy, described in {{joinproxy}}, which relays each DTLS message to the Registrar. A stateless Join Proxy will need some additional space to wrap each DTLS message inside a CoAP request, while the wrapped result needs to fit in the maximum IPv6 MTU guaranteed on 6LoWPAN networks, which is 1280 bytes.
For this reason it is RECOMMENDED that a PMTU of 1024 bytes be assumed for the DTLS handshake and appropriate DTLS fragmentation is used. It is unlikely that any Packet Too Big indications ({{RFC4443}}) will be relayed by the Join Proxy back to the Pledge.
During the operation of the EST-coaps protocol, the CoAP Block-wise transfer mechanism {{RFC7959}} will be automatically used when message sizes exceed the PMTU. A Pledge/EST-client on a constrained network MUST use the (D)TLS maximum fragment length extension ("max_fragment_length") defined in {{Section 4 of RFC6066}} with the maximum fragment length set to a value of either 2^9 or 2^10, when operating as a DTLS 1.2 client.
A Pledge/EST-client operating as DTLS 1.3 client, MUST use the (D)TLS record size limit extensions ("record_size_limit") defined in {{Section 4 of RFC8449}}, with RecordSizeLimit set to a value between 512 and 1024.
The SNI issue described below affects {{RFC8995}} as well, and is reported in errata: https://www.rfc-editor.org/errata/eid6648
As the Registrar is discovered by IP address, and typically connected via a Join Proxy, the name of the Registrar is not known to the Pledge. The Pledge will not know what the hostname for the Registrar is, so it cannot do DNS-ID validation ({{RFC9525}}) on the Registrar's certificate. Instead, it must do validation using the voucher.
As the Pledge does not know the name of the Registrar, the Pledge cannot put any reasonable value into the {{RFC6066}} Server Name Indicator (SNI). Threfore the Pledge SHOULD omit the SNI extension as per {{Section 9.2 of RFC8446}}.
In some cases, particularly while testing BRSKI, a Pledge may be given the hostname of a particular Registrar to connect to directly. Such a bypass of the discovery process may result in the Pledge taking a different code branch to establish a DTLS connection, and may result in the SNI being inserted by a library. The Registrar MUST ignore any SNI it receives from a Pledge.
A primary motivation for making the SNI ubiquitous in the public web is because it allows for multi-tenant hosting of HTTPS sites on a single (scarce) IPv4 address. This consideration does not apply to the server function in the Registrar because:
-
it uses DTLS and CoAP, not HTTPS
-
it typically uses IPv6, often {{RFC4193}} Unique Local Address, which are plentiful
-
the server port number is typically discovered, so multiple tenants can be accomodated via unique port numbers.
As per {{Section 3.6.1 of RFC7030}}, the Registrar certificate MUST have the Extended Key Usage (EKU) id-kp-cmcRA. This certificate is also used as a TLS Server Certificate, so it MUST also have the EKU id-kp-serverAuth.
See {{cosesign-registrar-cert}} for an example of a Registrar certificate with these EKUs set. See {{registrar-certificate-requirement-server}} for Registrar client certificate requirements.
{{I-D.ietf-anima-constrained-join-proxy}} specifies the details for a stateful and stateless constrained Join Proxy which is equivalent to the Proxy defined in {{RFC8995, Section 4}}. See also {{discovery}} for more details on discovery of a Join Proxy by a Pledge, and discovery of a Registrar by a Join Proxy.
cBRSKI operates using CoAP over DTLS, with request URIs using the coaps scheme. The Pledge operates in CoAP client role. To keep the protocol messages small the EST-coaps and cBRSKI request URIs are shorter than the respective EST and BRSKI URIs.
During the cBRSKI onboarding on an IPv6 network these request URIs have the following form:
coaps://[<link-local-ipv6>]:<port>/.well-known/brski/<short-name>
coaps://[<link-local-ipv6>]:<port>/.well-known/est/<short-name>
where <link-local-ipv6> is the discovered link-local IPv6 address of a Join Proxy, and <port> is the discovered port of the Join Proxy that is used to offer the cBRSKI proxy functionality.
<short-name> is the short resource name for the cBRSKI and EST-coaps resources. For EST-coaps, {{Section 5.1 of RFC9148}} defines the CoAP <short-name> resource names. For cBRSKI, this document defines the short resource names based on the {{RFC8995}} long HTTP resource names. See {{brski-est-short-uri}} for a summary of these resource names.
{{discovery-considerations}} details how the Pledge discovers a Join Proxy link-local address and port in different deployment scenarios.
The request URI formats defined here enable the Pledge to perform onboarding/enrollment without requiring discovery of the available onboarding options, voucher formats, BRSKI/EST resources, enrollment protocols, and so on. This is helpful for the majority of constrained Pledges that would support only a single set of these options. However, for Pledges that do support multiple options, {{I-D.eckert-anima-brski-discovery}} will define discovery methods so that a Pledge can select the optimal set of options for the current onboarding operation. Alternatively, a Pledge could also send CoAP discovery queries ({{Section 7 of RFC7252}}) to the Registrar to discover detailed options for onboarding and/or enrollment functions. Supporting these queries is OPTIONAL for both the Pledge and the Registrar. To clarify which options in particular can be discovered, {{pledge-discovery-on-registrar}} provides an informative overview of what can be discovered and how to discover it.
Because a Pledge only has indirect access to the Registrar via a single port on the Join Proxy, the Registrar MUST host all cBRSKI/EST-coaps resources on the same (UDP) server IP address and port. This is the address and port where a Join Proxy would relay DTLS records from the Pledge to.
Although the request URI templates include IP address, scheme and port, in practice the CoAP request sent over the secure DTLS connection only encodes the request URI. For example, a Pledge that skips resource discovery operations just sends the initial CoAP voucher request as follows:
REQ: POST /.well-known/brski/rv
Content-Format: 836
Payload : (COSE-signed Pledge Voucher Request, PVR)
Note that only Content-Format 836 ("application/voucher+cose") is defined in this document for the payload sent to the voucher request resource (/rv). Content-Format 836 MUST be supported by the Registrar for the /rv resource and it MAY support additional formats. The Pledge MAY also indicate in the request the desired format of the (voucher) response, using the Accept Option. An example of using this option in the request is as follows:
REQ: POST /.well-known/brski/rv
Content-Format: 836
Accept : 836
Payload : (COSE-signed Pledge Voucher Request, PVR)
If the Accept Option is omitted in the request, the response format follows from the request payload format (which is 836).
Note that this specification allows for voucher+cose format requests and vouchers to be transmitted over HTTPS, as well as for voucher-cms+json and other formats yet to be defined over CoAP. The burden for this flexibility is placed upon the Registrar. A Pledge on constrained hardware is expected to support a single format only.
The Pledge and MASA need to support one or more formats (at least format 836) for the voucher and for the voucher request. The MASA needs to support all formats that the Pledge supports.
{{RFC8995}} defines two telemetry returns from the Pledge which are sent to the Registrar. These are the BRSKI Status Telemetry {{RFC8995, Section 5.7}} and the Enrollment Status Telemetry {{RFC8995, Section 5.9.4}}. These are two CoAP POST request made the by Pledge at two key steps in the process.
{{RFC8995}} defines the content of these POST operations in CDDL, which are serialized as JSON. This document extends this with an additional CBOR format, derived using the CDDL rules from {{RFC8610}}.
The new CBOR format has CoAP Content-Format 60 ("application/cbor") and MUST be supported by the Registrar for both the /vs and /es resources. The existing JSON format has CoAP Content-Format 50 ("application/json") and also MUST be supported by the Registrar. A Pledge MUST support at least the new CBOR format and it MAY support the JSON format.
This document inherits EST-coaps {{RFC9148}} functions: specifically, the mandatory Simple (Re-)Enrollment (/sen and /sren) and Certification Authority certificates request (/crts). Support for CSR Attributes Request (/att) and server-side key generation (/skg, /skc) remains optional for the EST-coaps server.
{{brski-est-short-uri}} summarizes the resources used in cBRSKI. It includes both the short-name cBRSKI resources and the EST-coaps resources.
|-|-|-|-| | BRSKI + EST | cBRSKI + EST-coaps <short-name> | Well-known URI namespace | Required for Registrar? | /enrollstatus | /es | brski | MUST | /requestvoucher | /rv | brski | MUST | /voucher_status | /vs | brski | MUST | /cacerts | /crts | est | MUST | /csrattrs | /att | est | MAY | /simpleenroll | /sen | est | MUST | /simplereenroll | /sren | est | MUST | /serverkeygen | /skg | est | MAY | /serverkeygen | /skc | est | MAY {: #brski-est-short-uri title='BRSKI/EST resource name mapping to cBRSKI/EST-coaps short resource name'}
{{RFC8995, Section 5}} defines a number of HTTP response codes that the Registrar is to return when certain conditions occur.
The 401, 403, 404, 406 and 415 response codes map directly to CoAP codes 4.01, 4.03, 4.04, 4.06 and 4.15.
The 202 Retry process which occurs in the voucher request, is to be handled in the same way as the {{Section 5.7 of RFC9148}} process for Delayed Responses.
This section defines extensions to EST-coaps for Pledges (during initial onboarding), EST-coaps clients (after initial onboarding) and Registrars (that implement an EST-coaps server). Note that a device that is already onboarded is not called "Pledge" in this section: it now acts in the role of an EST-coaps client.
This section defines optimizations for the EST-coaps protocol as used by a Pledge. These aim to reduce payload sizes and the number of messages (round-trips) required for the initial EST enrollment.
A Pledge SHOULD NOT perform the optional EST-coaps "CSR attributes request" (/att). Instead, the Pledge selects the attributes to include in the CSR as specified below.
One or more Subject Distinguished Name fields MUST be included in the CSR. If the Pledge has no specific information on what attributes/fields are desired in the CSR, which is the common case, it MUST use the Subject Distinguished Name fields from its IDevID unmodified. Note that a Pledge MAY receive such specific information via the voucher data (encoded in a vendor-specific way) or via some other, out-of-band means.
A Pledge uses the following optimized EST-coaps procedure:
-
If the voucher, that validates the current Registrar, contains a single pinned domain CA certificate, the Pledge provisionally considers this certificate as the EST trust anchor, as if it were the result of a "CA certificates request" (/crts) to the Registrar.
-
Using this CA certificate as trust anchor it proceeds with EST simple enrollment (/sen) to obtain a provisionally trusted LDevID certificate.
-
If the Pledge determines that the pinned domain CA is (1) a root CA certificate and (2) signer of the LDevID certificate, the Pledge accepts the pinned domain CA certificate as the legitimate trust anchor root CA for the Registrar's domain. It also accepts the LDevID certificate as its new LDevID identity. And steps 4 and 5 are skipped.
-
Otherwise, if the step 3 condition was not met, the Pledge MUST perform a "CA certificates request" (/crts) to the EST server to obtain the full set of EST CA trust anchors. It then MUST attempt to chain the LDevID certificate to one of the CAs in the set.
-
If the Pledge cannot obtain the set of CA certificates, or it is unable to create the chain as defined in step 4, the Pledge MUST abort the enrollment process and report the error using the enrollment status telemetry (/es).
An EST-coaps client that has an idea of the current time (internally, or via Network Time Protocol) SHOULD consider the validity time of the trust anchor CA(s), and MAY begin requesting new trust anchor certificates(s) using the /crts request when the CA has 50% of it's validity time (notAfter - notBefore) left. A client without access to the current time cannot decide if trust anchor CA(s) have expired, and SHOULD poll periodically for a new trust anchor certificate(s) using the /crts request at an interval of approximately 1 month. An EST-coaps server SHOULD include the CoAP ETag Option in every response to a /crts request, to enable clients to perform low-overhead validation whether their trust anchor CA is still valid. The EST-coaps client SHOULD store the ETag resulting from a /crts response in memory and SHOULD use this value in an ETag Option in its next GET /crts request.
The domain trust anchor(s) may change over time. Such a change may happen due to relocation of the client device to a new domain, a new subdomain, or due to a key update of a trust anchor as described in {{RFC4210, Section 4.4}}.
From the client's viewpoint, a trust anchor change happens during EST-coaps re-enrollment: since a change of domain CA requires all devices operating under the old domain CA to acquire a new LDevID certificate issued by the new domain CA. A client's re-enrollment may be triggered by various events, such as an instruction to re-enroll sent by a domain entity, or an imminent expiry of its LDevID certificate, or other. How the re-enrollment is explicitly triggered on the client by a domain entity, such as a commissioner or a Registrar, is out of scope of this specification.
The mechanism described in {{RFC7030, Section 4.1.3}} and {{RFC4210, Section 4.4}} for Root CA key update requires four certificates: OldWithOld, OldWithNew, NewWithOld, and NewWithNew. Of these four, the OldWithOld certificate is already stored in the client's Explicit TA database. The other certificates will be provided to the client in a /crts response, during the EST-coaps re-enrollment procedure.
For re-enrollment, the EST-coaps client MUST support the following EST-coaps procedure. During this procedure the EST-coaps server MAY re-enroll the client into a new domain or into a new sub-CA within a domain.
-
The client connects with DTLS to the EST-coaps server, and authenticates with its present domain certificate (LDevID) as usual. The EST-coaps server authenticates itself with its domain RA certificate that is currently trusted by the client, i.e. it chains to a trust anchor CA that the client has stored in its Explicit TA database. This is the OldWithOld trust anchor. The client checks that the server is a Registration Authority (RA) of the domain as required by {{Section 3.6.1 of RFC7030}} before proceeding.
-
The client performs the simple re-enrollment request (/sren) and upon success it obtains a new LDevID certificate.
-
The client verifies the new LDevID certificate against its Explicit TA database. If the new LDevID chains successfully to a TA, this means trust anchors did not significantly change and the client MAY skip retrieving the current CA certificates using the "CA certificates request" (/crts). If it does not chain successfully, it means trust anchor(s) were changed significantly and the client MUST retrieve the new domain trust anchors using the "CA certificates request" (/crts).
-
If the client retrieved new trust anchor(s) in step 3, then it MUST verify that the new LDevID certificate it obtained in step 2 chains with the new trust anchor(s). If it chains successfully, the client stores the new trust anchor(s) in its Explicit TA database, accepts the new LDevID certificate and stops using its prior LDevID certificate. If it does not chain successfully, the client MUST NOT update its LDevID certificate, and it MUST NOT update its Explicit TA database, and the client MUST abort the enrollment process and MUST attempt to report the error to the EST-coaps server using enrollment status telemetry (/es).
Note that even though the EST-coaps client may skip the /crts request in step 3 at this time, it SHOULD still support retrieval of the trust anchors periodically as detailed in {{est-renewal-crts}}.
Note that an EST-coaps server that is also a Registrar will already support the enrollment status telemetry resource (/es) in step 4, while an EST-coaps server that purely implements {{RFC9148}}, and not the present specification, will not support this resource.
In EST-coaps {{RFC9148}} the PKCS#7 container format is used for CA certificates distribution. Because the PKCS#7 format is only used as a certificate container and no additional security is applied on the container, it becomes attractive to replace this format by something simpler, on a constrained Pledge: so that additional PKCS#7 code is avoided. Therefore, this document defines a container format using the {{RFC8710}} "application/multipart-core" media type (CoAP Content-Format 62). This is beneficial since a Pledge necessarily already supports CBOR parsing, so there is little code overhear to support this CBOR-based container format.
A Registrar or EST-coaps server MUST support Content-Format 62 for the /crts resource. The multipart collection MUST contain the individual CA certificates, each encoded as an "application/pkix-cert" (287) representation. Future documents may define other certificate formats: the multipart collection can handle any future types. The order of CA certificates MUST be in the CA hierarchy order starting from the issuer of the client's LDevID first, up to the highest-level domain CA, then optionally followed by any further CA certificates that are not part of this hierarchy. These further CA certificates may be Third-party TAs as defined in {{RFC7030}}. The highest-level domain CA may or may not be a root CA certificate.
As an example, for the two-level CA domain PKI of {{fig-twoca}} the multipart container will contain two representations:
[ <domain sub-CA cert (2)> , <domain CA cert (1)> ]
Encoded as an "application/multipart-core" CBOR array this is (shown in CBOR diagnostic notation):
[ 287, h'3082' ... 'd713', 287, h'3082' ... 'a034' ]
The total number of CA certificates SHOULD be 1, 2 or 3 and not higher to prevent constrained Pledges from running out of memory for the trust anchor storage (Explicit TA database). However if a domain operator can guarantee that any Pledges enrolled in its network can support larger sets of CA certificates, the total number MAY be configured as higher than 3. To facilitate a reliable transfer of large payloads over constrained networks, the server MUST support CoAP Block-wise transfer for the /crts response. The server MUST also support the Size2 Option {{RFC7959}} to provide the total resource length in bytes, when requested by a client.
Implementation notes: a client that receives the first block of payload data from the server, can already inspect the total number of CA certificates by decoding the first byte of the payload. In CBOR encoding, the respective first bytes 0x81-0x97 represent an array with length 1-23, respectively. Furthermore, the length in bytes of the first CA certificate can be already determined by decoding the first bytes of the second element, because the CBOR encoding for binary string includes the length of this string. A client that requires an estimate of the total resource size (to be returned as part of the first Block2 response from the server) can use a Size2 Option with value 0 in its request. Knowing the overall progress of the data transfer may be helpful in certain cases, e.g. when a Pledge provides visual progress information on the onboarding progress.
The Content-Format 60 ("application/cbor") MUST be supported by the Registrar for the /vs and /es resources.
Content-Format 836 ("application/voucher+cose") MUST be supported by the Registrar for the /rv resource for CoAP POST requests, both as request payload and as response payload.
Content-Format 287 ("application/pkix-cert") MUST be supported by the Registrar as a response payload for the /sen and /sren resources.
When a Registrar receives a "CA certificates request" (/crts) request with a CoAP Accept Option with value 287 ("application/pkix-cert") it MUST return only the single CA certificate that is the envisioned or actual CA authority for the current, authenticated Pledge making the request. An exception to this rule is when the domain has been configured to operate with multiple CA trust anchors only: then the Registrar returns 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.
This section describes extensions to and clarifications of the BRSKI-MASA protocol between Registrar and MASA.
{{Section 5.4 of RFC8995}} describes a connection between the Registrar and the MASA as being a normal TLS connection using HTTPS. This document does not change that. The Registrar MUST use the format "application/voucher+cose" in its voucher request to MASA, when the Pledge uses this format in its request to the Registrar.
The MASA only needs to support formats for which it has constructed Pledges that use that format.
The Registrar MUST use the same format for the RVR as the Pledge used for its PVR. The Registrar indicates the voucher format it wants to receive from MASA using the HTTP Accept header. This format MUST be the same as the format of the PVR, so that the Pledge can parse it.
At the moment of writing the creation of coaps based MASAs is deemed unrealistic. The use of CoAP for the BRSKI-MASA connection is out of scope but can be the subject of another document. Some consideration was made to specify CoAP support for consistency, but:
-
the Registrar is not expected to be so constrained that it cannot support HTTPS client connections.
-
the technology and experience to build Internet-scale HTTPS responders (which the MASA is) is common, while the experience doing the same for CoAP is much less common.
-
a Registrar is likely to provide onboarding services to both constrained and non-constrained devices. Such a Registrar would need to speak HTTPS anyway.
-
a manufacturer is likely to offer both constrained and non-constrained devices, so there may in practice be no situation in which the MASA could be CoAP-only. Additionally, as the MASA is intended to be a function that can easily be oursourced to a third-party service provider, reducing the complexity would also seem to reduce the cost of that function.
-
security-related considerations: see {{security-masa-coaps}}.
If the PVR contains a proximity assertion, the Registrar MUST propagate this assertion into the RVR by including the "assertion" field with the value "proximity". This conforms to the example in {{Section 3.3 of RFC8995}} of carrying the assertion forward.
A TLS/HTTPS connection is established between the Registrar and MASA.
{{Section 5.4 of RFC8995}} explains this process, and there are no externally visible changes. A MASA that supports the unconstrained voucher formats should be able to support constrained voucher formats equally well.
There is no requirement that a single MASA be used for both constrained and unconstrained voucher requests: the choice of MASA is determined by the id-mod-MASAURLExtn2016 extension contained in the IDevID.
The Registrar MUST do DNS-ID checks ({{RFC9525}}) on the contents of the certificate provided by the MASA.
In constrast to the Pledge/Registrar situation, the Registrar always knows the name of the MASA, and MUST always include an {{RFC6066}} Server Name Indicator. The SNI is optional in TLS1.2, but common. The SNI it considered mandatory with TLS1.3.
The presence of the SNI is needed by the MASA, in order for the MASA's server to host multiple tenants (for different customers).
The Registrar SHOULD use a TLS Client Certificate to authenticate to the MASA per {{Section 5.4.1 of RFC8995}}. If the certificate that the Registrar uses is marked as a id-kp-cmcRA certificate, via Extended Key Usage, then it MUST also have the id-kp-clientAuth EKU attribute set.
In summary for typical Registrar use, where a single Registrar certificate is used, then the certificate MUST have EKU of: id-kp-cmcRA, id-kp-serverAuth, id-kp-clientAuth.
The voucher is a statement by the MASA for use by the Pledge that provides the identity of the Pledge's owner. This section describes how the owner's identity is determined and how it is specified within the voucher.
{{Section 5.5 of RFC8995}} describes BRSKI policies for selection of the owner identity. It indicates some of the flexibility that is possible for the Registrar, and recommends the Registrar to include only certificates in the voucher request (CMS) signing structure that participate in the certificate chain that is to be pinned.
The MASA is expected to evaluate the certificates included by the Registrar in its voucher request, forming them into a chain with the Registrar's (signing) identity on one end. Then, it pins a certificate selected from the chain. For instance, for a domain with a two-level certification authority (see {{fig-twoca}}), where the voucher request has been signed by "Registrar", its signing structure includes two additional CA certificates. The arrows in the figure indicate the issuing of a certificate, i.e. author of (1) issued (2) and author of (2) issued (3).
{::include two-ca-chain.txt}
{: #fig-twoca title='Two-Level CA PKI'}
When the Registrar is using a COSE-signed constrained voucher request towards MASA, instead of a regular CMS-signed voucher request, the COSE_Sign1 object contains a protected and an unprotected header. The Registrar MUST place all the certificates needed to validate the signature chain from the Registrar on the RVR in an "x5bag" attribute in the unprotected header as defined in {{RFC9360}}.
The "x5bag" attribute is very important as it provides the required signals from the Registrar to control what identity is pinned in the resulting voucher. This is explained in the next section.
The MASA, having assembled and verified the chain in the signing structure of the voucher request needs to select a certificate to pin. (For the case that only the Registrar's End-Entity certificate is included, only this certificate can be selected and this section does not apply.) The BRSKI policy for pinning by the MASA as described in {{Section 5.5.2 of RFC8995}} leaves much flexibility to the manufacturer.
The present document adds the following rules to the MASA pinning policy to reduce the network load on the constrained network side:
- for a voucher containing a nonce, it SHOULD select the most specific (lowest-level) CA certificate in the chain.
- for a nonceless voucher, it SHOULD select the least-specific (highest-level) CA certificate in the chain that is allowed under the MASA's policy for this specific domain.
The rationale for 1. is that in case of a voucher with nonce, the voucher is valid only in scope of the present DTLS connection between Pledge and Registrar anyway, so there is no benefit to pin a higher-level CA. By pinning the most specific CA the constrained Pledge can validate its DTLS connection using less crypto operations. The rationale for pinning a CA instead of the Registrar's End-Entity certificate directly is based on the following benefit on constrained networks: the pinned certificate in the voucher can in common cases be re-used as a Domain CA trust anchor during the EST enrollment and during the operational phase that follows after EST enrollment, as explained in {{brski-est-extensions-pledge}}.
The rationale for 2. follows from the flexible BRSKI trust model for, and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of {{RFC8995}}).
Refering to {{fig-twoca}} of a domain with a two-level certification authority, the most specific CA ("Sub-CA") is the identity that is pinned by MASA in a nonced voucher. A Registrar that wished to have only the Registrar's End-Entity certificate pinned would omit the "domain CA" and "Sub-CA" certificates from the voucher request.
In case of a nonceless voucher, depending on the trust level, the MASA pins the "Registrar" certificate (low trust in customer), or the "Sub-CA" certificate (in case of medium trust, implying that any Registrar of that sub-domain is acceptable), or even the "domain CA" certificate (in case of high trust in the customer, and possibly a pre-agreed need of the customer to obtain flexible long-lived vouchers).
Specifically for the most-constrained use cases, the pinning of the raw public key (RPK) of the Registrar is also supported in the constrained voucher, instead of a PKIX certificate. This is used by the RPK variant of cBRSKI described in {{rpk-considerations}}, but it can also be used in the default cBRSKI flow as a means to reduce voucher size.
For both cases, if an RPK is pinned, it MUST be the RPK of the Registrar.
When the Pledge is known by MASA to support the RPK variant only, the voucher produced by the MASA pins the RPK of the Registrar in either the "pinned-domain-pubk" or "pinned-domain-pubk-sha256" field of the voucher data. This is described in more detail in {{RFC8366bis}} and {{rpk-considerations}}.
When the Pledge is known by MASA to support PKIX certificates, the "pinned-domain-cert" field present in a voucher normally pins a domain certificate. That can be either the End-Entity certificate of the Registrar, or the certificate of a domain CA of the Registrar's domain as specified in {{masa-pinning-policy}}. However, if the Pledge is known by MASA to also support RPK pinning and the MASA intends to pin the Registrar in the voucher (and not the CA), then MASA SHOULD pin the RPK (RPK3 in {{fig-pinning}}) of the Registrar instead of the Registrar's End-Entity certificate to save space in the voucher.
{::include pinning-options.txt}
{: #fig-pinning title='Raw Public Key (RPK) pinning examples'}
{{RFC8366bis}} and {{RFC8995}} define the idevid-issuer attribute for voucher and voucher-request (respectively), but they summarily explain when to use it.
The use of idevid-issuer is provided so that the serial-number to which the issued voucher pertains can be relative to the entity that issued the devices' IDevID. In most cases there is a one to one relationship between the trust anchor that signs vouchers (and is trusted by the pledge), and the Certification Authority that signs the IDevID. In that case, the serial-number in the voucher data must refer to the same device as the serial-number that is in the IDevID certificate.
However, there situations where the one to one relationship may be broken. This occurs whenever a manufacturer has a common MASA, but different products (on different assembly lines) are produced with identical serial numbers. A system of serial numbers which is just a simple counter is a good example of this. A system of serial numbers where there is some prefix relating the product type does not fit into this, even if the lower digits are a counter.
It is not possible for the Pledge or the Registrar to know which situation applies. The question to be answered is whether or not to include the idevid-issuer in the PVR and the RVR. A second question arises as to what the format of the idevid-issuer contents are.
Analysis of the situation shows that the pledge never needs to include the idevid-issuer in it's PVR, because the pledge's IDevID certificate is available to the Registrar, and the Authority Key Identifier is contained within that IDevID certificate. The pledge therefore has no need to repeat this.
For the RVR, the Registrar has to examine the pledge's IDevID certificate to discover the serial number for the Registrar's Voucher Request (RVR). This is clear in {{Section 5.5 of RFC8995}}. That section also clarifies that the idevid-issuer is to be included in the RVR.
Concerning the Authority Key Identifier, {{RFC8366bis}} specifies that the entire object i.e. the extnValue OCTET STRING is to be included: comprising the AuthorityKeyIdentifier, SEQUENCE, Choice as well as the OCTET STRING that is the keyIdentifier.
The YANG ({{RFC7950}}) module and CBOR serialization for the constrained voucher as used by cBRSKI are described in {{RFC8366bis}}. That document also assigns SID values to YANG elements in accordance with {{I-D.ietf-core-sid}}. The present section provides some examples of these artifacts and defines a new signature format for these, using COSE.
Compared to the first voucher request definition done in {{RFC8995}}, the constrained voucher request adds the fields proximity-registrar-pubk and proximity-registrar-pubk-sha256. One of these is optionally used to replace the proximity-registrar-cert field, for a smaller voucher data size - useful for the most constrained cases.
The constrained voucher adds the fields pinned-domain-pubk and pinned-domain-pubk-sha256. One of these is optionally used instead of the pinned-domain-cert field, for a smaller voucher data size.
Below, example voucher data from a constrained voucher request (PVR) from a Pledge to a Registrar is shown in CBOR diagnostic notation. Long CBOR byte strings have been shortened for readability, using the ellipsis ("...") to indicate elided bytes. This notation is defined in {{I-D.ietf-cbor-edn-literals}}. The enum value of the assertion field is 2 for the "proximity" assertion as defined in {{Section 6.3 of RFC8366bis}}.
INSERT_CBORDIAG_FROM_FILE examples/voucher-request-example1.txt END
The Pledge has included the item proximity-registrar-pubk which carries the public key of the Registrar, instead of including the full Registrar certificate in a proximity-registrar-cert item. This is done to reduce the size of the PVR. Also note that the Pledge did not include the created-on field since it lacks an internal real-time clock and has no knowledge of the current time at the moment of performing the onboarding.
Next, example voucher data from a constrained voucher request (RVR) from a Registrar to a MASA is shown in CBOR diagnostic notation. The Registrar has created this request triggered by the reception of the Pledge voucher request (PVR) of the previous example. Again, long CBOR byte strings have been shortened for readability.
INSERT_CBORDIAG_FROM_FILE examples/voucher-request-example2.txt END
Note that the Registrar uses here the string data type for all key names, instead of the more compact SID integer keys. This is fine for any use cases where the network between Registrar and MASA is an unconstrained network where data size is not critical. The constrained voucher request format supports both the string and SID key types.
Below, an example of constrained voucher data is shown in CBOR diagnostic notation. It was created by a MASA in response to receiving the Registrar Voucher Request (RVR) shown in {{example-rvr}}. The enum value of the assertion field is set to 2, to acknowledge to both the Pledge and the Registrar that the proximity of the Pledge to the Registrar is considered proven.
INSERT_CBORDIAG_FROM_FILE examples/voucher-example1.txt END
While the above example voucher data includes the nonce from the PVR, the next example is for a nonce-less voucher. Instead of a nonce, it includes an expires-on field with the date and time on which the voucher expires. Because the MASA did not verify the proximity of the Pledge and Registrar in this case, the assertion field contains a weaker assertion of "verified" (0). This indicates that the MASA verified the domain's ownership of the Pledge via some other means. The enum value of the assertion field for "verified" is calculated to be 0 by following the algorithm described in section 9.6.4.2 of {{RFC7950}}.
INSERT_CBORDIAG_FROM_FILE examples/voucher-example2.txt END
The voucher is valid for one week. To verify the voucher's validity, the Pledge would either need an internal real-time clock or some external means of obtaining the current time, such as Network Time Protocol (NTP) or a radio time signal receiver.
The COSE_Sign1 structure is discussed in {{Section 4.2 of RFC9052}}. The CBOR object that carries the body, the signature, and the information about the body and signature is called the COSE_Sign1 structure. It is used when only one signature is used on the body.
Support for ECDSA with SHA2-256 using curve secp256r1 (aka prime256k1) is RECOMMENDED. Most current low power hardware has support for acceleration of this algorithm. Future hardware designs could omit this in favour of a newer algorithms. This is the ES256 keytype from Table 1 of {{RFC9053}}. Support for curve secp256k1 is OPTIONAL.
Support for EdDSA using Curve 25519 is RECOMMENDED in new designs if hardware support is available. This is keytype EDDSA (-8) from Table 2 of {{RFC9053}}. A "crv" parameter is necessary to specify the Curve, which from Table 18. The 'kty' field MUST be present, and it MUST be 'OKP'. (Table 17)
A transition towards EdDSA is occurring in the industry. Some hardware can accelerate only some algorithms with specific curves, other hardware can accelerate any curve, and still other kinds of hardware provide a tool kit for acceleration of any eliptic curve algorithm.
In general, the Pledge is expected to support only a single algorithm, while the Registrar, usually not constrained, is expected to support a wide variety of algorithms: both legacy ones and up-and-coming ones via regular software updates.
An example of the supported COSE_Sign1 object structure containing a Pledge Voucher Request (PVR) is shown in {{fig-cose}}.
18( / tag for COSE_Sign1 /
[
h'A10126', / protected COSE header encoding: {1: -7} /
/ which means { "alg": ES256 } /
{}, / unprotected COSE header parameters /
h'A119' ... '3839', / voucher-request binary content (in CBOR)/
h'4567' ... '1234' / voucher-request binary Sign1 signature /
]
)
{: #fig-cose title='COSE_Sign1 PVR example in CBOR diagnostic notation' align="left"}
The {{COSE-registry}} specifies the integers/encoding for the "alg" field in {{fig-cose}}. The "alg" field restricts the key usage for verification of this COSE object to a particular cryptographic algorithm.
A Registrar MUST include a COSE "x5bag" structure in the RVR as explained in {{registrar-identity}}. {{fig-cose-rvr}} shows an example Registrar Voucher Request (RVR) that includes the x5bag as an unprotected header parameter (32). The bag contains two certificates in this case.
18( / tag for COSE_Sign1 /
[
h'A10126', / protected COSE header encoding: {1: -7} /
/ which means { "alg": ES256 } /
{
32: [h'308202' ... '20AE', h'308201' ... '8CFF'] / x5bag /
},
h'A178' ... '7FED', / voucher-request binary content (in CBOR)/
h'E1B7' ... '2925' / voucher-request binary Sign1 signature /
]
)
{: #fig-cose-rvr title='COSE_Sign1 RVR example in CBOR diagnostic notation' align="left"}
A "kid" (key ID) field is optionally present in the unprotected COSE header parameters map of a COSE object. If present, it identifies the public key of the key pair that was used to sign the COSE message. The value of the key identifier "kid" parameter may be in any format agreed between signer and verifier. Usually a hash of the public key is used to identify the public key; but the choice of key identifier method is vendor-specific. If "kid" is not present, then a verifying party needs to use other context information to retrieve the right public key to verify the COSE_Sign1 object against.
By default, a Registrar does not include a "kid" parameter in the RVR since the signing key is already identified by the signing certificates included in the COSE "x5bag" structure. A Registrar nevertheless MAY use a "kid" parameter in its RVR to identify its signing key/identity.
The method of generating such "kid" value is vendor-specific and SHOULD be configurable in the Registrar to support commonly used methods. In order to support future business cases and supply chain integrations, a Registrar using the "kid" field MUST be configurable, on a per-manufacturer basis, to select a particular method for generating the "kid" value such that it is compatible with the method that the manufacturer expects. Note that the "kid" field always has a CBOR byte string (bstr) format.
Like in the RVR, a "kid" (key ID) field is also optionally present in the PVR. It can be used to identify the signing key/identity to the MASA.
A Pledge by default SHOULD NOT use a "kid" parameter in its PVR, because its signing key is already identified by the Pledge's unique serial number that is included in the PVR and (by the Registrar) in the RVR. This achieves the smallest possible PVR data size while still enabling the MASA to verify the PVR. Still, when required the Pledge MAY use a "kid" parameter in its PVR to help the MASA identify the right public key to verify against. This can occur for example if a Pledge has multiple IDevID identities. The "kid" parameter in this case may be an integer byte identifying one out of N identities present, or it may be a hash of the public key, or anything else the Pledge vendor decides. A Registrar normally SHOULD ignore a "kid" parameter used in a received PVR, as this information is intended for the MASA. In other words, there is no need for the Registrar to verify the contents of this field, but it may include it in an audit log.
The example in {{fig-cose-pvr-kid}} shows a PVR with the "kid" parameter present.
18( / tag for COSE_Sign1 /
[
h'A10126', / protected COSE header encoding: {1: -7} /
/ which means { "alg": ES256 } /
{
4: h'59AB3E' / COSE "kid" header parameter /
},
h'A119' ... '3839', / voucher-request binary content (in CBOR)/
h'5678' ... '7890' / voucher-request binary Sign1 signature /
]
)
{: #fig-cose-pvr-kid title='COSE_Sign1 PVR example with "kid" field present' align="left"}
The Pledge SHOULD NOT use the "x5bag" structure in the PVR. A Registrar that processes a PVR with an "x5bag" structure MUST ignore it, and MUST use only the TLS Client Certificate extension for authentication of the Pledge.
A situation where the Pledge MAY use the x5bag structure is for communication of certificate chains to the MASA. This would arise in some vendor- specific situations involving outsourcing of MASA functionality, or rekeying of the IDevID certification authority.
In {{cosesign}} further examples of signed PVRs are shown.
The MASA SHOULD NOT use a "kid" parameter in the voucher response, because the MASA's signing key is already known to the Pledge. Still, where needed the MASA MAY use a "kid" parameter in the voucher response to help the Pledge identify the right MASA public key to verify against. This can occur for example if a Pledge has multiple IDevID identities.
The MASA SHOULD NOT include an x5bag attribute in the voucher response - the exception is if the MASA knows that the Pledge doesn't pre-store the signing public key and certificate, and thus the MASA needs to provide a cert or cert chain that will enable linking the signing identity to the pre-stored Trust Anchor (CA) in the Pledge. This approach is not recommended, because including certificates in the x5bag attribute will significantly increase the size of the voucher which impacts operations on constrained networks.
If the MASA signing key is based upon a PKI (see {{I-D.richardson-anima-masa-considerations}} Section 2.3), and the Pledge only pre-stores a manufacturer (root) CA identity in its Trust Store which is not the identity that signs the voucher, then a certificate chain needs to be included with the voucher in order for the Pledge to validate the MASA signing CA's signature by validating the chain up to the CA in its Trust Store.
In BRSKI CMS signed vouchers {{RFC8995}}, the CMS structure has a place for such certificates. In the COSE-signed constrained vouchers described in this document, the x5bag attribute {{RFC9360}} is used to contain the needed certificates to form the chain. A Registrar MUST NOT remove the x5bag attribute from the unprotected COSE header parameters when sending the voucher back to the Pledge.
In {{fig-cose-voucher}} an example is shown of a COSE-signed voucher. This example shows the common case where the "x5bag" attribute is not used.
18( / tag for COSE_Sign1 /
[
h'A10126', / protected COSE header encoding: {1: -7}/
/ which means { "alg": ES256 }/
{}, / unprotected COSE header parameters /
h'A119' ... '3839', / voucher data (binary CBOR) /
h'2A2C' ... '7FBF' / voucher binary Sign1 signature by MASA /
]
)
{: #fig-cose-voucher title='COSE_Sign1 signed voucher in CBOR diagnostic notation' align="left"}
It is assumed that a Join Proxy ({{joinproxy}}) seamlessly provides a relayed DTLS connection between the Pledge and the Registrar. To use a Join Proxy, a Pledge needs to discover it. For Pledge discovery of a Join Proxy, this section extends Section 4.1 of {{RFC8995}} for the cBRSKI case.
In general, the Pledge may be one or more hops away from the Registrar, where one hop means the Registrar is a direct link-local neighbor of the Pledge. The case of one hop away can be considered as a degenerate case, because a Join Proxy is not really needed then.
The degenerate case would be unusual in constrained wireless network deployments, because a Registrar would typically not have a wireless network interface of the type used for constrained devices. Rather, it would have a high-speed network interface. Nevertheless, the situation where the Registrar is one hop away from the Pledge could occur in various cases like wired IoT networks or in wireless constrained networks where the Pledge is in radio range of a 6LoWPAN Border Router (6LBR) and the 6LBR happens to host a Registrar.
In order to support the degenerate case, the Registrar SHOULD announce itself as if it were a Join Proxy -- though it would actually announce its real (stateful) Registrar CoAPS endpoint. No actual Join Proxy functionality is then required on the Registrar.
That way, a Pledge only needs to discover a Join Proxy, regardless of whether it is one or more than one hop away from a relevant Registrar. It first discovers the link-local address and the join-port of a Join Proxy. The Pledge then follows the cBRSKI procedure of initiating a DTLS connection using the link-local address and join-port of the Join Proxy.
Once enrolled, a Pledge itself may function as a Join Proxy. The decision whether or not to provide this functionality depends upon many factors and is out of scope for this document. Such a decision might depend upon the amount of energy available to the device, the network bandwidth available, as well as CPU and memory availability.
The process by which a Pledge discovers the Join Proxy, and how a Join Proxy discovers the location of the Registrar, are the subject of the remainder of this section. Further details on both these topics are provided in {{I-D.ietf-anima-constrained-join-proxy}}.
The Pledge must discover the address/port and optionally the protocol with which to communicate. The present document only defines coaps (CoAP over DTLS) as the default protocol for cBRSKI, therefore protocol discovery is out of scope.
For the discovery method, this section only defines unsecured CoAP discovery per {{Section 7 of RFC7252}} as the default method. This uses CoRE Link Format {{RFC6690}} payloads.
{{discovery-considerations}} briefly mentions other methods that apply to specific deployment types or technologies. Details about these deployment-specific methods, or yet other methods, new payload formats, or more elaborate CoAP-based methods, may be defined in future documents such as {{I-D.eckert-anima-brski-discovery}}. The more elaborate methods for example may include discovering only Join Proxies that support a particular desired onboarding protocol, voucher format, or cBRSKI variant.
Note that identifying the format of the voucher request and the voucher is currently not a required part of the Pledge's discovery operation. It is assumed that all Registrars support all relevant voucher(-request) formats, while the Pledge only supports a single format. A Pledge that makes a voucher request to a Registrar that does not support that format will receive a CoAP 4.06 Not Acceptable status code and the onboarding attempt will fail.
Using CoAP discovery, a Pledge can discover a Join Proxy by sending a link-local multicast discovery message to the All CoAP Nodes address FF02::FD. Zero, one, or multiple Constrained Join Proxies may respond. The handling of multiple responses and absence of responses cases follow the guidelines of Section 4 of [RFC8995]. The discovery message is a CoAP GET request on the URI path "/.well-known/core" using a URI query "rt=brski.jp". This resource type (rt) is defined in {{Section 8.3 of I-D.ietf-anima-constrained-join-proxy}}.
Below, a typical example is provided showing the Pledge's CoAP request and the Join Proxy's CoAP response. The Join Proxy responds with a link-local source address, which is the same address as indicated in the URI-reference element ({{RFC6690}}) in the discovery response payload. The Join Proxy has a dedicated port 8485 open for DTLS connections of Pledges.
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
The next example shows a Join Proxy that uses the default CoAPS port 5684 for DTLS connections of Pledges. In this case, the Join Proxy host is not using port 5684 for any other purposes, so it has the port available for this purpose.
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski.jp
RES: 2.05 Content
<coaps://[fe80::c78:e3c4:58a0:a4ad]>;rt=brski.jp
In the following example, two Join Proxies respond to the multicast query. The Join Proxies each use a slightly different CoRE Link Format 'rt' value encoding. While the first encoding is more compact, both encodings are allowed per {{RFC6690}}. The Pledge may now select one of the two Join Proxies for initiating its DTLS connection.
REQ: GET coap://[ff02::fd]/.well-known/core?rt=brski*
RES: 2.05 Content
<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
RES: 2.05 Content
<coaps://[fe80::d359:3813:f382:3b23]:63245>;rt="brski.jp"
A Join Proxy needs to discover a Registrar, either at the moment it needs to relay data (of a Pledge) towards the Registrar, or prior to that moment. For example, it may start Registrar discovery as soon as it is requested to be enabled in a Join Proxy role. It may periodically redo this discovery, or periodically or on-demand check that the Registrar is still available in the network at the discovered IP address.
Further details on CoAP discovery of the Registrar by a Join Proxy are provided in {{Section 5.1.1 of I-D.ietf-anima-constrained-join-proxy}}.
This section details how discovery of a Join Proxy is done by the Pledge in specific deployment scenarios. Future work such as {{I-D.eckert-anima-brski-discovery}} may define more details on discovery operations in the specific deployments listed here.
In 6TiSCH networks, the Constrained Join Proxy (CoJP) mechanism is used as described in {{RFC9031}}. Such networks are expected to use {{-EDHOC}} for key management. This is the subject of future work. The Enhanced Beacon has been extended in {{RFC9032}} to allow for discovery of a 6TiSCH-compliant Join Proxy.
In IP networks that support GRASP {{RFC8990}}, a Pledge can discover a Join Proxy by listening for GRASP messages. GRASP supports mesh networks, and can also be used over unencrypted Wi-Fi.
Details of GRASP discovery of Constrained Join Proxies are out of scope of this document and may be defined in future work.
{{RFC8995}} defines a mechanism for the Pledge to discover a Join Proxy by sending mDNS {{RFC6762}} queries. This mechanism can be used on any IP network which does not have another recommended mechanism. It can be used over unencrypted Wi-Fi. This mechanism does support link-local Join Proxy discovery in mesh networks. However, it does not support Registrar discovery by Join Proxies in mesh networks, because the Registrar is typically not reachable by link-local communication in that case. For this, another mechanism is needed, which is out of scope of this document and may be defined in future work.
A Pledge uses an mDNS PTR query for the name "_brski-proxy._udp.local." to discover link-local Constrained Join Proxies. The label "_udp" here indicates a query for cBRSKI Constrained Join Proxies, as opposed to "_tcp" defined in {{RFC8995}} which is for discovering BRSKI Join Proxies.
Thread {{Thread}} is a wireless mesh network protocol based on 6LoWPAN {{RFC6282}} and other IETF protocols. In Thread, a new device discovers potential Thread networks and Thread routers to join by using the Mesh Link Establishment (MLE) {{I-D.ietf-6lo-mesh-link-establishment}} protocol. MLE uses the UDP port number 19788. The new device sends discovery requests on different IEEE 802.15.4 radio channels, to which routers (if any present) respond with a discovery response containing information about their respective network. Once a suitable router is selected the new device initiates a DTLS transport-layer secured connection to the network's commissioning application, over a link-local single radio hop to the selected Thread router. This link is not yet secured at the radio/MAC link layer: link-layer security will be set up once the new device is approved by the commissioning application to join the Thread network, and it gets provisioned with network access credentials.
The Thread router acts here as a Join Proxy. The MLE discovery response message contains UDP port information to signal the new device which port to use for its DTLS connection to the Join Proxy function. The link-local IPv6 source address of the MLE response message indicates the address of the Join Proxy.
The design considerations for vouchers from {{Section 8 of RFC8366bis}} apply. Specifically for CBOR encoding of voucher data, one key difference with JSON encoding is that the names of the leaves in the YANG definition do not affect the size of the resulting CBOR, as the SID ({{I-D.ietf-core-sid}}) translation process assigns integers to the names.
To obtain the lowest code size and RAM use on the Pledge, it is recommended that a Pledge is designed to only process/generate these SID integers and not the lengthy strings. The MASA in that case is required to generate the voucher data for that Pledge using only SID integers. Yet, this MASA implementation MUST still support both SID integers and strings, to be able to process the field names in the RVR.
Any POST request to the Registrar with resource /vs or /es returns a 2.04 Changed response with empty payload. The client should be aware that the server may use a piggybacked CoAP response (ACK, 2.04) but may also respond with a separate CoAP response, i.e. first an (ACK, 0.0) that is an acknowledgement of the request reception followed by a (CON, 2.04) response in a separate CoAP message. See {{RFC7252}} for details.
This specification contains two extensions to {{RFC8995}}: a constrained voucher format (COSE), and a constrained transfer protocol (CoAP).
On constrained networks with constrained devices, it make senses to use both together. However, this document does not mandate that this be the only way.
A given constrained device design and software may be re-used for multiple device models, such as a model having only an IEEE 802.15.4 radio, or a model having only an IEEE 802.11 (Wi-Fi) radio, or a model having both these radios. A manufacturer of such device models may wish to have code only for the use of the constrained voucher format (COSE), and use it on all supported radios including the IEEE 802.11 radio. For this radio, the software stack to support HTTP/TLS may be already integrated into the radio module hence it is attractive for the manufacturer to reuse this. This type of approach is supported by this document. In the case that HTTPS is used, the regular long {{RFC8995}} resource names are used, together with the new "application/voucher+cose" media type described in this document. For status telemetry requests, the Pledge may use either one or both of the formats defined in {{telemetry}}. A Registrar MUST support both formats.
Other combinations are possible, but they are not enumerated here. New work such as {{I-D.ietf-anima-jws-voucher}} provides new formats that may be useable over a number of different transports. In general, sending larger payloads over constrained networks makes less sense, while sending smaller payloads over unconstrained networks is perfectly acceptable.
The Pledge will in most cases support a single voucher format, which it uses without negotiation i.e. without discovery of formats supported. The Registrar, being unconstrained, is expected to support all voucher formats. There will be cases where a Registrar does not support a new format that a new Pledge uses, and this is an unfortunate situation that will result in lack of interoperation.
The responsability for supporting new formats is on the Registrar.
This section introduces a cBRSKI variant to further reduce the data volume and complexity of the cBRSKI onboarding. The use of a raw public key (RPK) in the pinning process can significantly reduce the number of bytes sent over the wire and the number of round trips, and reduce the code footprint in a Pledge. But it comes with a few significant operational limitations.
One simplification that comes with RPK use is that a Pledge can avoid doing PKIX certificate operations, such as certificate chain validation.
When the Pledge first connects to the Registrar, the connection to the Registrar is provisional, as explained in {{Section 5.6.2 of RFC8995}}. The Registrar normally provides its public key in a TLSServerCertificate, and the Pledge uses that to validate that integrity of the (D)TLS connection, but it does not validate the identity of the provided certificate.
As the TLSServerCertificate object is never verified directly by the Pledge, sending it can be considered superfluous. So instead of using a (TLSServer)Certificate of type X509 (see section 4.4.2 of {{RFC8446}}), a RawPublicKey object (as defined by {{RFC7250}}) is used.
A Registrar operating in a mixed environment can determine whether to send a Certificate or a Raw Public Key to the Pledge: this is signaled by the Pledge. In the case it needs an RPK, it includes the server_certificate_type of RawPublicKey. This is shown in section 5 of {{RFC7250}}.
The Pledge MUST send a client_certificate_type of X509 (not an RPK), so that the Registrar can properly identify the Pledge and distill the MASA URI information from its IDevID certificate.
The Pledge puts the Registrar's public key into the proximity-registrar-pubk field of the Pledge Voucher Request (PVR). (The proximity-registrar-pubk-sha256 can alternatively be used for efficiency, if the 32-bytes of a SHA256 hash turns out to be smaller than a typical ECDSA key.)
As the format of this pubk field is identical to the TLS RawPublicKey data object, no manipulation at all is needed to insert this field into the PVR. This approach reduces the size of the PVR significantly.
A returned voucher will have a pinned-domain-pubk field with the identical key as was found in the proximity-registrar-pubk field above, as well as being identical to the Registrar's RPK in the currently active DTLS connection. (Or alternatively the MASA may include the "pinned-domain-pubk-sha256" field if it knows the Pledge supports this field.)
Validation of this key by the Pledge is what takes the DTLS connection out of the provisional state; see {{Section 5.6.2 of RFC8995}} for more details.
The received voucher needs to be validated first by the Pledge. The Pledge needs to have a public key to validate the signature from the MASA on the voucher.
The MASA's public key counterpart of the (private) MASA signing key MUST be already installed in the Pledge at manufacturing time. Otherwise, the Pledge cannot validate the voucher's signature.
A Pledge that does not support PKIX operations cannot use EST to enroll; it has to use another method for enrollment without certificates and the Registrar has to support this method also. For example, an enrollment process that records an RPK owned by the Pledge as a legitimate entity that is part of the domain.
It is possible that the Pledge will not enroll after obtaining a valid voucher, but instead will do only a network join operation (see for example {{RFC9031}}). How the Pledge discovers this method and details of such enrollment methods are out of scope of this document.
In the absense of correct use of idevid-issuer by the Registrar as detailed in {{registrar-idevid-issuer}}, it would be possible for a malicious Registrar to use an unauthorized voucher for a device. This would apply only to the case where a Manufacturer Authorized Signing Authority (MASA) is trusted by different products from the same manufacturer, and the manufacturer has duplicated serial numbers as a result of a merge, acquisition or mis-management.
For example, imagine the same manufacturer makes light bulbs as well as gas centrifuges, and said manufacturer does not uniquely allocate product serial numbers. This attack only works for nonceless vouchers. The attacker has obtained a light bulb which happens to have the same serial-number as a gas centrifuge which it wishes to obtain access. The attacker performs a normal BRSKI onboarding for the light bulb, but then uses the resulting voucher to onboard the gas centrifuge. The attack requires that the gas centrifuge be returned to a state where it is willing to perform a new onboarding operation.
This attack is prevented by the mechanism of having the Registrar include the idevid-issuer in the RVR, and the MASA including it in the resulting voucher. The idevid-issuer is not included by default: a MASA needs to be aware if there are parts of the organization which duplicates serial numbers, and if so, include it.
The security of this protocol depends upon the Pledge identifying itself to the Registrar using it's manufacturer installed certificate: the IDevID certificate. Associated with this certificate is the IDevID private key, known only to the Pledge. Disclosure of this private key to an attacker would permit the attacker to impersonate the Pledge towards the Registrar, probably gaining access credentials to that Registrar's network.
If the IDevID private key disclosure is known to the manufacturer, there is little recourse other than recall of the relevant part numbers. The process for communicating this recall would be within the BRSKI-MASA protocol. Neither this specification nor {{RFC8995}} provides for consultation of a Certification Revocation List (CRL) or Open Certificate Status Protocol (OCSP) by a Registrar when evaluating an IDevID certificate. However, the BRSKI-MASA protocol submits the IDevID from the Registrar to the manufacturer's MASA and a manufacturer would have an opportunity to decline to issue a voucher for a device which they believe has become compromised.
It may be difficult for a manufacturer to determine when an IDevID private key has been disclosed. Two situations present themselves: in the first situation a compromised private key might be reused in a counterfeit device, which is sold to another customer. This would present itself as an onboarding of the same device in two different networks. The manufacturer may become suspicious seeing two voucher requests for the same device from different Registrars. Such activity could be indistinguishable from a device which has been resold from one operator to another, or re-deployed by an operator from one location to another.
In the second situation, an attacker having compromised the IDevID private key of a device might then install malware into the same device and attempt to return it to service. The device, now blank, would go through a second onboarding process with the original Registrar. Such a Registrar could notice that the device has been "factory reset" and alert the operator to this situation. One remedy against the presence of malware is through the use of Remote Attestation such as described in {{?I-D.ietf-rats-architecture}}. Future work will need to specify a background-check Attestation flow as part of the voucher-request/voucher-response process. Attestation may still require access to a private key (e.g. IDevID private key) in order to sign Evidence, so a primary goal should be to keep any private key safe within the Pledge.
In larger, more expensive, systems there is budget (power, space, and bill of materials) to include more specific defenses for a private key. For instance, this includes putting the IDevID private key in a Trusted Platform Module (TPM), or use of Trusted Execution Environments (TEE) for access to the key. On smaller IoT devices, the cost and power budget for an extra part is often prohibitive.
It is becoming more and more common for CPUs to have an internal set of one-time fuses that can be programmed (often they are "burnt" by a laser) at the factory. This section of memory is only accessible in some priviledged CPU state. The use of this kind of CPU is appropriate as it provides significant resistance against key disclosure even when the device can be disassembled by an attacker.
In a number of industry verticals, there is increasing concern about counterfeit parts. These may be look-alike parts created in a different factory, or parts which are created in the same factory during an illegal night-shift, but which are not subject to the appropriate level of quality control. The use of a manufacturer-signed IDevID certificate provides for discovery of the pedigree of each part, and this often justifies the cost of the security measures associated with storing the private key.
{{brski-masa-protocol-format}} explains that no CoAPS version of the BRSKI-MASA protocol is proposed. The connection from the Registrar to the MASA continues to be HTTPS as in {{RFC8995}}. This has been done to simplify the MASA deployment for the manufacturer, because no new protocol needs to be enabled on the server.
The use of UDP protocols across the open Internet is sometimes fraught with security challenges. Denial-of-service attacks against UDP based protocols are trivial as there is no three-way handshake as done for TCP. The three-way handshake of TCP guarantees that the node sending the connection request is reachable using the origin IP address. While DTLS contains an option to do a stateless challenge -- a process actually stronger than that done by TCP -- it is not yet common for this mechanism to be available in hardware at multigigabit speeds. It is for this reason that this document defines using HTTPS for the Registrar to MASA connection.
The provisional (D)TLS connection formed by the Pledge with the Registrar does not authenticate the Registrar's identity. This Registrar's identity is validated by the {{RFC8366bis}} voucher that is issued by the MASA, signed with an anchor that was built-in to the Pledge.
The Registrar may therefore use any certificate, including a self-signed one. The only restrictions on the certificate is that it MUST have EKU bits set as detailed in {{registrar-certificate-requirement-server}} and {{registrar-certificate-requirement-client}}.
In {{RFC8366bis, Section voucher-request-artifact}} two compact alternative fields for proximity-registrar-cert are defined that include an RPK: proximity-registrar-pubk and proximity-registrar-pubk-sha256. The Pledge can use these fields in its PVR to identify the Registrar based on its public key only. Since the full certificate of the proximate Registrar is not included, use of these fields by a Pledge implies that a Registrar could insert another certificate with the same public key identity into the RVR. For example, an older or a newer version of its certificate. The MASA will not be able to detect such act by the Registrar. But since any 'other' certificate the Registrar could insert in this way still encodes its identity the additional risk of using the RPK alternatives is neglible.
When a Registrar sees a PVR that uses one of proximity-registrar-pubk or proximity-registrar-pubk-sha256 fields, this implies the Registrar must include the certificate identified by these fields into its RVR. Otherwise, the MASA is unable to verify proximity. This requirement is already implied by the "MUST" requirement in {{registrar-identity}}.
The use of CoAP for the BRSKI-MASA connection is not in scope of the current document. The following security considerations have led to this choice of scope:
-
the technology and experience to build secure Internet-scale HTTPS responders (which the MASA is) is common, while the experience in doing the same for CoAP is much less common.
-
in many enterprise networks, outgoing UDP connections are often treated as suspicious, which could effectively block CoAP connections for some firewall configurations.
-
reducing the complexity of MASA (i.e. less protocols supported) would also reduce its potential attack surface, which is relevant since the MASA is 24/7 exposed on the Internet and accepting (untrusted) incoming connections.
Additions to the sub-registry "Resource Type Link Target Attribute Values", within the "CoRE Parameters" IANA registry are specified below.
Reference: [This RFC]
| Attribute | Description |
|---|---|
| brski | Root path of Bootstrapping Remote Secure Key Infrastructure (BRSKI) resources |
| brski.rv | BRSKI request voucher resource |
| brski.vs | BRSKI voucher status telemetry resource |
| brski.es | BRSKI enrollment status telemetry resource |
| {: #iana-core-rt-values title='Resource Type (rt) link target attribute values for IANA registration'} |
This section registers the media type "application/voucher+cose" in the IANA "Media Types" registry. This media type is used to indicate that the content is a CBOR voucher or voucher request signed with a COSE_Sign1 structure {{RFC9052}}.
Type name: application
Subtype name: voucher+cose
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary (CBOR)
Security considerations: Security Considerations of [This RFC].
Interoperability considerations: The format is designed to be
broadly interoperable.
Published specification: [This RFC]
Applications that use this media type: ANIMA, 6TiSCH, and other
zero-touch onboarding systems
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): .vch
Macintosh file type code(s): N/A
Person & email address to contact for further information: IETF
ANIMA Working Group ([email protected]) or IETF Operations and
Management Area Working Group ([email protected])
Intended usage: COMMON
Restrictions on usage: N/A
Author: ANIMA WG
Change controller: IETF
Provisional registration? (standards tree only): NO
IANA has allocated ID 836 from the sub-registry "CoAP Content-Formats".
Media type Encoding ID Reference
----------------------------- --------- ---- ----------
application/voucher+cose - 836 [This RFC]
This section updates the BRSKI Well-Known URIs sub-registry of the IANA Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters Registry by adding a new column "Short URI". The contents of this field MUST be specified for any newly registered URI as follows:
Short URI: A short name for the "URI" resource that can be used by a cBRSKI ([This RFC]) Pledge in a CoAP request to the Registrar. In case the "URI" resource is only used between Registrar and MASA, the value "--" is registered denoting that a short name is not applicable.
The initial contents of the sub-registry including the new column are as follows:
| URI | Short URI | Description | Reference requestvoucher | rv | Request voucher: Pledge to Registrar, and Registrar to MASA | [RFC8995], [This RFC] voucher_status | vs | Voucher status telemetry: Pledge to Registrar | [RFC8995], [This RFC] requestauditlog| -- | Request audit log: Registrar to MASA | [RFC8995] enrollstatus | es | Enrollment status telemetry: Pledge to Registrar | [RFC8995], [This RFC] {: #brski-wellknown-uri title='Update of the BRSKI Well-Known URI Sub-Registry'}
This section registers the "+cose" suffix in the IANA Structured Syntax Suffixes Registry based on the [RFC6838] procedure.
Name: CBOR Object Signing and Encryption (COSE) object
+suffix: +cose
References: the "application/cose" media type [RFC9052]
Encoding considerations: binary (CBOR)
Interoperability considerations:
the "application/cose" media type has an optional parameter
"cose-type". Any new media type that uses the +cose suffix
and allows use of this parameter MUST specify this
explicitly, per Section 4.3 of [RFC6838]. If the parameter
"cose-type" is allowed, its usage MUST be identical to the
usage defined for the "application/cose" media type in
Section 2 of [RFC9052].
A COSE processor handling a media type "foo+cose" and which
does not know the specific type "foo" SHOULD use the
cose-type tag, if present, or cose-type parameter, if
present, to determine the specific COSE object type during
processing. If the specific type cannot be determined,
it MUST assume only the generic COSE object structure and
it MUST NOT perform security-critical operations using the
COSE object.
Fragment identifier considerations: N/A
Security considerations: see [RFC9052]
Contact:
IETF COSE Working Group ([email protected]) or IESG
([email protected])
Author/Change controller:
IETF ANIMA Working Group ([email protected]).
IESG has change control over this registration.
We are very grateful to for explaining COSE/CMS choices and for correcting early versions of the COSE_Sign1 objects. did extensive work on pyang to extend it to support the SID allocation process, and this document was among its first users. , , , , and provided review feedback. The BRSKI design team has met on many Tuesdays and Thursdays for document review. The team includes: , , , , and . , and provided review feedback on the registration of the +cose structured syntax suffix.
-25: Moved all software/library support info into Appendix A and added "open source" section; Removed use of formal Extends/Amends Update-tags (#303, #304); Moved Section 14 to Appendix E (#302); Editorial improvements.
-24: Rephrased well-known URL requirement in 14.1 (#292, #293); Added paragraph on future certificate formats like C509 (#281, #294); Add formal specification for CoAP discovery of Join Proxy by Pledge, instead of only showing examples (#296, #300); Enable mDNS discovery of Join Proxy by Pledge (also in mesh networks) and list service name to use (#297, #299); Add requirement to support Content-Format 287 in /sen and /sren response (#295, #298).
-23:
Removed Update tag for RFC 8366 (#285, #288);
Introduced cBRSKI acronym (#284, #286);
Added Update tag for RFC 9148 (#283, #289);
Keep CoAP discovery as only mechanism and refer to future discovery work (#279, #282, #290);
Introduce formal CBOR diagnostics ellipsis elision syntax (#281, #287);
Support for multi-tier CAs by introducing multipart-core /crts format (#275, #291);
Terminology updated for consistency with RFC 8366-bis (#274, #280);
Rename voucher media type to application/voucher+cose and register +cose SSS (#264, #277);
Editorial changes including section restructuring.
-22:
Streamlined text to focus mostly on the default flow, with optional functions moved to their own sections (#269, #273);
For DTLS 1.3 client, use the record_size_limit extensions RFC 8449 (#270);
Editorial updates;
Reference rfc6125bis updated to RFC 9525.
-11 to -21:
(For change details see GitHub issues https://github.com/anima-wg/constrained-voucher/issues , related Pull Requests and commits.)
-10:
Design considerations extended; Examples made consistent.
-08:
Examples for cose_sign1 are completed and improved.
-06:
New SID values assigned; regenerated examples.
-04:
voucher and request-voucher MUST be signed;
examples for signed request are added in appendix;
IANA SID registration is updated;
SID values in examples are aligned;
signed cms examples aligned with new SIDs.
-03:
Examples are inverted.
-02:
Example of requestvoucher with unsigned appllication/cbor is added;
attributes of voucher "refined" to optional;
CBOR serialization of vouchers improved;
Discovery port numbers are specified.
-01:
application/json is optional, application/cbor is compulsory;
Cms and cose mediatypes are introduced.
-00:
Initial version.
--- back
#Software and Library Support for cBRSKI This appendix lists software and security libraries that may be useful for implementing cBRSKI functionality.
There are a few ongoing open source projects to support cBRSKI development and testing. These include:
- OpenThread Registrar (OT Registrar) - a cBRSKI Registrar, test MASA server, and test Pledge written in Java.
Link: https://github.com/EskoDijk/ot-registrar - OpenThread CCM (pre-alpha) - a cBRSKI Pledge and Join Proxy for OpenThread-based IoT nodes, written in C/C++.
Link: EskoDijk/openthread#7 - OpenThread Network Simulator v2 (OTNS2) - a CLI + GUI simulator for OpenThread IoT nodes in 6LoWPAN mesh networks, able to accurately simulate cBRSKI Pledges onboarding (pre-alpha functionality) to a Thread mesh network via an OT Registrar.
Link: EskoDijk/ot-ns#165 - Fountain - a BRSKI/6TiSCH Registrar with support for COSE-signed vouchers, written in Ruby.
Link: https://github.com/AnimaGUS-minerva/fountain
For the implementation of BRSKI/cBRSKI, the use of a software library to manipulate PKIX certificates, estabilish secure (D)TLS connections, and use crypto algorithms is often beneficial. Two C-based examples are OpenSSL and mbedtls. Others more targeted to specific platforms or languages exist. It is important to realize that the library interfaces differ significantly between libraries.
Libraries do not support all known crypto algorithms. Before deciding on a library, it is important to look at their supported crypto algorithms and the roadmap for future support. Apart from availability, the library footprint, and the required execution cycles should be investigated beforehand.
The handling of certificates usually includes the checking of a certificate chain. In some libraries, chains are constructed and verified on the basis of a set of certificates, the trust anchor (usually a self signed root CA), and the target certificate. In other libraries, the chain must be constructed beforehand and obey ordering criteria. Verification always includes the checking of the signatures. Less frequent is the checking the validity of the dates or checking the existence of a revoked certificate in the chain against a set of revoked certificates. Checking the chain on the consistency of the certificate extensions which specify the use of the certificate usually needs to be programmed explicitly.
A libary can be used to construct a (D)TLS connection. It is useful to realize that differences beetween (D)TLS implementations will occur due to the differences in the certicate checks supported by the library. On top of that, checks between client and server certificates enforced by (D)TLS are not always helpful for a BRSKI implementation. For example, the certificates of Pledge and Registrar are usually not related when the BRSKI protocol is started. It must be verified that checks on the relation between client and server certificates do not hamper a succeful DTLS connection establishment.
From openssl's apps/verify.c :
INSERT_C_FROM_FILE examples/openssl-verify.c END
INSERT_C_FROM_FILE examples/mbedtls-verify.c END
This informative appendix shows example Bash shell scripts to generate test PKIX certificates for the Pledge IDevID, the Registrar and the MASA. The shell scripts cannot be run stand-alone because they depend on input files which are not all included in this appendix. Nevertheless, these scripts may provide guidance on how OpenSSL can be configured for generating cBRSKI certificates.
The scripts were tested with OpenSSL 3.0.2. Older versions may not work -- OpenSSL 1.1.1 for example does not support all extensions used.
INSERT_SH_FROM_FILE examples/script-cose-examples/create-cert-Pledge.sh END INSERT_CODE_FROM_FILE examples/script-cose-examples/x509v3.ext END INSERT_SH_FROM_FILE examples/script-cose-examples/create-cert-Registrar.sh END INSERT_SH_FROM_FILE examples/script-cose-examples/create-cert-MASA.sh END
#cBRSKI Message Examples
This appendix extends the EST-coaps message examples from Appendix A of {{RFC9148}} with cBRSKI messages. The CoAP headers are only fully worked out for the first example, enrollstatus.
##enrollstatus {#es}
A coaps enrollstatus message from Pledge to Registrar can be as follows:
REQ: POST coaps://192.0.2.1:8085/b/es
Content-Format: 60
Payload: <binary CBOR encoding of an enrollstatus map>
The corresponding CoAP header fields for this request are shown below.
Ver = 1
T = 0 (CON)
TKL = 1
Code = 0x02 (0.02 is POST method)
Message ID = 0xab0f
Token = 0x4d
Options
Option (Uri-Path)
Option Delta = 0xb (option nr = 11)
Option Length = 0x1
Option Value = "b"
Option (Uri-Path)
Option Delta = 0x0 (option nr = 11)
Option Length = 0x2
Option Value = "es"
Option (Content-Format)
Option Delta = 0x1 (option nr = 12)
Option Length = 0x1
Option Value = 60 (application/cbor)
Payload Marker = 0xFF
Payload = A26776657273696F6E0166737461747573F5 (18 bytes binary)
The Uri-Host and Uri-Port Options are omitted because they coincide with the transport protocol (UDP) destination address and port respectively.
The above binary CBOR enrollstatus payload looks as follows in CBOR diagnostic notation, for the case of enrollment success:
{
"version": 1,
"status": true
}
Alternatively the payload could look as follows in case of enrollment failure, using the reason field to describe the failure:
Payload = A36776657273696F6E0166737461747573F466726561736F6E782A3C
496E666F726D61746976652068756D616E207265616461626C652065
72726F72206D6573736167653E (69 bytes binary)
{
"version": 1,
"status": false,
"reason": "<Informative human readable error message>"
}
To indicate successful reception of the enrollmentstatus telemetry report, a response from the Registrar may then be:
2.04 Changed
Which in case of a piggybacked response has the following CoAP header fields:
Ver=1
T=2 (ACK)
TKL=1
Code = 0x44 (2.04 Changed)
Message ID = 0xab0f
Token = 0x4d
##voucher_status
A coaps voucher_status message from Pledge to Registrar can be as follows:
REQ: POST coaps://[2001:db8::2:1]/.well-known/brski/vs
Content-Format: 60 (application/cbor)
Payload =
INSERT_TEXT_FROM_FILE examples/voucher-status.hex END
The request payload above is binary CBOR but represented here in hexadecimal for readability. Below is the equivalent CBOR diagnostic format.
INSERT_CBORDIAG_FROM_FILE examples/voucher-statusdiag.txt END
A success response without payload will then be sent by the Registrar back to the Pledge to indicate reception of the telemetry report:
2.04 Changed
This appendix provides examples of COSE-signed voucher requests and vouchers. First, the used test keys and PKIX certificates are described, followed by examples of a constrained PVR, RVR and voucher.
This section documents the public and private keys used for all examples in this appendix. These keys are not used in any production system, and must only be used for testing purposes.
INSERT_PEM_FROM_FILE examples/script-cose-examples/keys/privkey_pledge.pem END
INSERT_X509_FROM_FILE examples/cose-examples/privkey_pledge.txt END
INSERT_PEM_FROM_FILE examples/script-cose-examples/keys/privkey_registrar.pem END
INSERT_X509_FROM_FILE examples/cose-examples/privkey_registrar.txt END
INSERT_PEM_FROM_FILE examples/script-cose-examples/keys/privkey_masa_ca.pem END
INSERT_X509_FROM_FILE examples/cose-examples/privkey_masa_ca.txt END
All keys and PKIX certificates used for the examples have been generated with OpenSSL - see {{appendix-gencerts}} for more details on certificate generation. Below the certificates are listed that accompany the keys shown above. Each certificate description is followed by the hexadecimal representation of the X.509 ASN.1 DER encoded certificate. This representation can be for example decoded using an online ASN.1 decoder.
INSERT_X509_FROM_FILE examples/cose-examples/pledge.txt END
Below is the hexadecimal representation of the binary X.509 DER-encoded certificate:
INSERT_HEX_FROM_FILE examples/cose-examples/pledge.hex END
INSERT_X509_FROM_FILE examples/cose-examples/registrar.txt END
Below is the hexadecimal representation of the binary X.509 DER-encoded certificate:
INSERT_HEX_FROM_FILE examples/cose-examples/registrar.hex END
The Domain CA certificate is the CA of the owner's domain. It has signed the Registrar (RA) certificate.
INSERT_X509_FROM_FILE examples/cose-examples/domain_ca.txt END
Below is the hexadecimal representation of the binary X.509 DER-encoded certificate:
INSERT_HEX_FROM_FILE examples/cose-examples/domain_ca.hex END
The MASA CA certificate is the CA that signed the Pledge's IDevID certificate.
INSERT_X509_FROM_FILE examples/cose-examples/masa_ca.txt END
Below is the hexadecimal representation of the binary X.509 DER-encoded certificate:
INSERT_HEX_FROM_FILE examples/cose-examples/masa_ca.hex END
In this example, the voucher request (PVR) has been signed by the Pledge using the IDevID private key of {{pledgepriv}}, and has been sent to the link-local constrained Join Proxy (JP) over CoAPS to the JP's join port. The join port happens to use the default CoAPS UDP port 5684.
REQ: POST coaps://[JP-link-local-address]/b/rv
Content-Format: 836
Payload: <signed_pvr>
When the Join Proxy receives the DTLS handshake messages from the Pledge, it will relay these messages to the Registrar. The payload signed_voucher_request is shown as hexadecimal dump (with lf added) below:
INSERT_HEX_FROM_FILE examples/cose-examples/pvr.hex END
The representiation of signed_pvr in CBOR diagnostic format (with lf added) is:
INSERT_CBORDIAG_FROM_FILE examples/cose-examples/pvr.txt END
The COSE payload is the PVR voucher data, encoded as a CBOR byte string. The diagnostic representation of it is shown below:
INSERT_CBORDIAG_FROM_FILE examples/cose-examples/pvr-nonsigned.txt END
The Pledge uses the "proximity" (key '1', SID 2502, enum value 2) assertion together with an included proximity-registrar-pubk field (key '12', SID 2513) to inform MASA about its proximity to the specific Registrar.
In this example the Registrar's voucher request has been signed by the JRC (Registrar) using the private key from {{jrcpriv}}. Contained within this voucher request is the voucher request PVR that was made by the Pledge to JRC. Note that the RVR uses the HTTPS protocol (not CoAP) and corresponding long URI path names as defined in {{RFC8995}}. The Content-Type and Accept headers indicate the constrained voucher format that is defined in the present document. Because the Pledge used this format in the PVR, the JRC must also use this format in the RVR.
REQ: POST https://masa.stok.nl/.well-known/brski/requestvoucher
Content-Type: application/voucher+cose
Accept: application/voucher+cose
Body: <signed_rvr>
The payload signed_rvr is shown as hexadecimal dump (with lf added):
INSERT_HEX_FROM_FILE examples/cose-examples/rvr.hex END
The representation of signed_rvr in CBOR diagnostic format (with lf added) is:
INSERT_CBORDIAG_FROM_FILE examples/cose-examples/rvr.txt END
The resulting voucher is created by the MASA and returned to the Registrar:
RES: 200 OK
Content-Type: application/voucher+cose
Body: <signed_voucher>
The Registrar then returns the voucher to the Pledge:
RES: 2.04 Changed
Content-Format: 836
Body: <signed_voucher>
It is signed by the MASA's private key (see {{masapriv}}) and can be verified by the Pledge using the MASA's public key that it stores.
Below is the binary signed_voucher, encoded in hexadecimal (with lf added):
INSERT_HEX_FROM_FILE examples/cose-examples/voucher.hex END
The representiation of signed_voucher in CBOR diagnostic format (with lf added) is:
INSERT_CBORDIAG_FROM_FILE examples/cose-examples/voucher.txt END
In the above, the third element in the array is the voucher data encoded as a CBOR byte string. When decoded, it can be represented by the following CBOR diagnostic notation:
INSERT_CBORDIAG_FROM_FILE examples/cose-examples/voucher-nonsigned.txt END
The largest element in the voucher is identified by key 8, which decodes to SID 2459 (pinned-domain-cert). It contains the complete PKIX (DER-encoded X.509v3) certificate of the Registrar's domain CA. This certificate is shown in {{cose-example-domain-ca-cert}}.
This specification allows implementers to select between various functional options for the Pledge, yielding different code size footprints and different requirements on Pledge hardware. Thus for each product an optimal trade-off between functionality, development/maintenance cost and hardware cost can be made.
This appendix illustrates different selection outcomes by means of defining different example "profiles" of constrained Pledges. In the following subsections, these profiles are defined and a comparison is provided.
The Minimal Pledge profile (Min) aims to reduce code size and hardware cost to a minimum. This comes with some severe functional restrictions, in particular:
- No support for EST re-enrollment: whenever this would be needed, a factory reset followed by a new onboarding process is required.
- No support for change of Registrar: for this case, a factory reset followed by a new onboarding process is required.
This profile would be appropriate for single-use devices which must be replaced rather than re-deployed. That might include medical devices, but also sensors used during construction, such as concrete temperature sensors.
The Typical Pledge profile (Typ) aims to support a typical cBRSKI feature set including EST re-enrollment support and Registrar changes.
The Full-featured Pledge profile (Full) illustrates a Pledge category that supports multiple onboarding methods, hardware real-time clock, BRSKI/EST resource discovery, and CSR Attributes request/response. It also supports most of the optional features defined in this specification.
The below table specifies the functions implemented in the three example Pledge classes Min ({{profile-min}}), Typ ({{profile-typ}}) and Full ({{profile-full}}).
| Functions Implemented | Min | Typ | Full |
|---|---|---|---|
| General | |||
| Support cBRSKI onboarding | Y | Y | Y |
| Support other onboarding method(s) | - | - | Y |
| Real-time clock and cert time checks | - | - | Y |
| cBRSKI | |||
| Discovery for rt=brski* | - | - | Y |
| Support pinned Registrar public key (RPK) | Y | - | Y |
| Support pinned Registrar certificate | - | Y | Y |
| Support pinned Domain CA | - | Y | Y |
| EST-coaps | |||
| Explicit TA database size (#certs) | 0 | 3 | 8 |
| Discovery for rt=ace.est* | - | - | Y |
| GET /att and response parsing | - | - | Y |
| GET /crts format 62 (multiple CA certs) | - | Y | Y |
| GET /crts format 281 (multiple CA certs) | - | - | Y |
| ETag handling support for GET /crts | - | Y | Y |
| Re-enrollment supported | - (*) | Y | Y |
| 6.6.1 optimized procedure | Y | Y | - |
| Pro-active re-enrollment at own initiative | - | - | Y |
| Periodic trust anchor retrieval GET /crts | - (*) | Y | Y |
| Supports change of Registrar identity | - (*) | Y | Y |
Notes: (*) means only possible via a factory-reset followed by a new cBRSKI onboarding procedure.
The functionality described in this section is informative only. In typical cases, for a constrained Pledge that only supports a single onboarding and enrollment method, this functionality is not needed.
A Pledge that wishes to discover the available cBRSKI onboarding options/formats can do a discovery operation using CoAP discovery per {{Section 7 of RFC7252}} and {{Section 4 of RFC6690}}. It first sends a CoAP discovery query to the Registrar over the secured DTLS connection. The Registrar then responds with a CoRE Link Format payload containing the requested resources, if any.
For example, if the Registrar supports a short cBRSKI URL (/b) instead of just the longer "/.well-known" resources, and supports only the voucher format "application/voucher+cose" (836), and status reporting in both CBOR and JSON formats, a CoAP resource discovery request and response may look as follows:
REQ: GET /.well-known/core?rt=brski*
RES: 2.05 Content
Content-Format: 40
Payload:
</b>;rt=brski,
</b/rv>;rt=brski.rv;ct=836,
</b/vs>;rt=brski.vs;ct="50 60",
</b/es>;rt=brski.es;ct="50 60"
The Registrar is under no obligation to provide shorter URLs, and may respond to this query with only the "/.well-known/brski/<short-name>" resources for the short names as defined in {{brski-est-short-uri}}. This case is shown in the below interaction:
REQ: GET /.well-known/core?rt=brski*
RES: 2.05 Content
Content-Format: 40
Payload:
</.well-known/brski>;rt=brski,
</.well-known/brski/rv>;rt=brski.rv;ct=836,
</.well-known/brski/vs>;rt=brski.vs;ct="50 60",
</.well-known/brski/es>;rt=brski.es;ct="50 60"
When responding to a discovery request for cBRSKI resources, the Registrar may return the full resource paths for all <short-name> resources and the content types which are supported by these resources (using ct attributes) as shown in the above examples. This is useful when multiple content types are specified for a particular resource on the Registrar and the discovering Pledge also supports multiple.
Registrars that have implemented shorter URLs must process a request on the corresponding "/.well-known/brski/<short-name>" URL identically. In particular, a Pledge may use the longer (well-known) and shorter URLs in any combination.
A Registrar may also be implemented without support for the (optional) CoAP discovery. In that case, it may for example return a 4.04 Not Found as shown below. In such case, the Pledge cannot discover any onboarding/enrollment options and so it has to rely on the default cBRSKI options and has to use the /.well-known/brski and /.well-known/est resources.
REQ: GET /.well-known/core?rt=brski*
RES: 4.04 Not Found
In case the client queries for only rt=brski type resources, the Registrar responds with only the root path for the cBRSKI resources (rt=brski, resource /b in earlier examples) and no others. (So, a query for rt=brski, without the wildcard character.) This is shown in the below example. The Pledge in this case requests only the cBRSKI root resource of type rt=brski to check if cBRSKI is supported by the Registrar and if short names are supported or not. In this case, the Pledge is not interested to check what voucher request formats, or status telemetry formats -- other than the mandatory default formats -- are supported. The compact response then shows that the Registrar indeed supports a short-name cBRSKI resource at /b:
REQ: GET /.well-known/core?rt=brski
RES: 2.05 Content
Content-Format: 40
Payload:
</b>;rt=brski
The Pledge can now start using any of the cBRSKI resources /b/<short-name>. In above example, the well-known resource present under /.well-known/brski is not returned because this is assumed to be well-known to the Pledge and would not require discovery anyway.
As a follow-up example, the Pledge can now start the onboarding by sending its PVR:
REQ: POST /b/rv
Content-Format: 836
Accept: 836
Payload: (binary COSE-signed PVR)
The return of multiple content-types in the "ct" attribute by the Registrar allows the Pledge to choose the most appropriate one for a particular operation, and allows extension with new voucher formats. Note that only Content-Format 836 ("application/voucher+cose") is defined in this document for the voucher request resource (/rv), both as request payload and as response payload. If the "ct" attribute is not indicated for the /rv resource in the CoRE link format description, this implies that at least format 836 is supported and maybe more.
Note that this specification allows for voucher+cose format requests and vouchers to be transmitted over HTTPS, as well as for voucher-cms+json and other formats yet to be defined over CoAP. The burden for this flexibility is placed upon the Registrar. A Pledge on constrained hardware is expected to support a single format only.
The Pledge and MASA need to support one or more formats (at least format 836) for the voucher and for the voucher request. The MASA needs to support all formats that the Pledge supports.
In the below example, a Pledge queries specifically for the brski.rv resource type to learn what voucher formats are supported:
REQ: GET /.well-known/core?rt=brski.rv
RES: 2.05 Content
Content-Format: 40
Payload:
</b/rv>;rt=brski.rv;ct="836 65123 65124"
The Registrar returns 3 supported voucher formats: 836, 65123, and 65124. The first is the mandatory "application/voucher+cose". The other two are numbers from the Experimental Use number range of the CoAP Content-Formats sub-registry, which are used as mere examples. The Pledge can now make a selection between the supported formats.
Note that if the Registrar only supports the default Content-Formats for each cBRSKI resource as specified by this document, it may also omit the ct attributes in the discovery query response. For example as in the following interaction:
REQ: GET /.well-known/core?rt=brski*
RES: 2.05 Content
Content-Format: 40
Payload:
</b>;rt=brski,
</b/rv>;rt=brski.rv,
</b/vs>;rt=brski.vs,
</b/es>;rt=brski.es
The Pledge can also use CoAP discovery to identify enrollment options, for example enrollment using EST-coaps or other methods. The below example shows a Pledge that wants to identify EST-coaps enrollment options by sending a discovery query:
REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content
Content-Format: 40
Payload:
</e/crts>;rt=ace.est.crts;ct="62 281 287",
</e/sen>;rt=ace.est.sen;ct="281 287",
</e/sren>;rt=ace.est.sren;ct="281 287",
</e/att>;rt=ace.est.att,
</e/skg>;rt=ace.est.skg,
</e/skc>;rt=ace.est.skc
The response indicates that EST-coaps enrollment (/sen) and re-enrollment (/sren) is supported, with a choice of two Content-Formats for the return payload: either a PKCS#7 container with a single LDevID certificate ("application/pkcs7-mime;smime-type=certs-only", content-format 281) or just a single LDevID certificate ("application/pkix-cert", content-format 287).
For the EST cacerts resources (/crts) there are three Content-Formats supported: a multipart-core container (62) per {{multipart-core}}, a PKCS#7 container with all CA certificates (287), or a single (most relevant) CA certificate.
The Pledge can now send a CoAP request to one or more of the discovered resources, with the Accept Option to indicate which return payload format the Pledge wants to receive.