]>

Austria christian@amsuess.com

Sandelman Software Works

mcr+ietf@sandelman.ca

CoRE coap Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus registering (relatively verbose) well-known URI paths. This document introduces an option that allows expressing well-known paths in as little as two bytes. About This Document Status information for this document may be found at . Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction [ This is a -00, please read the abstract. ]

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document assumes basic familiarity with CoAP (), in particular its Uri-* options.

The Short-Uri-Path option The Short-Uri-Path option expresses a request's URI path in a more compact form. The Short-Uri-Path option represents a particular path, and is thus equivalent to any number of Uri-Path options. Those paths are typically in a "/.well-known" location as described in . The option values are coordinated by IANA in the Short-Uri-Path registry established in this document. A client may use the option instead of the Uri-Path option if there is a suitable value that can express the requested path. Unless the client can be assured that the server supports it (e.g. because the specification describing the interaction mandates support for the option in the server) it SHOULD fall back to sending the path explicitly if it receives an error indicating that the option was not understood (otherwise, it would have limited interoperability). A server receiving the option with an unknown value MUST treat it as an unprocessable critical option, returning 4.02 Bad Option and MUST NOT return a 4.04 Not Found response, because the equivalent path may be present on the server. A server that supports a Short-Uri-Path value MUST also support the equivalent request composed of Uri-Path components. Short-Uri-Path Option Summary (C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable)

No.	C	U	N	R	Name	Format	Len.	Default
CPA13	x			x	Short-Uri-Path	uint / opaque	any	(none)

RFC-Editor: This document uses the CPA (code point allocation) convention described in . For each usage of the term "CPA", please remove the prefix "CPA" from the indicated value and replace the residue with the value assigned by IANA; perform an analogous substitution for all other occurrences of the prefix "CPA" in the document. Finally, please remove this note. The Short-Uri-Path option has an integer value in its first occurrence; the type of later occurrences differs depending on the first. It is a critical and safe-to-forward option that is part of the cache key, used in CoAP requests. summarizes these, extending Table 4 of ). Its OSCORE treatment is as Class E (). Apart from the format, these properties only deviate from the Uri-Path (for which it stands in) in that this option is safe to forward. This has unfortunate consequences for the interactions with the Proxy-URI option, but is generally desirable: It allows the option to be used with proxies that do not implement the option.

Proxy behavior A proxy MAY expand or introduce a Short-Uri-Path when forwarding a request, in particular for serving cached responses, as long as this introduces no new errors to the client. A proxy that knows Short-Uri-Path but not the concrete value SHOULD forward it unmodified, which is the behavior it would apply if it did not know the option. A reason to reject the request instead is when the proxy is tasked with enforcing access control (see ).

Interaction with other options The option is mutually exclusive with the Uri-Path option. Receiving both options in a single request MUST be treated like the presence of a critical request option that could not be processed (that option being either the Short-Uri-Path option or the conflicting option). The Short-Uri-Path option MUST NOT be used in combination with the Proxy-Uri option (or the similar Proxy-CRI option (of )) by clients. Proxies that understand Short-Uri-Path and convert Uri-* options into Proxy-Uri MUST expand any Short-Uri-Path if they know the value. By the (de)composition rules around Proxy-Uri, and because Short-Uri-Path is safe-to-forward, a proxy (being generally unaware of this specification) is allowed to combine the option with Proxy-Uri (or Proxy-CRI) when it combines the Uri-* options. In such a combined message, the Uri-Path segments to which the Short-Uri-Path corresponds are appended to the path as if all components were present as individual options in the request without conflicting. Servers that support both Short-Uri-Path and Proxy-URI/-CRI SHOULD process requests accordingly. (This is not a strict requirement, as there are no known implementations of proxies that actually compose a Proxy-URI/-CRI from individual options, nor is there a reason known why they should).

Repeated use The document defining the registered value of the first Short-Uri-Path option may allow additional Short-Uri-Path options, Their value is not expanded through the Short-Uri-Path IANA registry, but according to rules set up in that particular registration. To be implementable on a wide variety of platforms, those rules should allow expansion into Uri-Path options in an iterative way (i.e., any added Short-Uri-Path option corresponds only to appended Uri-Path options, or cause a 4.02 Bad Option error, except if there are no resources at all with that prefix, in which case 4.04 Not Found may be used instead).

Examples of rules Some rules anticipated to be used are:

• Options after the first are treated exactly like Uri-Path options.
• There can be only one added Short-Uri-Path option, and its opaque value is looked up in a table shaped like the Short-Uri-Path IANA registry.

Considerations for choosing rules and prefixes It is recommended that the expansion of the first Short-Uri-Path option does not end with a trailing slash. While that is a valid CoAP URI, any additional path segments generated by expanding additional Short-Uri-Path options would generated paths with interior double slashes, which is highly unusual and generally not intended. When no repeated use is anticipated, it is recommended to not forbid them outright: That would make it harder to use that exension point later, as allowing it would be a breaking change to the specification. Instead, either the common behavior of treating them as extra Uri-Path strings can be specified (which does not make a server without resources under the prefix any more complex, as it may answer react with 4.02 or 4.04 as per ), or the semantics of repeated options can explicitly be left unspecified (which retains more flexibility in assigning meaning later).

Choice of the option number TBD: Rephrase this to either be useful for readers of the final document who can thus learn how the option number namespace is managed, or remove before publication.

• It's already 1+1 -- we generally do try to keep even the 1+1 high so that later option typically paired with a low option (like EDHOC paired with OSCORE) can use the small delta. In this case, there's a good reason (being ordered before Uri-Query) though, and I don't expect that any other option would need this particular property (especially given that this option on its own has an extensible value range).

Initial Short-Uri-Path values This document registers values for the following well-known URIs:

• /.well-known/core
• /.well-known/rd (see )
• /.well-known/brski (see )
• /.well-known/est (see )

For all those, later occurrences of Short-Uri-Path are interpreted as additional Uri-Path values. While there are currently no resources under the CoRE and RD resource, this behavior is useful in BRSKI and EST. Note that the former two paths are commonly used with Uri-Query options.

Security Considerations Having alternative expressions for information that is input to policy decisions can be problematic when the mechanism performing the check has a different interpretation of the presented data than the mechanism at time of use. That concern is not new to this document: Both the Proxy-Uri of and the Proxy-Cri option of have the same properties in that regard. The appropriate behavior is for policy checkers to reject any request that contains critical options that is not understood; the application protected by the checker may provide the checker with an allow-list of options that it will treat as unchecked input.

IANA Considerations

CoAP option: Short-Uri-Path IANA is requested to enter an one option into the CoAP Option Numbers registry in the CoRE Parameters group:

• Number: CPA13
• Name: Short-Uri-Path
• Reference: this document

Short-Uri-Path registry IANA is requested to establish a new registry in the CoRE parameters group: Values of the first Short-Uri-Path option in a CoAP request correspond to a URI path according to this registry. The policy for adding any value is IETF Review (as described in ). Change control for the registry follows this document's publication stream. Initial values are given in . Entry fields are:

• First option value. An non-negative integer that can be expressed in 32 bits, unique within this registry. All positive values whose most significant bit of the most significant byte is 1 are reserved. The Python invocation python3 -c 'print("reserved" if (250).bit_length() % 8 == 0 else "unreserved")' can be used to quickly test this property for any positive number (250 in this example).
• Simple expanded path. This text is the URI path (starting with /) that the option, when present only once in a request, is expanded to. This field may be empty if the document describes that the option needs to be repeated when using this first value.
• Reference. A document that requested the allocation, and describes whether the option may be repeated after this first value, and how later values are expanded

Reviewer instructions: The reviewer is instructed to be frugal with the 128 values that correspond to a single-vbyte value, focusing on applications that are expected to be useful in different constrained ecosystems. If the considerations of are not followed, the reviewer is asked to verify with the applicant that they are deliberately deciding otherwise. The expanded path (or paths) are expected to be well-known paths at the time of writing, but it is up to the reviewers to exceptionally also admit paths that are not well-known. If the registration foresees updates, those should always just allow previously unacceptable values into new path segments, and not alter the semantics of previously valid expansions. Initial values for the Short-Uri-Path registry

First option value	Simple expanded path	Reference
0	/.well-known/core	of this document
1	/.well-known/rd	of this document, and
2	/.well-known/brski	of this document, and
3	/.well-known/est	of this document, and

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Informative References This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. Universität Bremen TZI CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the application-oriented EDN literal e'', a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 to add a note on how the "URI Schemes" registry of RFC 7595 cooperates with the "CRI Scheme Numbers" registry created by the present RFC. // (This "cref" paragraph will be removed by the RFC editor:) The // present revision –23 attempts to address the AD review comments; // it is submitted right before the I-D deadline in order to serve as // discussion input to IETF 123 even though not all discussions have // completed. In particular, the updated handling of zone // identifiers requires some additional scrutiny. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl 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. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol (CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.

Further development Several possible further directions are anticipated in this document, but not specified at this point in time; they are left for further documents:

• The mechanism of expanding one option into another option might be expressed using the terminology of SCHC. Such a generalization is not aimed for in this document; authors of any future document providing such a framework are encouraged to provide an equivalent but machine-readable explanation of the mechanism specified here.
• The registry for Short-Uri-Path values is set up such that first values can not have the most significant bit of the first byte set. This allows future documents to reuse the option for any CBOR expressions, e.g. the path component of a CRI . Note that those CBOR structures can only use the major types 4 to 7 for the top-level item, but that includes all containers (arrays, maps and tags). Senders and recipients of this option do not need to concern themselves with that extension mechanism unless they implement it: As the first value is compared to known registry entries, any CBOR item contained in it will simply not match any known value. Should the working group decide not to use that extension point, the registry's policy can be relaxed to also allow values with that leading bit set.
• A future document may update this document to allow registering values that are allowed to use together with Uri-Path values (but at the time of writing, no examples are known by which such a design could be properly vetted). In particular, that update weakens the "MUST" in .
• This option is designed to stand in for the Uri-Path option alone, not for any other option; this simplifies its interaction rules. In particular, application authors who seek to express Uri-Query options in a more concise or easier to process way are advised to avail themselves of the FETCH method introduced in .

Open questions This section will be gone by the time this document is published.

• Do we want to enable the use of Uri-Query with this option? If so, we need option number 13, or put what the author regards as unreasonable requirements on recipients. In particular, the .well-known/core resource that is attractive for compression is commonly used with Uri-Query options, and it also works well for /.well-known/rd. The alternative is to use a higher number (still 1+1 but less precious), eg. 267.
• Is the transformation of separate options to Proxy-URI even legal for proxies? If not, we can simplify the handling (and Uri-Path would really not have needed to be proxy-unsafe).
• This document might incentivise users to send more traffic through /.well-known/ paths, rather than go through discovery. It is up to WG discussion to decide whether this is desirable; to not make this document depend on that outcome, the registration policy is currently "IETF Review", which is extremely strict and can be relaxed in a later document if the WG decides so.
• Do we want to add /.well-known/edhoc here, or rather fix it by updating the EDHOC option to also work without an OSCORE option? (The author prefers the latter).

Change log Since -00:

• Switched option type from opaque to uint (retaining the lockout for values that look like CBOR arrays/maps).
• MCR joined as author.
• Added initial values for BRSKI and EST.
• Allow 4.04 responses.
• Add guidance for choosing prefixes and rules.
• Large editorial changes.

Acknowledgments This document was created out of discussion with Esko Dijk and Michael Richardson. Carsten Bormann provided useful input on shaping the registry.