[Anima] Re: Shepherd review draft-ietf-anima-constrained-voucher-30 / Limit scope to onboarding

[Esko Dijk <[e-mail]>]

Hi Toerless, (WG,)

While processing your review I noticed some of the specification around 
trust anchor (CA) renewal and LDevID (certificate) renewal was not fully 
specified yet; and some issues for IoT devices also related to their 
access to reliable clock time.  To avoid scope creep and addition of 
lots of text the authors propose to focus the cBRSKI draft on the 
onboarding phase.  Certificate and trust anchor renewal is then left to 
"standard EST procedures", while acknowledging that various improvements 
to this process would be possible for IoT devices, which could be 
written up in a new document.

Such a new document might be in scope of a WG like ACE, or maybe ANIMA.

As an idea: we might still keep an Appendix (informative) with a 
description of the renewal issues, if we want.

best regards

Esko

On 6/11/26 06:08, Toerless Eckert wrote:
> Dear Authors
>
> As shepherd for this document, i wanted to provide a shepherd review for
> the  document before hopefully we can pass it on soon to the AD and close
> the WGLC successfully.
>
> Overall, i am very happy with the document. I specifically like that it is
> not - as many RTG standards RFC - tersely focussed on not trying to write a
> single sentence more than what is needed to just line up all sentences with
> RFC2119 language. Instead, there are a lot of explanations coming obviously
> from experienced programmer background - who also has enough security expertise
> to help developers wanting to implement cBRSKI to do so. And i think specifically
> on this topic going above and beyond standard RTG-terseness is very important,
> because security is traditionally a badly understood topic in IoT development.
>
> There is a range hopefully useful and mostly minor or nit level issues which would
> be great to get fixed, but overall, there is really only one big structural issue
> that may incur some editorial pain, and that is:
>
> - For every text in this document, is it clear whether it only applies to cBRSKI,
>    or also to BRSKI ?
>
> Maybe as one idea how to solve this most easily, and abusing the same syntax from
> RFC8993: Simply go through all sections and mark those that also apply to BRSKI
> in the title with something like (*) - and then in the intrudoction explain that.
> But that still leaves the problem of explaining what actual "Updates" versus just
> maybe better explanations are in this document.
>
> Cheers & thanks a lot for the hard work on this document. This is very comprehensive.
>
> Toerless
>
>       1	
>       2	
>       3	
>       4	
>       5	anima Working Group                                        M. Richardson
>       6	Internet-Draft                                  Sandelman Software Works
>       7	Updates: 8995, 9148 (if approved)                        P. van der Stok
>       8	Intended status: Standards Track                  vanderstok consultancy
>       9	Expires: 31 August 2026                                    P. Kampanakis
>      10	                                                           Cisco Systems
>      11	                                                                 E. Dijk
>      12	                                                       IoTconsultancy.nl
>      13	                                                        27 February 2026
>      14	
>      15	
>      16	  Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI)
>      17	                draft-ietf-anima-constrained-voucher-30
>      18	
>      19	Abstract
>      20	
>      21	   This document defines the Constrained Bootstrapping Remote Secure Key
>      22	   Infrastructure (cBRSKI) protocol, which provides a solution for
>      23	   secure zero-touch onboarding of resource-constrained (IoT) devices
>      24	   into the network of a domain owner.  This protocol is designed for
>      25	   constrained networks, which may have limited data throughput or may
>      26	   experience frequent packet loss. cBRSKI is a variant of the BRSKI
>      27	   protocol, which uses an artifact signed by the device manufacturer
>
> minor:
>
> Suggest to replace "cBRSKI is a variant of the BRSKI protocol" as follows: cBRSKI is re-using the architecture introduced in 
> RFC8995 (BRSKI) with different protocols. Explanation: "BRSKI protocol" can either mean RFC8995 or "all the possible variations
> of protocols we can ever come up with roughly the BRSKI architecture". But it can not
> mean both. I think so far we have established it to mean "BRSKI protocol = RFC8995".
> Hence we should be very careful in how we use "BRSKI protocol".
>
> nit:
>
> "which uses" - unclear if the following refers to cBRSKI or BRSKI (or both).
>
> Suggest: Full stop before this, and "cBRSKI like BRSKI uses an artifact ...".
>
>      28	   called the "voucher" which enables a new device and the owner's
>      29	   network to mutually authenticate.  While the BRSKI voucher data is
>      30	   encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher.  The
>      31	   BRSKI voucher data definition is extended with new data types that
>      32	   allow for smaller voucher sizes.  The Enrollment over Secure
>      33	   Transport (EST) protocol, used in BRSKI, is replaced with EST-over-
>      34	   CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP
>      35	   (CoAPS).  This document Updates RFC 8995 and RFC 9148.
>
> Nice.
>
>      36	
>      37	About This Document
>      38	
>      39	   This note is to be removed before publishing as an RFC.
>      40	
>      41	   Status information for this document may be found at
>      42	https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-
>      43	   voucher/.
>      44	
>      45	   Discussion of this document takes place on the anima Working Group
>      46	   mailing list (mailto:[e-mail]), which is archived at
>      47	https://mailarchive.ietf.org/arch/browse/anima/.  Subscribe at
>      48	https://www.ietf.org/mailman/listinfo/anima/.
>      49	
>      50	   Source for this draft and an issue tracker can be found at
>      51	https://github.com/anima-wg/constrained-voucher.
>      52	
>      53	
>      54	
>      55	
>      56	Richardson, et al.       Expires 31 August 2026                 [Page 1]
>      57	
>      58	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>      59	
>      60	
>      61	Status of This Memo
>      62	
>      63	   This Internet-Draft is submitted in full conformance with the
>      64	   provisions of BCP 78 and BCP 79.
>      65	
>      66	   Internet-Drafts are working documents of the Internet Engineering
>      67	   Task Force (IETF).  Note that other groups may also distribute
>      68	   working documents as Internet-Drafts.  The list of current Internet-
>      69	   Drafts is athttps://datatracker.ietf.org/drafts/current/.
>      70	
>      71	   Internet-Drafts are draft documents valid for a maximum of six months
>      72	   and may be updated, replaced, or obsoleted by other documents at any
>      73	   time.  It is inappropriate to use Internet-Drafts as reference
>      74	   material or to cite them other than as "work in progress."
>      75	
>      76	   This Internet-Draft will expire on 31 August 2026.
>      77	
>      78	Copyright Notice
>      79	
>      80	   Copyright (c) 2026 IETF Trust and the persons identified as the
>      81	   document authors.  All rights reserved.
>      82	
>      83	   This document is subject to BCP 78 and the IETF Trust's Legal
>      84	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
>      85	   license-info) in effect on the date of publication of this document.
>      86	   Please review these documents carefully, as they describe your rights
>      87	   and restrictions with respect to this document.  Code Components
>      88	   extracted from this document must include Revised BSD License text as
>      89	   described in Section 4.e of the Trust Legal Provisions and are
>      90	   provided without warranty as described in the Revised BSD License.
>      91	
>      92	Table of Contents
>      93	
>      94	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
>      95	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
>      96	   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   7
>      97	   4.  Overview of Protocol  . . . . . . . . . . . . . . . . . . . .   7
>      98	   5.  Updates to RFC 8995 and RFC 9148  . . . . . . . . . . . . . .   9
>      99	   6.  BRSKI-EST Protocol  . . . . . . . . . . . . . . . . . . . . .  10
>     100	     6.1.  DTLS Connection . . . . . . . . . . . . . . . . . . . . .  10
>     101	       6.1.1.  DTLS Version  . . . . . . . . . . . . . . . . . . . .  10
>     102	       6.1.2.  TLS Client Certificates: IDevID authentication  . . .  10
>     103	       6.1.3.  DTLS Handshake Fragmentation Considerations . . . . .  11
>     104	       6.1.4.  Registrar and the Server Name Indicator (SNI) . . . .  11
>     105	       6.1.5.  Registrar Server Certificate Requirements . . . . . .  12
>     106	     6.2.  cBRSKI Join Proxy . . . . . . . . . . . . . . . . . . . .  12
>     107	     6.3.  Request URIs, Resource Discovery and Content-Formats  . .  12
>     108	       6.3.1.  Status Telemetry Returns  . . . . . . . . . . . . . .  14
>     109	
>     110	
>     111	
>     112	Richardson, et al.       Expires 31 August 2026                 [Page 2]
>     113	
>     114	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     115	
>     116	
>     117	       6.3.2.  CoAP Resources Table  . . . . . . . . . . . . . . . .  15
>     118	       6.3.3.  CoAP Uri-Path Abbreviation  . . . . . . . . . . . . .  15
>     119	     6.4.  CoAP Responses  . . . . . . . . . . . . . . . . . . . . .  15
>     120	     6.5.  Extensions to EST-coaps . . . . . . . . . . . . . . . . .  16
>     121	       6.5.1.  Pledge Enrollment Procedure . . . . . . . . . . . . .  16
>     122	       6.5.2.  Renewal of CA certificates  . . . . . . . . . . . . .  17
>     123	       6.5.3.  Change of Domain Trust Anchor(s)  . . . . . . . . . .  17
>     124	       6.5.4.  Re-enrollment Procedure . . . . . . . . . . . . . . .  18
>     125	       6.5.5.  Multipart Content-Format for CA certificates (/crts)
>     126	               Resource  . . . . . . . . . . . . . . . . . . . . . .  19
>     127	     6.6.  Registrar Extensions  . . . . . . . . . . . . . . . . . .  20
>     128	   7.  BRSKI-MASA Protocol . . . . . . . . . . . . . . . . . . . . .  21
>     129	     7.1.  Protocol and Formats  . . . . . . . . . . . . . . . . . .  21
>     130	     7.2.  Registrar Voucher Request . . . . . . . . . . . . . . . .  22
>     131	     7.3.  MASA and the Server Name Indicator (SNI)  . . . . . . . .  22
>     132	     7.4.  Registrar Client Certificate Requirements . . . . . . . .  23
>     133	   8.  Pinning in Voucher Artifacts  . . . . . . . . . . . . . . . .  23
>     134	     8.1.  Registrar Identity Selection and Encoding . . . . . . . .  23
>     135	     8.2.  MASA Pinning Policy . . . . . . . . . . . . . . . . . . .  24
>     136	     8.3.  Pinning of Raw Public Keys (RPK)  . . . . . . . . . . . .  25
>     137	   9.  Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . .  26
>     138	     9.1.  Example Artifacts . . . . . . . . . . . . . . . . . . . .  27
>     139	       9.1.1.  Example Pledge Voucher Request (PVR) Artifact . . . .  27
>     140	       9.1.2.  Example Registrar Voucher Request (RVR) Artifact  . .  27
>     141	       9.1.3.  Example Voucher Artifacts . . . . . . . . . . . . . .  28
>     142	     9.2.  Signing Voucher and Voucher Request Artifacts with
>     143	           COSE  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
>     144	       9.2.1.  Signing of Registrar Voucher Request (RVR)  . . . . .  30
>     145	       9.2.2.  Signing of Pledge Voucher Request (PVR) . . . . . . .  31
>     146	       9.2.3.  Signing of Voucher by MASA  . . . . . . . . . . . . .  32
>     147	       9.2.4.  Optional Validation of Voucher by Registrar . . . . .  34
>     148	       9.2.5.  Additional Information in the COSE Header . . . . . .  34
>     149	   10. Extensions to Discovery . . . . . . . . . . . . . . . . . . .  35
>     150	     10.1.  Discovery Operations by a Pledge . . . . . . . . . . . .  36
>     151	       10.1.1.  Examples . . . . . . . . . . . . . . . . . . . . . .  37
>     152	     10.2.  Discovery Operations by a Join Proxy . . . . . . . . . .  39
>     153	   11. Deployment-specific Discovery Considerations  . . . . . . . .  39
>     154	     11.1.  6TiSCH Deployments . . . . . . . . . . . . . . . . . . .  39
>     155	     11.2.  IP networks using GRASP  . . . . . . . . . . . . . . . .  39
>     156	     11.3.  IP networks using mDNS . . . . . . . . . . . . . . . . .  40
>     157	     11.4.  Thread Networks using Mesh Link Establishment (MLE)  . .  40
>     158	   12. Design and Implementation Considerations  . . . . . . . . . .  41
>     159	     12.1.  Voucher Format and Encoding  . . . . . . . . . . . . . .  41
>     160	     12.2.  CoAP Usage . . . . . . . . . . . . . . . . . . . . . . .  41
>     161	     12.3.  Use of cBRSKI with HTTPS . . . . . . . . . . . . . . . .  41
>     162	   13. Raw Public Key Variant  . . . . . . . . . . . . . . . . . . .  42
>     163	     13.1.  Introduction and Scope . . . . . . . . . . . . . . . . .  42
>     164	     13.2.  DTLS Connection and Registrar Trust Anchor . . . . . . .  42
>     165	
>     166	
>     167	
>     168	Richardson, et al.       Expires 31 August 2026                 [Page 3]
>     169	
>     170	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     171	
>     172	
>     173	     13.3.  The Pledge Voucher Request . . . . . . . . . . . . . . .  43
>     174	     13.4.  The Voucher Response . . . . . . . . . . . . . . . . . .  43
>     175	     13.5.  The Enrollment Phase . . . . . . . . . . . . . . . . . .  44
>     176	   14. Security Considerations . . . . . . . . . . . . . . . . . . .  44
>     177	     14.1.  Duplicate Serial Numbers . . . . . . . . . . . . . . . .  44
>     178	     14.2.  IDevID Security in the Pledge  . . . . . . . . . . . . .  45
>     179	     14.3.  Security of the BRSKI-MASA Protocol  . . . . . . . . . .  46
>     180	     14.4.  Registrar Certificate May Be Self-signed . . . . . . . .  47
>     181	     14.5.  Use of RPK Alternatives to 'proximity-registrar-cert'  .  47
>     182	   15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  48
>     183	     15.1.  Resource Type Link Target Attribute Values Registry  . .  48
>     184	     15.2.  Media Types Registry . . . . . . . . . . . . . . . . . .  48
>     185	       15.2.1.  application/voucher+cose . . . . . . . . . . . . . .  48
>     186	       15.2.2.  Interoperability Considerations for application/
>     187	               voucher+cose  . . . . . . . . . . . . . . . . . . . .  49
>     188	     15.3.  CoAP Content-Formats Registry  . . . . . . . . . . . . .  50
>     189	     15.4.  Update to BRSKI Well-Known URIs Registry . . . . . . . .  50
>     190	     15.5.  Structured Syntax Suffixes Registry  . . . . . . . . . .  51
>     191	   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  52
>     192	     16.1.  Normative References . . . . . . . . . . . . . . . . . .  52
>     193	     16.2.  Informative References . . . . . . . . . . . . . . . . .  56
>     194	   Appendix A.  Software and Library Support for cBRSKI  . . . . . .  58
>     195	     A.1.  Open Source cBRSKI Implementations  . . . . . . . . . . .  58
>     196	     A.2.  Security Library Support  . . . . . . . . . . . . . . . .  59
>     197	       A.2.1.  OpensSSL Example Code . . . . . . . . . . . . . . . .  60
>     198	       A.2.2.  mbedTLS Example Code  . . . . . . . . . . . . . . . .  61
>     199	     A.3.  Generating Certificates with OpenSSL  . . . . . . . . . .  61
>     200	   Appendix B.  cBRSKI Message Examples  . . . . . . . . . . . . . .  65
>     201	     B.1.  enrollstatus  . . . . . . . . . . . . . . . . . . . . . .  65
>     202	     B.2.  voucher_status  . . . . . . . . . . . . . . . . . . . . .  67
>     203	   Appendix C.  COSE-signed Voucher (Request) Examples . . . . . . .  68
>     204	     C.1.  Pledge, Registrar and MASA Keys . . . . . . . . . . . . .  68
>     205	       C.1.1.  Pledge IDevID Private Key . . . . . . . . . . . . . .  68
>     206	       C.1.2.  Registrar Private Key . . . . . . . . . . . . . . . .  68
>     207	       C.1.3.  MASA Private Key  . . . . . . . . . . . . . . . . . .  69
>     208	     C.2.  Pledge, Registrar, Domain CA and MASA Certificates  . . .  69
>     209	       C.2.1.  Pledge IDevID Certificate . . . . . . . . . . . . . .  69
>     210	       C.2.2.  Registrar Certificate . . . . . . . . . . . . . . . .  71
>     211	       C.2.3.  Domain CA Certificate . . . . . . . . . . . . . . . .  73
>     212	       C.2.4.  MASA Certificate  . . . . . . . . . . . . . . . . . .  75
>     213	     C.3.  COSE-signed Pledge Voucher Request (PVR)  . . . . . . . .  77
>     214	     C.4.  COSE-signed Registrar Voucher Request (RVR) . . . . . . .  78
>     215	     C.5.  COSE-signed Voucher from MASA . . . . . . . . . . . . . .  81
>     216	   Appendix D.  Pledge Device Class Profiles . . . . . . . . . . . .  83
>     217	     D.1.  Minimal Pledge  . . . . . . . . . . . . . . . . . . . . .  83
>     218	     D.2.  Typical Pledge  . . . . . . . . . . . . . . . . . . . . .  83
>     219	     D.3.  Full-featured Pledge  . . . . . . . . . . . . . . . . . .  84
>     220	     D.4.  Comparison Chart of Pledge Classes  . . . . . . . . . . .  84
>     221	
>     222	
>     223	
>     224	Richardson, et al.       Expires 31 August 2026                 [Page 4]
>     225	
>     226	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     227	
>     228	
>     229	   Appendix E.  Pledge Discovery of Onboarding and Enrollment
>     230	           Options . . . . . . . . . . . . . . . . . . . . . . . . .  86
>     231	     E.1.  Pledge Discovery Query for All cBRSKI Resources . . . . .  86
>     232	     E.2.  Pledge Discovery Query for the cBRSKI Base Resource . . .  88
>     233	     E.3.  Usage of ct Attribute . . . . . . . . . . . . . . . . . .  88
>     234	     E.4.  EST-coaps Resource Discovery  . . . . . . . . . . . . . .  89
>     235	   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  90
>     236	   Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . .  91
>     237	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  93
>     238	
>     239	1.  Introduction
>     240	
>     241	   Secure enrollment of new nodes into constrained networks with
>     242	   constrained nodes presents unique challenges.  As explained in
>     243	   [RFC7228], such networks may have limited data throughput or may
>
> nit:
>
> mind to add at least a section to the rfc7228 reference?
>
>     244	   experience frequent packet loss.  In addition, its nodes may be
>     245	   constrained by energy availability, memory space, and code size.
>     246	
>     247	   The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
>     248	   described in [RFC8995] provides a solution for secure zero-touch
>     249	   (automated) onboarding of new (unconfigured) devices.  These new
>     250	   devices are called "Pledges", equipped with a factory-installed
>     251	   Initial Device Identifier (IDevID) (see [ieee802-1AR]).  Using the
>     252	   IDevID, a Pledge is securely enrolled into a network.
>     253	
>     254	   The BRSKI solution described in [RFC8995] was designed to be modular,
>     255	   and this document describes a version scaled to the constraints of
>
> nit: replace "version" with "version of that solution"
>
>     256	   IoT deployments.  This document uses the constrained voucher and
>     257	   voucher request artifacts defined in [RFC8366bis] for a constrained
>     258	   version of the BRSKI protocol: cBRSKI.  The cBRSKI protocol uses the
>
> nit: "version of the BRSKI protocol" -> "variation of the BRSKI solution"
>
>     259	   CoAP-based version of EST (EST-coaps from [RFC9148]) rather than the
>     260	   EST over HTTPS [RFC7030].  cBRSKI is itself scalable to multiple
>     261	   resource levels through the definition of optional functions.
>     262	   Appendix D illustrates this.
>     263	
>     264	   In BRSKI, the [RFC8366bis] voucher data is by default serialized to
>     265	   JSON with a signature in CMS [RFC5652]. cBRSKI uses the CBOR
>     266	   [RFC8949] voucher data serialization defined by [RFC8366bis], and
>     267	   applies a new COSE [RFC9052] signature format as defined in
>     268	   Section 9.
>     269	
>     270	   This COSE-signed CBOR-encoded voucher is transported using both
>     271	   secured CoAP [RFC7252] and HTTPS.  The CoAP connection (between
>
> nit: append after HTTP: "depending on the communicating entities:"
>
>     272	   Pledge and Registrar) is to be protected by DTLS (CoAPS).  The HTTP
>     273	   connection (between Registrar and MASA) is to be protected using TLS
>     274	   (HTTPS).
>     275	
>     276	
>     277	
>     278	
>     279	
>     280	Richardson, et al.       Expires 31 August 2026                 [Page 5]
>     281	
>     282	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     283	
>     284	
>     285	   Section 4 to Section 10 define the default cBRSKI protocol, by means
>     286	   of additions to and modifications of regular BRSKI.  Section 11
>
> minor:
>
> Implies too much relationship between cBRSKI protocol and BRSKI (protocol) (remember above
> concerns about difference BRSKI protocol versus architecture/solution.
>
> suggested replacement:
>
> Section 4 to Section 10 specify the default cBRSKI protocol. Readers are expected
> to understand RFC8995 as this specification does not repeat the unchanged
> principles of operations established through RFC8995.
>
> followed by new paragraph.
>
>
>     286	   Section 11
>     287	   considers some variations of the protocol, specific to particular
>     288	   deployments or IoT networking technologies.  Next in Section 12, some
>     289	   considerations for the design and implementation of cBRSKI components
>     290	   are provided.
>     291	
>     292	   Section 13 introduces a variant of cBRSKI for the most-constrained
>     293	   Pledges, using Raw Public Keys (RPK).  This variant achieves smaller
>     294	   sizes of data objects and avoids doing certain costly PKIX
>     295	   verification operations on the Pledge.
>     296	
>     297	   Appendix E provides more details on how a Pledge may discover the
>     298	   various onboarding/enrollment options that a Registrar provides.
>     299	   Implementing these methods is optional for a Pledge.
>
> minor:
>
> There should to be a paragraph summarizing how this document updates proper (non cBRSKI)
> implementations (aka: proper RFC8995 protocol)  given how it has the update flag for RFC8995.
>
> Likewise there should be a paragraph doing the same for rfc9148.
>
>     300	
>     301	2.  Terminology
>     302	
>     303	   The following terms are defined in [RFC8366bis], and are used
>     304	   identically as in that document: Artifact, Attribute, Domain, Join
>     305	   Registrar and Coordinator (JRC), Malicious Registrar, Manufacturer
>     306	   Authorized Signing Authority (MASA), Pledge, Registrar, Onboarding,
>     307	   Owner, Voucher Data, Voucher Request and Voucher.
>     308	
>     309	   The protocol described in this document is referred to as cBRSKI, the
>     310	   constrained version of BRSKI [RFC8995].
>
> nit:
>
> s/version/variation/
>
>     311	
>     312	   The following terms from [RFC8995] are used identically as in that
>     313	   document: Domain CA, enrollment, IDevID, Join Proxy, LDevID,
>     314	   manufacturer, nonced, nonceless, PKIX.
>     315	
>     316	   The following terms from [RFC7030] are used identically as in that
>     317	   document: Explicit Trust Anchor (TA), Explicit TA database, Third-
>     318	   party TA.
>     319	
>     320	   The following terms from [RFC7252] are used identically as in that
>     321	   document: Confirmable (CON), Acknowledgement (ACK), Endpoint, ETag,
>     322	   Client, Server, Piggybacked Response, resource, Resource Discovery,
>     323	   Content-Format.
>     324	
>     325	   The term Pledge Voucher Request, or acronym PVR, is introduced to
>
> nit:
>
> "or" -> "and its"... "are introduced"
>
> reason: text is introducing both, hence i think syntactically "and" is correct.
>
>     326	   refer to the voucher request between the Pledge and the Registrar.
>     327	
>     328	   The term Registrar Voucher Request, or acronym RVR, is introduced to
>     329	   refer to the voucher request between the Registrar and the MASA.
>
> nit: likewise
>
>     330	
>     331	   The terms "PKIX Certificate" and "certificate" both refer to the
>     332	   X.509v3 profile described in [RFC5280].
>     333	
>     334	
>     335	
>     336	Richardson, et al.       Expires 31 August 2026                 [Page 6]
>     337	
>     338	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     339	
>     340	
>     341	   The term "base resource" is defined as a CoAP resource that can be
>     342	   used as a base to append an additional path segment to, where this
>     343	   segment is a short resource name ('short-name') as defined in
>     344	   Section 6.3 and Table 1.
>
> sorry:
>
> Forgot:
>
> I am by the way skipping "define on first use" checks, but hereby reminding authors
> that it's good to check for that. Alas, there still doesn't seem to be a good automated
> way for that... *sigh*
>
>     345	
>     346	   In code examples, the string "<CODE BEGINS>" denotes the start of a
>     347	   code example and "<CODE ENDS>" the end of the code example. "lf
>     348	   added" means that extra linefeed characters were added to an example
>     349	   to make lines fit in this document.
>     350	
>     351	   The ellipsis ("...") in a CBOR diagnostic notation byte string
>     352	   denotes a further sequence of bytes that is not shown for brevity.
>     353	   This notation is defined in [I-D.ietf-cbor-edn-literals].
>
> great terminology section!
>
>     354	
>     355	3.  Requirements Language
>     356	
>     357	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     358	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>     359	   "OPTIONAL" in this document are to be interpreted as described in
>     360	   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>     361	   capitals, as shown here.
>     362	
>     363	4.  Overview of Protocol
>     364	
>     365	   [RFC8366bis] defines a voucher that can assert proximity,
>     366	   authenticates the Registrar, and can offer varying levels of anti-
>     367	   replay protection.  The proximity proof provided by a voucher is an
>     368	   assertion that the Pledge and the Registrar are believed to be close
>     369	   together, from a network topology point of view.  Similar to BRSKI
>     370	   [RFC8995], proximity is proven by making a DTLS connection between a
>     371	   Pledge and a Registrar.  The Pledge initiates this connection using a
>     372	   link-local source address.
>
> nit:
>
> This text starts with explaining stuff about [RFC8366bis] and then throws in
> BRSKI and cBRSKI. Likewise DTLS is thrown in when i think it's not beneficial.
> After all, we would still use DTLS even if we had a setup where a pledge discovery
> a non-link-local connection.
>
> Simply replace sentenc "Similar to BRSKI ..." with The proximity assertion is raised when the Pledge is making the 
> connection to the registrar using link-local addresses. And then 
> upfront the following paragraph with moving over to cBRSKI: Where 
> BRSKI [RFC8995] uses TLS connections from Pledge to registrar, cBRSKI 
> uses DTLS. This secure ... 373 374 The secure DTLS connection is then 
> used by the Pledge to send a 375 Pledge Voucher Request (PVR). The 
> Registrar then includes the PVR 376 into its own Registrar Voucher 
> Request (RVR), which is sent to an 377 agent (MASA) of the Pledge's 
> manufacturer. The MASA verifies the PVR 378 and RVR and issues a 
> signed voucher. The voucher provides an 379 authorization statement 
> from the manufacturer indicating that the 380 Registrar is the 
> intended owner of the Pledge. The voucher refers to 381 the Registrar 
> through pinning of the Registrar's identity. nit: I am still uneasy 
> referring to the voucher pinning without explanation because it 
> behaves differently than classical web certificate pinning. I'd rather 
> explain our functionality and not introduce the term pinning here: "The voucher refers.." -> The voucher also includes an identity of the owner, such
> as a certificate which the Pledge can then use to authenticate the owner.
>
>     382	
>     383	
>     384	
>     385	
>     386	
>     387	
>     388	
>     389	
>     390	
>     391	
>     392	Richardson, et al.       Expires 31 August 2026                 [Page 7]
>     393	
>     394	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     395	
>     396	
> nit:
>
> I'd frontent the following paragraph with:
>
> This MASA communication is necessary because the only trust anchors that a Pledges
> software can have are those installed by the manufacturer, simply because the role
> as Pledge assumes that nobody but the manufacturer ever had to touch it. Therefore the
> voucher can only be signed by such an agent trusted by the manufacturer.
>
>     397	   After verification of the voucher, the Pledge enrolls into the
>     398	   Registrar's domain by obtaining a certificate using the EST-coaps
>
> nit:
>
> would move mentioning of LDevID here:
>
> "a certtificate called the LDevID"
>
>     399	   [RFC9148] protocol, suitable for constrained devices.  Once the
>     400	   Pledge has obtained its domain identity (LDevID) in this manner, it
>     401	   can use this identity to obtain network access credentials, which are
>     402	   used to join the local IP network.  The method to obtain such
>     403	   credentials depends on the particular network technology used and is
>     404	   outside the scope of this document.
>
> nit:
>
> >From "Once the Pledge" on: I would try to explain these benefits but also limitations of 
> the scope of cBRSKI stronger: While the LDevID can serve as an 
> identity of the Pledge in the domain of the owner for any type of 
> communication, the fact that cBRSKI only required link-local 
> communications up to this point specifically allows pledges to use 
> cBRSKI to join a domain in which allocation of (non link-local) 
> addresses needs authentication and/or where (non link-local) 
> communication is secured in any form. Note that these mechanisms are 
> outside the scope of this document 405 406 The two main parts of the 
> BRSKI protocol are named separately in this 407 document: BRSKI-EST 
> (Section 6) for the protocol between Pledge and 408 Registrar, and 
> BRSKI-MASA (Section 7) for the protocol between the 409 Registrar and 
> the MASA. 410 411 Time-based vouchers are supported, but given that 
> constrained devices 412 are unlikely to have accurate time, their use 
> will be uncommon. Most 413 Pledges using constrained vouchers will be 
> online during enrollment 414 and will use live nonces to provide 
> anti-replay protection rather 415 than expiry times. nit: Start with the "Most" sentence, then add "for offline enrollment, anti-replay
> protection can be achieved via time-based voucher..."
>
> And given how that then leaves the question about offline enrollment for
> constrained devices without clocks, maybe add sentence that BRSKI such as
> those specified in PRM could close this gap but are currently not specified
> for constrained BRSKI.
>
>     416	
>     417	   [RFC8366bis] defines the CBOR voucher data encoding for the
>
> nit:
>
> "also defines" - as you're circling back to RFC8366
>
>     418	   constrained voucher and the constrained voucher request, which are
>     419	   used by cBRSKI.
>     420	
>     421	   The constrained voucher request MUST be signed by the Pledge.  COSE
>     422	   [RFC9052] is used for signing as defined in Section 9.2.  It signs
>     423	   using the private key of its IDevID.  The constrained voucher MUST be
>     424	   signed by the MASA.  Also in this case, COSE is used for signing.
>
> nit:
>
> Can you check if the normative requirements can go reasonably into later parts
> of the document. Its a weird to have them here. Then replace by "must" here.
>
>     425	
>     426	   For the constrained voucher request (PVR) the default method for the
>     427	   Pledge to identify the Registrar is using the Registrar's full PKIX
>     428	   certificate.  But when operating PKIX-less as described in
>     429	   Section 13, the Registrar's Raw Public Key (RPK) is used for this.
>     430	
>     431	   For the constrained voucher the default method to indicate ("pin") a
>     432	   trusted domain identity is the domain's PKIX CA certificate, but when
>     433	   operating PKIX-less instead the RPK of the Registrar is pinned.
>     434	
>     435	   For certificates, cBRSKI currently uses the X.509 format, like BRSKI.
>
> nit:
>
> Do you want to add some explanation such as "While X.509 is not the most
> constrained friendly encoding, at the time of writing this document, no single
> better alternatives has appeared. Therefore...
>
>     436	   The protocol and data formats are defined such that future extension
>     437	   to other certificate formats is enabled.  For example, CBOR-encoded
>     438	   and COSE-signed C509 certificates ([I-D.ietf-cose-cbor-encoded-cert])
>     439	   may provide data size savings as well as code sharing benefits with
>     440	   CBOR/COSE libraries, when applied to cBRSKI.
>     441	
>     442	   The BRSKI architecture mandates that the MASA be aware of the
>     443	   capabilities of the Pledge.  This is not a drawback as a Pledge is
>
> nit:
> "capabilities of the Pledge to construct the appropriate voucher"
>
>     444	   constructed by a manufacturer which also arranges for the MASA to be
>     445	
>     446	
>     447	
>     448	Richardson, et al.       Expires 31 August 2026                 [Page 8]
>     449	
>     450	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     451	
>     452	
>     453	   aware of the inventory of devices.  The MASA therefore knows if the
>     454	   Pledge supports PKIX operations, or if it is limited to RPK
>     455	   operations only.  Based upon this, the MASA can select which
>     456	   attributes to use in the voucher for certain operations, like the
>     457	   pinning of the Registrar or domain identity.
>     458	
>     459	5.  Updates to RFC 8995 and RFC 9148
>
> nit: rename to "Changes to existing RFC" and then subsections "Updates to RFC8995" and
> "Updates to RFC9148"
>     460	
>     461	   This section details the ways in which this document updates other
>     462	   RFCs.
>
>     463	
>     464	   This document Updates [RFC8995] because it:
>
> major: At this point in time, the text and explanations in this section make it
> very hard to justify both the "update to rfc8995" as well as "update to rfc9148"
>
> While i am not sure i 100% understand the rules for "update" or whether they are even so well specified into these details: - A "clarifies" itself does not justify an update. Worst case, that's just an informational
>    optional addendum, not an update.
>
> - If you can come up with specific examples of how a well-meaning possible implementation
>    of either of these RFC could have resulted in something that is not allowed anymore
>    under this rfc-to-be, then those cases should be explicitly summarized in these
>    update sections. That's the minimum IMHO to call for "update".
>
> - More annoyingly to implementers, they are right now on their own because if in any
>    situation existing text of either of these RFC looks like it's being in contradiction
>    with this new "clarifying" text, then the implementer may assume that that older
>    RFC text is to be ignored. BUT: explicit instructions to the same would be much
>    stronger justifying an "update":
>
> - Ideally, each text that is meant to "update" an older RFC should explicitly state
>    exactly which text of the updated RFC it replaces (think removing the old text), and/or
>    amends "insert the following text at exactly the following location of the original RFC.
>
> - If it is hard to come up with very simple replace/insert rules for the new text, then
>    i would suggest to simply copy the respective section(s) from the original RFC into
>    this RFC and modify it accordingly with the new goals/text. That way, you come up with
>    a simple "this section replaces section foobar of rfc8995", but you may also make
>    it potentially a lot easier to read this drafts new text.
>
> - Are there any current or future possible implementations of RFC8995 and/or RFC9148
>    WIHOUT considerations for constrained vouchers that would need to change under the
>    new text ? Thats the strongest argument for "update" and should be explained as the
>    first item in either of these update sections. And if there is anything like this,
>    how does it impact interoperability with implementations of BRSKI only against RFC8995
>    (without these changes). Given how few implementations of BRSKI there may be, we can
>    i think even be quite "adventorous" if those changes are seen as important enhancements.
>
> So, in summary maybe consider grouping into three types:
>
> 1. Changes for non-constrained cases. These are core updateso
>
> 2. Better text that could help to avoid misinterpretations of prior RFC
>
> 3. Extensions: these are not updates per-se and should be called out as such,
> but by calling them out, i think it's fine to keep them in the "update" section here.
>
>     465	
>     466	   *  clarifies how pinning in vouchers is done (Section 8),
>
>
>     467	
>     468	   *  clarifies the use of TLS Server Name Indicator (SNI)
>     469	      (Section 6.1.4, Section 7.3),
>     470	
>     471	   *  clarifies when new trust anchors should be retrieved by a Pledge
>     472	      (Section 6.5.1),
>     473	
>     474	   *  clarifies what kinds of Extended Key Usage attributes are
>     475	      appropriate for each certificate (Section 6.1.5, Section 7.4),
>     476	
>     477	   *  extends BRSKI with the use of CoAP,
>
> minor: CoAP is explicitly out of scope for RFC8995, so this extension is not
> an update to rfc8995 but an extension.
>
>     478	
>     479	   *  makes some BRSKI messages optional to send if the results can be
>     480	      inferred from other validations (Section 6.5),
>     481	
>     482	   *  extends the BRSKI-EST/BRSKI-MASA protocols (Section 6, Section 7,
>     483	      Section 9.2) to carry the new application/voucher+cose format.
>     484	
>     485	   This document Updates [RFC9148] because it:
>     486	
>     487	   *  defines stricter DTLS requirements (Section 6.1)),
>
> nit: quick one sentence example of the most likely previously implemented option (under 9148
> rules) that would need to be different under this docs rule. Would be nice.
>
>     488	
>     489	   *  details how an EST-coaps client handles certificate renewal and
>     490	      re-enrollment (Section 6.5),
>     491	
>     492	   *  details how an EST-coaps server processes a "CA certificates"
>     493	      request for content-format 287 (application/pkix-cert)
>     494	      (Section 6.6).
>     495	
>     496	   *  adds enrollment status telemetry to the certificate renewal
>     497	      procedure (Section 6.5.4),
>     498	
>     499	   *  adds support for the media type application/multipart-core for the
>     500	      CA certificates (/crts) resource (Section 6.5.5),
>
>     501	
>     502	
>     503	
>     504	Richardson, et al.       Expires 31 August 2026                 [Page 9]
>     505	
>     506	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     507	
>     508	
>     509	   *  defines a resource type ('rt') attribute value "ace.est" for the
>     510	      EST-coaps base resource (Section 15.1).
>     511	
>     512	6.  BRSKI-EST Protocol
>     513	
>     514	   This section describes the extensions to both BRSKI [RFC8995] and
>     515	   EST-coaps [RFC9148] operations between Pledge and Registrar.
>     516	
>     517	6.1.  DTLS Connection
>     518	
>     519	   A DTLS connection is established between the Pledge and the
>     520	   Registrar, similar to the TLS connection described in Section 5.1 of
>     521	   [RFC8995].  This may occur via a Join Proxy as described in
>     522	   Section 6.2.  Regardless of the Join Proxy presence or particular
>     523	   mechanism used, the DTLS connection should operate identically.  The
>     524	   cBRSKI and EST-coaps requests and responses for onboarding are
>     525	   carried over this DTLS connection.
>     526	
>     527	6.1.1.  DTLS Version
>     528	
>     529	   DTLS version 1.3 [RFC9147] SHOULD be used in any implementation of
>     530	   this specification.  An exception case where DTLS 1.2 [RFC6347] MAY
>     531	   be used is in a Pledge that uses a software platform where a DTLS 1.3
>     532	   client is not available (yet).  This may occur for example if a
>     533	   legacy device gets software-upgraded to support cBRSKI.  For this
>     534	   reason, a Registrar MUST by default support both DTLS 1.3 and DTLS
>     535	   1.2 client connections.  However, for security reasons the Registrar
>     536	   MAY be administratively configured to support only a particular DTLS
>     537	   version or higher.
>
> Nice! Lets hope this goes through. It does make a good case with sufficient
> explanation to the SME. Hopefully IESG gets that.
>
>     538	
>     539	   An EST-coaps server [RFC9148] (if present as a separate entity from
>     540	   above Registrar) that implements this specification also MUST support
>     541	   both DTLS 1.3 and DTLS 1.2 client connections by default.  However,
>     542	   for security reasons the EST-coaps server MAY be administratively
>     543	   configured to support only a particular DTLS version or higher.
>
> major: If 6.1.1 says for registrar to MUST support DTLS 1.3, how then do we
> justify the support need for DTLS 1.2 - given how we only have connections from
> those 1.3 registrars ?
>
>     544	
>     545	6.1.2.  TLS Client Certificates: IDevID authentication
>     546	
>     547	   As described in Section 5.1 of [RFC8995], the Pledge makes a
>     548	   connection to the Registrar using a TLS Client Certificate for
>     549	   authentication.  This is the Pledge's IDevID certificate.
>     550	
>     551	   Subsequently the Pledge will send a Pledge Voucher Request (PVR).
>     552	   Further elements of Pledge authentication may be present in the PVR,
>     553	   as detailed in Section 9.2.
>     554	
>     555	
>     556	
>     557	
>     558	
>     559	
>     560	Richardson, et al.       Expires 31 August 2026                [Page 10]
>     561	
>     562	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     563	
>     564	
>     565	6.1.3.  DTLS Handshake Fragmentation Considerations
>     566	
>     567	   DTLS includes a mechanism to fragment handshake messages.  This is
>     568	   described in Section 4.4 of [RFC9147]. cBRSKI will often be used with
>     569	   a Join Proxy, described in Section 6.2, which relays each DTLS
>     570	   message to the Registrar.  A stateless Join Proxy will need some
>     571	   additional space to wrap each DTLS message inside a Join Proxy UDP
>     572	   message, while the wrapped result needs to fit in the maximum IPv6
>     573	   MTU guaranteed on 6LoWPAN [RFC6282] networks, which is 1280 bytes.
>     574	
>     575	   For this reason it is RECOMMENDED that a PMTU of 1024 bytes be
>     576	   assumed for the DTLS handshake and appropriate DTLS fragmentation is
>     577	   used.  It is unlikely that any ICMPv6 Packet Too Big indications
>     578	   ([RFC4443]) will be relayed by the Join Proxy back to the Pledge.
>     579	
>     580	   During the operation of the EST-coaps protocol, the CoAP Block-wise
>     581	   transfer mechanism [RFC7959] will be automatically used when message
>     582	   sizes exceed the PMTU.  A Pledge/EST-client on a constrained network
>     583	   MUST use the (D)TLS maximum fragment length extension
>     584	   ('max_fragment_length') defined in Section 4 of [RFC6066] with the
>     585	   maximum fragment length set to a value of either 2^9 or 2^10, when
>     586	   operating as a DTLS 1.2 client.
>     587	
>     588	   A Pledge/EST-client operating as DTLS 1.3 client, MUST use the (D)TLS
>     589	   record size limit extensions ('record_size_limit') defined in
>     590	   Section 4 of [RFC8449], with RecordSizeLimit set to a value between
>     591	   512 and 1024 (inclusive).
>     592	
>     593	6.1.4.  Registrar and the Server Name Indicator (SNI)
>     594	
>
> major:
>
> I think in our last call discussing this, we figured that this section should
> explain that
>
> a) The core (and maybe only discussed) reason to mention for explicitly NOT using SNI is
>     to allow for (c) BRSKI implementations on pledge and registrars to always be
>     able to operate in the presence of (c)BRSKI proxies, even if not initially
>     considered by an implementation or deployment. And whenever a proxy is used,
>     then the pledge can not know the right hostname of the registrar that is picked
>     by the proxy potentially from a list of multiple registrars.
>
> b) the way (c)BRSKI uses (d)TLS is an application profile of (d)TLS and is hence
>     overriding the requirement for SNI in so far as that it overrides (d)TLS
>     requirements to use SNI and replaces them with the requirement to ignore
>     SNI on the responder if inserted.
>
> I will refer to this major point is in the followin paragraphs for further suggestions
>
>     595	   The SNI issue described below affects [RFC8995] as well, and is
>     596	   reported in errata:https://www.rfc-editor.org/errata/eid6648
>     597	   (https://www.rfc-editor.org/errata/eid6648)
>
> major:
>
> The big open question is whether you want to write this section to indicate it
> applies only to cBRSKI or also to BRSKI. If you write it to also claim that it
> applies to BRSKI, then this section would become a resolution to the mentioned
> RFC8995 errata and this document would become an update to RFC8995. If you do
> so, then keep the above paragraph and explain how this paragraph applies to BRSKI
> and cBRSKI and add appropriate text to an "update to RFC8995" section pointing
> to this section.
>
> If you want to have less work, then write this text only applies to cBRSKI and
> you can remove the paragraph referring to that errata. Less work.
>
> Authors choice. As a contributor, it would be nice if this document would do
> this update to RFC8995 and use this section to resolve that errata.
>
>     598	
>     599	   As the Registrar is discovered by IP address, and typically connected
>     600	   via a Join Proxy, the hostname of the Registrar is not known to the
>     601	   Pledge.  Therefore, it cannot do DNS-ID validation ([RFC9525]) on the
>     602	   Registrar's certificate.  Instead, it must do validation using the
>     603	   voucher.
>     604	
>     605	   Without knowing the hostname, the Pledge cannot put any reasonable
>     606	   value into the [RFC6066] Server Name Indicator (SNI) extension.
>
> minor:
>
> Would suggest to remove that explanation. Future discovery mechanisms could discover hostnames,
> but they would happen in the proxy, and not the pledge. Also, the DNS-ID validation
> is i think totally unrelated to the problem at hand. Instead just use the justification/
> explanation of above a).
>
>     607	   Therefore the Pledge SHOULD omit the SNI extension as per Section 9.2
>     608	   of [RFC8446].
>
> mainor:
>
> Change text according to the justification of a) and the approach of b). MUST seems
> also feasible becauseof approach b).
>
>
>     609	
>     610	   In some cases, particularly while testing BRSKI, a Pledge may be
>     611	   given the hostname of a particular Registrar to connect to directly.
>     612	   Such a bypass of the discovery process may result in the Pledge
>     613	
>     614	
>     615	
>     616	Richardson, et al.       Expires 31 August 2026                [Page 11]
>     617	
>     618	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     619	
>     620	
>     621	   taking a different code branch to establish a DTLS connection, and
>     622	   may result in the SNI being inserted by a library.  For this reason,
>     623	   the Registrar MUST ignore any SNI it receives from a Pledge.
>
> Fine.
>
>     624	
>     625	   A primary motivation for making the SNI ubiquitous in the public web
>     626	   is because it allows for multi-tenant hosting of HTTPS sites on a
>     627	   single (scarce) IPv4 address.  This consideration does not apply to
>     628	   the server function in the Registrar because:
>     629	
>     630	   *  it uses DTLS and CoAP, not HTTPS;
>     631	
>     632	   *  it typically uses IPv6, often [RFC4193] Unique Local Address,
>     633	      which are plentiful;
>     634	
>     635	   *  the server port number is typically discovered, so multiple
>     636	      tenants can be accommodated via unique UDP port numbers.
>
> minor:
>
> That text needs to be rewritten:
>
> If the choice is to make this about cBRSKI and BRSKI, then the cBRSKI justification
> (CoAP) is not relevant anymore.
>
> I would phrase it as follows:
>
> By explicitly not using SNI, (c)BRSKI does not allow hosting multiple domain name
> services on the same IPv4 address and port number.
>
> The desire to support
> this model is primarily driven by the use case in which humans enter domain names
> into applications such as browsers where remembering additional port numbers
> is highly undesirable. Given how (c)BRSKI registrars are intended to be automatically
> discovered, this benefit of SNI is considered insignificant if not irrelevant.
>
> [The following of course only when this text is written to also apply to BRSKI]
>
> Additionally, use of only port 443 for HTTPS may be beneficial in environments where
> firewalls are blocking off other ports because of the firewall administrators (misguided)
> hope that only more trustworthy services are using port 443. These conditions
> may impact the use of Internet (cloud) based (c)BRSKI registrars
> (see I-D.ietf-anima-brski-cloud). It is thus RECOMMENDED to use only port 443
> for cloud based BRKI registrars. No cBRSKI variation of such cloud registrar service
> has currently been defined.
>
>     637	
>     638	6.1.5.  Registrar Server Certificate Requirements
>     639	
>     640	   As per Section 3.6.1 of [RFC7030], the Registrar certificate MUST
>     641	   have the Extended Key Usage (EKU) id-kp-cmcRA.
>
>     641	   This certificate is
>     642	   also used as a TLS Server Certificate, so it MUST also have the EKU
>     643	   id-kp-serverAuth.
>
> minor:
>
> Any reference for the id-kp-serverAuth ? Please ad.
>
>
>     644	
>     645	   See Appendix C.2.2 for an example of a Registrar certificate with
>     646	   these EKUs set.  See Section 7.4 for Registrar client certificate
>     647	   requirements.
>     648	
>     649	6.2.  cBRSKI Join Proxy
>     650	
>     651	   [I-D.ietf-anima-constrained-join-proxy] specifies the details for a
>     652	   stateful or stateless constrained Join Proxy which is equivalent to
>     653	   the BRSKI Proxy defined in [RFC8995], Section 4.  See also Section 10
>     654	   for more details on discovery of a Join Proxy by a Pledge, and
>     655	   discovery of a Registrar by a Join Proxy.
>     656	
>     657	6.3.  Request URIs, Resource Discovery and Content-Formats
>     658	
>     659	   cBRSKI operates using CoAP over DTLS, with request URIs using the
>     660	   coaps scheme.  The Pledge operates in CoAP client role.  To keep the
>     661	   protocol messages small the EST-coaps and cBRSKI request URIs are
>                                    ^ ", "
>
> Run a better spell checker that finds stuff like this please.
>
>     662	   shorter than the respective EST and BRSKI URIs.
>     663	
>     664	   During the cBRSKI onboarding on an IPv6 network these request URIs
>     665	   have the following form:
>     666	
>     667	     coaps://[<link-local-ipv6>]:<port>/.well-known/brski/<short-name>
>     668	     coaps://[<link-local-ipv6>]:<port>/.well-known/est/<short-name>
>     669	
>     670	
>     671	
>     672	Richardson, et al.       Expires 31 August 2026                [Page 12]
>     673	
>     674	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     675	
>     676	
>     677	   where <link-local-ipv6> is the discovered link-local IPv6 address of
>     678	   a Join Proxy, and <port> is the discovered port of the Join Proxy
>     679	   that is used to offer the cBRSKI proxy functionality.
>
> minor:
>
> Is there any reason to exclude the option to use IPv4 ? I have no strong opinions,
> but if cBRSKI is meant to only specify IPv6 (even though it should work fine for
> IPv4 IMHO), then it would be very good to explain and justify this early on in the
> document.
>
> In addition, you should in the beginning of the text specify what "IP" means in
> this document. There is still a wild mix of RFC where one side uses IP to mean
> just IPv4 (as historic RFCs did) and other RFCs mean it to indicate IPv4 and/or IPv6.
> I am not aware though of any RFC where IP mean only IPv6. You can do that, but
> you need to specify this in the beginning of the RFC.
>
>     680	
>     681	   <short-name> is the short resource name for the cBRSKI and EST-coaps
>     682	   resources.  For EST-coaps, Section 5.1 of [RFC9148] defines the CoAP
>     683	   <short-name> resource names.  For cBRSKI, this document defines the
>     684	   short resource names based on the [RFC8995] long HTTP resource names.
>     685	   See Table 1 for a summary of these resource names.
>     686	
>     687	   Section 11 details how the Pledge discovers a Join Proxy link-local
>     688	   address and port in different deployment scenarios.
>     689	
>     690	   The request URI formats defined here enable the Pledge to perform
>     691	   onboarding/enrollment without requiring discovery of the available
>     692	   onboarding options, voucher formats, BRSKI/EST resources, enrollment
>     693	   protocols, and so on.  This is helpful for the majority of
>     694	   constrained Pledges that would support only a single set of these
>     695	   options.  However, for Pledges that do support multiple options,
>     696	   [I-D.ietf-anima-brski-discovery] will define discovery methods so
>     697	   that a Pledge can select the optimal set of options for the current
>     698	   onboarding operation.
>
> minor:
>
> I think this is not correctly explained.
>
>     The request URI formats as well as their request and response formats
>     specified here are the default formats for cBRSKI. Whenever a pledge
>     is looking for just a 'cBRSKI' Registrar (or Proxy), then it is expected
>     to support these format. These formats are choosen as the best choice
>     for the mayority of pledges.
>
>     Variations of cBRSKI with other onboarding options such as other voucher
>     formats or enrolment protocols other than EST need to be discovered by more
>     flexible discovery mechanisms and not every Registrar may support them.
>     See [I-D.ietf-anima-brski-discovery] for discovery options including the
>     ability to only support other than these default options - when needed.
>
>     699	
>     700	   Alternatively, a Pledge could also send CoAP discovery queries
>     701	   (Section 7 of [RFC7252]) to the Registrar to discover detailed
>     702	   options for onboarding and/or enrollment functions.  Supporting these
>     703	   queries is OPTIONAL for both the Pledge and the Registrar.  To
>     704	   clarify which options in particular can be discovered, Appendix E
>     705	   provides an informative overview of what can be discovered and how to
>     706	   discover it.
>
> nit:
>
> Maybe append: When using CoAP discovery queries to the Registrar, it may not
> support the desired options and the pledge needs to poll multiple registrars
> before finding one that supports them.  The mechanisms of
> [I-D.ietf-anima-brski-discovery] avoid such issues.
>
>
>     707	
>     708	   Because a Pledge only has indirect access to the Registrar via a
>     709	   single port on the Join Proxy, the Registrar MUST host all cBRSKI/
>     710	   EST-coaps resources on the same (UDP) server IP address and port.
>     711	   This is the address and port where a Join Proxy would relay DTLS
>     712	   records from the Pledge to.
>
> minor:
>
> I think the even stronger (and primary) justification is
>
> Because a Pledge using cBRSKI
> only builds a single DTLS secure connection (potentially via a Proxy) to
> a Registrar, the Registrar MUST host all cBRSKI and EST-coaps ...
>
> This requirement also eliminates the need to discover (and potentially proxy)
> additional connections for EST-coaps DTLS connections.
>
> aka: suggest to use that text.
>
>     713	
>     714	   Although the request URI templates include IP address, scheme and
>     715	   port, in practice the CoAP request message sent over the secure DTLS
>     716	   connection only encodes the URI path explicitly.  For example, a
>     717	   Pledge that skips resource discovery operations just sends the
>     718	   initial CoAP voucher request as follows:
>     719	
>     720	     REQ: POST /.well-known/brski/rv
>     721	       Content-Format: 836 (application/voucher+cose)
>     722	       Payload       : (COSE-signed Pledge Voucher Request, PVR)
>     723	
>
> minor:
>
> Is there ever a case where the IP address field would be signaled in CoAP ?
> And when that's done, doesn't the Registrar need to ignore the IP address because
> it belongs to the proxy ? If so, it would be good to be explained. Unless
> you explicitly want to specify that level of detail only in constrained proxy
> spec..
>
>     724	
>     725	
>     726	
>     727	
>     728	Richardson, et al.       Expires 31 August 2026                [Page 13]
>     729	
>     730	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     731	
>     732	
>     733	   Note that only content-format 836 (application/voucher+cose) is
>     734	   defined in this document for the payload sent to the voucher request
>     735	   resource (/rv).  Content-format 836 MUST be supported by the
>     736	   Registrar for the /rv resource and it MAY support additional formats.
>     737	   The Pledge MAY also indicate in the request the desired format of the
>     738	   (voucher) response, using the Accept Option.  An example of using
>     739	   this option in the request is as follows:
>     740	
>     741	     REQ: POST /.well-known/brski/rv
>     742	       Content-Format: 836 (application/voucher+cose)
>     743	       Accept        : 836 (application/voucher+cose)
>     744	       Payload       : (COSE-signed Pledge Voucher Request, PVR)
>     745	
>     746	   If the Accept Option is omitted in the request, the response format
>     747	   follows from the request payload format (which is 836).
>     748	
>     749	   Note that this specification allows for application/voucher+cose
>     750	   format requests and vouchers to be transported over HTTPS, as well as
>     751	   for application/voucher-cms+json and other formats yet to be defined
>     752	   over CoAP.  The burden for this flexibility is placed upon the
>     753	   Registrar.  A Pledge on constrained hardware is expected to support a
>     754	   single format only.
>
> minor:
>
> I don't think this paragraph specifies this correctly. Or sells it well.
>
> A pledge that only supports a different variation from the
>
> Note that application/voucher+cose format requests and vouchers can also be transported
> over HTTPS, and application/voucher-cms+json and other formats yet to be defined
> can be transported over CoAP. Any such variation may be more beneficial for a
> specific type of pleges, for example because of the ability to reuse pre-existing
> software modules implementing these options, and when this is the case, a pledge
> may want to implement only such an option.
>
> This flexibility of BRSKI makes it possible to optimize it for different type of pledges
> - at the expense of Registrars having to support multiple options. The use of any such
> variations is outside the scope of this specification. Discovery of Registrars
> supporting specific options is covered in [I-D.ietf-anima-brski-discovery].
>
>
> Aka:
>
> This text should silently imply that there may be the need for additional specifications
> for any such variations - we're never quite sure if there will be a need or not - until
> someone actually implements and tests!
>
>     755	
>     756	   The Pledge and MASA need to support one or more formats (at least
>     757	   format 836) for the voucher and for the voucher request.  The MASA
>     758	   needs to support all formats that the Pledge supports.
>
> minor:
>
> I think that also needs to be refactored into what this spec normtively requires,
> and text over variations, which is just informational. For example:
>
> Like Pledge and Registrar, the MASA also MUST support format 836.
>
> Any variations supported by Pledges also need to be supported by their MASA.
>
>     759	
>     760	6.3.1.  Status Telemetry Returns
>     761	
>     762	   [RFC8995] defines two telemetry returns from the Pledge which are
>     763	   sent to the Registrar.  These are the BRSKI Status Telemetry
>     764	   [RFC8995], Section 5.7 and the Enrollment Status Telemetry [RFC8995],
>     765	   Section 5.9.4.  These are two CoAP POST requests made the by Pledge
>     766	   at two key steps in the process.
>     767	
>     768	   [RFC8995] defines the content of these POST operations in CDDL, which
>     769	   are serialized as JSON.  This document extends this with an
>     770	   additional CBOR format, derived using the CDDL rules in [RFC8610].
>
> minor:
>
> s/This document extends this with/For use with CoAPS, this document replaces this with/
>
>     771	
>     772	   The new CBOR telemetry format has CoAP content-format 60
>     773	   (application/cbor) and MUST be supported by the Registrar for both
>     774	   the /vs and /es resources.  The existing JSON format has CoAP
>     775	   content-format 50 (application/json) and MAY also be supported by the
>     776	   Registrar.  A Pledge MUST use the new CBOR format to send telemetry
>     777	   messages.
>
> minor:
>
> Do we really need the freedom for content-format 50 ? When would this ever happen ?
> What's the benefit ?
>
> Seems its just a redundant option asking for interop trouble.
>
>     778	
>     779	
>     780	
>     781	
>     782	
>     783	
>     784	Richardson, et al.       Expires 31 August 2026                [Page 14]
>     785	
>     786	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     787	
>     788	
>     789	6.3.2.  CoAP Resources Table
>     790	
>     791	   cBRSKI inherits EST-coaps [RFC9148] functions: specifically, the
>     792	   mandatory Simple (Re-)Enrollment (/sen and /sren) and Certification
>     793	   Authority certificates request (/crts).  Support for CSR Attributes
>     794	   Request (/att) and server-side key generation (/skg, /skc) remains
>     795	   optional for the EST-coaps server.
>     796	
>     797	   Table 1 summarizes the resources used in cBRSKI.  It includes both
>     798	   the short-name cBRSKI resources and the EST-coaps resources.
>     799	
>     800	   +=================+====================+===============+============+
>     801	   | BRSKI + EST     | cBRSKI + EST-coaps | Well-known    | Required   |
>     802	   | name            | <short-name>       | URI           | for        |
>     803	   |                 |                    | namespace     | Registrar? |
>     804	   +=================+====================+===============+============+
>     805	   | /enrollstatus   | /es                | brski         | MUST       |
>     806	   +-----------------+--------------------+---------------+------------+
>     807	   | /requestvoucher | /rv                | brski         | MUST       |
>     808	   +-----------------+--------------------+---------------+------------+
>     809	   | /voucher_status | /vs                | brski         | MUST       |
>     810	   +-----------------+--------------------+---------------+------------+
>     811	   | /cacerts        | /crts              | est           | MUST       |
>     812	   +-----------------+--------------------+---------------+------------+
>     813	   | /csrattrs       | /att               | est           | MAY        |
>     814	   +-----------------+--------------------+---------------+------------+
>     815	   | /simpleenroll   | /sen               | est           | MUST       |
>     816	   +-----------------+--------------------+---------------+------------+
>     817	   | /simplereenroll | /sren              | est           | MUST       |
>     818	   +-----------------+--------------------+---------------+------------+
>     819	   | /serverkeygen   | /skg               | est           | MAY        |
>     820	   +-----------------+--------------------+---------------+------------+
>     821	   | /serverkeygen   | /skc               | est           | MAY        |
>     822	   +-----------------+--------------------+---------------+------------+
>     823	
>     824	        Table 1: BRSKI/EST resource name mapping to cBRSKI/EST-coaps
>     825	                            short resource name
>     826	
>     827	6.3.3.  CoAP Uri-Path Abbreviation
>     828	
>     829	   To minimize the size of CoAP request packets on constrained networks,
>     830	   the CoAP Uri-Path-Abbrev Option defined in
>     831	   [I-D.ietf-core-uri-path-abbrev] MUST be supported by the Registrar.
>     832	
>     833	6.4.  CoAP Responses
>     834	
>     835	   [RFC8995], Section 5 defines a number of HTTP response codes that the
>     836	   Registrar is to return when certain conditions occur.
>     837	
>     838	
>     839	
>     840	Richardson, et al.       Expires 31 August 2026                [Page 15]
>     841	
>     842	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     843	
>     844	
>     845	   The 401, 403, 404, 406 and 415 response codes map directly to CoAP
>     846	   codes 4.01, 4.03, 4.04, 4.06 and 4.15 respectively.
>     847	
>     848	   The 202 Retry process which may occur in the voucher request, is to
>     849	   be handled in the same way as the Section 5.7 of [RFC9148] process
>     850	   for Delayed Responses.
>     851	
>     852	6.5.  Extensions to EST-coaps
>     853	
>     854	   This section defines extensions to EST-coaps for Pledges (during
>     855	   initial onboarding), EST-coaps clients (after initial onboarding) and
>     856	   Registrars (that implement an EST-coaps server).  Note that a device
>     857	   that is already onboarded is not called "Pledge" in this section: it
>     858	   now acts in the role of an EST-coaps client.
>     859	
>     860	6.5.1.  Pledge Enrollment Procedure
>     861	
>     862	   This section defines optimizations for the EST-coaps protocol as used
>     863	   by a Pledge.  These aim to reduce payload sizes and the number of
>                  ^^^^^^
>
> nit: in 6.5 you just said you wanted to call it EST-coaps client...
>
> maybe go back to 6.5 and loosen up the text by saying that this section _also_
> uses the term EST-coaps client for the Pledge.
>
>     864	   messages (round-trips) required for the initial EST enrollment.
>     865	
>     866	   A Pledge SHOULD NOT perform the optional EST-coaps "CSR attributes
>     867	   request" (/att).  Instead, the Pledge selects the attributes to
>
> minor:
>
> Add an explanation, even if just forward pointer to why not perform CSR attributes.
>
>     868	   include in the CSR as specified below.
>     869	
>     870	   One or more Subject Distinguished Name fields MUST be included in the
>     871	   CSR.  If the Pledge has no specific information on what attributes/
>     872	   fields are desired in the CSR, which is the common case, it MUST use
>     873	   the Subject Distinguished Name fields from its IDevID unmodified.
>     874	   Note that a Pledge MAY receive such specific information via the
>     875	   voucher data (encoded in a vendor-specific way, or as defined by a
>     876	   future specification) or via some other, out-of-band means.
>     877	
>     878	   A Pledge uses the following optimized EST-coaps procedure:
>     879	
>     880	   1.  If the voucher, that validates the current Registrar, contains a
>     881	       single pinned domain CA certificate, the Pledge provisionally
>     882	       considers this certificate as the EST trust anchor, as if it were
>     883	       the result of a "CA certificates request" (/crts) to the
>     884	       Registrar.
>     885	
>     886	   2.  Using this CA certificate as trust anchor it proceeds with EST
>     887	       simple enrollment (/sen) to obtain a provisionally trusted LDevID
>     888	       certificate.
>     889	
>     890	   3.  If the Pledge determines that the pinned domain CA is (1) a root
>     891	       CA certificate and (2) signer of the LDevID certificate, the
>     892	       Pledge accepts the pinned domain CA certificate as the legitimate
>     893	
>     894	
>     895	
>     896	Richardson, et al.       Expires 31 August 2026                [Page 16]
>     897	
>     898	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     899	
>     900	
>     901	       trust anchor root CA for the Registrar's domain.  It also accepts
>     902	       the LDevID certificate as its new LDevID identity.  And steps 4
>     903	       and 5 are skipped.
>     904	
>     905	   4.  Otherwise, if the step 3 condition was not met, the Pledge MUST
>     906	       perform a "CA certificates request" (/crts) to the EST server to
>     907	       obtain the full set of EST CA trust anchors.  It then MUST
>     908	       attempt to chain the LDevID certificate to one of the CAs in the
>     909	       set.
>     910	
>     911	   5.  If the Pledge cannot obtain the set of CA certificates, or it is
>     912	       unable to create the chain as defined in step 4, the Pledge MUST
>     913	       abort the enrollment process and report the error using the
>     914	       enrollment status telemetry (/es).
>     915	
>     916	6.5.2.  Renewal of CA certificates
>     917	
>     918	   An EST-coaps client that has an idea of the current time (internally,
>     919	   or via Network Time Protocol) SHOULD consider the validity time of
>
> minor:
>
> via network clock synchronization such as (but not limited to) NTP
>
> NTP is a well-known RFC-editor abbreviation, so no need to expand or provide reference
>
>     920	   the trust anchor CA(s), and MAY begin requesting new trust anchor
>     921	   certificates(s) using the /crts request when the CA has 50% of it's
>     922	   validity time (notAfter - notBefore) left.  A client without access
>     923	   to the current time cannot decide if trust anchor CA(s) have expired,
>     924	   and SHOULD poll periodically for a new trust anchor certificate(s)
>     925	   using the /crts request at an interval of approximately 1 month.  An
>
> minor:
>
> If the pledge has no idea of clock, not even when operating then it also does
> not have an idea of what 1 month is.... Unless change that to something like
> "1 month of some pledge measured operating time including but not limited to uptime".
>
> nit:
>
> maybe new pararaph before the following
>
> mayor:
>
> The problem of clockless pledges does not only apply to the renewal of the CA
> certificates, but also to its own LDevID. So it would be useful to
> structure this text so that this clocking stuff is not just inside the section 6.5.2
>
>
>     926	   EST-coaps server SHOULD include the CoAP ETag Option ([RFC7252],
>     927	   Section 5.10.6)in every response to a /crts request, to enable
>     928	   clients to perform low-overhead validation whether their trust anchor
>     929	   CA is still valid.  The EST-coaps client SHOULD store the ETag
>     930	   resulting from a /crts response in memory and SHOULD use this value
>     931	   in an ETag Option in its next GET /crts request.
>     932	
>     933	6.5.3.  Change of Domain Trust Anchor(s)
>     934	
>     935	   The domain trust anchor(s) may change over time.  Such a change may
>     936	   happen due to relocation of the client device to a new domain, a new
>     937	   subdomain, or due to a key update of a trust anchor as described in
>     938	   [RFC4210], Section 4.4.
>     939	
>     940	   From the client's viewpoint, a trust anchor change happens during
>     941	   EST-coaps re-enrollment: since a change of domain CA requires all
>     942	   devices operating under the old domain CA to acquire a new LDevID
>     943	   certificate issued by the new domain CA.  A client's re-enrollment
>     944	   may be triggered by various events, such as an instruction to re-
>     945	   enroll sent by a domain entity, or an imminent expiry of its LDevID
>     946	   certificate, or other.  How the re-enrollment is explicitly triggered
>     947	   on the client by a domain entity, such as a commissioner or a
>     948	   Registrar, is out of scope of this specification.
>
> minor:
>
> It would be nice to keep two things apart and describe them also that way.
>
> a) This spec should be completely sufficient for the pledge to do the right
> thing to get its LDevID and trust anchors updated before they expire or
> whenever som other error makes it obvious to the pledge to get them updated.
> No "outside of scope" problems here!
>
> b) Any additional options for change in trust anchors or LDevID - which may
> depend on out-of-scope additional components such as special triggers.
>
>     949	
>     950	
>     951	
>     952	Richardson, et al.       Expires 31 August 2026                [Page 17]
>     953	
>     954	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>     955	
>     956	
>     957	   The mechanism described in [RFC7030], Section 4.1.3 and [RFC4210],
>     958	   Section 4.4 for root CA key update requires four certificates:
>     959	   OldWithOld, OldWithNew, NewWithOld, and NewWithNew.  Of these four,
>     960	   the OldWithOld certificate is already stored in the client's Explicit
>     961	   TA database.  The other certificates will be provided to the client
>     962	   in a /crts response, during the EST-coaps re-enrollment procedure.
>     963	
>     964	6.5.4.  Re-enrollment Procedure
>
> minor:
>
> If i am not mistaken, we only talk about Re-enrollment when the client identifies
> itself with something else, but not the existing LDevID. Otherwise we are talking
> about Certificate renewal/rekeying. Rekeying is the same as renewal, except that
> the client also creates a new key-pair for the new certificate. Whether or not
> that is necessary/desirable is i think within these fully automated cBRSKI procedure
> solely responsiblity of the pledge implementation.
>
> But in any case, call this section something like LDevID Renewal/Rekeying - and
> when you discuss procedure for when the existing LDevID does not work for
> Renewal/Rekeying, then call it Re-Enrollment.
>   
> And i think all of this would logically look better if it comes before the
> more complex (and less often happening) CA cert change section (reorder).
>
>     965	
>     966	   For re-enrollment, the EST-coaps client MUST support the following
>     967	   EST-coaps procedure.  During this procedure the EST-coaps server MAY
>     968	   re-enroll the client into a new domain or into a new sub-CA within a
>     969	   larger domain.
>     970	
>     971	   1.  The client connects with DTLS to the EST-coaps server, and
>     972	       authenticates with its present domain certificate (LDevID) as
>     973	       usual.  The EST-coaps server authenticates itself with its domain
>     974	       RA certificate that is currently trusted by the client, i.e. it
>     975	       chains to a trust anchor CA that the client has stored in its
>     976	       Explicit TA database.  This is the OldWithOld trust anchor.  The
>     977	       client checks that the server is a Registration Authority (RA) of
>     978	       the domain as required by Section 3.6.1 of [RFC7030] before
>     979	       proceeding.
>     980	
>     981	   2.  The client performs the simple re-enrollment request (/sren) and
>     982	       upon success it obtains a new LDevID certificate.
>     983	
>     984	   3.  The client verifies the new LDevID certificate against its
>     985	       Explicit TA database.  If the new LDevID chains successfully to a
>     986	       TA, this means trust anchors did not significantly change and the
>     987	       client MAY skip retrieving the current CA certificates using the
>     988	       "CA certificates request" (/crts).  If it does not chain
>     989	       successfully, it means trust anchor(s) were changed significantly
>     990	       and the client MUST retrieve the new domain trust anchors using
>     991	       the "CA certificates request" (/crts).
>     992	
>     993	   4.  If the client retrieved new trust anchor(s) in step 3, then it
>     994	       MUST verify that the new LDevID certificate it obtained in step 2
>     995	       chains with the new trust anchor(s).  If it chains successfully,
>     996	       the client stores the new trust anchor(s) in its Explicit TA
>     997	       database, accepts the new LDevID certificate and stops using its
>     998	       prior LDevID certificate.  If it does not chain successfully, the
>     999	       client MUST NOT update its LDevID certificate, and it MUST NOT
>    1000	       update its Explicit TA database, and the client MUST abort the
>    1001	       enrollment process and MUST attempt to report the error to the
>    1002	       EST-coaps server using enrollment status telemetry (/es).
>    1003	
>    1004	
>    1005	
>    1006	
>    1007	
>    1008	Richardson, et al.       Expires 31 August 2026                [Page 18]
>    1009	
>    1010	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1011	
>    1012	
>    1013	   Note that even though the EST-coaps client may skip the /crts request
>    1014	   in step 3 at this time, it SHOULD still support renewal of the trust
>    1015	   anchors as detailed in Section 6.5.2.
>    1016	
>    1017	   Note that an EST-coaps server that is also a Registrar will already
>    1018	   support the enrollment status telemetry resource (/es) in step 4,
>    1019	   while an EST-coaps server that purely implements [RFC9148], and not
>    1020	   the present specification, will not support this resource.
>
> minor:
>
> I may have missed it, but before this paragraph you did not talk about a
> pure EST-coaps server that is not also a registrar - but only used renewal or
> re-enrollment. Or how to discover them. In RFC8994 i explicitly wanted to support
> that option so i even specified discovery options for that.
>
> Not sure what you find important enough to specify here, but it should be clear.
> For example, that the procedures mandated to be supported by Pledges only
> include renewal/re-enrolment (LdevID and CA certificates) from Registrars - to
> avoid additional discovery mechanism needs. And also put that type of discussion
> further towards the beginning of this whole "Cert lifecycle requirements".
>
>    1021	
>    1022	6.5.5.  Multipart Content-Format for CA certificates (/crts) Resource
>    1023	
>    1024	   In EST-coaps [RFC9148] the PKCS#7 container format is used for CA
>    1025	   certificates distribution.  Because the PKCS#7 format is only used as
>    1026	   a certificate container and no additional security is applied on the
>    1027	   container, it becomes attractive to replace this format by something
>    1028	   simpler, on a constrained Pledge: so that additional PKCS#7 code is
>    1029	   avoided.  Therefore, this document defines a container format using
>    1030	   the [RFC8710] application/multipart-core media type (CoAP content-
>    1031	   format 62).  This is beneficial since a Pledge necessarily already
>    1032	   supports CBOR parsing, so there is little code overhead to support
>    1033	   this CBOR-based container format.
>    1034	
>    1035	   A Registrar or EST-coaps server MUST support content-format 62 for
>    1036	   the /crts resource.  The multipart collection MUST contain the
>    1037	   individual CA certificates, each encoded as an application/pkix-cert
>    1038	   (287) representation.  Future documents may define other certificate
>    1039	   formats: the multipart collection can handle any future types.  The
>    1040	   order of CA certificates MUST be in the CA hierarchy order starting
>    1041	   from the issuer of the client's LDevID first, up to the highest-level
>    1042	   domain CA, then optionally followed by any further CA certificates
>    1043	   that are not part of this hierarchy.  These further CA certificates
>    1044	   may be Third-party TAs as defined in [RFC7030].  The highest-level
>    1045	   domain CA may or may not be a root CA certificate.
>    1046	
>    1047	   As an example, for the two-level CA domain PKI of Figure 1 the
>    1048	   multipart container will contain two representations:
>    1049	
>    1050	   [ <domain sub-CA cert (2)> , <domain CA cert (1)> ]
>    1051	
>    1052	   Encoded as an application/multipart-core CBOR array this is (shown in
>    1053	   CBOR diagnostic notation):
>    1054	
>    1055	   [ 287, h'3082' ... 'd713', 287, h'3082' ... 'a034' ]
>    1056	
>    1057	   The total number of CA certificates SHOULD be 1, 2 or 3 and not
>    1058	   higher to prevent constrained Pledges from running out of memory for
>    1059	   the trust anchor storage (Explicit TA database).  However if a domain
>    1060	   operator can guarantee that any Pledges enrolled in its network can
>    1061	
>    1062	
>    1063	
>    1064	Richardson, et al.       Expires 31 August 2026                [Page 19]
>    1065	
>    1066	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1067	
>    1068	
>    1069	   support larger sets of CA certificates, the total number MAY be
>    1070	   configured as higher than 3.  To facilitate a reliable transfer of
>    1071	   large payloads over constrained networks, the server MUST support
>    1072	   CoAP Block-wise transfer for the /crts response.  The server MUST
>    1073	   also support the Size2 Option [RFC7959] to provide the total resource
>    1074	   length in bytes, when requested by a client.
>    1075	
>    1076	   Implementation notes: a client that receives the first block of
>    1077	   payload data from the server, can already inspect the total number of
>    1078	   CA certificates by decoding the first byte of the payload.  In CBOR
>    1079	   encoding, the respective first bytes 0x81-0x97 represent an array
>    1080	   with length 1-23, respectively.  Furthermore, the length in bytes of
>    1081	   the first CA certificate can be already determined by decoding the
>    1082	   first bytes of the second element, because the CBOR encoding for
>    1083	   binary string includes the length of this string.  A client that
>    1084	   requires an estimate of the total resource size (to be returned as
>    1085	   part of the first Block2 response from the server) can use a Size2
>    1086	   Option with value 0 in its request.  Knowing the overall progress of
>    1087	   the data transfer may be helpful in certain cases, e.g. when a Pledge
>    1088	   provides visual progress information on the onboarding progress.
>    1089	
>    1090	6.6.  Registrar Extensions
>    1091	
>    1092	   Before a Registrar forwards a COSE-signed voucher from MASA to the
>    1093	   Pledge, it MUST remove any 'x5bag' or 'x5chain' unprotected COSE
>    1094	   header attributes (which are defined in [RFC9360]).  The contents of
>    1095	   these unprotected attributes are solely for validation/logging use by
>    1096	   the Registrar.  Removing these attributes reduces the voucher size on
>    1097	   the constrained network path to the Pledge.
>    1098	
>    1099	   The content-format 60 (application/cbor) MUST be supported by the
>    1100	   Registrar for the /vs and /es resources.
>    1101	
>    1102	   Content-format 836 (application/voucher+cose) MUST be supported by
>    1103	   the Registrar for the /rv resource for CoAP POST requests, both as
>    1104	   request payload and as response payload.
>    1105	
>    1106	   Content-format 287 (application/pkix-cert) MUST be supported by the
>    1107	   Registrar as a response payload for the /sen and /sren resources.
>    1108	
>    1109	
>    1110	
>    1111	
>    1112	
>    1113	
>    1114	
>    1115	
>    1116	
>    1117	
>    1118	
>    1119	
>    1120	Richardson, et al.       Expires 31 August 2026                [Page 20]
>    1121	
>    1122	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1123	
>    1124	
>    1125	   When a Registrar receives a "CA certificates request" (/crts) request
>    1126	   with a CoAP Accept Option with value 287 (application/pkix-cert) it
>    1127	   MUST return only the single CA certificate that is the envisioned or
>    1128	   actual CA authority for the current, authenticated Pledge making the
>    1129	   request.  An exception to this rule is when the domain has been
>    1130	   configured to operate with multiple CA trust anchors exclusively:
>    1131	   then the Registrar returns a 4.06 Not Acceptable error to signal to
>    1132	   the client that it needs to request another content-format that
>    1133	   supports retrieval of multiple CA certificates.
>    1134	
>    1135	7.  BRSKI-MASA Protocol
>    1136	
>    1137	   This section describes extensions to and clarifications of the BRSKI-
>    1138	   MASA protocol between Registrar and MASA.
>    1139	
>    1140	7.1.  Protocol and Formats
>    1141	
>    1142	   Section 5.4 of [RFC8995] describes a connection between the Registrar
>    1143	   and the MASA as being a normal TLS connection using HTTPS.  This
>    1144	   document does not change that.
>    1145	
>    1146	   The MASA only needs to support formats for which it has constructed
>
> nit:
>    how about "supports Pledges" instead of "has constructed Pledges".
>    Nobody knows if a Masa really is the same company as a manufacturer...
>
>    1147	   Pledges that use that format.
>    1148	
>    1149	   The Registrar MUST use the same format for the RVR as the Pledge used
>    1150	   for its PVR.  Specifically, the Registrar MUST use the media type
>    1151	   application/voucher+cose for its voucher request to MASA, when the
>    1152	   Pledge used content-format 836 in the payload of its request to the
>    1153	   Registrar.
>    1154	
>    1155	   The Registrar indicates the voucher format (by media type) it wants
>    1156	   to receive from MASA using the HTTP Accept header.  This format MUST
>    1157	   be the same as the format of the PVR, so that the Pledge can parse
>    1158	   the resulting voucher.
>    1159	
>    1160	   At the moment of writing the creation of CoAPS based MASAs is deemed
>    1161	   unrealistic and unnecessary.  The use of CoAP for the BRSKI-MASA
>    1162	   connection is out of scope but can be the subject of another
>    1163	   document.  Some consideration was made to specify CoAP support for
>    1164	   consistency, but:
>    1165	
>    1166	   *  the Registrar is not expected to be so constrained that it cannot
>
> nit: is expected not to be so constrained
>
>    1167	      support HTTPS client connections.
>    1168	
>    1169	   *  the technology and experience to build Internet-scale HTTPS
>    1170	      responders (which the MASA is) is common, while the experience
>    1171	      doing the same for CoAP is much less common.
>
> nit: CoAPS
>    1172	
>    1173	
>    1174	
>    1175	
>    1176	Richardson, et al.       Expires 31 August 2026                [Page 21]
>    1177	
>    1178	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1179	
>    1180	
>    1181	   *  a Registrar is likely to provide onboarding services to both
>    1182	      constrained and non-constrained devices.  Such a Registrar would
>    1183	      need to speak HTTPS anyway.
>    1184	
>    1185	   *  a manufacturer is likely to offer both constrained and non-
>    1186	      constrained devices, so there may in practice be no situation in
>    1187	      which the MASA could be CoAP-only.  Additionally, as the MASA is
>    1188	      intended to be a function that can easily be outsourced to a
>    1189	      third-party service provider, reducing the complexity would also
>    1190	      seem to reduce the cost of that function.
>    1191	
>    1192	   *  security-related considerations: see Section 14.3.
>
> All fine!
>
>    1193	
>    1194	7.2.  Registrar Voucher Request
>    1195	
>    1196	   If the PVR contains a proximity assertion, the Registrar MUST
>    1197	   propagate this assertion into the RVR by including the 'assertion'
>    1198	   attribute with the value "proximity".  This conforms to the example
>    1199	   in Section 3.3 of [RFC8995] of carrying the assertion forward.
>    1200	
>    1201	7.3.  MASA and the Server Name Indicator (SNI)
>    1202	
>    1203	   A TLS/HTTPS connection is established between the Registrar and MASA.
>    1204	
>    1205	   Section 5.4 of [RFC8995] explains this process, and there are no
>    1206	   externally visible changes made by this document.  A MASA that
>    1207	   supports the unconstrained voucher formats should be able to support
>    1208	   constrained voucher formats equally well.
>    1209	
>    1210	   There is no requirement that a single MASA be used for both
>    1211	   constrained and unconstrained voucher requests: the choice of MASA is
>    1212	   determined by the id-mod-MASAURLExtn2016 extension contained in the
>    1213	   IDevID, so it can be determined by the manufacturer.
>    1214	
>    1215	   The Registrar MUST do DNS-ID checks ([RFC9525]) on the contents of
>    1216	   the certificate provided by the MASA during the TLS handshake.
>
> minor:
>
> How about adding:
>
> To support MASA across non Internet networks where DNS-ID is not a desirable
> or available dependency, Registrar MAY also support other forms of authenticating the
> MASA certificate provided during TLS handshake.
>
>    1217	
>    1218	   In contrast to the Pledge/Registrar situation, the Registrar always
>    1219	   knows the name of the MASA, and MUST always include an [RFC6066]
>    1220	   Server Name Indicator.  The SNI is optional in TLS 1.2, but common.
>    1221	   The SNI is considered mandatory with TLS 1.3.
>    1222	
>    1223	   The presence of the SNI extension is required by the MASA, in order
>    1224	   for the MASA's server to host multiple tenants (for different
>    1225	   customers).
>
> minor: would remove "for different customers" because it could be different
> services (same customer). But would add
>
> "and to recognize possible DNS errors (such as misconfigurations)".
>
> E.g.: when Registrar get DNS error, connects to an IP address that doesn't even
> belong to the DNS-ID it wanted to connect to, then only SNI allows server to
> recognize that problem. And useful to remember that because when someone doesn't
> need multi-tenancy, they may think SNI is useless. It's not.
>
>    1226	
>    1227	
>    1228	
>    1229	
>    1230	
>    1231	
>    1232	Richardson, et al.       Expires 31 August 2026                [Page 22]
>    1233	
>    1234	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1235	
>    1236	
>    1237	7.4.  Registrar Client Certificate Requirements
>    1238	
>    1239	   The Registrar SHOULD use a TLS Client Certificate to authenticate to
>    1240	   the MASA per Section 5.4.1 of [RFC8995].  If the certificate that the
>    1241	   Registrar uses is marked as a id-kp-cmcRA certificate, via Extended
>    1242	   Key Usage, then it MUST also have the id-kp-clientAuth EKU attribute
>    1243	   set.
>    1244	
>    1245	   In summary, for typical Registrar use, where a single Registrar
>    1246	   certificate is used for both client and server roles, the certificate
>    1247	   MUST have an EKU set with at least all of id-kp-cmcRA, id-kp-
>    1248	   serverAuth, and id-kp-clientAuth.
>    1249	
>    1250	8.  Pinning in Voucher Artifacts
>    1251	
>    1252	   The voucher is a statement by the MASA for use by the Pledge that
>    1253	   provides the identity of the Pledge's owner.  This section describes
>    1254	   how the owner's identity is determined and how it is specified within
>    1255	   the voucher.
>
> Nit: That is a nice statement but does not mention at all how it relates to pinning.
> Suggest text that does. For example:
>
> Vouchers allow to carry one certificate of the owner in the so-called
> 'pinned-domain-certificate' field. Pledges can use this certificate as the trust
> anchor for the owner, eliminating the need for further PKI communications in
> many cases. This section describes that mechanism.
>
> minor Q: Normal 'pinning' does actually pin the public key, not the certificate. Do
> we describe this in RFC8995 or here ? I think not. Should we ?
>
>    1256	
>    1257	8.1.  Registrar Identity Selection and Encoding
>    1258	
>    1259	   Section 5.5 of [RFC8995] describes BRSKI policies for selection of
>    1260	   the owner identity.  It indicates some of the flexibility enabled for
>    1261	   the Registrar, and recommends the Registrar to include only
>    1262	   certificates in the voucher request (CMS) signing structure that
>
> nit:
>
> next paragraph uses term RVR, here you use "voucher request". Pick one for
> consistency.
>
>    1263	   participate in the certificate chain that is to be pinned.
>    1264	
>    1265	   The MASA is expected to evaluate the certificates included in an RVR,
>    1266	   forming them into a chain with the Registrar's (signing) identity on
>    1267	   one end.  Then, it pins a certificate selected from this chain
>    1268	   according to its pinning policy (Section 8.2).
>    1269	
>    1270	   For instance, for a domain with a two-level certification authority
>    1271	   (see Figure 1), where the RVR has been signed by "domain Registrar",
>    1272	   the RVR includes the chain formed by the domain Registrar EE
>    1273	   certificate, the domain Sub-CA certificate, and the domain CA trust
>    1274	   anchor certificate.  The arrows in the figure indicate the issuing of
>    1275	   a certificate, i.e. author of (1) issued (2) and author of (2) issued
>    1276	   (3).
>
> nit: introduce the paragraph with something like "the following example will
> be used as a reference for explanations and speciications in the following
> sections" - that's helpful to make readers understand why this is here.
>    1277	
>    1278	
>    1279	
>    1280	
>    1281	
>    1282	
>    1283	
>    1284	
>    1285	
>    1286	
>    1287	
>    1288	Richardson, et al.       Expires 31 August 2026                [Page 23]
>    1289	
>    1290	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1291	
>    1292	
>    1293	    .------------------.
>    1294	    |  domain CA (1)   |
>    1295	    |  trust anchor    |
>    1296	    '------------------'
>    1297	              |
>    1298	              v
>    1299	       .------------.
>    1300	       | domain (2) |
>    1301	       | Sub-CA     |
>    1302	       '------------'
>    1303	              |
>    1304	              v
>    1305	     .----------------.
>    1306	     |   domain       |
>    1307	     | Registrar (3)  |
>    1308	     | EE certificate |
>    1309	     '----------------'
>    1310	
>    1311	                         Figure 1: Two-Level CA PKI
>    1312	
>    1313	   When the Registrar is using a COSE-signed RVR, the COSE_Sign1 object
>    1314	   contains a protected and an unprotected header.  The Registrar MUST
>    1315	   place all the certificates needed by MASA to validate the signature
>    1316	   chain for its RVR in an 'x5bag' attribute in either the protected or
>    1317	   the unprotected header as defined in Section 2 of [RFC9360].
>
> nit: even just as a single paragraph now this is not BRSKI+cBRSKI
> explanation but new functionality. Break up 8.1, make this paragraph
> separate section , e.g.: Registrar Certificate(s) COSE Encoding" or the like
>
>    1318	
>    1319	8.2.  MASA Pinning Policy
>    1320	
>    1321	   The MASA, having assembled and verified the certificate chain that
>    1322	   signed the RVR then needs to select a certificate to pin.  (For the
>    1323	   case that only the Registrar's End-Entity certificate is included,
>    1324	   only this certificate can be selected and this section does not
>    1325	   apply.)  The BRSKI policy for pinning by the MASA as described in
>    1326	   Section 5.5.2 of [RFC8995] leaves much flexibility to the
>    1327	   manufacturer.
>    1328	
>    1329	   The present document adds the following rules to the MASA pinning
>    1330	   policy to reduce the network load on the constrained network side:
>
> nit: how is network load reduced ? Minimum voucher size ? something else ?
> Add an explanation for the claim.
>
>    1331	
>    1332	   1.  for a voucher containing a nonce, it SHOULD pin the most specific
>    1333	       (lowest-level) CA certificate in the chain.
>    1334	
>    1335	   2.  for a nonceless voucher, it SHOULD pin the least-specific
>    1336	       (highest-level) CA certificate in the chain that is allowed under
>    1337	       the MASA's policy for this specific domain.
>    1338	
>    1339	
>    1340	
>    1341	
>    1342	
>    1343	
>    1344	Richardson, et al.       Expires 31 August 2026                [Page 24]
>    1345	
>    1346	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1347	
>    1348	
>    1349	   The rationale for 1. is that in case of a voucher with nonce, the
>    1350	   voucher is valid only in scope of the present DTLS connection between
>    1351	   Pledge and Registrar anyway, so there is no benefit to pin a higher-
>    1352	   level CA.  By pinning the most specific CA the constrained Pledge can
>    1353	   validate its DTLS connection using less crypto operations.  The
>    1354	   rationale for pinning a CA instead of the Registrar's End-Entity
>    1355	   certificate directly is based on the following benefit on constrained
>    1356	   networks: the pinned certificate in the voucher can in common cases
>    1357	   be re-used as a Domain CA trust anchor during the EST enrollment and
>    1358	   during the operational phase that follows after EST enrollment, as
>    1359	   explained in Section 6.5.1.
>    1360	
>    1361	   The rationale for 2. follows from the flexible BRSKI trust model for,
>    1362	   and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of
>    1363	   [RFC8995]).
>    1364	
>    1365	   Referring to the example of Figure 1 of a domain with a two-level
>    1366	   certification authority, the most specific CA ("Sub-CA") is the
>    1367	   identity that is pinned by MASA in a nonced voucher.
>    1368	
>    1369	   In case of a nonceless voucher, depending on the trust level, the
>    1370	   MASA pins the "Registrar" certificate (low trust in customer), or the
>    1371	   "Sub-CA" certificate (in case of medium trust, implying that any
>    1372	   Registrar of that sub-domain is acceptable), or even the "domain CA"
>    1373	   certificate (in case of high trust in the customer, and possibly a
>    1374	   pre-agreed need of the customer to obtain flexible long-lived
>    1375	   vouchers).
>    1376	
>    1377	8.3.  Pinning of Raw Public Keys (RPK)
>    1378	
>    1379	   Specifically for the most-constrained use cases, the pinning of the
>    1380	   raw public key (RPK) of the Registrar is also supported in the
>    1381	   constrained voucher, instead of a PKIX certificate.  This is used by
>    1382	   the RPK variant of cBRSKI described in Section 13, but it can also be
>    1383	   used in the default cBRSKI flow as a means to reduce voucher size.
>    1384	
>    1385	   For both cases, if an RPK is pinned, it MUST be the RPK of the
>    1386	   Registrar, which equals the public key of the Registrar's EE
>    1387	   certificate.
>    1388	
>    1389	   When the Pledge is known by MASA to support the RPK variant only, the
>    1390	   voucher produced by the MASA pins the RPK of the Registrar in either
>    1391	   the 'pinned-domain-pubk' or 'pinned-domain-pubk-sha256' attribute of
>    1392	   the voucher data.  This is described in more detail in [RFC8366bis]
>    1393	   and Section 13.
>    1394	
>    1395	
>    1396	
>    1397	
>    1398	
>    1399	
>    1400	Richardson, et al.       Expires 31 August 2026                [Page 25]
>    1401	
>    1402	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1403	
>    1404	
>    1405	   When the Pledge is known by MASA to support PKIX operations, the
>    1406	   'pinned-domain-cert' attribute present in a voucher normally pins a
>    1407	   domain certificate.  That can be either the End-Entity certificate of
>    1408	   the Registrar, or the certificate of a domain CA, as specified in
>    1409	   Section 8.2.  However, if the Pledge is known by MASA to also support
>    1410	   RPK pinning and the MASA policy intends to pin the Registrar in the
>    1411	   voucher (and not a CA), then MASA SHOULD pin the RPK (RPK3 in
>    1412	   Figure 2) of the Registrar instead of the Registrar's End-Entity
>    1413	   certificate to save space in the voucher.
>    1414	
>    1415	                                             .-------------.
>    1416	    .------------.                           | private     |
>    1417	    | pub-CA (1) |                           | root-CA (1) |
>    1418	    '------------'                           '-------------'
>    1419	           |                                        |
>    1420	           v             .-------------.            v
>    1421	    .------------.       | private     |     .------------.
>    1422	    | sub-CA (2) |       | root-CA (1) |     | sub-CA (2) |
>    1423	    '------------'       '-------------'     '------------'
>    1424	           |                    |                   |
>    1425	           v                    v                   v
>    1426	   .--------------.     .--------------.     .--------------.
>    1427	   | Registrar(3) |     | Registrar(3) |     | Registrar(3) |
>    1428	   |    RPK3      |     |    RPK3      |     |    RPK3      |
>    1429	   '--------------'     '--------------'     '--------------'
>    1430	
>    1431	              Figure 2: Raw Public Key (RPK) pinning examples
>    1432	
>    1433	9.  Artifacts
>    1434	
>    1435	   The YANG ([RFC7950]) module and CBOR serialization for the
>    1436	   constrained voucher as used by cBRSKI are described in [RFC8366bis].
>    1437	   That document also assigns SID values to YANG elements in accordance
>
> nit: values (as required for CBOR encoding)
>
> Yes, maybe everybody should know this already... maybe not...
>
>    1438	   with [RFC9254] and [RFC9595].  The present section provides some
>    1439	   examples of these artifacts and defines a new signature format for
>    1440	   these, using COSE.
>    1441	
>    1442	   Compared to the first voucher request definition done in [RFC8995],
>    1443	   the constrained voucher request adds the attributes 'proximity-
>    1444	   registrar-pubk' and 'proximity-registrar-pubk-sha256'.  One of these
>    1445	   is optionally used to replace the 'proximity-registrar-cert'
>    1446	   attribute, for a smaller voucher request data size - useful for the
>    1447	   most constrained cases.
>    1448	
>    1449	   The constrained voucher adds the attributes 'pinned-domain-pubk' and
>    1450	   'pinned-domain-pubk-sha256' to pin an RPK.  One of these is
>    1451	   optionally used instead of the 'pinned-domain-cert' attribute, for a
>    1452	   smaller voucher data size.
>    1453	
>    1454	
>    1455	
>    1456	Richardson, et al.       Expires 31 August 2026                [Page 26]
>    1457	
>    1458	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1459	
>    1460	
>    1461	9.1.  Example Artifacts
>    1462	
>    1463	9.1.1.  Example Pledge Voucher Request (PVR) Artifact
>    1464	
>    1465	   Below, example voucher data from a constrained voucher request (PVR)
>    1466	   from a Pledge to a Registrar is shown in CBOR diagnostic notation.
>    1467	   Long CBOR byte strings have been shortened for readability, using the
>    1468	   ellipsis ("...") to indicate elided bytes.  This notation is defined
>    1469	   in [I-D.ietf-cbor-edn-literals].  The enum value of the assertion
>    1470	   attribute is 2 for the 'proximity' assertion as defined in
>    1471	   Section 8.3 of [RFC8366bis].
>    1472	
>    1473	   {
>    1474	    2501: {          / SID=2501,ietf-voucher-request:voucher|voucher /
>    1475	      1: 2,                      / SID=2502, assertion 2 = "proximity"/
>    1476	      7: h'831D5198A6CA2C7F',    / SID=2508, nonce                    /
>    1477	     12: h'30593013' ... '9A54', / SID=2513, proximity-registrar-pubk /
>    1478	     13: "JADA123456789"         / SID=2514, serial-number            /
>    1479	    }
>    1480	   }
>
> nit: might be helpful to add a small paragraph explaining how this is delta-encoded,
> that the receiver knows it is delta encoded from the context of being an encoded
> YANG, and that hence 1,7,12,13 map to e.g.: 2501+1, 2501+7, ...
>    
>    1481	
>    1482	   The Pledge has included the attribute 'proximity-registrar-pubk'
>    1483	   which carries the public key of the Registrar, instead of including
>    1484	   the full Registrar certificate in a 'proximity-registrar-cert'
>    1485	   attribute.  This is done to reduce the size of the PVR.  Also note
>    1486	   that the Pledge did not include the 'created-on' attribute since it
>    1487	   lacks an internal real-time clock and has no knowledge of the current
>    1488	   time at the moment of performing the onboarding.
>    1489	
>    1490	9.1.2.  Example Registrar Voucher Request (RVR) Artifact
>    1491	
>    1492	   Next, example voucher data from a constrained voucher request (RVR)
>    1493	   from a Registrar to a MASA is shown in CBOR diagnostic notation.  The
>    1494	   Registrar has created this request triggered by the reception of the
>    1495	   Pledge voucher request (PVR) of the previous example.  Again, long
>    1496	   CBOR byte strings have been shortened for readability.
>    1497	
>    1498	   {
>    1499	"ietf-voucher-request:voucher": {
>    1500	       "assertion":     2,
>    1501	       "created-on":    "2022-12-05T19:19:19.536Z",
>    1502	       "nonce":         h'831D5198A6CA2C7F',
>    1503	       "idevid-issuer": h'04183016' ... '1736C3E0',
>    1504	       "serial-number": "JADA123456789",
>    1505	       "prior-signed-voucher-request": h'A11909' ... '373839'
>    1506	    }
>    1507	   }
>    1508	
>    1509	
>    1510	
>    1511	
>    1512	Richardson, et al.       Expires 31 August 2026                [Page 27]
>    1513	
>    1514	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1515	
>    1516	
>    1517	   Note that the Registrar uses here the string data type for all key
>    1518	   names, instead of the more compact SID integer keys.  This is fine
>    1519	   for any use cases where the network between Registrar and MASA is an
>    1520	   unconstrained network where data size is not critical.  The
>    1521	   constrained voucher request format supports both the string and SID
>    1522	   key types, for PVR as well as RVR.
>
> minor: should there be some requirement that registrar/MASA MUSTsupport both,
> but Pledges only need to support one, and replies to the pledge should use
> the same encoding style as was received in request from the pledge ?
>
>    1523	
>    1524	9.1.3.  Example Voucher Artifacts
>    1525	
>    1526	   Below, an example of constrained voucher data is shown in CBOR
>    1527	   diagnostic notation.  It was created by a MASA in response to
>    1528	   receiving the Registrar Voucher Request (RVR) shown in Section 9.1.2.
>    1529	   The enum value of the 'assertion' attribute is set to "proximity"
>    1530	   (2), to acknowledge to both the Pledge and the Registrar that the
>    1531	   proximity of the Pledge to the Registrar is considered proven.
>    1532	
>    1533	   {
>    1534	    2451: {               / SID = 2451,ietf-voucher:voucher|voucher /
>    1535	      1: 2,                      / SID = 2452, assertion "proximity" /
>    1536	      2: "2022-12-05T19:19:23Z", / SID = 2453, created-on            /
>    1537	      3: false,       / SID = 2454, domain-cert-revocation-checks    /
>    1538	      7: h'831D5198A6CA2C7F',    / SID = 2508, nonce                 /
>    1539	      8: h'308201' ... '8CFF',   / SID = 2459, pinned-domain-cert    /
>    1540	     11: "JADA123456789"         / SID = 2462, serial-number         /
>    1541	    }
>    1542	   }
>    1543	
>    1544	   While the above example voucher data includes the nonce from the PVR,
>    1545	   the next example is for a nonce-less voucher.  Instead of a nonce, it
>    1546	   includes an 'expires-on' attribute with the date and time on which
>    1547	   the voucher expires.  Because the MASA did not verify the proximity
>    1548	   of the Pledge and Registrar in this case, the 'assertion' attribute
>    1549	   contains a weaker assertion of "verified" (0).  This indicates that
>    1550	   the MASA verified the domain's ownership of the Pledge via some other
>    1551	   means.
>    1552	
>    1553	   {
>    1554	    2451: {               / SID = 2451,ietf-voucher:voucher|voucher /
>    1555	      1: 0,                      / SID = 2452, assertion "verified"  /
>    1556	      2: "2022-12-06T10:15:32Z", / SID = 2453, created-on            /
>    1557	      3: false,          / SID = 2454, domain-cert-revocation-checks /
>    1558	      4: "2022-12-13T10:15:32Z", / SID = 2455, expires-on            /
>    1559	      8: h'308201F8' ... 'FF',   / SID = 2459, pinned-domain-cert    /
>    1560	     11: "JADA123456789"         / SID = 2462, serial-number         /
>    1561	    }
>    1562	   }
>    1563	
>    1564	
>    1565	
>    1566	
>    1567	
>    1568	Richardson, et al.       Expires 31 August 2026                [Page 28]
>    1569	
>    1570	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1571	
>    1572	
>    1573	   The voucher is valid for one week.  To verify the voucher's validity,
>    1574	   the Pledge would either need an internal real-time clock or some
>    1575	   external means of obtaining the current time, such as Network Time
>    1576	   Protocol (NTP) or a radio time signal receiver.
>    1577	
>    1578	9.2.  Signing Voucher and Voucher Request Artifacts with COSE
>    1579	
>    1580	   The COSE_Sign1 structure is discussed in Section 4.2 of [RFC9052].
>    1581	   The CBOR object that carries the body, the signature, and the
>    1582	   information about the body and signature is called the COSE_Sign1
>    1583	   structure.  It is used when only one signature is used on the body.
>    1584	
>    1585	   Support for ECDSA with SHA2-256 using curve secp256r1 (aka
>    1586	   prime256k1) is RECOMMENDED.  Most current low power hardware has
>    1587	   support for acceleration of this algorithm.  Future hardware designs
>    1588	   could omit this in favour of a newer algorithms.  This is the ES256
>    1589	   (-7) keytype from Table 1 of [RFC9053].  Support for curve secp256k1
>    1590	   is OPTIONAL.
>    1591	
>    1592	   Support for EdDSA using Curve 25519 is RECOMMENDED in new designs if
>    1593	   hardware support is available.  This is keytype EDDSA (-8) from
>    1594	   Table 2 of [RFC9053].  A 'crv' parameter is necessary to specify the
>    1595	   Curve, for example value Ed25519 (6) from Table 18 of [RFC9053].  The
>    1596	   'kty' field MUST be present, and it MUST be "OKP" (Table 17 of
>    1597	   [RFC9053]).
>    1598	
>    1599	   A transition towards EdDSA is occurring in the industry.  Some
>    1600	   hardware can accelerate only some algorithms with specific curves,
>    1601	   other hardware can accelerate any curve, and still other kinds of
>    1602	   hardware provide a tool kit for acceleration of any elliptic curve
>    1603	   algorithm.
>    1604	
>    1605	   In general, the Pledge is expected to support only a single
>    1606	   algorithm, while the Registrar, usually not constrained, is expected
>    1607	   to support a wide variety of algorithms: both legacy ones and up-and-
>    1608	   coming ones via regular software updates.
>    1609	
>    1610	   An example of the supported COSE_Sign1 object structure containing a
>    1611	   Pledge Voucher Request (PVR) is shown below.
>    1612	
>    1613	
>    1614	
>    1615	
>    1616	
>    1617	
>    1618	
>    1619	
>    1620	
>    1621	
>    1622	
>    1623	
>    1624	Richardson, et al.       Expires 31 August 2026                [Page 29]
>    1625	
>    1626	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1627	
>    1628	
>    1629	   18(                   / tag for COSE_Sign1                       /
>    1630	    [
>    1631	      h'A10126',         / protected COSE header encoding: {1: -7}  /
>    1632	                         /            which means { "alg": ES256 }  /
>    1633	      {},                / unprotected COSE header parameters       /
>    1634	      h'A119' ... '3839', / PVR payload wrapped in CBOR byte string /
>    1635	      h'4567' ... '1234'  / PVR binary Sign1 signature              /
>    1636	    ]
>    1637	   )
>    1638	
>    1639	   The [COSE-registry] specifies the integers/encoding for the 'alg'
>    1640	   field.  The 'alg' field restricts the key usage for verification of
>    1641	   this COSE object to a particular cryptographic algorithm.
>    1642	
>    1643	9.2.1.  Signing of Registrar Voucher Request (RVR)
>    1644	
>    1645	   A Registrar MUST include a COSE 'x5bag' structure in the RVR as
>    1646	   explained in Section 8.1.  Below, an example Registrar Voucher
>    1647	   Request (RVR) is shown that includes the 'x5bag' unprotected header
>    1648	   parameter (32).  The bag contains two certificates in this case.
>    1649	
>    1650	   18(                    / tag for COSE_Sign1                      /
>    1651	    [
>    1652	      h'A10126',          / protected COSE header encoding: {1: -7} /
>    1653	                          /            which means { "alg": ES256 } /
>    1654	      {                   / unprotected COSE header/
>    1655	        32: [h'308202' ... '20AE', h'308201' ... '8CFF']    / x5bag /
>    1656	      },
>    1657	      h'A178' ... '7FED', / RVR payload wrapped in CBOR byte string /
>    1658	      h'E1B7' ... '2925'  / RVR binary Sign1 signature              /
>    1659	    ]
>    1660	   )
>    1661	
>    1662	   Besides storing the Registrar's own RVR-signing certificate chain
>    1663	   (per Section 8.1), the Registrar MUST include in the same 'x5bag'
>    1664	   structure all the certificates that the Pledge used to identify
>    1665	   itself in the Pledge/Registrar DTLS handshake, including the End-
>    1666	   Entity (IDevID) certificate and all CAs up to the root CA.  This
>    1667	   serves two purposes:
>    1668	
>    1669	   1.  A MASA that does not store the IDevIDs for all Pledges and their
>    1670	       related sub-CAs is still able to reconstruct the certificate
>    1671	       chain for a given Pledge and validate the Pledge's signature on
>    1672	       the PVR based purely on the root CA of the Pledge's manufacturer
>    1673	       that the MASA is storing.
>    1674	
>    1675	
>    1676	
>    1677	
>    1678	
>    1679	
>    1680	Richardson, et al.       Expires 31 August 2026                [Page 30]
>    1681	
>    1682	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1683	
>    1684	
>    1685	   2.  Diagnostic/debugging purposes: since the PVR's COSE signature
>    1686	       does not store any certificates related to the signer, but only
>    1687	       the signature itself, it can be useful for the MASA to log or
>    1688	       inspect the Pledge's certificate chain in case the onboarding
>    1689	       attempt fails.  Having the complete signing certificate chain at
>    1690	       hand facilitates finding the root cause of the problem and helps
>    1691	       in the communication with the customer.
>    1692	
>    1693	   A 'kid' (key ID) field is OPTIONAL in the unprotected COSE header
>    1694	   parameters map of a COSE object.  If present, it identifies the
>    1695	   public key of the key pair that was used to sign the COSE message.
>    1696	   The value of the key identifier 'kid' parameter may be in any format
>    1697	   agreed between signer and verifier.  Usually a hash of the public key
>    1698	   is used to identify the public key; but the choice of key identifier
>    1699	   method is vendor-specific.
>    1700	
>    1701	   By default, a Registrar does not include a 'kid' parameter in the RVR
>    1702	   since the signing key is already identified by the signing
>    1703	   certificates chain included in the COSE 'x5bag' structure.  A
>    1704	   Registrar nevertheless MAY use a 'kid' parameter in its RVR to
>    1705	   identify its signing key/identity.
>    1706	
>    1707	   The method of generating such 'kid' value is vendor-specific and
>    1708	   SHOULD be configurable in the Registrar to support commonly used
>    1709	   methods.  In order to support future business cases and supply chain
>    1710	   integrations, a Registrar using the 'kid' field MUST be configurable,
>    1711	   on a per-manufacturer basis, to select a particular method for
>    1712	   generating the 'kid' value such that it is compatible with the method
>    1713	   that the manufacturer expects.  Note that the 'kid' field always has
>    1714	   a CBOR byte string (bstr) format.
>    1715	
>    1716	   In Appendix C.4 a further example of a signed RVR is shown.
>    1717	
>    1718	9.2.2.  Signing of Pledge Voucher Request (PVR)
>    1719	
>    1720	   Like in the RVR, a 'kid' (key ID) field is also OPTIONAL in the PVR.
>    1721	   It can be used to identify the signing key/identity to the MASA.
>    1722	
>    1723	   A Pledge by default SHOULD NOT use a 'kid' parameter in its PVR,
>    1724	   because its signing key is already identified by the Pledge's unique
>    1725	   serial number that is included in the PVR and (by the Registrar) in
>    1726	   the RVR.  This achieves the smallest possible PVR data size while
>    1727	   still enabling the MASA to fully verify the PVR.  Still, when
>    1728	   required the Pledge MAY use a 'kid' parameter in its PVR to help the
>    1729	   MASA identify the right public key to verify against.  This can occur
>    1730	   for example if a Pledge has multiple IDevID identities.  The 'kid'
>    1731	   parameter in this case may be an integer byte identifying one out of
>    1732	   N identities present, or it may be a hash of the public key, or
>    1733	
>    1734	
>    1735	
>    1736	Richardson, et al.       Expires 31 August 2026                [Page 31]
>    1737	
>    1738	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1739	
>    1740	
>    1741	   anything else the Pledge vendor decides.  A Registrar normally SHOULD
>    1742	   ignore a 'kid' parameter used in a received PVR, as this information
>    1743	   is intended for the MASA.  In other words, there is no need for the
>    1744	   Registrar to verify the contents of this field, but it may include it
>    1745	   in an audit log.
>    1746	
>    1747	   The example below shows a PVR with 'kid' present as an unprotected
>    1748	   header parameter.
>    1749	
>    1750	   18(                    / tag for COSE_Sign1                      /
>    1751	    [
>    1752	      h'A10126',          / protected COSE header encoding: {1: -7} /
>    1753	                          /            which means { "alg": ES256 } /
>    1754	      {
>    1755	         4: h'59AB3E'     / COSE "kid" header parameter             /
>    1756	      },
>    1757	      h'A119' ... '3839', / PVR payload wrapped in CBOR byte string /
>    1758	      h'5678' ... '7890'  / PVR binary Sign1 signature              /
>    1759	    ]
>    1760	   )
>    1761	
>    1762	   The Pledge SHOULD NOT use the 'x5bag' or 'x5chain' COSE header
>    1763	   parameters in the PVR.  A Registrar that processes a PVR with such a
>    1764	   structure MUST ignore it, and MUST use only the TLS Client
>    1765	   Certificate extension for authentication of the Pledge.
>    1766	
>    1767	   A situation where the Pledge MAY use the 'x5bag' or 'x5chain'
>    1768	   structure is for communication of certificate chains to the MASA.
>    1769	   This would arise in some vendor- specific situations involving
>    1770	   outsourcing of MASA functionality, or rekeying of the IDevID
>    1771	   certification authority.
>    1772	
>    1773	   In Appendix C.3 a further example of a signed PVR is shown.
>    1774	
>    1775	9.2.3.  Signing of Voucher by MASA
>    1776	
>    1777	   The MASA SHOULD NOT use a 'kid' parameter in the voucher response,
>    1778	   because the MASA's signing key is already known to the Pledge.
>    1779	   Still, where needed the MASA MAY use a 'kid' parameter in the voucher
>    1780	   response to help the Pledge identify the right MASA public key to
>    1781	   verify against.  This can occur for example if a Pledge has multiple
>    1782	   IDevID identities.
>    1783	
>    1784	   The MASA SHOULD NOT include an 'x5bag' or 'x5chain' attribute in the
>    1785	   protected header of the voucher response, because normally a Pledge
>    1786	   already stores the required public key for validation of the signed
>    1787	   voucher.  The exception case is if the MASA knows that the Pledge
>    1788	   doesn't pre-store the MASA's public key used for signing, and thus
>    1789	
>    1790	
>    1791	
>    1792	Richardson, et al.       Expires 31 August 2026                [Page 32]
>    1793	
>    1794	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1795	
>    1796	
>    1797	   the MASA needs to provide a certificate or certificate chain that
>    1798	   will enable linking the signing identity to a pre-stored Trust Anchor
>    1799	   (CA) in the Pledge.  This approach is not recommended, because
>    1800	   including certificates in the protected 'x5bag' or 'x5chain' COSE
>    1801	   header parameters will significantly increase the size of the voucher
>    1802	   which impacts cBRSKI operation on constrained networks.
>    1803	
>    1804	   For example, if the MASA signing key is based upon a PKI (see
>    1805	   [I-D.richardson-anima-masa-considerations] Section 2.3), and the
>    1806	   Pledge only pre-stores a manufacturer (root) CA identity in its Trust
>    1807	   Store which is not the identity that signs the voucher, then a
>    1808	   certificate chain needs to be included with the voucher in order for
>    1809	   the Pledge to validate the MASA signing CA's signature by validating
>    1810	   the chain up to the CA in its Trust Store.  In BRSKI CMS signed
>    1811	   vouchers [RFC8995], the CMS structure has a place for such a
>    1812	   certificate chain.  In cBRSKI COSE-signed vouchers, the 'x5bag'
>    1813	   attribute [RFC9360] placed in the COSE protected header parameters is
>    1814	   used to contain the needed certificates for the Pledge to form the
>    1815	   chain.
>    1816	
>    1817	   To signal the complete chain of the MASA's signing identity to the
>    1818	   Registrar, the MASA MUST include the complete chain of signing
>    1819	   certificates in an 'x5bag' attribute in the unprotected header of the
>    1820	   voucher.  This allows the Registrar to optionally validate the
>    1821	   voucher before forwarding it to the Pledge, or to validate it for
>    1822	   logging purposes.  There is no voucher size impact of including this
>    1823	   certificate chain in an unprotected 'x5bag' COSE header parameter for
>    1824	   constrained networks, because the Registrar will remove this
>    1825	   unprotected attribute prior to forwarding the voucher response to the
>    1826	   Pledge, as defined in Section 6.6.
>    1827	
>    1828	   Note that cBRSKI currently does not support signing the voucher with
>    1829	   an RPK for which there is no corresponding certificate at all.  If
>    1830	   the MASA wants to sign a voucher with an RPK that is not part of any
>    1831	   PKIX hierarchy, it creates a single self-signed "placeholder" root CA
>    1832	   certificate that uses the designated RPK as the public key.  This
>    1833	   "placeholder" certificate is then included as the sole certificate in
>    1834	   an unprotected 'x5bag' header parameter, as defined in the previous
>    1835	   paragraph.
>    1836	
>    1837	   Below, an example is shown of a COSE-signed voucher as created by
>    1838	   MASA.  This example shows the common case where a protected 'x5bag'
>    1839	   (32) attribute is not used, while an unprotected 'x5bag' (32)
>    1840	   attribute is used to communicate the MASA's signature certificate
>    1841	   chain to the Registrar.  The bag contains two certificates in this
>    1842	   example.  One of these is the identity of the signer of the
>    1843	   COSE_Sign1 object, whose signature is stored as the last CBOR array
>    1844	   element in the below example.
>    1845	
>    1846	
>    1847	
>    1848	Richardson, et al.       Expires 31 August 2026                [Page 33]
>    1849	
>    1850	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1851	
>    1852	
>    1853	   18(                    / tag for COSE_Sign1                        /
>    1854	    [
>    1855	      h'A10126',          / protected COSE header encoding: {1: -7}   /
>    1856	                          /            which means { "alg": ES256 }   /
>    1857	      {                   / unprotected COSE header parameters        /
>    1858	        32: [h'308202' ... '20AE', h'308201' ... '8CFF']      / x5bag /
>    1859	      },
>    1860	      h'A119' ... '3839', / voucher payload wrapped in CBOR byte str  /
>    1861	      h'2A2C' ... '7FBF'  / voucher binary Sign1 signature by MASA    /
>    1862	    ]
>    1863	   )
>    1864	
>    1865	   In Appendix C.5 a further example of a signed voucher is shown.
>    1866	
>    1867	9.2.4.  Optional Validation of Voucher by Registrar
>    1868	
>    1869	   For a Registrar, validation of the voucher and/or the signature of
>    1870	   the voucher is optional, per Section 5.6 of [RFC8995].  However, if a
>    1871	   Registrar does perform the validation of the signature chain,
>    1872	   communicated in the 'x5bag' unprotected COSE header parameter (see
>    1873	   Section 9.2.3)), it MUST validate that one of the below cases hold:
>    1874	
>    1875	   1.  The signature chain is a single self-signed root CA certificate
>    1876	       with a correct signature; and the public key in this certificate
>    1877	       is also the public key that signed the voucher.  This represents
>    1878	       the case where a voucher has been effectively signed with an RPK.
>    1879	
>    1880	   2.  The signature chain consists of one or more certificates that can
>    1881	       be chained to a known (preconfigured) trust root in the
>    1882	       Registrar.
>    1883	
>    1884	   The above validation elements are needed only for cases where
>    1885	   (nonceless) vouchers are communicated over potentially unsecure
>    1886	   channels to the Registrar.  Since the 'x5bag' header parameter is not
>    1887	   protected by the voucher's COSE signature, it could have been
>    1888	   modified in transit.
>    1889	
>    1890	9.2.5.  Additional Information in the COSE Header
>    1891	
>    1892	   The COSE header of the signed voucher can contain COSE header
>    1893	   parameters with additional information, to be used by the Pledge.
>    1894	   This information is additional to, and separate from, the voucher
>    1895	   data defined by [RFC8366bis].
>    1896	
>    1897	   An example of how this additional information can be used is adding a
>    1898	   CBOR Web Token (CWT, [RFC8392]) claim in the COSE header as defined
>    1899	   by [RFC9597], to encode the COSE signing time as an integer value in
>    1900	   an 'iat' (Issued At) CWT claim.  This information in an integer
>    1901	
>    1902	
>    1903	
>    1904	Richardson, et al.       Expires 31 August 2026                [Page 34]
>    1905	
>    1906	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1907	
>    1908	
>    1909	   format may be useful for a Pledge that does not have date/time
>    1910	   parsing functions, so it is unable to parse the date/time string
>    1911	   value contained in the voucher.  Many other types of CWT claims can
>    1912	   be included in a voucher in the same way, as needed for particular
>    1913	   use cases.
>    1914	
>    1915	   Such additional information can also be included in a COSE header of
>    1916	   a voucher request by a Pledge, to be used by the MASA.
>    1917	
>    1918	10.  Extensions to Discovery
>    1919	
>    1920	   It is assumed that a Join Proxy (Section 6.2) seamlessly provides a
>    1921	   relayed DTLS connection between the Pledge and the Registrar.  To use
>    1922	   a Join Proxy, a Pledge needs to discover it.  For Pledge discovery of
>    1923	   a Join Proxy, this section extends Section 4.1 of [RFC8995] for the
>    1924	   cBRSKI case.
>    1925	
>    1926	   In general, the Pledge may be one or more hops away from the
>    1927	   Registrar, where one hop means the Registrar is a direct link-local
>    1928	   neighbor of the Pledge.  The case of one hop away can be considered
>    1929	   as a degenerate case, because a Join Proxy is not really needed then.
>    1930	
>    1931	   The degenerate case would be unusual in constrained wireless network
>    1932	   deployments, because a Registrar would typically not have a wireless
>    1933	   network interface of the type used by constrained devices.  Rather,
>    1934	   it would have a high-speed network interface.  Nevertheless, the
>    1935	   situation where the Registrar is one hop away from the Pledge could
>    1936	   occur in various cases like wired IoT networks or in wireless
>    1937	   constrained networks where the Pledge is in radio range of a 6LoWPAN
>    1938	   Border Router (6LBR) ([RFC6775])and the 6LBR happens to host a
>    1939	   Registrar.
>    1940	
>    1941	   In order to support the degenerate case, the Registrar SHOULD
>    1942	   announce itself as if it were a Join Proxy -- though it would
>    1943	   actually announce its real (stateful) Registrar CoAPS endpoint.  No
>    1944	   actual Join Proxy functionality is then required on the Registrar.
>    1945	
>    1946	   That way, a Pledge only needs to discover a Join Proxy, regardless of
>    1947	   whether it is one or more than one hop away from a relevant
>    1948	   Registrar.  It first discovers the link-local address and the UDP
>    1949	   join-port of a Join Proxy.  The Pledge then follows the cBRSKI
>    1950	   procedure of initiating a DTLS connection using the link-local
>    1951	   address and join-port of the Join Proxy.
>    1952	
>    1953	
>    1954	
>    1955	
>    1956	
>    1957	
>    1958	
>    1959	
>    1960	Richardson, et al.       Expires 31 August 2026                [Page 35]
>    1961	
>    1962	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    1963	
>    1964	
>    1965	   Once enrolled, a Pledge itself may function as a Join Proxy.  The
>    1966	   decision whether or not to provide this functionality depends upon
>    1967	   many factors and is out of scope for this document.  Such a decision
>    1968	   might depend upon the amount of energy available to the device, the
>    1969	   network bandwidth available, as well as CPU and memory availability.
>    1970	
>    1971	   The process by which a Pledge discovers the Join Proxy, and how a
>    1972	   Join Proxy discovers the location of the Registrar, are the subject
>    1973	   of the remainder of this section.  Further details on both these
>    1974	   topics are provided in [I-D.ietf-anima-constrained-join-proxy].
>    1975	
>    1976	10.1.  Discovery Operations by a Pledge
>    1977	
>    1978	   The Pledge must discover the address/port and optionally the protocol
>    1979	   with which to communicate.  The present document only defines coaps
>    1980	   (CoAP over DTLS) as the default protocol for cBRSKI, therefore
>    1981	   protocol discovery is out of scope.
>    1982	
>    1983	   For the discovery method, this section only defines unsecured CoAP
>    1984	   discovery per Section 7 of [RFC7252] as the default method.  This
>    1985	   uses CoRE Link Format [RFC6690] payloads.
>    1986	
>    1987	   Section 11 briefly mentions other methods that apply to specific
>    1988	   deployment types or technologies.  Details about these deployment-
>    1989	   specific methods, or yet other methods, new payload formats, or more
>    1990	   elaborate CoAP-based methods, may be defined in future documents such
>    1991	   as [I-D.ietf-anima-brski-discovery].  The more elaborate methods for
>    1992	   example may include discovering only Join Proxies that support a
>    1993	   particular desired onboarding protocol, voucher format, or cBRSKI
>    1994	   variant.
>    1995	
>    1996	   Note that identifying the format of the voucher request and the
>    1997	   voucher is currently not a required part of the Pledge's discovery
>    1998	   operation.  It is assumed that all Registrars support all relevant
>    1999	   voucher(-request) formats, while the Pledge only supports a single
>    2000	   format.  A Pledge that makes a voucher request to a Registrar that
>    2001	   does not support that format will receive a CoAP 4.06 Not Acceptable
>    2002	   status code and the onboarding attempt will fail.
>    2003	
>    2004	   Using CoAP discovery, a Pledge can discover a Join Proxy by sending a
>    2005	   link-local multicast discovery message to the All CoAP Nodes address
>    2006	FF02::FD.  Zero, one, or multiple Join Proxies may respond.  The
>    2007	   handling of multiple responses and absence of responses cases follow
>    2008	   the guidelines of Section 4 of [RFC8995].  The discovery message is a
>    2009	   CoAP GET request on the URI path /.well-known/core using a URI query
>    2010	   "rt=brski.jp".  This resource type ('rt') is defined in Section 8.1
>    2011	   of [I-D.ietf-anima-constrained-join-proxy].
>    2012	
>    2013	
>    2014	
>    2015	
>    2016	Richardson, et al.       Expires 31 August 2026                [Page 36]
>    2017	
>    2018	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2019	
>    2020	
>    2021	   Responding Join Proxies return a CoRE Link Format document with one
>    2022	   or more links.  Each link indicates one CoAPS endpoint that offers
>    2023	   cBRSKI Join Proxy functionality.  Formally, each link indicates a
>    2024	   CoAP root resource (/) tagged with the "brski.jp" type, hosted on a
>    2025	   CoAPS endpoint.
>    2026	
>    2027	   In case a Pledge selects a particular Join Proxy for cBRSKI
>    2028	   onboarding, it MUST use the link-local source address of the Join
>    2029	   Proxy's discovery response as the destination IP address for its
>    2030	   subsequent onboarding attempt.  This implies that the UTF-8 encoded
>    2031	   link-local address literal that appears in the host subcomponent of
>    2032	   each returned link is not used for determining the destination IP
>    2033	   address of the onboarding attempt.
>    2034	
>    2035	10.1.1.  Examples
>    2036	
>    2037	   Below, a typical example is provided showing the Pledge's CoAP
>    2038	   request and the Join Proxy's CoAP response.  The Join Proxy responds
>    2039	   with a link-local source address, which is the same address as
>    2040	   indicated in the URI-reference element ([RFC6690]) in the link in the
>    2041	   discovery response payload.  The Join Proxy has a dedicated UDP port
>    2042	   8485 open for DTLS connections of Pledges:
>    2043	
>    2044	     REQ: GETcoap://[ff02::fd]/.well-known/core?rt=brski.jp
>    2045	
>    2046	     RES: 2.05 Content
>    2047	       Content-Format: 40 (application/link-format)
>    2048	       Payload:
>    2049	<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
>    2050	
>    2051	   Note that the Pledge would use the port number from the link in this
>    2052	   response, but not the IPv6 literal in the host subcomponent
>    2053	   ([fe80::c78:e3c4:58a0:a4ad]), as defined by the above discovery
>    2054	   operation steps.
>    2055	
>    2056	   The next example shows a Join Proxy that uses the default CoAPS port
>    2057	   5684 for DTLS connections of Pledges.  In this case, the Join Proxy
>    2058	   host is not using port 5684 for any other purposes, so it has the
>    2059	   port available exclusively for accepting DTLS connections of Pledges.
>    2060	
>    2061	     REQ: GETcoap://[ff02::fd]/.well-known/core?rt=brski.jp
>    2062	
>    2063	     RES: 2.05 Content
>    2064	       Content-Format: 40 (application/link-format)
>    2065	       Payload:
>    2066	<coaps://[fe80::c78:e3c4:58a0:a4ad]>;rt=brski.jp
>    2067	
>    2068	
>    2069	
>    2070	
>    2071	
>    2072	Richardson, et al.       Expires 31 August 2026                [Page 37]
>    2073	
>    2074	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2075	
>    2076	
>    2077	   In the following example, two Join Proxies respond to the multicast
>    2078	   query.  The Join Proxies each use a slightly different CoRE Link
>    2079	   Format 'rt' value encoding.  While the first encoding is more
>    2080	   compact, both encodings are allowed per [RFC6690].  The Pledge may
>    2081	   now select one of the two Join Proxies for initiating its DTLS
>    2082	   connection.
>    2083	
>    2084	     REQ: GETcoap://[ff02::fd]/.well-known/core?rt=brski*
>    2085	
>    2086	     RES: 2.05 Content
>    2087	       Content-Format: 40 (application/link-format)
>    2088	       Payload:
>    2089	<coaps://[fe80::c78:e3c4:58a0:a4ad]:8485>;rt=brski.jp
>    2090	
>    2091	     RES: 2.05 Content
>    2092	       Content-Format: 40 (application/link-format)
>    2093	       Payload:
>    2094	<coaps://[fe80::d359:3813:f382:3b23]:63245>;rt="brski.jp"
>    2095	
>    2096	   In the final example, a single Join Proxy host responds with two
>    2097	   distinct cBRSKI endpoints.  The Pledge may now select one of the two
>    2098	   CoAP endpoints for initiating its DTLS connection.
>    2099	
>    2100	     REQ: GETcoap://[ff02::fd]/.well-known/core?rt=brski*
>    2101	
>    2102	     RES: 2.05 Content
>    2103	       Content-Format: 40 (application/link-format)
>    2104	       Payload:
>    2105	<coaps://[fe80::d359:3813:f382:3b23]:61616>;rt=brski.jp
>    2106	<coaps://[fe80::d359:3813:f382:3b23]:61617>;rt=brski.jp;
>    2107	                                                     var="c509 v2"
>
> minor: maybe use some var that is consistent with brski-discovery unless
> there is reason not to ? e.g.: var="est-tls prm-jose cmp"
>    2108	
>    2109	   The first endpoint on port 61616 supports only the cBRSKI protocol as
>    2110	   defined by this document.  The second endpoint, on port 61617,
>    2111	   supports the same cBRSKI protocol as well as additional variations or
>    2112	   extensions.  In this example, these variations/extensions are encoded
>    2113	   using string values in a single attribute 'var'.  This information
>    2114	   may be also encoded using other attributes defined by a future
>    2115	   specification.
>    2116	
>    2117	   A Pledge not aware of these variations can safely ignore these
>    2118	   values, because the base cBRSKI protocol is supported by both
>    2119	   endpoints, as indicated by the resource type ('rt').  If however a
>    2120	   Pledge is aware of these variations, it can select the endpoint with
>    2121	   the variation it prefers, in case multiple options are discovered.
>    2122	   The use of attributes with a single base resource type allows future
>    2123	   extensibility of cBRSKI, and enables the Join Proxies to support
>    2124	   cBRSKI variants that are unknown to them.
>    2125	
>    2126	
>    2127	
>    2128	Richardson, et al.       Expires 31 August 2026                [Page 38]
>    2129	
>    2130	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2131	
>    2132	
>    2133	10.2.  Discovery Operations by a Join Proxy
>    2134	
>    2135	   A Join Proxy needs to discover a Registrar, either at the moment it
>    2136	   needs to relay data (of a Pledge) towards the Registrar, or prior to
>    2137	   that moment.  For example, it may start Registrar discovery as soon
>    2138	   as it is requested to be enabled in a Join Proxy role.  It may
>    2139	   periodically redo this discovery, or periodically or on-demand check
>    2140	   that the Registrar is still available in the network at the
>    2141	   discovered IP address.
>    2142	
>    2143	   As shown in the final example in Section 10.1.1, a Join Proxy can
>    2144	   discover multiple Registrars in its network and present these options
>    2145	   to the Pledge.  Each of these Registrars may support specific
>    2146	   variations/extensions of cBRSKI - which may be defined in future
>    2147	   documents.  It is up to the administrator of the network how many
>    2148	   Registrars are enabled.
>
> nit: would be good to explain that registrars supporting different variations
> need to be offered by the proxy via different coap endpoints? (port?) so that upon
> traffic from a proxy to that endpoint/port the proxy knows which registrar to pass
> the messages on to.
>
>    2149	
>    2150	   Further details on CoAP discovery of the Registrar by a Join Proxy
>    2151	   are provided in Section 5.1.1 of
>    2152	   [I-D.ietf-anima-constrained-join-proxy].
>    2153	
>    2154	11.  Deployment-specific Discovery Considerations
>    2155	
>    2156	   This section details how discovery of a Join Proxy is done by the
>    2157	   Pledge in specific deployment scenarios.  Future work such as
>    2158	   [I-D.ietf-anima-brski-discovery] may define more details on discovery
>    2159	   operations in the specific deployments listed here.
>    2160	
>    2161	11.1.  6TiSCH Deployments
>    2162	
>    2163	   In 6TiSCH networks, the Constrained Join Protocol (CoJP) is used as
>    2164	   described in [RFC9031].  Such networks are expected to use EDHOC
>    2165	   [RFC9528] for key management, which is out of scope of this document.
>    2166	   The IEEE 802.15.4 Enhanced Beacon has been extended in [RFC9032] to
>    2167	   allow for discovery of a 6TiSCH-compliant Join Proxy.
>    2168	
>    2169	11.2.  IP networks using GRASP
>    2170	
>    2171	   In IP networks that support GRASP [RFC8990], a Pledge can discover a
>    2172	   Join Proxy by listening for GRASP messages.  GRASP supports mesh
>    2173	   networks, and can also be used over unencrypted Wi-Fi.
>    2174	
>    2175	   Details of GRASP discovery of constrained Join Proxies are out of
>    2176	   scope of this document and may be defined in future work.
>    2177	
>    2178	
>    2179	
>    2180	
>    2181	
>    2182	
>    2183	
>    2184	Richardson, et al.       Expires 31 August 2026                [Page 39]
>    2185	
>    2186	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2187	
>    2188	
>    2189	11.3.  IP networks using mDNS
>    2190	
>    2191	   [RFC8995] defines a mechanism for the Pledge to discover a Join Proxy
>    2192	   by sending mDNS [RFC6762] queries.  This mechanism can be used on any
>    2193	   IP network which does not have another recommended mechanism.  It can
>    2194	   be used over unencrypted Wi-Fi.  This mechanism does support link-
>    2195	   local Join Proxy discovery in mesh networks.  However, it does not
>    2196	   support Registrar discovery by Join Proxies in mesh networks, because
>    2197	   the Registrar is typically not reachable by link-local communication
>    2198	   in that case.  For this, another mechanism is needed, which is out of
>    2199	   scope of this document and may be defined in future work.
>    2200	
>    2201	   A Pledge uses an mDNS PTR query for the name "_brski-
>    2202	   proxy._udp.local." to discover link-local constrained Join Proxies.
>    2203	   The label "_udp" here indicates a query for cBRSKI constrained Join
>    2204	   Proxies, as opposed to "_tcp" defined in [RFC8995] which is for
>    2205	   discovering BRSKI Proxies.
>    2206	
>    2207	11.4.  Thread Networks using Mesh Link Establishment (MLE)
>    2208	
>    2209	   Thread [Thread] is a wireless mesh network protocol based on 6LoWPAN
>    2210	   [RFC6282] and other IETF protocols.  In Thread, a new device
>    2211	   discovers potential Thread networks and Thread nodes to join by using
>    2212	   the Mesh Link Establishment (MLE)
>    2213	   [I-D.ietf-6lo-mesh-link-establishment] protocol.  MLE uses the UDP
>    2214	   port number 19788.
>    2215	
>    2216	   The new device sends discovery requests on different IEEE 802.15.4
>    2217	   radio channels, to which Thread nodes (if any present) respond with a
>    2218	   discovery response containing information about their respective
>    2219	   network.  The MLE discovery response message contains UDP port
>    2220	   information to signal the new device which UDP port to use for its
>    2221	   DTLS connection to the Join Proxy function.  The link-local IPv6
>    2222	   source address of the MLE response message indicates the address of
>    2223	   the Join Proxy.
>    2224	
>    2225	   Once a suitable Thread node is selected as its Join Proxy, the new
>    2226	   device initiates a DTLS transport-layer secured connection to the
>    2227	   network's commissioning application, over a link-local single radio
>    2228	   hop to the selected Join Proxy.  This link is not yet secured at the
>    2229	   radio/MAC link layer: link-layer security will be set up once the new
>    2230	   device is approved by the commissioning application to join the
>    2231	   Thread network, and it gets provisioned with network access
>    2232	   credentials.
>    2233	
>    2234	   A Thread node that is capable to act as a Join Proxy will only enable
>    2235	   this role if the network-wide configuration data indicates that new
>    2236	   device commissioning is allowed.
>    2237	
>    2238	
>    2239	
>    2240	Richardson, et al.       Expires 31 August 2026                [Page 40]
>    2241	
>    2242	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2243	
>    2244	
>    2245	12.  Design and Implementation Considerations
>    2246	
>    2247	12.1.  Voucher Format and Encoding
>    2248	
>    2249	   The design considerations for vouchers from Section 10 of
>    2250	   [RFC8366bis] apply.  Specifically for CBOR encoding of voucher data,
>    2251	   one key difference with JSON encoding is that the names of the leaves
>    2252	   in the YANG definition do not affect the size of the resulting CBOR,
>    2253	   if the SID ([RFC9254], [RFC9595]) translation process is used that
>    2254	   assigns integers to the names.
>    2255	
>    2256	   To obtain the lowest code size and RAM use on the Pledge, it is
>    2257	   recommended that a Pledge is designed to only process/generate these
>    2258	   SID integers and not the lengthy strings.  The MASA in that case is
>    2259	   required to generate the voucher data for that Pledge using only SID
>    2260	   integers.  Yet, this MASA MUST still support both SID integers and
>    2261	   strings, to be able to process attribute (string) names in the RVR
>    2262	   which the Registrar may use.
>    2263	
>    2264	12.2.  CoAP Usage
>    2265	
>    2266	   A successful POST request to the Registrar's telemetry resources
>    2267	   (/vs, /es) returns a 2.04 Changed response with empty payload.
>    2268	
>    2269	   A CoAP client sending a request should be aware that the server, even
>    2270	   in case of an empty payload, may use either a piggybacked CoAP
>    2271	   response (for example ACK with code 2.04) but may also respond with a
>    2272	   separate CoAP response.  This is first an ACK message with code 0.0
>    2273	   that acknowledges the reception of the request.  It is followed by a
>    2274	   CON message with a code 2.04 response in a separate CoAP message.
>    2275	   See [RFC7252] for details.
>    2276	
>    2277	12.3.  Use of cBRSKI with HTTPS
>    2278	
>    2279	   This specification contains two major extensions to [RFC8995]: a
>    2280	   constrained voucher format (COSE), and a constrained transfer
>    2281	   protocol (CoAP).
>    2282	
>    2283	   On constrained networks with constrained devices, it make senses to
>    2284	   use both together.  However, this document does not mandate that this
>    2285	   be the only way.
>    2286	
>    2287	   A given constrained device design and software may be re-used for
>    2288	   multiple device models, such as a model having only an IEEE 802.15.4
>    2289	   radio, or a model having only an IEEE 802.11 (Wi-Fi) radio, or a
>    2290	   model having both these radios.  A manufacturer of such device models
>    2291	   may wish to have code only for the use of the constrained voucher
>    2292	   format (COSE), and use it on all supported radios including the IEEE
>    2293	
>    2294	
>    2295	
>    2296	Richardson, et al.       Expires 31 August 2026                [Page 41]
>    2297	
>    2298	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2299	
>    2300	
>    2301	   802.11 radio.  For this radio, the software stack to support HTTP/TLS
>    2302	   may be already integrated into the radio module hence it is
>    2303	   attractive for the manufacturer to reuse this.  This type of approach
>    2304	   is supported by this document.  In the case that HTTPS is used, the
>    2305	   regular long [RFC8995] resource names are used, together with the new
>    2306	   application/voucher+cose media type described in this document.  For
>    2307	   status telemetry requests, the format and requirements defined in
>    2308	   Section 6.3.1 remain unchanged.
>    2309	
>    2310	   Other combinations are possible, but they are not enumerated here.
>    2311	   New work such as [I-D.ietf-anima-jws-voucher] provides new formats
>    2312	   that may be usable over a number of different transports.  In
>    2313	   general, sending larger payloads over constrained networks makes less
>    2314	   sense, while sending smaller payloads over unconstrained networks is
>    2315	   perfectly acceptable.
>    2316	
>    2317	   The Pledge will in most cases support a single voucher format, which
>    2318	   it uses without negotiation i.e. without discovery of formats
>    2319	   supported.  The Registrar, being unconstrained, is expected to
>    2320	   support all voucher formats.  There will be cases where a Registrar
>    2321	   does not support a new format that a new Pledge uses, and this is an
>    2322	   unfortunate situation that will result in lack of interoperation.
>    2323	
>    2324	   The responsibility for supporting new formats is on the Registrar.
>    2325	
>    2326	13.  Raw Public Key Variant
>    2327	
>    2328	13.1.  Introduction and Scope
>    2329	
>    2330	   This section introduces a cBRSKI variant to further reduce the data
>    2331	   volume and complexity of the cBRSKI onboarding.  The use of a raw
>    2332	   public key (RPK) in the pinning process can significantly reduce the
>    2333	   number of bytes sent over the wire and the number of round trips, and
>    2334	   reduce the code footprint in a Pledge.  But it comes with a few
>    2335	   significant operational limitations.
>    2336	
>    2337	   One simplification that comes with RPK use is that a Pledge can avoid
>    2338	   doing PKIX operations, such as certificate chain validation.
>    2339	
>    2340	13.2.  DTLS Connection and Registrar Trust Anchor
>    2341	
>    2342	   When the Pledge first connects to the Registrar, the connection to
>    2343	   the Registrar is provisional, as explained in Section 5.6.2 of
>    2344	   [RFC8995].  The Registrar normally provides its public key in a
>    2345	   TLSServerCertificate, and the Pledge uses that to validate that
>    2346	   integrity of the DTLS connection, but it does not validate the
>    2347	   identity of the provided certificate.
>    2348	
>    2349	
>    2350	
>    2351	
>    2352	Richardson, et al.       Expires 31 August 2026                [Page 42]
>    2353	
>    2354	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2355	
>    2356	
>    2357	   As the TLSServerCertificate object is never verified directly by the
>    2358	   Pledge, sending it can be considered superfluous.  So instead of
>    2359	   using a (TLSServer)Certificate of type X509 (see Section 4.4.2 of
>    2360	   [RFC8446]), a RawPublicKey object (as defined by [RFC7250]) is used.
>    2361	
>    2362	   A Registrar operating in a mixed environment can determine whether to
>    2363	   send a PKIX certificate chain or a Raw Public Key to the Pledge: this
>    2364	   is signaled by the Pledge.  In the case the Pledge needs an RPK, it
>    2365	   includes the server_certificate_type of RawPublicKey.  This is shown
>    2366	   in Section 5 of [RFC7250].
>    2367	
>    2368	   The Pledge MUST send a client_certificate_type of X509 (not an RPK),
>    2369	   so that the Registrar can properly identify the Pledge and distill
>    2370	   the MASA URI information from its IDevID certificate.
>    2371	
>    2372	13.3.  The Pledge Voucher Request
>    2373	
>    2374	   The Pledge puts the Registrar's public key into the 'proximity-
>    2375	   registrar-pubk' attribute of the Pledge Voucher Request (PVR).  The
>    2376	   'proximity-registrar-pubk-sha256' can alternatively be used for
>    2377	   efficiency, if the 32-bytes of a SHA256 hash turns out to be smaller
>    2378	   than a typical ECDSA key.
>    2379	
>    2380	   As the format of the 'proximity-registrar-pubk' attribute is
>    2381	   identical to the TLS RawPublicKey data object, no manipulation at all
>    2382	   is needed to insert this attribute into the PVR.  This approach
>    2383	   reduces the size of the PVR significantly, compared to including the
>    2384	   full certificate.
>    2385	
>    2386	13.4.  The Voucher Response
>    2387	
>    2388	   A returned voucher will have a 'pinned-domain-pubk' attribute with
>    2389	   the identical key as was found in the 'proximity-registrar-pubk'
>    2390	   attribute above, as well as being identical to the Registrar's RPK in
>    2391	   the currently active DTLS connection.  (Or alternatively the MASA may
>    2392	   include the 'pinned-domain-pubk-sha256' attribute if it knows the
>    2393	   Pledge supports this attribute.)
>    2394	
>    2395	   Validation of this key by the Pledge is what takes the DTLS
>    2396	   connection out of the provisional state; see Section 5.6.2 of
>    2397	   [RFC8995] for more details.
>    2398	
>    2399	   The received voucher needs to be validated by the Pledge.  The Pledge
>    2400	   needs to have a public key to validate the signature from the MASA on
>    2401	   the voucher.
>    2402	
>    2403	
>    2404	
>    2405	
>    2406	
>    2407	
>    2408	Richardson, et al.       Expires 31 August 2026                [Page 43]
>    2409	
>    2410	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2411	
>    2412	
>    2413	   The MASA's public key counterpart of the (private) MASA signing key
>    2414	   MUST be already installed in the Pledge at manufacturing time.
>    2415	   Otherwise, the Pledge cannot validate the voucher's signature.
>    2416	
>    2417	13.5.  The Enrollment Phase
>    2418	
>    2419	   A Pledge that does not support PKIX operations cannot use EST to
>    2420	   enroll; it has to use another method for enrollment without
>    2421	   certificates and the Registrar has to support this method also.  For
>    2422	   example, an enrollment process that records an RPK owned by the
>    2423	   Pledge as a legitimate entity that is part of the domain.
>    2424	
>    2425	   It is possible that the Pledge will not enroll after obtaining a
>    2426	   valid voucher, but instead will do only a network join operation (see
>    2427	   for example [RFC9031]).  How the Pledge discovers this method and
>    2428	   details of such enrollment methods are out of scope of this document.
>    2429	
>    2430	14.  Security Considerations
>    2431	
>    2432	14.1.  Duplicate Serial Numbers
>
> minor:
>
> As fun as this section of duplicate serial numbers is, i would suggest to remove
> it unless you can find a much more persuasive plausibility for it to ever happen.
>
> Right now it sounds like its totally impossble. And starting a security section with
> something like that... if you really want to keep it, move it all the way to the end
> of the security section.
>
> There is an argument to be made for the need to have good serial number management,
> i guess.
>
> There was the fun story back in the 80th when i was doing mandatory military
> service in Germany and the folks in supply management told me that the armed services
> had a simple number space for everything you could order, so if you just made a mistake
> of one digit, you might not get a delivery of one block of offiece paper but instead
> you could receive a battle ship.
>
> I always remember this annoyance  when i see examples of certs where the serial number
> is really just a numeric number. Instead of a structured string consisting of at
> least a product type string (PID) followed by an actual unit serial number. But
> i still can not find a good reference for this format. Cisco uses it. Huawei seemingly
> not. I am happy to have more advertisement of that type of serial number types
> in certs. But of course, the issues you get when you do not have this are
> IMHO primarily operational issues, not security issues. But most often it is
> perfectly fine to do policies on accepting products into a domain based on
> pattern matches against cert serial numbers that just match on PID, not unit serial
> number field. So if you like to have something like that, maybe thats section
> "Operational Considerations". Else we can put it into our operational considerations
> draft.
>
> But no... right now drawing a blank re. actual security attack issues here.
>
>    2433	
>    2434	   If a manufacturer sold products with duplicated serial numbers, that
>    2435	   use the same MASA CA as their root of trust, a customer of one of
>    2436	   these products can potentially perform an attack where it uses a
>    2437	   voucher created for product 1 to onboard product 2.  This attack only
>    2438	   works for nonceless vouchers.
>    2439	
>    2440	   Note that such a situation could only arise due to manufacturer mis-
>    2441	   management or oversight.
>    2442	
>    2443	   For example, imagine the same manufacturer makes light bulbs as well
>    2444	   as gas centrifuges, and said manufacturer does not uniquely allocate
>    2445	   product serial numbers.  The attacker has obtained a light bulb which
>    2446	   happens to have the same serial number as an operational gas
>    2447	   centrifuge which it wishes to obtain access to.  The attacker
>    2448	   performs a normal BRSKI onboarding for the light bulb, but then uses
>    2449	   the resulting nonceless voucher to onboard the gas centrifuge.  The
>    2450	   attack requires that the gas centrifuge be returned to a state where
>    2451	   it is willing to perform a new onboarding operation.  For example, a
>    2452	   factory reset.
>    2453	
>    2454	   This attack is normally prevented by the mechanisms of using
>    2455	   different trust root CAs for different product lines, and/or using
>    2456	   unique serial numbers within a single MASA CA scope.
>    2457	
>    2458	
>    2459	
>    2460	
>    2461	
>    2462	
>    2463	
>    2464	Richardson, et al.       Expires 31 August 2026                [Page 44]
>    2465	
>    2466	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2467	
>    2468	
>    2469	   Section 6.2 of [RFC8366bis] discusses cases of duplicated serial
>    2470	   numbers in products across different CAs and the role of the 'idevid-
>    2471	   issuer' attribute in the RVR and in the voucher to disambiguate these
>    2472	   products.
>    2473	
>    2474	14.2.  IDevID Security in the Pledge
>    2475	
>    2476	   The security of this protocol depends upon the Pledge identifying
>    2477	   itself to the Registrar using its manufacturer installed certificate:
>    2478	   the IDevID certificate.  Associated with this certificate is the
>    2479	   IDevID private key, known only to the Pledge.  Disclosure of this
>    2480	   private key to an attacker would permit the attacker to impersonate
>    2481	   the Pledge towards the Registrar, probably gaining access credentials
>    2482	   to that Registrar's network.
>
> mayor:
>
> Quite in the opposite to the prior section, it would be very good to frontent
> this section with a section describing the IMHO most fundamental issue, also
> well suited to cBRSKI:
>
> Pledge LDevID as network credentials
>
> The most significant security issue is in understanding and selecting the right
> hardware security for IDevID and LDevID storage and software security in
> the pledge that can access IDevID and LDevID.
>
> When LDevID is only used to authenticate pledges in (end-to-end) application
> layer communications, then the required level of security can often the
> fairly minimal because impairing an IoT device such as a temperature sensor
> can only attack application behavior. Which may be dramatic or not. One may cause
> A fire alert and sprinkler damaging a warehouse by impersonating such a sensor,
> likely from the convenience of a remote location for example. Even when impairment
> itself (earlier) may have required physical access.
>
> However, an even broader set of attacks may be possible when the LDevID
> is also used as a credential to access the network itself, especially if on that
> network not all communications is also end-to-end secured separately, and therefore
> network access can additionally (to above described application layer impersnation)
> also enable much broader attack scenarios against such non-end-to-end secured
> communication or observation of other traffic to determine further exploitation options
> or DoS attacks.
>
> In summary: cBRSKI has the opportunity of bringing automated trust infrastructures
> via LDevID into many areas where there was no good security now, especially in
> many IoT environments, but LDevID alone is not sufficient for better security, it
> is just a pre-requisite. End-to-end authentication for all communications is the
> most important requirement to minimize broad attacks, and as soon as LDevID are
> used for network layer security (without ubiquitous use of end-to-end security too),
> it is important to ensure an appropriate layer of hardening of devices is done,
> specifically TPM type containment of private keys and secure software loading to
> prohibit or minimize impairment by malicious software.
>
> Something like this if the authors like it ;-))
>
>    2483	
>    2484	   If the IDevID private key disclosure is known to the manufacturer,
>    2485	   there is little recourse other than recall of the relevant part
>    2486	   numbers.  The process for communicating this recall would be within
>    2487	   the BRSKI-MASA protocol.  Neither this specification nor [RFC8995]
>    2488	   provides for consultation of a Certification Revocation List (CRL) or
>    2489	   Open Certificate Status Protocol (OCSP) by a Registrar when
>    2490	   evaluating an IDevID certificate.  However, the BRSKI-MASA protocol
>    2491	   submits the IDevID from the Registrar to the manufacturer's MASA and
>    2492	   a manufacturer would have an opportunity to decline to issue a
>    2493	   voucher for a device which they believe has become compromised.
>    2494	
>    2495	   It may be difficult for a manufacturer to determine when an IDevID
>    2496	   private key has been disclosed.  Two situations present themselves:
>    2497	   in the first situation a compromised private key might be reused in a
>    2498	   counterfeit device, which is sold to another customer.  This would
>    2499	   present itself as an onboarding of the same device in two different
>    2500	   networks.  The manufacturer may become suspicious seeing two voucher
>    2501	   requests for the same device from different Registrars.  Such
>    2502	   activity could be indistinguishable from a device which has been
>    2503	   resold from one operator to another, or re-deployed by an operator
>    2504	   from one location to another.
>    2505	
>    2506	
>    2507	
>    2508	
>    2509	
>    2510	
>    2511	
>    2512	
>    2513	
>    2514	
>    2515	
>    2516	
>    2517	
>    2518	
>    2519	
>    2520	Richardson, et al.       Expires 31 August 2026                [Page 45]
>    2521	
>    2522	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2523	
>    2524	
>    2525	   In the second situation, an attacker having compromised the IDevID
>    2526	   private key of a device might then install malware into the same
>    2527	   device and attempt to return it to service.  The device, now blank,
>    2528	   would go through a second onboarding process with the original
>    2529	   Registrar.  Such a Registrar could notice that the device has been
>    2530	   "factory reset" and alert the operator to this situation.  One remedy
>    2531	   against the presence of malware is through the use of Remote
>    2532	   Attestation such as described in [RFC9334].  Future work will need to
>    2533	   specify a background-check Attestation flow as part of the voucher
>    2534	   request/response process.  Attestation may still require access to a
>    2535	   private key (e.g. IDevID private key) in order to sign Evidence, so a
>    2536	   primary goal should be to keep any private key safe within the
>    2537	   Pledge.
>    2538	
>    2539	   In larger, more expensive, systems there is budget (power, space, and
>    2540	   bill of materials) to include more specific defenses for a private
>    2541	   key.  For instance, this includes putting the IDevID private key in a
>    2542	   Trusted Platform Module (TPM), or use of Trusted Execution
>    2543	   Environments (TEE) for access to the key.  On smaller IoT devices,
>    2544	   the cost and power budget for an extra part is often prohibitive.
>    2545	
>    2546	   It is becoming more and more common for CPUs to have an internal set
>    2547	   of one-time fuses that can be programmed (often they are "burnt" by a
>    2548	   laser) at the factory.  This section of memory is only accessible in
>    2549	   some privileged CPU state.  The use of this kind of CPU is
>    2550	   appropriate as it provides significant resistance against key
>    2551	   disclosure even when the device can be disassembled by an attacker.
>    2552	
>    2553	   In a number of industry verticals, there is increasing concern about
>    2554	   counterfeit parts.  These may be look-alike parts created in a
>    2555	   different factory, or parts which are created in the same factory
>    2556	   during an illegal night-shift, but which are not subject to the
>    2557	   appropriate level of quality control.  The use of a manufacturer-
>    2558	   signed IDevID certificate provides for discovery of the pedigree of
>    2559	   each part, and this often justifies the cost of the security measures
>    2560	   associated with storing the private key.
>    2561	
>    2562	14.3.  Security of the BRSKI-MASA Protocol
>    2563	
>    2564	   Section 7.1 explains why no CoAPS version of the BRSKI-MASA protocol
>    2565	   is specified.  The connection from the Registrar to the MASA
>    2566	   continues to be HTTPS as in [RFC8995].
>    2567	
>    2568	   This choice enables the BRSKI-MASA protocol, which operates over the
>    2569	   open Internet, to be secured using standard solutions that are
>    2570	   commonly used for HTTPS over the Internet.  The use of UDP protocols
>    2571	   across the Internet is sometimes fraught with security challenges.
>    2572	   Denial-of-service attacks against UDP based protocols are trivial as
>    2573	
>    2574	
>    2575	
>    2576	Richardson, et al.       Expires 31 August 2026                [Page 46]
>    2577	
>    2578	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2579	
>    2580	
>    2581	   there is no three-way handshake as done for TCP.  The three-way
>    2582	   handshake of TCP guarantees that the node sending the connection
>    2583	   request is reachable using the origin IP address.  While DTLS
>    2584	   contains an option to do a stateless challenge -- a process actually
>    2585	   stronger than that done by TCP -- it is not yet common for this
>    2586	   mechanism to be available in hardware at multigigabit speeds.
>
> minor:
>
>   No MASA needs multigigabit speeds, so the missing argument is that
> it may be a lot more difficult to get competitive cloud service pricing for running
> a MASA service if the MASA requires such uncommon protocols, because cloud services
> will preferentially treat application that they know can best be hardware optimized
> so as to not exhaust more resources as other services.
>
>    2587	
>    2588	   Also, in many enterprise networks outgoing UDP connections can be
>    2589	   treated as suspicious, which could effectively block CoAP connections
>    2590	   for some firewall configurations.  Reducing the complexity of MASA
>    2591	   (i.e. less protocols supported) also reduces its potential attack
>    2592	   surface, which is relevant since the MASA is 24/7 exposed on the
>    2593	   Internet and accepting (untrusted) incoming connections.
>    2594	
>    2595	14.4.  Registrar Certificate May Be Self-signed
>    2596	
>    2597	   The provisional (D)TLS connection formed by the Pledge with the
>    2598	   Registrar does not authenticate the Registrar's identity.  This
>    2599	   Registrar's identity is validated by the [RFC8366bis] voucher that is
>    2600	   issued by the MASA, signed with a trust anchor that was built-in to
>    2601	   the Pledge.
>    2602	
>    2603	   The Registrar may therefore use any certificate, including a self-
>    2604	   signed one.  The only restrictions on the certificate is that it MUST
>    2605	   have EKU bits set as detailed in Section 6.1.5 and Section 7.4.
>    2606	
>    2607	14.5.  Use of RPK Alternatives to 'proximity-registrar-cert'
>    2608	
>    2609	   In Section 9 of [RFC8366bis] two compact alternative attributes for
>    2610	   'proximity-registrar-cert' are defined that include an RPK:
>    2611	   'proximity-registrar-pubk' and 'proximity-registrar-pubk-sha256'.
>    2612	   The Pledge can use these attributes in its PVR to identify the
>    2613	   Registrar based on its public key only.  Since the full certificate
>    2614	   of the proximate Registrar is not included, use of these attributes
>    2615	   by a Pledge implies that a Registrar could insert another certificate
>    2616	   with the same public key identity into the RVR.  For example, an
>    2617	   older or a newer version of its certificate.  The MASA will not be
>    2618	   able to detect such act by the Registrar.  But since any certificate
>    2619	   the Registrar could insert in this way still encodes its own identity
>    2620	   the additional risk of using the RPK alternatives is negligible.
>    2621	
>    2622	   When a Registrar sees a PVR that uses one of 'proximity-registrar-
>    2623	   pubk' or 'proximity-registrar-pubk-sha256' attributes, this implies
>    2624	   the Registrar must include the certificate identified by these
>    2625	   attributes into its RVR.  Otherwise, the MASA is unable to verify
>    2626	   proximity.  This requirement is already implied by the "MUST"
>    2627	   requirement in Section 8.1.
>    2628	
>    2629	
>    2630	
>    2631	
>    2632	Richardson, et al.       Expires 31 August 2026                [Page 47]
>    2633	
>    2634	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2635	
>    2636	
>    2637	15.  IANA Considerations
>    2638	
>    2639	15.1.  Resource Type Link Target Attribute Values Registry
>    2640	
>    2641	   Additions to the "Resource Type (rt=) Link Target Attribute Values"
>    2642	   IANA registry, within the "CoRE Parameters" registry group are
>    2643	   specified below.
>    2644	
>    2645	   Reference: [This RFC]
>    2646	
>    2647	        +==========+==============================================+
>    2648	        | Value    | Description                                  |
>    2649	        +==========+==============================================+
>    2650	        | brski    | Base resource of all Bootstrapping Remote    |
>    2651	        |          | Secure Key Infrastructure (cBRSKI) resources |
>    2652	        +----------+----------------------------------------------+
>    2653	        | brski.rv | cBRSKI request voucher resource              |
>    2654	        +----------+----------------------------------------------+
>    2655	        | brski.vs | cBRSKI voucher status telemetry resource     |
>    2656	        +----------+----------------------------------------------+
>    2657	        | brski.es | cBRSKI enrollment status telemetry resource  |
>    2658	        +----------+----------------------------------------------+
>    2659	        | ace.est  | Base resource of all Enrollment over Secure  |
>    2660	        |          | Transport CoAPS (EST-coaps) resources        |
>    2661	        +----------+----------------------------------------------+
>    2662	
>    2663	             Table 2: Resource Type (rt) link target attribute
>    2664	                      values for cBRSKI and EST- coaps
>    2665	
>    2666	   Note that the resource type "brski" identifies a base resource in a
>    2667	   resource hierarchy on a CoAP server, where its sub-resources each
>    2668	   have one of the resource types "brski.*" as defined by this
>    2669	   specification.  Similarly, the resource type "ace.est" identifies a
>    2670	   base resource in a resource hierarchy, where its sub-resources each
>    2671	   have one of the resource types "ace.est.*" as defined by [RFC9148].
>    2672	
>    2673	15.2.  Media Types Registry
>    2674	
>    2675	   This section registers the media type application/voucher+cose in the
>    2676	   "Media Types" IANA registry.  This media type is used to indicate
>    2677	   that the content is a CBOR voucher or voucher request signed with a
>    2678	   COSE_Sign1 structure [RFC9052] as defined in this document.
>    2679	
>    2680	15.2.1.  application/voucher+cose
>    2681	
>    2682	
>    2683	
>    2684	
>    2685	
>    2686	
>    2687	
>    2688	Richardson, et al.       Expires 31 August 2026                [Page 48]
>    2689	
>    2690	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2691	
>    2692	
>    2693	   Type name:  application
>    2694	   Subtype name:  voucher+cose
>    2695	   Required parameters:  N/A
>    2696	   Optional parameters:  N/A
>    2697	   Encoding considerations:  binary (CBOR)
>    2698	   Security considerations:  Section 14 of [This RFC], and Section 12
>    2699	     of [RFC 9052] for the COSE_Sign1 structured that is used.
>    2700	   Interoperability considerations:  Section 15.2.2 of [This RFC]
>    2701	   Published specification:  [This RFC]
>    2702	   Applications that use this media type:  cBRSKI/ANIMA, 6TiSCH, and
>    2703	     other zero-touch onboarding systems
>    2704	   Fragment identifier considerations: N/A
>    2705	   Additional information:
>    2706	     Deprecated alias names for this type: N/A
>    2707	     Magic number(s):  N/A
>    2708	     File extension(s):  .vch
>    2709	     Macintosh file type code(s):  N/A
>    2710	   Person & email address to contact for further information:  IETF
>    2711	     ANIMA Working Group ([e-mail]) or IETF Operations and
>    2712	     Management Area Working Group ([e-mail])
>    2713	   Intended usage:  COMMON
>    2714	   Restrictions on usage:  N/A
>    2715	   Author:  ANIMA WG
>    2716	   Change controller:  IETF
>    2717	   Provisional registration? (standards tree only):  NO
>    2718	
>    2719	15.2.2.  Interoperability Considerations for application/voucher+cose
>    2720	
>    2721	   The media type defined here does not have any parameter to indicate
>    2722	   whether names are used, or SID integers are used, or both can be
>    2723	   mixed within a voucher data item.  In absence of any specific further
>    2724	   knowledge about this, a mixed use of SID integers and names MUST be
>    2725	   assumed, which is equivalent to the application/yang-data+cbor media
>    2726	   type ([RFC9254]) without the optional 'id' parameter.
>    2727	
>    2728	   Furthermore,
>    2729	
>    2730	   *  a Registrar assumes that mixed SIDs/names MAY be present in a
>    2731	      received PVR or voucher;
>    2732	
>    2733	   *  a MASA assumes that mixed SIDs/names MAY be present in a received
>    2734	      RVR;
>    2735	
>    2736	   *  a Pledge assumes, depending on its implementation, that SIDs are
>    2737	      present only, or names are present only, or mixed SIDs/names are
>    2738	      present in a received voucher.
>    2739	
>    2740	
>    2741	
>    2742	
>    2743	
>    2744	Richardson, et al.       Expires 31 August 2026                [Page 49]
>    2745	
>    2746	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2747	
>    2748	
>    2749	   Because the MASA and Pledge are under control (either directly or by
>    2750	   contract) of the same manufacturer, they can be co-developed
>    2751	   regarding the type of identifiers produced and identifiers consumed
>    2752	   in order to guarantee interoperability.
>    2753	
>    2754	15.3.  CoAP Content-Formats Registry
>    2755	
>    2756	   IANA has allocated ID 836 from the "CoAP Content-Formats" registry as
>    2757	   shown below.
>    2758	
>    2759	        +==========================+==========+=====+============+
>    2760	        | Media type               | Encoding | ID  | Reference  |
>    2761	        +==========================+==========+=====+============+
>    2762	        | application/voucher+cose | -        | 836 | [This RFC] |
>    2763	        +--------------------------+----------+-----+------------+
>    2764	
>    2765	           Table 3: Additions to the IANA CoAP Content-Formats
>    2766	                                 Registry
>    2767	
>    2768	15.4.  Update to BRSKI Well-Known URIs Registry
>    2769	
>    2770	   This section updates the "BRSKI Well-Known URIs" IANA registry of the
>    2771	   Bootstrapping Remote Secure Key Infrastructures (BRSKI) Parameters
>    2772	   Registry group, by adding a new column "Short Path Segment",
>    2773	   clarifying existing "Description" values, and renaming the column
>    2774	   "URI" to "Path Segment".
>    2775	
>    2776	   The new "Short Path Segment" entry denotes a shorter alternative to
>    2777	   Path Segment for the resource that can be used by a client in a CoAP
>    2778	   request on a well-known BRSKI resource.  A value "N/A" can be 2779 registered to denote that there is no short path segment 
> defined. 2780 2781 The contents of the registry with these changes 
> applied are as 2782 follows: 2783 2784 2785 2786 2787 2788 2789 2790 
> 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 Richardson, et al. 
> Expires 31 August 2026 [Page 50] 2801  2802 Internet-Draft 
> Constrained BRSKI (cBRSKI) February 2026 2803 2804 2805 
> +=================+============+=======================+============+ 
> 2806 | Path Segment | Short | Description | Reference | 2807 | | Path 
> | | | 2808 | | Segment | | | 2809 
> +=================+============+=======================+============+ 
> 2810 | requestvoucher | rv | Request voucher: | [RFC8995], | 2811 | | 
> | Pledge to Registrar, | [This RFC] | 2812 | | | and Registrar to MASA 
> | | 2813 
> +-----------------+------------+-----------------------+------------+ 
> 2814 | voucher_status | vs | Voucher status | [RFC8995], | 2815 | | | 
> telemetry: Pledge to | [This RFC] | 2816 | | | Registrar | | 2817 
> +-----------------+------------+-----------------------+------------+ 
> 2818 | requestauditlog | N/A | Request audit log: | [RFC8995] | 2819 | 
> | | Registrar to MASA | | 2820 
> +-----------------+------------+-----------------------+------------+ 
> 2821 | enrollstatus | es | Enrollment status | [RFC8995], | 2822 | | | 
> telemetry: Pledge to | [This RFC] | 2823 | | | Registrar | | 2824 
> +-----------------+------------+-----------------------+------------+ 
> 2825 2826 Table 4: Update of the IANA BRSKI Well-Known URIs Registry 
> 2827 2828 15.5. Structured Syntax Suffixes Registry 2829 2830 This 
> section registers the "+cose" suffix in the "Structured Syntax
>    2831	   Suffixes" IANA Registry based on the [RFC6838] procedure.
>    2832	
>    2833	
>    2834	
>    2835	
>    2836	
>    2837	
>    2838	
>    2839	
>    2840	
>    2841	
>    2842	
>    2843	
>    2844	
>    2845	
>    2846	
>    2847	
>    2848	
>    2849	
>    2850	
>    2851	
>    2852	
>    2853	
>    2854	
>    2855	
>    2856	Richardson, et al.       Expires 31 August 2026                [Page 51]
>    2857	
>    2858	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2859	
>    2860	
>    2861	   Name:       CBOR Object Signing and Encryption (COSE) object
>    2862	   +suffix:    +cose
>    2863	   References: the application/cose media type [RFC9052]
>    2864	   Encoding considerations: binary (CBOR)
>    2865	   Interoperability considerations:
>    2866	     the application/cose media type has an optional parameter
>    2867	     "cose-type". Any new media type that uses the +cose suffix
>    2868	     and allows use of this parameter MUST specify this
>    2869	     explicitly, per Section 4.3 of [RFC6838]. If the parameter
>    2870	     "cose-type" is allowed, its usage MUST be identical to the
>    2871	     usage defined for the application/cose media type in
>    2872	     Section 2 of [RFC9052].
>    2873	     A COSE processor handling a media type foo+cose and which
>    2874	     does not know the specific type "foo" SHOULD use the
>    2875	     cose-type COSE tag, if present, or cose-type parameter, if
>    2876	     present, to determine the specific COSE object type during
>    2877	     processing. If the specific type cannot be determined,
>    2878	     it MUST assume only the generic COSE object structure and
>    2879	     it MUST NOT perform security-critical operations using the
>    2880	     COSE object.
>    2881	   Fragment identifier considerations: N/A
>    2882	   Security considerations: see [RFC9052]
>    2883	   Contact:
>    2884	     IETF COSE Working Group ([e-mail]) or
>    2885	     IESG ([e-mail])
>    2886	   Author/Change controller:
>    2887	     IETF ANIMA Working Group ([e-mail])
>    2888	     IESG has change control over this registration.
>    2889	
>
> EOR - End Of Review
>
>    2890	16.  References
>    2891	
>    2892	16.1.  Normative References
>    2893	
>    2894	   [I-D.ietf-anima-constrained-join-proxy]
>    2895	              Dijk, E., Richardson, M., Van der Stok, P., and P.
>    2896	              Kampanakis, "Join Proxy for Bootstrapping of Constrained
>    2897	              Network Elements", Work in Progress, Internet-Draft,
>    2898	              draft-ietf-anima-constrained-join-proxy-18, 19 October
>    2899	              2025,<https://datatracker.ietf.org/doc/html/draft-ietf- 2900 
> anima-constrained-join-proxy-18>.
>    2901	
>    2902	   [I-D.ietf-core-uri-path-abbrev]
>    2903	              Amsüss, C. and M. Richardson, "URI-Path abbreviation in
>    2904	              CoAP", Work in Progress, Internet-Draft, draft-ietf-core-
>    2905	              uri-path-abbrev-02, 20 October 2025,
>    2906	<https://datatracker.ietf.org/doc/html/draft-ietf-core- 2907 
> uri-path-abbrev-02>.
>    2908	
>    2909	
>    2910	
>    2911	
>    2912	Richardson, et al.       Expires 31 August 2026                [Page 52]
>    2913	
>    2914	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2915	
>    2916	
>    2917	   [ieee802-1AR]
>    2918	              "IEEE 802.1AR Secure Device Identity", IEEE Standards
>    2919	              Association, 2018,
>    2920	<https://standards.ieee.org/ieee/802.1AR/6995/>.
>    2921	
>    2922	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>    2923	              Requirement Levels", BCP 14, RFC 2119,
>    2924	              DOI 10.17487/RFC2119, March 1997,
>    2925	<https://www.rfc-editor.org/rfc/rfc2119>.
>    2926	
>    2927	   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
>    2928	              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
>    2929	<https://www.rfc-editor.org/rfc/rfc4193>.
>    2930	
>    2931	   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
>    2932	              "Internet X.509 Public Key Infrastructure Certificate
>    2933	              Management Protocol (CMP)", RFC 4210,
>    2934	              DOI 10.17487/RFC4210, September 2005,
>    2935	<https://www.rfc-editor.org/rfc/rfc4210>.
>    2936	
>    2937	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
>    2938	              Housley, R., and W. Polk, "Internet X.509 Public Key
>    2939	              Infrastructure Certificate and Certificate Revocation List
>    2940	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
>    2941	<https://www.rfc-editor.org/rfc/rfc5280>.
>    2942	
>    2943	   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
>    2944	              Extensions: Extension Definitions", RFC 6066,
>    2945	              DOI 10.17487/RFC6066, January 2011,
>    2946	<https://www.rfc-editor.org/rfc/rfc6066>.
>    2947	
>    2948	   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
>    2949	              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
>    2950	              January 2012,<https://www.rfc-editor.org/rfc/rfc6347>.
>    2951	
>    2952	   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
>    2953	              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
>    2954	<https://www.rfc-editor.org/rfc/rfc6690>.
>    2955	
>    2956	   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
>    2957	              DOI 10.17487/RFC6762, February 2013,
>    2958	<https://www.rfc-editor.org/rfc/rfc6762>.
>    2959	
>    2960	   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
>    2961	              "Enrollment over Secure Transport", RFC 7030,
>    2962	              DOI 10.17487/RFC7030, October 2013,
>    2963	<https://www.rfc-editor.org/rfc/rfc7030>.
>    2964	
>    2965	
>    2966	
>    2967	
>    2968	Richardson, et al.       Expires 31 August 2026                [Page 53]
>    2969	
>    2970	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    2971	
>    2972	
>    2973	   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
>    2974	              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
>    2975	              Transport Layer Security (TLS) and Datagram Transport
>    2976	              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
>    2977	              June 2014,<https://www.rfc-editor.org/rfc/rfc7250>.
>    2978	
>    2979	   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
>    2980	              Application Protocol (CoAP)", RFC 7252,
>    2981	              DOI 10.17487/RFC7252, June 2014,
>    2982	<https://www.rfc-editor.org/rfc/rfc7252>.
>    2983	
>    2984	   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
>    2985	              the Constrained Application Protocol (CoAP)", RFC 7959,
>    2986	              DOI 10.17487/RFC7959, August 2016,
>    2987	<https://www.rfc-editor.org/rfc/rfc7959>.
>    2988	
>    2989	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
>    2990	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
>    2991	              May 2017,<https://www.rfc-editor.org/rfc/rfc8174>.
>    2992	
>    2993	   [RFC8366bis]
>    2994	              Watsen, K., Richardson, M., Dijk, E., Eckert, T. T., and
>    2995	              Q. Ma, "A Voucher Artifact for Bootstrapping Protocols",
>    2996	              Work in Progress, Internet-Draft, draft-ietf-anima-
>    2997	              rfc8366bis-27, 26 February 2026,
>    2998	<https://datatracker.ietf.org/doc/html/draft-ietf-anima- 2999 
> rfc8366bis-27>.
>    3000	
>    3001	   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
>    3002	              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
>    3003	<https://www.rfc-editor.org/rfc/rfc8446>.
>    3004	
>    3005	   [RFC8449]  Thomson, M., "Record Size Limit Extension for TLS",
>    3006	              RFC 8449, DOI 10.17487/RFC8449, August 2018,
>    3007	<https://www.rfc-editor.org/rfc/rfc8449>.
>    3008	
>    3009	   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
>    3010	              Definition Language (CDDL): A Notational Convention to
>    3011	              Express Concise Binary Object Representation (CBOR) and
>    3012	              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
>    3013	              June 2019,<https://www.rfc-editor.org/rfc/rfc8610>.
>    3014	
>    3015	   [RFC8710]  Fossati, T., Hartke, K., and C. Bormann, "Multipart
>    3016	              Content-Format for the Constrained Application Protocol
>    3017	              (CoAP)", RFC 8710, DOI 10.17487/RFC8710, February 2020,
>    3018	<https://www.rfc-editor.org/rfc/rfc8710>.
>    3019	
>    3020	
>    3021	
>    3022	
>    3023	
>    3024	Richardson, et al.       Expires 31 August 2026                [Page 54]
>    3025	
>    3026	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3027	
>    3028	
>    3029	   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
>    3030	              Representation (CBOR)", STD 94, RFC 8949,
>    3031	              DOI 10.17487/RFC8949, December 2020,
>    3032	<https://www.rfc-editor.org/rfc/rfc8949>.
>    3033	
>    3034	   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
>    3035	              and K. Watsen, "Bootstrapping Remote Secure Key
>    3036	              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
>    3037	              May 2021,<https://www.rfc-editor.org/rfc/rfc8995>.
>    3038	
>    3039	   [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
>    3040	              Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
>    3041	              RFC 9031, DOI 10.17487/RFC9031, May 2021,
>    3042	<https://www.rfc-editor.org/rfc/rfc9031>.
>    3043	
>    3044	   [RFC9032]  Dujovne, D., Ed. and M. Richardson, "Encapsulation of
>    3045	              6TiSCH Join and Enrollment Information Elements",
>    3046	              RFC 9032, DOI 10.17487/RFC9032, May 2021,
>    3047	<https://www.rfc-editor.org/rfc/rfc9032>.
>    3048	
>    3049	   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
>    3050	              Structures and Process", STD 96, RFC 9052,
>    3051	              DOI 10.17487/RFC9052, August 2022,
>    3052	<https://www.rfc-editor.org/rfc/rfc9052>.
>    3053	
>    3054	   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
>    3055	              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
>    3056	              August 2022,<https://www.rfc-editor.org/rfc/rfc9053>.
>    3057	
>    3058	   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
>    3059	              Datagram Transport Layer Security (DTLS) Protocol Version
>    3060	              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
>    3061	<https://www.rfc-editor.org/rfc/rfc9147>.
>    3062	
>    3063	   [RFC9148]  van der Stok, P., Kampanakis, P., Richardson, M., and S.
>    3064	              Raza, "EST-coaps: Enrollment over Secure Transport with
>    3065	              the Secure Constrained Application Protocol", RFC 9148,
>    3066	              DOI 10.17487/RFC9148, April 2022,
>    3067	<https://www.rfc-editor.org/rfc/rfc9148>.
>    3068	
>    3069	   [RFC9254]  Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
>    3070	              C., and M. Richardson, "Encoding of Data Modeled with YANG
>    3071	              in the Concise Binary Object Representation (CBOR)",
>    3072	              RFC 9254, DOI 10.17487/RFC9254, July 2022,
>    3073	<https://www.rfc-editor.org/rfc/rfc9254>.
>    3074	
>    3075	
>    3076	
>    3077	
>    3078	
>    3079	
>    3080	Richardson, et al.       Expires 31 August 2026                [Page 55]
>    3081	
>    3082	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3083	
>    3084	
>    3085	   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
>    3086	              Header Parameters for Carrying and Referencing X.509
>    3087	              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
>    3088	              2023,<https://www.rfc-editor.org/rfc/rfc9360>.
>    3089	
>    3090	   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
>    3091	              RFC 9525, DOI 10.17487/RFC9525, November 2023,
>    3092	<https://www.rfc-editor.org/rfc/rfc9525>.
>    3093	
>    3094	16.2.  Informative References
>    3095	
>    3096	   [COSE-registry]
>    3097	              IANA, "CBOR Object Signing and Encryption (COSE) registry
>    3098	              group", 11 January 2017,
>    3099	<https://www.iana.org/assignments/cose/cose.xhtml>.
>    3100	
>    3101	   [I-D.ietf-6lo-mesh-link-establishment]
>    3102	              Kelsey, R., "Mesh Link Establishment", Work in Progress,
>    3103	              Internet-Draft, draft-ietf-6lo-mesh-link-establishment-00,
>    3104	              1 December 2015,<https://datatracker.ietf.org/doc/html/ 3105 
> draft-ietf-6lo-mesh-link-establishment-00>.
>    3106	
>    3107	   [I-D.ietf-anima-brski-discovery]
>    3108	              Eckert, T. T. and E. Dijk, "BRSKI discovery and
>    3109	              variations", Work in Progress, Internet-Draft, draft-ietf-
>    3110	              anima-brski-discovery-09, 20 October 2025,
>    3111	<https://datatracker.ietf.org/doc/html/draft-ietf-anima- 3112 
> brski-discovery-09>.
>    3113	
>    3114	   [I-D.ietf-anima-jws-voucher]
>    3115	              Werner, T. and M. Richardson, "JWS signed Voucher
>    3116	              Artifacts for Bootstrapping Protocols", Work in Progress,
>    3117	              Internet-Draft, draft-ietf-anima-jws-voucher-16, 15
>    3118	              January 2025,<https://datatracker.ietf.org/doc/html/ 3119 
> draft-ietf-anima-jws-voucher-16>.
>    3120	
>    3121	   [I-D.ietf-cbor-edn-literals]
>    3122	              Bormann, C., "CBOR Extended Diagnostic Notation (EDN)",
>    3123	              Work in Progress, Internet-Draft, draft-ietf-cbor-edn-
>    3124	              literals-19, 16 October 2025,
>    3125	<https://datatracker.ietf.org/doc/html/draft-ietf-cbor- 3126 
> edn-literals-19>.
>    3127	
>    3128	
>    3129	
>    3130	
>    3131	
>    3132	
>    3133	
>    3134	
>    3135	
>    3136	Richardson, et al.       Expires 31 August 2026                [Page 56]
>    3137	
>    3138	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3139	
>    3140	
>    3141	   [I-D.ietf-cose-cbor-encoded-cert]
>    3142	              Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
>    3143	              M. Furuhed, "CBOR Encoded X.509 Certificates (C509
>    3144	              Certificates)", Work in Progress, Internet-Draft, draft-
>    3145	              ietf-cose-cbor-encoded-cert-16, 25 January 2026,
>    3146	<https://datatracker.ietf.org/doc/html/draft-ietf-cose- 3147 
> cbor-encoded-cert-16>.
>    3148	
>    3149	   [I-D.richardson-anima-masa-considerations]
>    3150	              Richardson, M. and W. Pan, "Operational Considerations for
>    3151	              Voucher infrastructure for BRSKI MASA", Work in Progress,
>    3152	              Internet-Draft, draft-richardson-anima-masa-
>    3153	              considerations-09, 22 January 2025,
>    3154	<https://datatracker.ietf.org/doc/html/draft-richardson- 3155 
> anima-masa-considerations-09>.
>    3156	
>    3157	   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
>    3158	              Control Message Protocol (ICMPv6) for the Internet
>    3159	              Protocol Version 6 (IPv6) Specification", STD 89,
>    3160	              RFC 4443, DOI 10.17487/RFC4443, March 2006,
>    3161	<https://www.rfc-editor.org/rfc/rfc4443>.
>    3162	
>    3163	   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
>    3164	              RFC 5652, DOI 10.17487/RFC5652, September 2009,
>    3165	<https://www.rfc-editor.org/rfc/rfc5652>.
>    3166	
>    3167	   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
>    3168	              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
>    3169	              DOI 10.17487/RFC6282, September 2011,
>    3170	<https://www.rfc-editor.org/rfc/rfc6282>.
>    3171	
>    3172	   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
>    3173	              Bormann, "Neighbor Discovery Optimization for IPv6 over
>    3174	              Low-Power Wireless Personal Area Networks (6LoWPANs)",
>    3175	              RFC 6775, DOI 10.17487/RFC6775, November 2012,
>    3176	<https://www.rfc-editor.org/rfc/rfc6775>.
>    3177	
>    3178	   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
>    3179	              Specifications and Registration Procedures", BCP 13,
>    3180	              RFC 6838, DOI 10.17487/RFC6838, January 2013,
>    3181	<https://www.rfc-editor.org/rfc/rfc6838>.
>    3182	
>    3183	   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
>    3184	              Constrained-Node Networks", RFC 7228,
>    3185	              DOI 10.17487/RFC7228, May 2014,
>    3186	<https://www.rfc-editor.org/rfc/rfc7228>.
>    3187	
>    3188	
>    3189	
>    3190	
>    3191	
>    3192	Richardson, et al.       Expires 31 August 2026                [Page 57]
>    3193	
>    3194	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3195	
>    3196	
>    3197	   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
>    3198	              RFC 7950, DOI 10.17487/RFC7950, August 2016,
>    3199	<https://www.rfc-editor.org/rfc/rfc7950>.
>    3200	
>    3201	   [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
>    3202	              "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
>    3203	              May 2018,<https://www.rfc-editor.org/rfc/rfc8392>.
>    3204	
>    3205	   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
>    3206	              Autonomic Signaling Protocol (GRASP)", RFC 8990,
>    3207	              DOI 10.17487/RFC8990, May 2021,
>    3208	<https://www.rfc-editor.org/rfc/rfc8990>.
>    3209	
>    3210	   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
>    3211	              W. Pan, "Remote ATtestation procedureS (RATS)
>    3212	              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
>    3213	              2023,<https://www.rfc-editor.org/rfc/rfc9334>.
>    3214	
>    3215	   [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
>    3216	              "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
>    3217	              DOI 10.17487/RFC9528, March 2024,
>    3218	<https://www.rfc-editor.org/rfc/rfc9528>.
>    3219	
>    3220	   [RFC9595]  Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed.,
>    3221	              Bormann, C., and M. Richardson, "YANG Schema Item
>    3222	              iDentifier (YANG SID)", RFC 9595, DOI 10.17487/RFC9595,
>    3223	              July 2024,<https://www.rfc-editor.org/rfc/rfc9595>.
>    3224	
>    3225	   [RFC9597]  Looker, T. and M.B. Jones, "CBOR Web Token (CWT) Claims in
>    3226	              COSE Headers", RFC 9597, DOI 10.17487/RFC9597, June 2024,
>    3227	<https://www.rfc-editor.org/rfc/rfc9597>.
>    3228	
>    3229	   [Thread]   Thread Group, Inc, "Thread Group website", February 2026,
>    3230	<https://www.threadgroup.org/>.
>    3231	
>    3232	Appendix A.  Software and Library Support for cBRSKI
>    3233	
>    3234	   This appendix lists software and security libraries that may be
>    3235	   useful for implementing cBRSKI functionality.
>    3236	
>    3237	A.1.  Open Source cBRSKI Implementations
>    3238	
>    3239	   There are a few ongoing open source projects to support cBRSKI
>    3240	   development and testing.  These include:
>    3241	
>    3242	   *  OpenThread Registrar (OT Registrar) - a cBRSKI Registrar, test
>    3243	      MASA server, and test Pledge written in Java.  Link
>    3244	      (https://github.com/EskoDijk/ot-registrar)
>    3245	
>    3246	
>    3247	
>    3248	Richardson, et al.       Expires 31 August 2026                [Page 58]
>    3249	
>    3250	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3251	
>    3252	
>    3253	   *  OpenThread CCM (pre-alpha) - a cBRSKI Pledge and Join Proxy for
>    3254	      OpenThread-based IoT nodes, written in C/C++. OpenThread nodes
>    3255	      implement the [Thread] protocol.  Link
>    3256	      (https://github.com/EskoDijk/openthread/pull/7)
>    3257	
>    3258	   *  OpenThread Network Simulator v2 (OTNS2) - a CLI + GUI simulator
>    3259	      for OpenThread IoT nodes in 6LoWPAN [RFC6282] mesh networks, able
>    3260	      to accurately simulate cBRSKI Pledges onboarding (pre-alpha
>    3261	      functionality) to a Thread mesh network via an OT Registrar.  Link
>    3262	      (https://github.com/EskoDijk/ot-ns/pull/165)
>    3263	
>    3264	   *  Fountain - a BRSKI/6TiSCH Registrar with support for COSE-signed
>    3265	      vouchers, written in Ruby.  Link (https://github.com/AnimaGUS-
>    3266	      minerva/fountain)
>    3267	
>    3268	A.2.  Security Library Support
>    3269	
>    3270	   For the implementation of BRSKI/cBRSKI, the use of a software library
>    3271	   to manipulate PKIX certificates, establish secure (D)TLS connections,
>    3272	   and use crypto algorithms is often beneficial.  Two C-based examples
>    3273	   are OpenSSL and mbedtls.  Others more targeted to specific platforms
>    3274	   or languages exist.  It is important to realize that the library
>    3275	   interfaces differ significantly between libraries.
>    3276	
>    3277	   Libraries do not support all known crypto algorithms.  Before
>    3278	   deciding on a library, it is important to look at their supported
>    3279	   crypto algorithms and the roadmap for future support.  Apart from
>    3280	   availability, the library footprint, and the required execution
>    3281	   cycles should be investigated beforehand.
>    3282	
>    3283	   The handling of certificates usually includes the checking of a
>    3284	   certificate chain.  In some libraries, chains are constructed and
>    3285	   verified on the basis of a set of certificates, the trust anchor
>    3286	   (usually a self signed root CA), and the target certificate.  In
>    3287	   other libraries, the chain must be constructed beforehand and obey
>    3288	   ordering criteria.  Verification always includes the checking of the
>    3289	   signatures.  Less frequent is the checking the validity of the dates
>    3290	   or checking the existence of a revoked certificate in the chain
>    3291	   against a set of revoked certificates.  Checking the chain on the
>    3292	   consistency of the certificate extensions which specify the use of
>    3293	   the certificate usually needs to be programmed explicitly.
>    3294	
>    3295	   A library can be used to construct a (D)TLS connection.  It is useful
>    3296	   to realize that differences between (D)TLS implementations will occur
>    3297	   due to the differences in the certificate checks supported by the
>    3298	   library.  On top of that, checks between client and server
>    3299	   certificates enforced by (D)TLS are not always helpful for a BRSKI
>    3300	   implementation.  For example, the certificates of Pledge and
>    3301	
>    3302	
>    3303	
>    3304	Richardson, et al.       Expires 31 August 2026                [Page 59]
>    3305	
>    3306	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3307	
>    3308	
>    3309	   Registrar are usually not related when the BRSKI protocol is started.
>    3310	   It must be verified that checks on the relation between client and
>    3311	   server certificates do not hamper a succeful DTLS connection
>    3312	   establishment.
>    3313	
>    3314	A.2.1.  OpensSSL Example Code
>    3315	
>    3316	   From OpenSSL's apps/verify.c :
>    3317	
>    3318	   <CODE BEGINS>
>    3319	   X509 *x = NULL;
>    3320	   int i = 0, ret = 0;
>    3321	   X509_STORE_CTX *csc;
>    3322	   STACK_OF(X509) *chain = NULL;
>    3323	   int num_untrusted;
>    3324	
>    3325	   x = load_cert(file, "certificate file");
>    3326	   if (x == NULL)
>    3327	       goto end;
>    3328	
>    3329	   csc = X509_STORE_CTX_new();
>    3330	   if (csc == NULL) {
>    3331	       BIO_printf(bio_err, "error %s: X.509 store context"
>    3332	                  "allocation failed\n",
>    3333	                  (file == NULL) ? "stdin" : file);
>    3334	       goto end;
>    3335	   }
>    3336	
>    3337	   X509_STORE_set_flags(ctx, vflags);
>    3338	   if (!X509_STORE_CTX_init(csc, ctx, x, uchain)) {
>    3339	       X509_STORE_CTX_free(csc);
>    3340	       BIO_printf(bio_err,
>    3341	                  "error %s: X.509 store context"
>    3342	                  "initialization failed\n",
>    3343	                  (file == NULL) ? "stdin" : file);
>    3344	       goto end;
>    3345	   }
>    3346	   if (tchain != NULL)
>    3347	       X509_STORE_CTX_set0_trusted_stack(csc, tchain);
>    3348	   if (crls != NULL)
>    3349	       X509_STORE_CTX_set0_crls(csc, crls);
>    3350	
>    3351	   i = X509_verify_cert(csc);
>    3352	   X509_STORE_CTX_free(csc);
>    3353	
>    3354	   <CODE ENDS>
>    3355	
>    3356	
>    3357	
>    3358	
>    3359	
>    3360	Richardson, et al.       Expires 31 August 2026                [Page 60]
>    3361	
>    3362	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3363	
>    3364	
>    3365	A.2.2.  mbedTLS Example Code
>    3366	
>    3367	   <CODE BEGINS>
>    3368	   mbedtls_x509_crt cert;
>    3369	   mbedtls_x509_crt caCert;
>    3370	   uint32_t         certVerifyResultFlags;
>    3371	   // ...
>    3372	   int result = mbedtls_x509_crt_verify(&cert, &caCert, NULL, NULL,
>    3373	                                &certVerifyResultFlags, NULL, NULL);
>    3374	
>    3375	   <CODE ENDS>
>    3376	
>    3377	A.3.  Generating Certificates with OpenSSL
>    3378	
>    3379	   This informative appendix shows example Bash shell scripts to
>    3380	   generate test PKIX certificates for the Pledge IDevID, the Registrar
>    3381	   and the MASA.  The shell scripts cannot be run stand-alone because
>    3382	   they depend on input files which are not all included in this
>    3383	   appendix.  Nevertheless, these scripts may provide guidance on how
>    3384	   OpenSSL can be configured for generating cBRSKI certificates.
>    3385	
>    3386	   The scripts were tested with OpenSSL 3.0.2.  Older versions may not
>    3387	   work -- OpenSSL 1.1.1 for example does not support all extensions
>    3388	   used.
>    3389	
>    3390	
>    3391	
>    3392	
>    3393	
>    3394	
>    3395	
>    3396	
>    3397	
>    3398	
>    3399	
>    3400	
>    3401	
>    3402	
>    3403	
>    3404	
>    3405	
>    3406	
>    3407	
>    3408	
>    3409	
>    3410	
>    3411	
>    3412	
>    3413	
>    3414	
>    3415	
>    3416	Richardson, et al.       Expires 31 August 2026                [Page 61]
>    3417	
>    3418	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3419	
>    3420	
>    3421	   <CODE BEGINS>
>    3422	   #!/bin/bash
>    3423	   # File: create-cert-Pledge.sh
>    3424	   # Create new cert for: Pledge IDevID
>    3425	
>    3426	   # days certificate is valid - try to get close to the 802.1AR
>    3427	   # specified 9999-12-31 end date.
>    3428	   SECONDS1=`date +%s` # time now
>    3429	   SECONDS2=`date --date="9999-12-31 23:59:59Z" +%s` # target end time
>    3430	   let VALIDITY="(${SECONDS2}-${SECONDS1})/(24*3600)"
>    3431	   echo "Using validity param -days ${VALIDITY}"
>    3432	
>    3433	   NAME=pledge
>    3434	
>    3435	   # create csr for device
>    3436	   # conform to 802.1AR guidelines, using only CN + serialNumber when
>    3437	   # manufacturer is already present as CA.
>    3438	   # CN is not even mandatory, but just good practice.
>    3439	   openssl req -new -key keys/privkey_pledge.pem -out $NAME.csr -subj \
>    3440	                "/CN=Stok IoT sensor Y-42/serialNumber=JADA123456789"
>    3441	
>    3442	   # sign csr - it uses faketime only to get endtime to 23:59:59Z
>    3443	   faketime '23:59:59Z' \
>    3444	   openssl x509 -set_serial 32429 -CAform PEM -CA output/masa_ca.pem \
>    3445	     -CAkey keys/privkey_masa_ca.pem -extfile x509v3.ext -extensions \
>    3446	     pledge_ext -req -in $NAME.csr -out output/$NAME.pem \
>    3447	     -days $VALIDITY -sha256
>    3448	
>    3449	   # Note: alternative method using 'ca' command. Currently
>    3450	   # doesn't work without 'country' subject field.
>    3451	   # openssl ca -rand_serial -enddate 99991231235959Z -certform PEM \
>    3452	   #  -cert output/masa_ca.pem -keyfile keys/privkey_masa_ca.pem \
>    3453	   #  -extfile x509v3.ext -extensions pledge_ext -in $NAME.csr \
>    3454	   #  -out $NAME.pem -outdir output
>    3455	
>    3456	   # delete temp files
>    3457	   rm -f $NAME.csr
>    3458	
>    3459	   # convert to .der format
>    3460	   openssl x509 -in output/$NAME.pem -inform PEM -out output/$NAME.der \
>    3461	                -outform DER
>    3462	
>    3463	   <CODE ENDS>
>    3464	
>    3465	
>    3466	
>    3467	
>    3468	
>    3469	
>    3470	
>    3471	
>    3472	Richardson, et al.       Expires 31 August 2026                [Page 62]
>    3473	
>    3474	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3475	
>    3476	
>    3477	   <CODE BEGINS>
>    3478	   # File: x509v3.ext
>    3479	   # This file contains all X509v3 extension definitions for OpenSSL
>    3480	   # certificate generation. Each certificate has its own _ext
>    3481	   # section below.
>    3482	
>    3483	   [ req ]
>    3484	   prompt = no
>    3485	
>    3486	   [ masa_ca_ext ]
>    3487	   subjectAltName=email:[e-mail]
>    3488	   keyUsage = critical,digitalSignature, keyCertSign, cRLSign
>    3489	   basicConstraints = critical,CA:TRUE,pathlen:3
>    3490	   subjectKeyIdentifier=hash
>    3491	   authorityKeyIdentifier=keyid
>    3492	
>    3493	   [ pledge_ext ]
>    3494	   keyUsage = critical,digitalSignature, nonRepudiation, \
>    3495	              keyEncipherment, dataEncipherment
>    3496	   # basicConstraints for a non-CA cert MAY be marked either
>    3497	   # non-critical or critical.
>    3498	   basicConstraints =CA:FALSE
>    3499	   # Don't include subjectKeyIdentifier (SKI) - see 802.1AR-2018
>    3500	   subjectKeyIdentifier = none
>    3501	   authorityKeyIdentifier=keyid
>    3502	   # Include the MASA URI
>    3503	   1.3.6.1.5.5.7.1.32 =ASN1:IA5STRING:masa.stok.nl
>    3504	
>    3505	   [ domain_ca_ext ]
>    3506	   subjectAltName=email:[e-mail]
>    3507	   keyUsage = critical, keyCertSign, digitalSignature, cRLSign
>    3508	   basicConstraints=critical,CA:TRUE
>    3509	   # RFC 5280 4.2.1.1 : AKI MAY be omitted, and MUST be non-critical;
>    3510	   # SKI MUST be non-critical
>    3511	   subjectKeyIdentifier=hash
>    3512	
>    3513	   [ registrar_ext ]
>    3514	   keyUsage = critical, digitalSignature, nonRepudiation, \
>    3515	              keyEncipherment, dataEncipherment
>    3516	   basicConstraints=CA:FALSE
>    3517	   subjectKeyIdentifier=hash
>    3518	   authorityKeyIdentifier=keyid
>    3519	   # Set Registrar 'RA' flag along with TLS client/server usage
>    3520	   #  see draft-ietf-anima-constrained-voucher#section-7.3
>    3521	   #  see tools.ietf.org/html/rfc6402#section-2.10
>    3522	   #  seewww.openssl.org/docs/man1.1.1/man5/x509v3_config.html
>    3523	   extendedKeyUsage = critical,1.3.6.1.5.5.7.3.28, serverAuth, \
>    3524	                      clientAuth
>    3525	
>    3526	
>    3527	
>    3528	Richardson, et al.       Expires 31 August 2026                [Page 63]
>    3529	
>    3530	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3531	
>    3532	
>    3533	   <CODE ENDS>
>    3534	
>    3535	   <CODE BEGINS>
>    3536	   #!/bin/bash
>    3537	   # File: create-cert-Registrar.sh
>    3538	   # Create new cert for: Registrar in a company domain
>    3539	
>    3540	   # days certificate is valid
>    3541	   VALIDITY=1095
>    3542	
>    3543	   # cert filename
>    3544	   NAME=registrar
>    3545	
>    3546	   # create csr
>    3547	   openssl req -new -key keys/privkey_registrar.pem -out $NAME.csr \
>    3548	    -subj "/CN=Custom-ER Registrar/OU=Office dept/O=Custom-ER, Inc./\
>    3549	   L=Ottowa/ST=ON/C=CA"
>    3550	
>    3551	   # sign csr
>    3552	   openssl x509 -set_serial 0xC3F62149B2E30E3E -CAform PEM -CA \
>    3553	    output/domain_ca.pem -extfile x509v3.ext -extensions registrar_ext \
>    3554	    -req -in $NAME.csr -CAkey keys/privkey_domain_ca.pem \
>    3555	    -out output/$NAME.pem -days $VALIDITY -sha256
>    3556	
>    3557	   # delete temp files
>    3558	   rm -f $NAME.csr
>    3559	
>    3560	   # convert to .der format
>    3561	   openssl x509 -in output/$NAME.pem -inform PEM -out output/$NAME.der \
>    3562	                -outform DER
>    3563	
>    3564	   <CODE ENDS>
>    3565	
>    3566	
>    3567	
>    3568	
>    3569	
>    3570	
>    3571	
>    3572	
>    3573	
>    3574	
>    3575	
>    3576	
>    3577	
>    3578	
>    3579	
>    3580	
>    3581	
>    3582	
>    3583	
>    3584	Richardson, et al.       Expires 31 August 2026                [Page 64]
>    3585	
>    3586	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3587	
>    3588	
>    3589	   <CODE BEGINS>
>    3590	   #!/bin/bash
>    3591	   # File: create-cert-MASA.sh
>    3592	   # Create new cert for: MASA CA, self-signed CA certificate
>    3593	
>    3594	   # days certificate is valid
>    3595	   VALIDITY=3650
>    3596	
>    3597	   NAME=masa_ca
>    3598	
>    3599	   # create csr
>    3600	   openssl req -new -key keys/privkey_masa_ca.pem -out $NAME.csr \
>    3601	               -subj "/CN=masa.stok.nl/O=vanderstok/L=Helmond/C=NL"
>    3602	
>    3603	   # sign csr
>    3604	   mkdir output >& /dev/null
>    3605	   openssl x509 -set_serial 0xE39CDA17E1386A0A  -extfile x509v3.ext \
>    3606	    -extensions masa_ca_ext -req -in $NAME.csr \
>    3607	    -signkey keys/privkey_masa_ca.pem -out output/$NAME.pem \
>    3608	    -days $VALIDITY -sha256
>    3609	
>    3610	   # delete temp files
>    3611	   rm -f $NAME.csr
>    3612	
>    3613	   # convert to .der format
>    3614	   openssl x509 -in output/$NAME.pem -inform PEM -out output/$NAME.der \
>    3615	                -outform DER
>    3616	
>    3617	   <CODE ENDS>
>    3618	
>    3619	Appendix B.  cBRSKI Message Examples
>    3620	
>    3621	   This appendix extends the EST-coaps message examples from Appendix A
>    3622	   of [RFC9148] with cBRSKI messages.  The CoAP headers are only fully
>    3623	   worked out for the first example, enrollstatus.
>    3624	
>    3625	B.1.  enrollstatus
>    3626	
>    3627	   A coaps enrollstatus message from Pledge to Registrar can be as
>    3628	   follows:
>    3629	
>    3630	     REQ: POST /b/es
>    3631	       Content-Format: 60 (application/cbor)
>    3632	       Payload: <binary CBOR encoding of an enrollstatus map>
>    3633	
>    3634	   The corresponding CoAP header fields for this request are shown
>    3635	   below.
>    3636	
>    3637	
>    3638	
>    3639	
>    3640	Richardson, et al.       Expires 31 August 2026                [Page 65]
>    3641	
>    3642	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3643	
>    3644	
>    3645	     Ver = 1
>    3646	     T = 0 (CON)
>    3647	     TKL = 1
>    3648	     Code = 0x02 (0.02 is POST method)
>    3649	     Message ID = 0xab0f
>    3650	     Token = 0x4d
>    3651	     Options
>    3652	      Option  (Uri-Path)
>    3653	        Option Delta = 0xb   (option nr = 11)
>    3654	        Option Length = 0x1
>    3655	        Option Value = "b"
>    3656	      Option  (Uri-Path)
>    3657	        Option Delta = 0x0   (option nr = 11)
>    3658	        Option Length = 0x2
>    3659	        Option Value = "es"
>    3660	      Option  (Content-Format)
>    3661	        Option Delta = 0x1   (option nr = 12)
>    3662	        Option Length = 0x1
>    3663	        Option Value = 60    (application/cbor)
>    3664	     Payload Marker = 0xFF
>    3665	     Payload = A26776657273696F6E0166737461747573F5 (18 bytes binary)
>    3666	
>    3667	   The Uri-Host and Uri-Port Options are omitted because they coincide
>    3668	   with the transport protocol (UDP) destination address and port
>    3669	   respectively.
>    3670	
>    3671	   The above binary CBOR enrollstatus payload looks as follows in CBOR
>    3672	   diagnostic notation, for the case of enrollment success:
>    3673	
>    3674	     {
>    3675	       "version": 1,
>    3676	       "status": true
>    3677	      }
>    3678	
>    3679	   Alternatively the payload could look as follows in case of enrollment
>    3680	   failure, using the 'reason' map item value to describe the failure:
>    3681	
>    3682	     Payload = A36776657273696F6E0166737461747573F466726561736F6E782A3C
>    3683	               496E666F726D61746976652068756D616E207265616461626C652065
>    3684	               72726F72206D6573736167653E    (69 bytes binary)
>    3685	
>    3686	     {
>    3687	       "version": 1,
>    3688	       "status": false,
>    3689	       "reason": "<Informative human readable error message>"
>    3690	     }
>    3691	
>    3692	
>    3693	
>    3694	
>    3695	
>    3696	Richardson, et al.       Expires 31 August 2026                [Page 66]
>    3697	
>    3698	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3699	
>    3700	
>    3701	   To indicate successful reception of the enrollmentstatus telemetry
>    3702	   report, a response from the Registrar may then be:
>    3703	
>    3704	     2.04 Changed
>    3705	
>    3706	   Which in case of a piggybacked response has the following CoAP header
>    3707	   fields:
>    3708	
>    3709	     Ver=1
>    3710	     T=2 (ACK)
>    3711	     TKL=1
>    3712	     Code = 0x44 (2.04 Changed)
>    3713	     Message ID = 0xab0f
>    3714	     Token = 0x4d
>    3715	
>    3716	B.2.  voucher_status
>    3717	
>    3718	   A coaps voucher_status message from Pledge to Registrar can be as
>    3719	   follows:
>    3720	
>    3721	     REQ: POST /.well-known/brski/vs
>    3722	       Content-Format: 60 (application/cbor)
>    3723	       Payload:
>    3724	       A46776657273696F6E0166737461747573F466726561736F6E7828496E66
>    3725	       6F726D61746976652068756D616E2D7265616461626C65206572726F7220
>    3726	       6D6573736167656E726561736F6E2D636F6E74657874A100764164646974
>    3727	       696F6E616C20696E666F726D6174696F6E
>    3728	
>    3729	   The request payload above is binary CBOR but represented here in
>    3730	   hexadecimal for readability.  Below is the equivalent CBOR diagnostic
>    3731	   format.
>    3732	
>    3733	     {
>    3734	       "version": 1,
>    3735	       "status": false,
>    3736	       "reason": "Informative human-readable error message",
>    3737	       "reason-context": { 0: "Additional information" }
>    3738	     }
>    3739	
>    3740	   A success response without payload will then be sent by the Registrar
>    3741	   back to the Pledge to indicate reception of the telemetry report:
>    3742	
>    3743	     RES: 2.04 Changed
>    3744	
>    3745	
>    3746	
>    3747	
>    3748	
>    3749	
>    3750	
>    3751	
>    3752	Richardson, et al.       Expires 31 August 2026                [Page 67]
>    3753	
>    3754	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3755	
>    3756	
>    3757	Appendix C.  COSE-signed Voucher (Request) Examples
>    3758	
>    3759	   This appendix provides examples of COSE-signed voucher requests and
>    3760	   vouchers.  First, the used test keys and PKIX certificates are
>    3761	   described, followed by examples of a constrained PVR, RVR and
>    3762	   voucher.
>    3763	
>    3764	C.1.  Pledge, Registrar and MASA Keys
>    3765	
>    3766	   This section documents the public and private keys used for all
>    3767	   examples in this appendix.  These keys are not used in any production
>    3768	   system, and must only be used for testing purposes.
>    3769	
>    3770	C.1.1.  Pledge IDevID Private Key
>    3771	
>    3772	   -----BEGIN EC PRIVATE KEY-----
>    3773	   MHcCAQEEIMv+C4dbzeyrEH20qkpFlWIH2FFACGZv9kW7rNWtSlYtoAoGCCqGSM49
>    3774	   AwEHoUQDQgAESH6OUiYFRhfIgWl4GG8jHoj8a+8rf6t5s1mZ/4SePlKom39GQ34p
>    3775	   VYryJ9aHmboLLfz69bzICQFKbkoQ5oaiew==
>    3776	   -----END EC PRIVATE KEY-----
>    3777	
>    3778	   Private-Key: (256 bit)
>    3779	   priv:
>    3780	cb:fe:0b:87:5b:cd:ec:ab:10:7d:b4:aa:4a:45:95:
>    3781	       62:07:d8:51:40:08:66:6f:f6:45:bb:ac:d5:ad:4a:
>    3782	       56:2d
>    3783	   pub:
>    3784	       04:48:7e:8e:52:26:05:46:17:c8:81:69:78:18:6f:
>    3785	       23:1e:88:fc:6b:ef:2b:7f:ab:79:b3:59:99:ff:84:
>    3786	       9e:3e:52:a8:9b:7f:46:43:7e:29:55:8a:f2:27:d6:
>    3787	       87:99:ba:0b:2d:fc:fa:f5:bc:c8:09:01:4a:6e:4a:
>    3788	       10:e6:86:a2:7b
>    3789	   ASN1 OID: prime256v1
>    3790	   NIST CURVE: P-256
>    3791	
>    3792	C.1.2.  Registrar Private Key
>    3793	
>    3794	   -----BEGIN PRIVATE KEY-----
>    3795	   MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgYJ/MP0dWA9BkYd4W
>    3796	   s6oRY62hDddaEmrAVm5dtAXE/UGhRANCAAQgMIVb6EaRCz7LFcr4Vy0+tWW9xlSh
>    3797	   Xvr27euqi54WCMXJEMk6IIaPyFBNNw8bJvqXWfZ5g7t4hj7amsvqUST2
>    3798	   -----END PRIVATE KEY-----
>    3799	
>    3800	
>    3801	
>    3802	
>    3803	
>    3804	
>    3805	
>    3806	
>    3807	
>    3808	Richardson, et al.       Expires 31 August 2026                [Page 68]
>    3809	
>    3810	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3811	
>    3812	
>    3813	   Private-Key: (256 bit)
>    3814	   priv:
>    3815	       60:9f:cc:3f:47:56:03:d0:64:61:de:16:b3:aa:11:
>    3816	       63:ad:a1:0d:d7:5a:12:6a:c0:56:6e:5d:b4:05:c4:
>    3817	fd:41
>    3818	   pub:
>    3819	       04:20:30:85:5b:e8:46:91:0b:3e:cb:15:ca:f8:57:
>    3820	       2d:3e:b5:65:bd:c6:54:a1:5e:fa:f6:ed:eb:aa:8b:
>    3821	       9e:16:08:c5:c9:10:c9:3a:20:86:8f:c8:50:4d:37:
>    3822	       0f:1b:26:fa:97:59:f6:79:83:bb:78:86:3e:da:9a:
>    3823	cb:ea:51:24:f6
>    3824	   ASN1 OID: prime256v1
>    3825	   NIST CURVE: P-256
>    3826	
>    3827	C.1.3.  MASA Private Key
>    3828	
>    3829	   -----BEGIN PRIVATE KEY-----
>    3830	   MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgrbJ1oU+HIJ2SWYAk
>    3831	   DkBTL+YNPxQG+gwsMsZB94N8mZ2hRANCAASS9NVlWJdztwNY81yPlH2UODYWhlYA
>    3832	   ZfsqnEPSFZKnq8mq8gF78ZVbYi6q2FEg8kkORY/rpIU/X7SQsRuD+wMW
>    3833	   -----END PRIVATE KEY-----
>    3834	
>    3835	   Private-Key: (256 bit)
>    3836	   priv:
>    3837	ad:b2:75:a1:4f:87:20:9d:92:59:80:24:0e:40:53:
>    3838	       2f:e6:0d:3f:14:06:fa:0c:2c:32:c6:41:f7:83:7c:
>    3839	       99:9d
>    3840	   pub:
>    3841	       04:92:f4:d5:65:58:97:73:b7:03:58:f3:5c:8f:94:
>    3842	       7d:94:38:36:16:86:56:00:65:fb:2a:9c:43:d2:15:
>    3843	       92:a7:ab:c9:aa:f2:01:7b:f1:95:5b:62:2e:aa:d8:
>    3844	       51:20:f2:49:0e:45:8f:eb:a4:85:3f:5f:b4:90:b1:
>    3845	       1b:83:fb:03:16
>    3846	   ASN1 OID: prime256v1
>    3847	   NIST CURVE: P-256
>    3848	
>    3849	C.2.  Pledge, Registrar, Domain CA and MASA Certificates
>    3850	
>    3851	   All keys and PKIX certificates used for the examples have been
>    3852	   generated with OpenSSL - see Appendix A.3 for more details on
>    3853	   certificate generation.  Below the certificates are listed that
>    3854	   accompany the keys shown above.  Each certificate description is
>    3855	   followed by the hexadecimal representation of the X.509 ASN.1 DER
>    3856	   encoded certificate.  This representation can be for example decoded
>    3857	   using an online ASN.1 decoder.
>    3858	
>    3859	C.2.1.  Pledge IDevID Certificate
>    3860	
>    3861	
>    3862	
>    3863	
>    3864	Richardson, et al.       Expires 31 August 2026                [Page 69]
>    3865	
>    3866	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3867	
>    3868	
>    3869	   Certificate:
>    3870	   Data:
>    3871	    Version: 3 (0x2)
>    3872	    Serial Number: 32429 (0x7ead)
>    3873	    Signature Algorithm: ecdsa-with-SHA256
>    3874	    Issuer: CN = masa.stok.nl, O = vanderstok, L = Helmond,
>    3875	            C = NL
>    3876	    Validity
>    3877	      Not Before: Dec  9 12:50:47 2022 GMT
>    3878	      Not After : Dec 31 12:50:47 9999 GMT
>    3879	    Subject: CN = Stok IoT sensor Y-42, serialNumber = JADA123456789
>    3880	    Subject Public Key Info:
>    3881	      Public Key Algorithm: id-ecPublicKey
>    3882	        Public-Key: (256 bit)
>    3883	        pub:
>    3884	          04:48:7e:8e:52:26:05:46:17:c8:81:69:78:18:6f:
>    3885	          23:1e:88:fc:6b:ef:2b:7f:ab:79:b3:59:99:ff:84:
>    3886	          9e:3e:52:a8:9b:7f:46:43:7e:29:55:8a:f2:27:d6:
>    3887	          87:99:ba:0b:2d:fc:fa:f5:bc:c8:09:01:4a:6e:4a:
>    3888	          10:e6:86:a2:7b
>    3889	        ASN1 OID: prime256v1
>    3890	        NIST CURVE: P-256
>    3891	    X509v3 extensions:
>    3892	      X509v3 Key Usage: critical
>    3893	        Digital Signature, Non Repudiation, Key Encipherment,
>    3894	                Data Encipherment
>    3895	      X509v3 Basic Constraints:
>    3896	CA:FALSE
>    3897	      X509v3 Authority Key Identifier:
>    3898	CB:8D:98:CA:74:C5:1B:58:DD:E7:AC:EF:86:9A:94:43:A8:D6:66:A6
>    3899	      1.3.6.1.5.5.7.1.32:
>    3900	         hl=2 l=  12 prim: IA5STRING     :masa.stok.nl
>    3901	
>    3902	   Signature Algorithm: ecdsa-with-SHA256
>    3903	   Signature Value:
>    3904	    30:45:02:20:4d:89:90:7e:03:fb:52:56:42:0c:3f:c1:b1:f1:
>    3905	    47:b5:b3:93:65:45:2e:be:50:db:67:85:8f:23:89:a2:3f:9e:
>    3906	    02:21:00:95:33:69:d1:c6:db:f0:f1:f6:52:24:59:d3:0a:95:
>    3907	    4e:b2:f4:96:a1:31:3c:7b:d9:2f:28:b3:29:71:bb:60:df
>    3908	
>    3909	   Below is the hexadecimal representation of the binary X.509 DER-
>    3910	   encoded certificate:
>    3911	
>    3912	
>    3913	
>    3914	
>    3915	
>    3916	
>    3917	
>    3918	
>    3919	
>    3920	Richardson, et al.       Expires 31 August 2026                [Page 70]
>    3921	
>    3922	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3923	
>    3924	
>    3925	   308201CE30820174A00302010202027EAD300A06082A8648CE3D040302304B31
>    3926	   15301306035504030C0C6D6173612E73746F6B2E6E6C31133011060355040A0C
>    3927	   0A76616E64657273746F6B3110300E06035504070C0748656C6D6F6E64310B30
>    3928	   09060355040613024E4C3020170D3232313230393132353034375A180F393939
>    3929	   39313233313132353034375A3037311D301B06035504030C1453746F6B20496F
>    3930	   542073656E736F7220592D3432311630140603550405130D4A41444131323334
>    3931	   35363738393059301306072A8648CE3D020106082A8648CE3D03010703420004
>    3932	   487E8E5226054617C8816978186F231E88FC6BEF2B7FAB79B35999FF849E3E52
>    3933	   A89B7F46437E29558AF227D68799BA0B2DFCFAF5BCC809014A6E4A10E686A27B
>    3934	   A35A3058300E0603551D0F0101FF0404030204F030090603551D130402300030
>    3935	   1F0603551D23041830168014CB8D98CA74C51B58DDE7ACEF869A9443A8D666A6
>    3936	   301A06082B06010505070120040E160C6D6173612E73746F6B2E6E6C300A0608
>    3937	   2A8648CE3D040302034800304502204D89907E03FB5256420C3FC1B1F147B5B3
>    3938	   9365452EBE50DB67858F2389A23F9E022100953369D1C6DBF0F1F6522459D30A
>    3939	   954EB2F496A1313C7BD92F28B32971BB60DF
>    3940	
>    3941	C.2.2.  Registrar Certificate
>    3942	
>    3943	
>    3944	
>    3945	
>    3946	
>    3947	
>    3948	
>    3949	
>    3950	
>    3951	
>    3952	
>    3953	
>    3954	
>    3955	
>    3956	
>    3957	
>    3958	
>    3959	
>    3960	
>    3961	
>    3962	
>    3963	
>    3964	
>    3965	
>    3966	
>    3967	
>    3968	
>    3969	
>    3970	
>    3971	
>    3972	
>    3973	
>    3974	
>    3975	
>    3976	Richardson, et al.       Expires 31 August 2026                [Page 71]
>    3977	
>    3978	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    3979	
>    3980	
>    3981	   Certificate:
>    3982	   Data:
>    3983	    Version: 3 (0x2)
>    3984	    Serial Number:
>    3985	c3:f6:21:49:b2:e3:0e:3e
>    3986	    Signature Algorithm: ecdsa-with-SHA256
>    3987	    Issuer: CN = Custom-ER Global CA, OU = IT, O = "Custom-ER, Inc.",
>    3988	            L = San Jose, ST = CA, C = US
>    3989	    Validity
>    3990	      Not Before: Dec  9 12:50:47 2022 GMT
>    3991	      Not After : Dec  8 12:50:47 2025 GMT
>    3992	    Subject: CN = Custom-ER Registrar, OU = Office dept, O = "Custom-ER,
>    3993	            Inc.", L = Ottowa, ST = ON, C = CA
>    3994	    Subject Public Key Info:
>    3995	      Public Key Algorithm: id-ecPublicKey
>    3996	        Public-Key: (256 bit)
>    3997	        pub:
>    3998	          04:20:30:85:5b:e8:46:91:0b:3e:cb:15:ca:f8:57:
>    3999	          2d:3e:b5:65:bd:c6:54:a1:5e:fa:f6:ed:eb:aa:8b:
>    4000	          9e:16:08:c5:c9:10:c9:3a:20:86:8f:c8:50:4d:37:
>    4001	          0f:1b:26:fa:97:59:f6:79:83:bb:78:86:3e:da:9a:
>    4002	cb:ea:51:24:f6
>    4003	        ASN1 OID: prime256v1
>    4004	        NIST CURVE: P-256
>    4005	    X509v3 extensions:
>    4006	      X509v3 Key Usage: critical
>    4007	        Digital Signature, Non Repudiation, Key Encipherment,
>    4008	                Data Encipherment
>    4009	      X509v3 Basic Constraints:
>    4010	CA:FALSE
>    4011	      X509v3 Subject Key Identifier:
>    4012	C9:08:0B:38:7D:8D:D8:5B:3A:59:E7:EC:10:0B:86:63:93:A9:CA:4C
>    4013	      X509v3 Authority Key Identifier:
>    4014	        92:EA:76:40:40:4A:8F:AB:4F:27:0B:F3:BC:37:9D:86:CD:72:80:F8
>    4015	      X509v3 Extended Key Usage: critical
>    4016	        CMC Registration Authority, TLS Web Server Authentication,
>    4017	                TLS Web Client Authentication
>    4018	   Signature Algorithm: ecdsa-with-SHA256
>    4019	   Signature Value:
>    4020	    30:45:02:21:00:d8:4a:7c:69:2f:f9:58:6e:82:22:87:18:f6:
>    4021	    3b:c3:05:f0:ae:b8:ae:ec:42:78:82:38:79:81:2a:5d:15:61:
>    4022	    64:02:20:08:f2:3c:13:69:13:b0:2c:e2:63:09:d5:99:4f:eb:
>    4023	    75:70:af:af:ed:98:cd:f1:12:11:c0:37:f7:18:4d:c1:9d
>    4024	
>    4025	   Below is the hexadecimal representation of the binary X.509 DER-
>    4026	   encoded certificate:
>    4027	
>    4028	
>    4029	
>    4030	
>    4031	
>    4032	Richardson, et al.       Expires 31 August 2026                [Page 72]
>    4033	
>    4034	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4035	
>    4036	
>    4037	   3082026D30820213A003020102020900C3F62149B2E30E3E300A06082A8648CE
>    4038	   3D0403023072311C301A06035504030C13437573746F6D2D455220476C6F6261
>    4039	   6C204341310B3009060355040B0C02495431183016060355040A0C0F43757374
>    4040	   6F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B
>    4041	   300906035504080C024341310B3009060355040613025553301E170D32323132
>    4042	   30393132353034375A170D3235313230383132353034375A3079311C301A0603
>    4043	   5504030C13437573746F6D2D4552205265676973747261723114301206035504
>    4044	   0B0C0B4F6666696365206465707431183016060355040A0C0F437573746F6D2D
>    4045	   45522C20496E632E310F300D06035504070C064F74746F7761310B3009060355
>    4046	   04080C024F4E310B30090603550406130243413059301306072A8648CE3D0201
>    4047	   06082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3EB565
>    4048	   BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA9759
>    4049	   F67983BB78863EDA9ACBEA5124F6A3818A308187300E0603551D0F0101FF0404
>    4050	   030204F030090603551D1304023000301D0603551D0E04160414C9080B387D8D
>    4051	   D85B3A59E7EC100B866393A9CA4C301F0603551D2304183016801492EA764040
>    4052	   4A8FAB4F270BF3BC379D86CD7280F8302A0603551D250101FF0420301E06082B
>    4053	   0601050507031C06082B0601050507030106082B06010505070302300A06082A
>    4054	   8648CE3D0403020348003045022100D84A7C692FF9586E82228718F63BC305F0
>    4055	   AEB8AEEC4278823879812A5D156164022008F23C136913B02CE26309D5994FEB
>    4056	   7570AFAFED98CDF11211C037F7184DC19D
>    4057	
>    4058	C.2.3.  Domain CA Certificate
>    4059	
>    4060	   The Domain CA certificate is the CA of the owner's domain.  It has
>    4061	   signed the Registrar (RA) certificate.
>    4062	
>    4063	
>    4064	
>    4065	
>    4066	
>    4067	
>    4068	
>    4069	
>    4070	
>    4071	
>    4072	
>    4073	
>    4074	
>    4075	
>    4076	
>    4077	
>    4078	
>    4079	
>    4080	
>    4081	
>    4082	
>    4083	
>    4084	
>    4085	
>    4086	
>    4087	
>    4088	Richardson, et al.       Expires 31 August 2026                [Page 73]
>    4089	
>    4090	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4091	
>    4092	
>    4093	   Certificate:
>    4094	   Data:
>    4095	    Version: 3 (0x2)
>    4096	    Serial Number: 3092288576548618702 (0x2aea0413a42dc1ce)
>    4097	    Signature Algorithm: ecdsa-with-SHA256
>    4098	    Issuer: CN = Custom-ER Global CA, OU = IT, O = "Custom-ER, Inc.",
>    4099	            L = San Jose, ST = CA, C = US
>    4100	    Validity
>    4101	      Not Before: Dec  9 12:50:47 2022 GMT
>    4102	      Not After : Dec  6 12:50:47 2032 GMT
>    4103	    Subject: CN = Custom-ER Global CA, OU = IT, O = "Custom-ER, Inc.",
>    4104	            L = San Jose, ST = CA, C = US
>    4105	    Subject Public Key Info:
>    4106	      Public Key Algorithm: id-ecPublicKey
>    4107	        Public-Key: (256 bit)
>    4108	        pub:
>    4109	          04:97:b1:ed:96:91:64:93:09:85:bb:b8:ac:9a:2a:
>    4110	f9:45:5c:df:ee:a4:b1:1d:e2:e7:9d:06:8b:fa:80:
>    4111	          39:26:b4:00:52:51:b3:4f:1c:08:15:a4:cb:e0:3f:
>    4112	bd:1b:bc:b6:35:f6:43:1a:22:de:78:65:3b:87:b9:
>    4113	          95:37:ec:e1:6c
>    4114	        ASN1 OID: prime256v1
>    4115	        NIST CURVE: P-256
>    4116	    X509v3 extensions:
>    4117	      X509v3 Subject Alternative Name:
>    4118	email:[e-mail]
>    4119	      X509v3 Key Usage: critical
>    4120	        Digital Signature, Certificate Sign, CRL Sign
>    4121	      X509v3 Basic Constraints: critical
>    4122	CA:TRUE
>    4123	      X509v3 Subject Key Identifier:
>    4124	        92:EA:76:40:40:4A:8F:AB:4F:27:0B:F3:BC:37:9D:86:CD:72:80:F8
>    4125	   Signature Algorithm: ecdsa-with-SHA256
>    4126	   Signature Value:
>    4127	    30:44:02:20:66:15:df:c3:70:11:f6:73:78:d8:fd:1c:2a:3f:
>    4128	bd:d1:3f:51:f6:b6:6f:2d:7c:e2:7a:13:18:21:bb:70:f0:c0:
>    4129	    02:20:69:86:d8:d2:28:b2:92:6e:23:9e:19:0b:8f:18:25:c9:
>    4130	c1:4c:67:95:ff:a0:b3:24:bd:4d:ac:2e:cb:68:d7:13
>    4131	
>    4132	   Below is the hexadecimal representation of the binary X.509 DER-
>    4133	   encoded certificate:
>    4134	
>    4135	
>    4136	
>    4137	
>    4138	
>    4139	
>    4140	
>    4141	
>    4142	
>    4143	
>    4144	Richardson, et al.       Expires 31 August 2026                [Page 74]
>    4145	
>    4146	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4147	
>    4148	
>    4149	   30820242308201E9A00302010202082AEA0413A42DC1CE300A06082A8648CE3D
>    4150	   0403023072311C301A06035504030C13437573746F6D2D455220476C6F62616C
>    4151	   204341310B3009060355040B0C02495431183016060355040A0C0F437573746F
>    4152	   6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B30
>    4153	   0906035504080C024341310B3009060355040613025553301E170D3232313230
>    4154	   393132353034375A170D3332313230363132353034375A3072311C301A060355
>    4155	   04030C13437573746F6D2D455220476C6F62616C204341310B3009060355040B
>    4156	   0C02495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111
>    4157	   300F06035504070C0853616E204A6F7365310B300906035504080C024341310B
>    4158	   30090603550406130255533059301306072A8648CE3D020106082A8648CE3D03
>    4159	   01070342000497B1ED969164930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D06
>    4160	   8BFA803926B4005251B34F1C0815A4CBE03FBD1BBCB635F6431A22DE78653B87
>    4161	   B99537ECE16CA369306730250603551D11041E301C811A68656C704063757374
>    4162	   6F6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF0404030201
>    4163	   86300F0603551D130101FF040530030101FF301D0603551D0E0416041492EA76
>    4164	   40404A8FAB4F270BF3BC379D86CD7280F8300A06082A8648CE3D040302034700
>    4165	   304402206615DFC37011F67378D8FD1C2A3FBDD13F51F6B66F2D7CE27A131821
>    4166	   BB70F0C002206986D8D228B2926E239E190B8F1825C9C14C6795FFA0B324BD4D
>    4167	   AC2ECB68D713
>    4168	
>    4169	C.2.4.  MASA Certificate
>    4170	
>    4171	   The MASA CA certificate is the CA that signed the Pledge's IDevID
>    4172	   certificate.
>    4173	
>    4174	
>    4175	
>    4176	
>    4177	
>    4178	
>    4179	
>    4180	
>    4181	
>    4182	
>    4183	
>    4184	
>    4185	
>    4186	
>    4187	
>    4188	
>    4189	
>    4190	
>    4191	
>    4192	
>    4193	
>    4194	
>    4195	
>    4196	
>    4197	
>    4198	
>    4199	
>    4200	Richardson, et al.       Expires 31 August 2026                [Page 75]
>    4201	
>    4202	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4203	
>    4204	
>    4205	   Certificate:
>    4206	   Data:
>    4207	    Version: 3 (0x2)
>    4208	    Serial Number:
>    4209	e3:9c:da:17:e1:38:6a:0a
>    4210	    Signature Algorithm: ecdsa-with-SHA256
>    4211	    Issuer: CN = masa.stok.nl, O = vanderstok, L = Helmond,
>    4212	            C = NL
>    4213	    Validity
>    4214	      Not Before: Dec  9 12:50:47 2022 GMT
>    4215	      Not After : Dec  6 12:50:47 2032 GMT
>    4216	    Subject: CN = masa.stok.nl, O = vanderstok, L = Helmond,
>    4217	            C = NL
>    4218	    Subject Public Key Info:
>    4219	      Public Key Algorithm: id-ecPublicKey
>    4220	        Public-Key: (256 bit)
>    4221	        pub:
>    4222	          04:92:f4:d5:65:58:97:73:b7:03:58:f3:5c:8f:94:
>    4223	          7d:94:38:36:16:86:56:00:65:fb:2a:9c:43:d2:15:
>    4224	          92:a7:ab:c9:aa:f2:01:7b:f1:95:5b:62:2e:aa:d8:
>    4225	          51:20:f2:49:0e:45:8f:eb:a4:85:3f:5f:b4:90:b1:
>    4226	          1b:83:fb:03:16
>    4227	        ASN1 OID: prime256v1
>    4228	        NIST CURVE: P-256
>    4229	    X509v3 extensions:
>    4230	      X509v3 Subject Alternative Name:
>    4231	email:[e-mail]
>    4232	      X509v3 Key Usage: critical
>    4233	        Digital Signature, Certificate Sign, CRL Sign
>    4234	      X509v3 Basic Constraints: critical
>    4235	CA:TRUE,pathlen:3
>    4236	      X509v3 Subject Key Identifier:
>    4237	CB:8D:98:CA:74:C5:1B:58:DD:E7:AC:EF:86:9A:94:43:A8:D6:66:A6
>    4238	   Signature Algorithm: ecdsa-with-SHA256
>    4239	   Signature Value:
>    4240	    30:46:02:21:00:94:3f:a5:26:51:68:16:38:5b:78:9a:d8:c3:
>    4241	af:8e:49:28:22:60:56:26:43:4a:14:98:3e:e1:e4:81:ad:ca:
>    4242	    1b:02:21:00:ba:4d:aa:fd:fa:68:42:74:03:2b:a8:41:6b:e2:
>    4243	    90:0c:9e:7b:b8:c0:9c:f7:0e:3f:b4:36:8a:b3:9c:3e:31:0e
>    4244	
>    4245	   Below is the hexadecimal representation of the binary X.509 DER-
>    4246	   encoded certificate:
>    4247	
>    4248	
>    4249	
>    4250	
>    4251	
>    4252	
>    4253	
>    4254	
>    4255	
>    4256	Richardson, et al.       Expires 31 August 2026                [Page 76]
>    4257	
>    4258	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4259	
>    4260	
>    4261	   308201F130820196A003020102020900E39CDA17E1386A0A300A06082A8648CE
>    4262	   3D040302304B3115301306035504030C0C6D6173612E73746F6B2E6E6C311330
>    4263	   11060355040A0C0A76616E64657273746F6B3110300E06035504070C0748656C
>    4264	   6D6F6E64310B3009060355040613024E4C301E170D3232313230393132353034
>    4265	   375A170D3332313230363132353034375A304B3115301306035504030C0C6D61
>    4266	   73612E73746F6B2E6E6C31133011060355040A0C0A76616E64657273746F6B31
>    4267	   10300E06035504070C0748656C6D6F6E64310B3009060355040613024E4C3059
>    4268	   301306072A8648CE3D020106082A8648CE3D0301070342000492F4D565589773
>    4269	   B70358F35C8F947D9438361686560065FB2A9C43D21592A7ABC9AAF2017BF195
>    4270	   5B622EAAD85120F2490E458FEBA4853F5FB490B11B83FB0316A3633061301C06
>    4271	   03551D11041530138111696E666F406D6173612E73746F6B2E6E6C300E060355
>    4272	   1D0F0101FF04040302018630120603551D130101FF040830060101FF02010330
>    4273	   1D0603551D0E04160414CB8D98CA74C51B58DDE7ACEF869A9443A8D666A6300A
>    4274	   06082A8648CE3D0403020349003046022100943FA526516816385B789AD8C3AF
>    4275	   8E492822605626434A14983EE1E481ADCA1B022100BA4DAAFDFA684274032BA8
>    4276	   416BE2900C9E7BB8C09CF70E3FB4368AB39C3E310E
>    4277	
>    4278	C.3.  COSE-signed Pledge Voucher Request (PVR)
>    4279	
>    4280	   In this example, the voucher request (PVR) has been signed by the
>    4281	   Pledge using the IDevID private key of Appendix C.1.1, and has been
>    4282	   sent to the link-local constrained Join Proxy (JP) over CoAPS to JP's
>    4283	   join port.  The join port happens to use the default CoAPS UDP port
>    4284	   5684.
>    4285	
>    4286	     REQ: POST coaps://[JP-link-local-address]/b/rv
>    4287	       Content-Format: 836 (application/voucher+cose)
>    4288	       Payload: <signed_pvr>
>    4289	
>    4290	   When the Join Proxy receives the DTLS handshake messages from the
>    4291	   Pledge, it will relay these messages to the Registrar.  The payload
>    4292	   signed_voucher_request is shown as hexadecimal dump (with lf added)
>    4293	   below:
>    4294	
>    4295	   D28443A10126A0587EA11909C5A40102074823BFBBC9C2BCF2130C585B305930
>    4296	   1306072A8648CE3D020106082A8648CE3D030107034200042030855BE846910B
>    4297	   3ECB15CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868F
>    4298	   C8504D370F1B26FA9759F67983BB78863EDA9ACBEA5124F60D6D4A4144413132
>    4299	   33343536373839584068987DE8B007F4E9416610BBE2D48E1D7EA1032092B8BF
>    4300	   CE611421950F45B22F17E214820C07E777ADF86175E25D3205568404C25FCEEC
>    4301	   1B817C7861A6104B3D
>    4302	
>    4303	   The representation of signed_pvr in CBOR diagnostic format (with lf
>    4304	   added) is:
>    4305	
>    4306	
>    4307	
>    4308	
>    4309	
>    4310	
>    4311	
>    4312	Richardson, et al.       Expires 31 August 2026                [Page 77]
>    4313	
>    4314	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4315	
>    4316	
>    4317	   18([h'A10126', {}, h'A11909C5A40102074823BFBBC9C2BCF2130C585B3059301
>    4318	   306072A8648CE3D020106082A8648CE3D030107034200042030855BE846910B3ECB1
>    4319	   5CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370
>    4320	   F1B26FA9759F67983BB78863EDA9ACBEA5124F60D6D4A41444131323334353637383
>    4321	   9', h'68987DE8B007F4E9416610BBE2D48E1D7EA1032092B8BFCE611421950F45B2
>    4322	   2F17E214820C07E777ADF86175E25D3205568404C25FCEEC1B817C7861A6104B3D']
>    4323	   )
>    4324	
>    4325	   The COSE payload is the PVR voucher data, encoded as a CBOR byte
>    4326	   string.  The diagnostic representation of it is shown below:
>    4327	
>    4328	   {2501: {1: 2, 7: h'23BFBBC9C2BCF213', 12: h'3059301306072A8648CE3D02
>    4329	   0106082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3EB565BD
>    4330	   C654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA9759F67983
>    4331	   BB78863EDA9ACBEA5124F6', 13: "JADA123456789"}}
>    4332	
>    4333	   The Pledge uses the 'proximity' (key '1', SID 2502, enum value 2)
>    4334	   assertion together with an included 'proximity-registrar-pubk'
>    4335	   attribute (key '12', SID 2513) to inform MASA about its proximity to
>    4336	   the specific Registrar.
>    4337	
>    4338	C.4.  COSE-signed Registrar Voucher Request (RVR)
>    4339	
>    4340	   In this example the Registrar's voucher request has been signed by
>    4341	   the JRC (Registrar) using the private key from Appendix C.1.2.
>    4342	   Contained within this voucher request is the voucher request PVR that
>    4343	   was made by the Pledge to JRC.  Note that the RVR uses the HTTPS
>    4344	   protocol (not CoAP) and corresponding long URI path names as defined
>    4345	   in [RFC8995].  The Content-Type and Accept headers indicate the
>    4346	   constrained voucher format that is defined in the present document.
>    4347	   Because the Pledge used this format in the PVR, the JRC must also use
>    4348	   this format in the RVR.
>    4349	
>    4350	     REQ: POSThttps://masa.stok.nl/.well-known/brski/requestvoucher
>    4351	       Content-Type: application/voucher+cose
>    4352	       Accept: application/voucher+cose
>    4353	       Body: <signed_rvr>
>    4354	
>    4355	   The payload signed_rvr is shown as hexadecimal dump (with lf added):
>    4356	
>    4357	   D28443A10126A11820825902843082028030820225A003020102020900C3F621
>    4358	   49B2E30E3E300A06082A8648CE3D0403023072311C301A06035504030C134375
>    4359	   73746F6D2D455220476C6F62616C204341310B3009060355040B0C0249543118
>    4360	   3016060355040A0C0F437573746F6D2D45522C20496E632E3111300F06035504
>    4361	   070C0853616E204A6F7365310B300906035504080C024341310B300906035504
>    4362	   0613025553301E170D3232313230363131333735395A170D3235313230353131
>    4363	   333735395A30818D3131302F06035504030C28437573746F6D2D455220436F6D
>    4364	   6D65726369616C204275696C64696E6773205265676973747261723113301106
>    4365	
>    4366	
>    4367	
>    4368	Richardson, et al.       Expires 31 August 2026                [Page 78]
>    4369	
>    4370	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4371	
>    4372	
>    4373	   0355040B0C0A4F6666696365206F707331183016060355040A0C0F437573746F
>    4374	   6D2D45522C20496E632E310F300D06035504070C064F74746F7761310B300906
>    4375	   035504080C024F4E310B30090603550406130243413059301306072A8648CE3D
>    4376	   020106082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3E
>    4377	   B565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA
>    4378	   9759F67983BB78863EDA9ACBEA5124F6A3818730818430090603551D13040230
>    4379	   00300B0603551D0F0404030204F0301D0603551D0E04160414C9080B387D8DD8
>    4380	   5B3A59E7EC100B866393A9CA4C301F0603551D2304183016801492EA7640404A
>    4381	   8FAB4F270BF3BC379D86CD7280F8302A0603551D250101FF0420301E06082B06
>    4382	   01050507031C06082B0601050507030106082B06010505070302300A06082A86
>    4383	   48CE3D040302034900304602210091A2033692EB81503D53505FFC8DA326B1EE
>    4384	   7DEA96F29174F0B3341A07812201022100FF7339288108B712F418530A18025A
>    4385	   895408CC45E0BB678B46FBAB37DDB4D36B59024730820243308201E9A0030201
>    4386	   0202082AEA0413A42DC1CE300A06082A8648CE3D0403023072311C301A060355
>    4387	   04030C13437573746F6D2D455220476C6F62616C204341310B3009060355040B
>    4388	   0C02495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111
>    4389	   300F06035504070C0853616E204A6F7365310B300906035504080C024341310B
>    4390	   3009060355040613025553301E170D3232313230363131333735395A170D3332
>    4391	   313230333131333735395A3072311C301A06035504030C13437573746F6D2D45
>    4392	   5220476C6F62616C204341310B3009060355040B0C0249543118301606035504
>    4393	   0A0C0F437573746F6D2D45522C20496E632E3111300F06035504070C0853616E
>    4394	   204A6F7365310B300906035504080C024341310B300906035504061302555330
>    4395	   59301306072A8648CE3D020106082A8648CE3D0301070342000497B1ED969164
>    4396	   930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA803926B4005251B34F1C
>    4397	   0815A4CBE03FBD1BBCB635F6431A22DE78653B87B99537ECE16CA3693067300F
>    4398	   0603551D130101FF040530030101FF30250603551D11041E301C811A68656C70
>    4399	   40637573746F6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF
>    4400	   040403020186301D0603551D0E0416041492EA7640404A8FAB4F270BF3BC379D
>    4401	   86CD7280F8300A06082A8648CE3D0403020348003045022100D6D813B390BD3A
>    4402	   7B4E85424BCB1ED933AD1E981F2817B59083DD6EC1C5E3FADF02202CEE440619
>    4403	   2BC767E98D7CFAE044C6807481AD8564A7D569DCA3D1CDF1E5E843590124A119
>    4404	   09C5A60102027818323032322D31322D30365432303A30343A31352E3735345A
>    4405	   05581A041830168014CB8D98CA74C51B58DDE7ACEF869A9443A8D666A6074823
>    4406	   BFBBC9C2BCF2130958C9D28443A10126A0587EA11909C5A40102074823BFBBC9
>    4407	   C2BCF2130C585B3059301306072A8648CE3D020106082A8648CE3D0301070342
>    4408	   00042030855BE846910B3ECB15CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E
>    4409	   1608C5C910C93A20868FC8504D370F1B26FA9759F67983BB78863EDA9ACBEA51
>    4410	   24F60D6D4A414441313233343536373839584068987DE8B007F4E9416610BBE2
>    4411	   D48E1D7EA1032092B8BFCE611421950F45B22F17E214820C07E777ADF86175E2
>    4412	   5D3205568404C25FCEEC1B817C7861A6104B3D0D6D4A41444131323334353637
>    4413	   38395840B1DD40B10787437588AEAC9036899191C16CCDBECA31C197855CCB6B
>    4414	   BA142D709FE329CBC3F76297D6063ACB6759EAB98E96EA4C4AA2135AA48A247B
>    4415	   AC1D6A3F
>    4416	
>    4417	   The representation of signed_rvr in CBOR diagnostic format (with lf
>    4418	   added) is:
>    4419	
>    4420	
>    4421	
>    4422	
>    4423	
>    4424	Richardson, et al.       Expires 31 August 2026                [Page 79]
>    4425	
>    4426	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4427	
>    4428	
>    4429	   18([h'A10126', {32: [h'3082028030820225A003020102020900C3F62149B2E30
>    4430	   E3E300A06082A8648CE3D0403023072311C301A06035504030C13437573746F6D2D4
>    4431	   55220476C6F62616C204341310B3009060355040B0C02495431183016060355040A0
>    4432	   C0F437573746F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7
>    4433	   365310B300906035504080C024341310B3009060355040613025553301E170D32323
>    4434	   13230363131333735395A170D3235313230353131333735395A30818D3131302F060
>    4435	   35504030C28437573746F6D2D455220436F6D6D65726369616C204275696C64696E6
>    4436	   7732052656769737472617231133011060355040B0C0A4F6666696365206F7073311
>    4437	   83016060355040A0C0F437573746F6D2D45522C20496E632E310F300D06035504070
>    4438	   C064F74746F7761310B300906035504080C024F4E310B30090603550406130243413
>    4439	   059301306072A8648CE3D020106082A8648CE3D030107034200042030855BE846910
>    4440	   B3ECB15CAF8572D3EB565BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC85
>    4441	   04D370F1B26FA9759F67983BB78863EDA9ACBEA5124F6A3818730818430090603551
>    4442	   D1304023000300B0603551D0F0404030204F0301D0603551D0E04160414C9080B387
>    4443	   D8DD85B3A59E7EC100B866393A9CA4C301F0603551D2304183016801492EA7640404
>    4444	   A8FAB4F270BF3BC379D86CD7280F8302A0603551D250101FF0420301E06082B06010
>    4445	   50507031C06082B0601050507030106082B06010505070302300A06082A8648CE3D0
>    4446	   40302034900304602210091A2033692EB81503D53505FFC8DA326B1EE7DEA96F2917
>    4447	   4F0B3341A07812201022100FF7339288108B712F418530A18025A895408CC45E0BB6
>    4448	   78B46FBAB37DDB4D36B', h'30820243308201E9A00302010202082AEA0413A42DC1
>    4449	   CE300A06082A8648CE3D0403023072311C301A06035504030C13437573746F6D2D45
>    4450	   5220476C6F62616C204341310B3009060355040B0C02495431183016060355040A0C
>    4451	   0F437573746F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F73
>    4452	   65310B300906035504080C024341310B3009060355040613025553301E170D323231
>    4453	   3230363131333735395A170D3332313230333131333735395A3072311C301A060355
>    4454	   04030C13437573746F6D2D455220476C6F62616C204341310B3009060355040B0C02
>    4455	   495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111300F0603
>    4456	   5504070C0853616E204A6F7365310B300906035504080C024341310B300906035504
>    4457	   06130255533059301306072A8648CE3D020106082A8648CE3D0301070342000497B1
>    4458	   ED969164930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA803926B4005251B3
>    4459	   4F1C0815A4CBE03FBD1BBCB635F6431A22DE78653B87B99537ECE16CA3693067300F
>    4460	   0603551D130101FF040530030101FF30250603551D11041E301C811A68656C704063
>    4461	   7573746F6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF04040302
>    4462	   0186301D0603551D0E0416041492EA7640404A8FAB4F270BF3BC379D86CD7280F830
>    4463	   0A06082A8648CE3D0403020348003045022100D6D813B390BD3A7B4E85424BCB1ED9
>    4464	   33AD1E981F2817B59083DD6EC1C5E3FADF02202CEE4406192BC767E98D7CFAE044C6
>    4465	   807481AD8564A7D569DCA3D1CDF1E5E843']}, h'A11909C5A601020278183230323
>    4466	   22D31322D30365432303A30343A31352E3735345A05581A041830168014CB8D98CA7
>    4467	   4C51B58DDE7ACEF869A9443A8D666A6074823BFBBC9C2BCF2130958C9D28443A1012
>    4468	   6A0587EA11909C5A40102074823BFBBC9C2BCF2130C585B3059301306072A8648CE3
>    4469	   D020106082A8648CE3D030107034200042030855BE846910B3ECB15CAF8572D3EB56
>    4470	   5BDC654A15EFAF6EDEBAA8B9E1608C5C910C93A20868FC8504D370F1B26FA9759F67
>    4471	   983BB78863EDA9ACBEA5124F60D6D4A414441313233343536373839584068987DE8B
>    4472	   007F4E9416610BBE2D48E1D7EA1032092B8BFCE611421950F45B22F17E214820C07E
>    4473	   777ADF86175E25D3205568404C25FCEEC1B817C7861A6104B3D0D6D4A41444131323
>    4474	   3343536373839', h'B1DD40B10787437588AEAC9036899191C16CCDBECA31C19785
>    4475	   5CCB6BBA142D709FE329CBC3F76297D6063ACB6759EAB98E96EA4C4AA2135AA48A24
>    4476	   7BAC1D6A3F'])
>    4477	
>    4478	
>    4479	
>    4480	Richardson, et al.       Expires 31 August 2026                [Page 80]
>    4481	
>    4482	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4483	
>    4484	
>    4485	C.5.  COSE-signed Voucher from MASA
>    4486	
>    4487	   The resulting voucher is created by the MASA and returned to the
>    4488	   Registrar:
>    4489	
>    4490	     RES: 200 OK
>    4491	       Content-Type: application/voucher+cose
>    4492	       Body: <signed_voucher>
>    4493	
>    4494	   The Registrar then returns the voucher to the Pledge:
>    4495	
>    4496	     RES: 2.04 Changed
>    4497	       Content-Format: 836 (application/voucher+cose)
>    4498	       Payload: <signed_voucher>
>    4499	
>    4500	   It is signed by the MASA's private key (see Appendix C.1.3) and can
>    4501	   be verified by the Pledge using the MASA's public key that it stores.
>    4502	
>    4503	   Below is the binary signed_voucher, encoded in hexadecimal (with lf
>    4504	   added):
>    4505	
>    4506	   D28443A10126A0590288A1190993A60102027818323032322D31322D30365432
>    4507	   303A32333A33302E3730385A03F4074857EED786AD4049070859024730820243
>    4508	   308201E9A00302010202082AEA0413A42DC1CE300A06082A8648CE3D04030230
>    4509	   72311C301A06035504030C13437573746F6D2D455220476C6F62616C20434131
>    4510	   0B3009060355040B0C02495431183016060355040A0C0F437573746F6D2D4552
>    4511	   2C20496E632E3111300F06035504070C0853616E204A6F7365310B3009060355
>    4512	   04080C024341310B3009060355040613025553301E170D323231323036313133
>    4513	   3735395A170D3332313230333131333735395A3072311C301A06035504030C13
>    4514	   437573746F6D2D455220476C6F62616C204341310B3009060355040B0C024954
>    4515	   31183016060355040A0C0F437573746F6D2D45522C20496E632E3111300F0603
>    4516	   5504070C0853616E204A6F7365310B300906035504080C024341310B30090603
>    4517	   550406130255533059301306072A8648CE3D020106082A8648CE3D0301070342
>    4518	   000497B1ED969164930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA8039
>    4519	   26B4005251B34F1C0815A4CBE03FBD1BBCB635F6431A22DE78653B87B99537EC
>    4520	   E16CA3693067300F0603551D130101FF040530030101FF30250603551D11041E
>    4521	   301C811A68656C7040637573746F6D2D65722E6578616D706C652E636F6D300E
>    4522	   0603551D0F0101FF040403020186301D0603551D0E0416041492EA7640404A8F
>    4523	   AB4F270BF3BC379D86CD7280F8300A06082A8648CE3D04030203480030450221
>    4524	   00D6D813B390BD3A7B4E85424BCB1ED933AD1E981F2817B59083DD6EC1C5E3FA
>    4525	   DF02202CEE4406192BC767E98D7CFAE044C6807481AD8564A7D569DCA3D1CDF1
>    4526	   E5E8430B6D4A4144413132333435363738395840DF31B21A6AD3F5AC7F4C8B02
>    4527	   6F551BD28FBCE62330D3E262AC170F6BFEDDBA5F2E8FBAA2CAACFED9E8614EAC
>    4528	   5BF2450DADC53AC29DFA30E8787A1400B2E7C832
>    4529	
>    4530	   The representation of signed_voucher in CBOR diagnostic format (with
>    4531	   lf added) is:
>    4532	
>    4533	
>    4534	
>    4535	
>    4536	Richardson, et al.       Expires 31 August 2026                [Page 81]
>    4537	
>    4538	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4539	
>    4540	
>    4541	   18([h'A10126', {}, h'A1190993A60102027818323032322D31322D30365432303
>    4542	   A32333A33302E3730385A03F4074857EED786AD4049070859024730820243308201E
>    4543	   9A00302010202082AEA0413A42DC1CE300A06082A8648CE3D0403023072311C301A0
>    4544	   6035504030C13437573746F6D2D455220476C6F62616C204341310B3009060355040
>    4545	   B0C02495431183016060355040A0C0F437573746F6D2D45522C20496E632E3111300
>    4546	   F06035504070C0853616E204A6F7365310B300906035504080C024341310B3009060
>    4547	   355040613025553301E170D3232313230363131333735395A170D333231323033313
>    4548	   1333735395A3072311C301A06035504030C13437573746F6D2D455220476C6F62616
>    4549	   C204341310B3009060355040B0C02495431183016060355040A0C0F437573746F6D2
>    4550	   D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B300906035
>    4551	   504080C024341310B30090603550406130255533059301306072A8648CE3D0201060
>    4552	   82A8648CE3D0301070342000497B1ED969164930985BBB8AC9A2AF9455CDFEEA4B11
>    4553	   DE2E79D068BFA803926B4005251B34F1C0815A4CBE03FBD1BBCB635F6431A22DE786
>    4554	   53B87B99537ECE16CA3693067300F0603551D130101FF040530030101FF302506035
>    4555	   51D11041E301C811A68656C7040637573746F6D2D65722E6578616D706C652E636F6
>    4556	   D300E0603551D0F0101FF040403020186301D0603551D0E0416041492EA7640404A8
>    4557	   FAB4F270BF3BC379D86CD7280F8300A06082A8648CE3D0403020348003045022100D
>    4558	   6D813B390BD3A7B4E85424BCB1ED933AD1E981F2817B59083DD6EC1C5E3FADF02202
>    4559	   CEE4406192BC767E98D7CFAE044C6807481AD8564A7D569DCA3D1CDF1E5E8430B6D4
>    4560	   A414441313233343536373839', h'DF31B21A6AD3F5AC7F4C8B026F551BD28FBCE6
>    4561	   2330D3E262AC170F6BFEDDBA5F2E8FBAA2CAACFED9E8614EAC5BF2450DADC53AC29D
>    4562	   FA30E8787A1400B2E7C832'])
>    4563	
>    4564	   In the above, the third element in the array is the voucher data
>    4565	   encoded as a CBOR byte string.  When decoded, it can be represented
>    4566	   by the following CBOR diagnostic notation:
>    4567	
>    4568	   {2451: {1: 2, 2: "2022-12-06T20:23:30.708Z", 3: false, 7: h'57EED786
>    4569	   AD404907', 8: h'30820243308201E9A00302010202082AEA0413A42DC1CE300A06
>    4570	   082A8648CE3D0403023072311C301A06035504030C13437573746F6D2D455220476C
>    4571	   6F62616C204341310B3009060355040B0C02495431183016060355040A0C0F437573
>    4572	   746F6D2D45522C20496E632E3111300F06035504070C0853616E204A6F7365310B30
>    4573	   0906035504080C024341310B3009060355040613025553301E170D32323132303631
>    4574	   31333735395A170D3332313230333131333735395A3072311C301A06035504030C13
>    4575	   437573746F6D2D455220476C6F62616C204341310B3009060355040B0C0249543118
>    4576	   3016060355040A0C0F437573746F6D2D45522C20496E632E3111300F06035504070C
>    4577	   0853616E204A6F7365310B300906035504080C024341310B30090603550406130255
>    4578	   533059301306072A8648CE3D020106082A8648CE3D0301070342000497B1ED969164
>    4579	   930985BBB8AC9A2AF9455CDFEEA4B11DE2E79D068BFA803926B4005251B34F1C0815
>    4580	   A4CBE03FBD1BBCB635F6431A22DE78653B87B99537ECE16CA3693067300F0603551D
>    4581	   130101FF040530030101FF30250603551D11041E301C811A68656C7040637573746F
>    4582	   6D2D65722E6578616D706C652E636F6D300E0603551D0F0101FF040403020186301D
>    4583	   0603551D0E0416041492EA7640404A8FAB4F270BF3BC379D86CD7280F8300A06082A
>    4584	   8648CE3D0403020348003045022100D6D813B390BD3A7B4E85424BCB1ED933AD1E98
>    4585	   1F2817B59083DD6EC1C5E3FADF02202CEE4406192BC767E98D7CFAE044C6807481AD
>    4586	   8564A7D569DCA3D1CDF1E5E843', 11: "JADA123456789"}}
>    4587	
>    4588	
>    4589	
>    4590	
>    4591	
>    4592	Richardson, et al.       Expires 31 August 2026                [Page 82]
>    4593	
>    4594	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4595	
>    4596	
>    4597	   The largest element in the voucher is identified by key 8, which
>    4598	   decodes to SID 2459 (pinned-domain-cert) based on the delta encoding
>    4599	   defined by [RFC9254].  It contains the complete PKIX (DER-encoded
>    4600	   X.509v3) certificate of the Registrar's domain CA.  This certificate
>    4601	   is shown in Appendix C.2.3.
>    4602	
>    4603	Appendix D.  Pledge Device Class Profiles
>    4604	
>    4605	   cBRSKI allows implementers to select between various functional
>    4606	   options for the Pledge, yielding different code size footprints and
>    4607	   different requirements on Pledge hardware.  Thus for each product
>    4608	   type an optimal trade-off between functionality, development/
>    4609	   maintenance cost and hardware cost can be made.
>    4610	
>    4611	   This appendix illustrates different selection outcomes by means of
>    4612	   defining different example "profiles" of constrained Pledges.  In the
>    4613	   following subsections, these profiles are defined and a comparison is
>    4614	   provided.
>    4615	
>    4616	D.1.  Minimal Pledge
>    4617	
>    4618	   The Minimal Pledge profile (Min) aims to reduce code size and
>    4619	   hardware cost to a minimum.  This comes with some severe functional
>    4620	   restrictions, in particular:
>    4621	
>    4622	   *  No support for EST re-enrollment: whenever this would be needed, a
>    4623	      factory reset followed by a new onboarding process is required.
>    4624	
>    4625	   *  No support for change of Registrar: for this case, a factory reset
>    4626	      followed by a new onboarding process is required.
>    4627	
>    4628	   This profile would be appropriate for single-use devices which must
>    4629	   be replaced rather than re-deployed.  That might include medical
>    4630	   devices, but also sensors used during construction, such as concrete
>    4631	   temperature sensors.
>    4632	
>    4633	D.2.  Typical Pledge
>    4634	
>    4635	   The Typical Pledge profile (Typ) aims to support a typical cBRSKI
>    4636	   feature set including EST re-enrollment support and Registrar
>    4637	   changes.
>    4638	
>    4639	
>    4640	
>    4641	
>    4642	
>    4643	
>    4644	
>    4645	
>    4646	
>    4647	
>    4648	Richardson, et al.       Expires 31 August 2026                [Page 83]
>    4649	
>    4650	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4651	
>    4652	
>    4653	D.3.  Full-featured Pledge
>    4654	
>    4655	   The Full-featured Pledge profile (Full) illustrates a Pledge category
>    4656	   that supports multiple onboarding methods, hardware real-time clock,
>    4657	   BRSKI/EST resource discovery, and CSR Attributes request/response.
>    4658	   It also supports most of the optional features defined in this
>    4659	   specification.
>    4660	
>    4661	D.4.  Comparison Chart of Pledge Classes
>    4662	
>    4663	   The below table specifies the functions implemented in the three
>    4664	   example Pledge classes Min (Appendix D.1), Typ (Appendix D.2) and
>    4665	   Full (Appendix D.3).
>    4666	
>    4667	
>    4668	
>    4669	
>    4670	
>    4671	
>    4672	
>    4673	
>    4674	
>    4675	
>    4676	
>    4677	
>    4678	
>    4679	
>    4680	
>    4681	
>    4682	
>    4683	
>    4684	
>    4685	
>    4686	
>    4687	
>    4688	
>    4689	
>    4690	
>    4691	
>    4692	
>    4693	
>    4694	
>    4695	
>    4696	
>    4697	
>    4698	
>    4699	
>    4700	
>    4701	
>    4702	
>    4703	
>    4704	Richardson, et al.       Expires 31 August 2026                [Page 84]
>    4705	
>    4706	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4707	
>    4708	
>    4709	    +============================================+=======+=====+======+
>    4710	    | Functions Implemented                      |  Min  | Typ | Full |
>    4711	    +============================================+=======+=====+======+
>    4712	    | *General*                                  |       |     |      |
>    4713	    +--------------------------------------------+-------+-----+------+
>    4714	    | Support cBRSKI onboarding                  |   Y   |  Y  |  Y   |
>    4715	    +--------------------------------------------+-------+-----+------+
>    4716	    | Support other onboarding method(s)         |   -   |  -  |  Y   |
>    4717	    +--------------------------------------------+-------+-----+------+
>    4718	    | Real-time clock and cert time checks       |   -   |  -  |  Y   |
>    4719	    +--------------------------------------------+-------+-----+------+
>    4720	    | *cBRSKI*                                   |       |     |      |
>    4721	    +--------------------------------------------+-------+-----+------+
>    4722	    | CoAP discovery for rt=brski*               |   -   |  -  |  Y   |
>    4723	    +--------------------------------------------+-------+-----+------+
>    4724	    | Support pinned Registrar public key (RPK)  |   Y   |  -  |  Y   |
>    4725	    +--------------------------------------------+-------+-----+------+
>    4726	    | Support pinned Registrar certificate       |   -   |  Y  |  Y   |
>    4727	    +--------------------------------------------+-------+-----+------+
>    4728	    | Support pinned Domain CA                   |   -   |  Y  |  Y   |
>    4729	    +--------------------------------------------+-------+-----+------+
>    4730	    | *EST-coaps*                                |       |     |      |
>    4731	    +--------------------------------------------+-------+-----+------+
>    4732	    | Explicit TA database size (#certs)         |   0   |  3  |  8   |
>    4733	    +--------------------------------------------+-------+-----+------+
>    4734	    | CoAP discovery for rt=ace.est*             |   -   |  -  |  Y   |
>    4735	    +--------------------------------------------+-------+-----+------+
>    4736	    | GET /att and response parsing              |   -   |  -  |  Y   |
>    4737	    +--------------------------------------------+-------+-----+------+
>    4738	    | GET /crts format 62 (multiple CA certs)    |   -   |  Y  |  Y   |
>    4739	    +--------------------------------------------+-------+-----+------+
>    4740	    | GET /crts format 281 (multiple CA certs)   |   -   |  -  |  Y   |
>    4741	    +--------------------------------------------+-------+-----+------+
>    4742	    | ETag handling support for GET /crts        |   -   |  Y  |  Y   |
>    4743	    +--------------------------------------------+-------+-----+------+
>    4744	    | Re-enrollment supported                    | - (*) |  Y  |  Y   |
>    4745	    +--------------------------------------------+-------+-----+------+
>    4746	    | Section 6.5.1 optimized procedure          |   Y   |  Y  |  -   |
>    4747	    +--------------------------------------------+-------+-----+------+
>    4748	    | Pro-active re-enrollment at own initiative |   -   |  -  |  Y   |
>    4749	    +--------------------------------------------+-------+-----+------+
>    4750	    | Periodic trust anchor retrieval GET /crts  | - (*) |  Y  |  Y   |
>    4751	    +--------------------------------------------+-------+-----+------+
>    4752	    | Supports change of Registrar identity      | - (*) |  Y  |  Y   |
>    4753	    +--------------------------------------------+-------+-----+------+
>    4754	
>    4755	       Table 5: Comparison Chart of Pledge Classes Min, Typ and Full
>    4756	
>    4757	
>    4758	
>    4759	
>    4760	Richardson, et al.       Expires 31 August 2026                [Page 85]
>    4761	
>    4762	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4763	
>    4764	
>    4765	   Notes: (*) means only possible via a factory-reset followed by a new
>    4766	   cBRSKI onboarding procedure.
>    4767	
>    4768	Appendix E.  Pledge Discovery of Onboarding and Enrollment Options
>    4769	
>    4770	   The discovery functionality described in this section is informative
>    4771	   only: it derives from the normative CoRE documents [RFC6690],
>    4772	   [RFC7252] and from [RFC9148].  In typical cases, for a constrained
>    4773	   Pledge that only supports a single onboarding and enrollment method,
>    4774	   this functionality is not needed.
>    4775	
>    4776	   Note that the full-featured Pledge class defined in Appendix D.3 does
>    4777	   support CoAP discovery functionality.
>    4778	
>    4779	E.1.  Pledge Discovery Query for All cBRSKI Resources
>    4780	
>    4781	   A Pledge that wishes to discover the available cBRSKI onboarding
>    4782	   options/formats can do a discovery operation using CoAP discovery per
>    4783	   Section 7 of [RFC7252] and Section 4 of [RFC6690].  It first sends a
>    4784	   CoAP discovery query to the Registrar over the secured DTLS
>    4785	   connection.  The Registrar then responds with a CoRE Link Format
>    4786	   payload containing the requested resources, if any.
>    4787	
>    4788	   For example, if the Registrar supports a cBRSKI base resource /b in
>    4789	   addition to the longer /.well-known/brski base resource, and supports
>    4790	   only the voucher format application/voucher+cose (836), and status
>    4791	   reporting in both CBOR (60) and JSON (50) formats, a CoAP resource
>    4792	   discovery request and response may look as follows:
>    4793	
>    4794	     REQ: GET /.well-known/core?rt=brski*
>    4795	
>    4796	     RES: 2.05 Content
>    4797	       Content-Format: 40 (application/link-format)
>    4798	       Payload:
>    4799	         </b>;rt=brski,
>    4800	         </b/rv>;rt=brski.rv;ct=836,
>    4801	         </b/vs>;rt=brski.vs;ct="50 60",
>    4802	         </b/es>;rt=brski.es;ct="50 60"
>    4803	
>    4804	   In this case, the Registrar returns only the shorter URI paths
>    4805	   matching the query filter, which are located under the /b base
>    4806	   resource.  The /.well-known/brski based URI paths are not returned,
>    4807	   as these are assumed to be well-known (i.e. mandatory to support for
>    4808	   a Registrar that offers this functionality under /b.)
>    4809	
>    4810	
>    4811	
>    4812	
>    4813	
>    4814	
>    4815	
>    4816	Richardson, et al.       Expires 31 August 2026                [Page 86]
>    4817	
>    4818	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4819	
>    4820	
>    4821	   The Registrar is however under no obligation to provide the shorter
>    4822	   URLs under /b, and may respond to this query with only the /.well-
>    4823	   known/brski/\<short-name\> resources for the short names as defined
>    4824	   in Table 1, if these resources are not hosted anywhere else.  This
>    4825	   case is shown in the below interaction:
>    4826	
>    4827	     REQ: GET /.well-known/core?rt=brski*
>    4828	
>    4829	     RES: 2.05 Content
>    4830	       Content-Format: 40 (application/link-format)
>    4831	       Payload:
>    4832	         </.well-known/brski>;rt=brski,
>    4833	         </.well-known/brski/rv>;rt=brski.rv;ct=836,
>    4834	         </.well-known/brski/vs>;rt=brski.vs;ct="50 60",
>    4835	         </.well-known/brski/es>;rt=brski.es;ct="50 60"
>    4836	
>    4837	   When responding to a discovery request for cBRSKI resources, the
>    4838	   Registrar may return the full resource paths for all <short-name>
>    4839	   resources and the content-formats supported by these resources (using
>    4840	   ct attributes) as shown in the above examples.  This is useful when
>    4841	   multiple content-formats are supported for a particular resource on
>    4842	   the Registrar and the discovering Pledge also supports multiple.
>    4843	
>    4844	   Registrars that have implemented any cBRSKI or EST-coaps URI paths
>    4845	   outside of /.well-known must process a request on the corresponding
>    4846	   /.well-known/brski/\<short-name\> or /.well-known/est/\<short-name\>
>    4847	   URI paths identically.  In particular, a Pledge may use the longer
>    4848	   (well-known) and shorter URI paths in any combination.
>    4849	
>    4850	   A Registrar may also be implemented without support for the
>    4851	   (optional) CoAP discovery.  In that case, it may for example return a
>    4852	   4.04 Not Found as shown in the example below, in case the Registrar
>    4853	   does not host the resource /.well-known/core at all.  In such case,
>    4854	   the Pledge cannot discover any onboarding/enrollment options and so
>    4855	   it has to rely on the default cBRSKI resources under /.well-known/
>    4856	   brski/... and /.well-known/est/....
>    4857	
>    4858	     REQ: GET /.well-known/core?rt=brski*
>    4859	
>    4860	     RES: 4.04 Not Found
>    4861	
>    4862	
>    4863	
>    4864	
>    4865	
>    4866	
>    4867	
>    4868	
>    4869	
>    4870	
>    4871	
>    4872	Richardson, et al.       Expires 31 August 2026                [Page 87]
>    4873	
>    4874	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4875	
>    4876	
>    4877	E.2.  Pledge Discovery Query for the cBRSKI Base Resource
>    4878	
>    4879	   In case the client queries for only rt=brski type resources, the
>    4880	   Registrar responds with only the base path for the cBRSKI resources
>    4881	   (rt=brski, resource /b in earlier examples) and no others.  (So, the
>    4882	   query is "rt=brski", without the wildcard character.)  This is shown
>    4883	   in the below example.  The Pledge in this case requests only the
>    4884	   cBRSKI base resource of type rt=brski to check if cBRSKI is supported
>    4885	   by the Registrar and if a shorter-length cBRSKI base resource path is
>    4886	   supported or not.  In this case, the Pledge is not interested to
>    4887	   check what voucher request formats, or status telemetry formats --
>    4888	   other than the mandatory default formats -- are supported.  The
>    4889	   compact response below then shows that the Registrar indeed supports
>    4890	   a cBRSKI resource at /b:
>    4891	
>    4892	     REQ: GET /.well-known/core?rt=brski
>    4893	
>    4894	     RES: 2.05 Content
>    4895	       Content-Format: 40 (application/link-format)
>    4896	       Payload:
>    4897	         </b>;rt=brski
>    4898	
>    4899	   The Pledge can now start using any of the cBRSKI resources
>    4900	   /b/\<short-name\> in a next CoAP request to the Registrar.  In above
>    4901	   example, again the well-known resource present under /.well-known/
>    4902	   brski is not returned because this is assumed to be well-known to the
>    4903	   Pledge and mandatory to support for a Registrar that offers this
>    4904	   functionality under /b.
>    4905	
>    4906	   As a follow-up example, the Pledge can now start the onboarding by
>    4907	   sending its PVR:
>    4908	
>    4909	     REQ: POST /b/rv
>    4910	       Content-Format: 836 (application/voucher+cose)
>    4911	       Accept: 836 (application/voucher+cose)
>    4912	       Payload: <binary COSE-signed PVR>
>    4913	
>    4914	E.3.  Usage of ct Attribute
>    4915	
>    4916	   The return of multiple content-formats in the 'ct' link format
>    4917	   attribute by the Registrar allows the Pledge to choose the most
>    4918	   appropriate one for a particular operation, and allows extension with
>    4919	   new voucher formats.  Note that only content-format 836 (application/
>    4920	   voucher+cose) is defined in this document for the voucher request
>    4921	   resource (/rv), both as request payload and as response payload.  If
>    4922	   the 'ct' attribute is not indicated for the /rv resource in the CoRE
>    4923	   Link Format description, this implies that at least format 836 is
>    4924	   supported and maybe more.
>    4925	
>    4926	
>    4927	
>    4928	Richardson, et al.       Expires 31 August 2026                [Page 88]
>    4929	
>    4930	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4931	
>    4932	
>    4933	   Note that this specification allows for application/voucher+cose
>    4934	   payloads to be transmitted over HTTPS, as well as for application/
>    4935	   voucher-cms+json and other formats yet to be defined over CoAP.  The
>    4936	   burden for this flexibility is placed upon the Registrar.  A Pledge
>    4937	   on constrained hardware is expected to support a single format only.
>    4938	
>    4939	   The Pledge needs to support one or more formats for the PVR and
>    4940	   resulting voucher.  The MASA needs to support all formats that the
>    4941	   associated Pledges use.
>    4942	
>    4943	   In the below example, a Pledge queries specifically for the brski.rv
>    4944	   resource type to learn what voucher formats are supported:
>    4945	
>    4946	     REQ: GET /.well-known/core?rt=brski.rv
>    4947	
>    4948	     RES: 2.05 Content
>    4949	       Content-Format: 40 (application/link-format)
>    4950	       Payload:
>    4951	         </b/rv>;rt=brski.rv;ct="836 65123 65124"
>    4952	
>    4953	   The Registrar returns 3 supported voucher formats: 836, 65123, and
>    4954	   65124.  The first is the mandatory application/voucher+cose.  The
>    4955	   other two are numbers from the Experimental Use number range of the
>    4956	   CoAP Content-Formats sub-registry, which are used as mere examples.
>    4957	   The Pledge can now make a selection between the supported formats.
>    4958	
>    4959	   Note that if the Registrar only supports the default content-formats
>    4960	   for each cBRSKI resource as specified by this document, it may omit
>    4961	   the ct attributes in the discovery query response.  For example as in
>    4962	   the following interaction:
>    4963	
>    4964	     REQ: GET /.well-known/core?rt=brski*
>    4965	
>    4966	     RES: 2.05 Content
>    4967	       Content-Format: 40 (application/link-format)
>    4968	       Payload:
>    4969	         </b>;rt=brski,
>    4970	         </b/rv>;rt=brski.rv,
>    4971	         </b/vs>;rt=brski.vs,
>    4972	         </b/es>;rt=brski.es
>    4973	
>    4974	E.4.  EST-coaps Resource Discovery
>    4975	
>    4976	   The Pledge can also use CoAP discovery to identify enrollment
>    4977	   options, for example enrollment using EST-coaps or other methods.
>    4978	   The below example shows a Pledge that wants to identify EST-coaps
>    4979	   enrollment options by sending a discovery query.  This is done either
>    4980	   before or after the voucher has been validated.
>    4981	
>    4982	
>    4983	
>    4984	Richardson, et al.       Expires 31 August 2026                [Page 89]
>    4985	
>    4986	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    4987	
>    4988	
>    4989	     REQ: GET /.well-known/core?rt=ace.est*
>    4990	
>    4991	     RES: 2.05 Content
>    4992	       Content-Format: 40 (application/link-format)
>    4993	       Payload:
>    4994	         </e/crts>;rt=ace.est.crts;ct="62 281 287",
>    4995	         </e/sen>;rt=ace.est.sen;ct="281 287",
>    4996	         </e/sren>;rt=ace.est.sren;ct="281 287",
>    4997	         </e/att>;rt=ace.est.att,
>    4998	         </e/skg>;rt=ace.est.skg,
>    4999	         </e/skc>;rt=ace.est.skc
>    5000	
>    5001	   The response from the Registrar indicates that EST-coaps enrollment
>    5002	   (/sen) and re-enrollment (/sren) is supported, with a choice of two
>    5003	   content-formats for the response payload: either a PKCS#7 container
>    5004	   with a single LDevID certificate (application/pkcs7-mime;smime-
>    5005	   type=certs-only, content-format 281) which is the BRSKI [RFC8995]
>    5006	   encoding, or just a single LDevID certificate (application/pkix-cert,
>    5007	   content-format 287) which is the default cBRSKI encoding.
>    5008	
>    5009	   For the EST cacerts resource (/crts) there are three content-formats
>    5010	   supported: an application/multipart-core container (62) per
>    5011	   Section 6.5.5, a PKCS#7 container with all CA certificates (287), or
>    5012	   a single (most relevant) CA certificate (281).
>    5013	
>    5014	   The Pledge can now send a CoAP request to one of the discovered
>    5015	   resources, with the Accept Option to indicate which return payload
>    5016	   content-format the Pledge wants to receive.
>    5017	
>    5018	Acknowledgements
>    5019	
>    5020	   We are very grateful to Jim Schaad for explaining COSE/CMS choices
>    5021	   and for correcting early versions of the COSE_Sign1 objects.
>    5022	
>    5023	   Michel Veillette did extensive work on _pyang_ to extend it to
>    5024	   support the SID allocation process, and this document was among its
>    5025	   first users.
>    5026	
>    5027	   Russ Housley , Daniel Franke , Henk Birkholtz , Kathleen Moriarty ,
>    5028	   Xufeng Liu and Karl Moberg provided review feedback.
>    5029	
>    5030	   The BRSKI design team has met on many Tuesdays and Thursdays for
>    5031	   document review.  The team includes the authors and: Aurelio
>    5032	   Schellenbaum , David von Oheimb , Steffen Fries , Thomas Werner ,
>    5033	   Bill Atwood and Toerless Eckert .
>    5034	
>    5035	   Darrel Miller , Orie Steele and Manu Sporny provided review feedback
>    5036	   on the registration of the +cose structured syntax suffix.
>    5037	
>    5038	
>    5039	
>    5040	Richardson, et al.       Expires 31 August 2026                [Page 90]
>    5041	
>    5042	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    5043	
>    5044	
>    5045	   Carsten Bormann suggested the use of CBOR Web Token (CWT) claims in
>    5046	   the voucher's COSE header.
>    5047	
>    5048	Changelog
>    5049	
>    5050	   -30: Require Pledge's DTLS cert chain to be included in RVR 'x5bag'
>    5051	   (#343).  Add support for CoAP Uri-Path-Abbrev Option (#336).  Move
>    5052	   'idevid-issuer' clarification text to draft-8366bis.  Update the
>    5053	   duplicate serial number attack to focus only on the case where the
>    5054	   attack could be successful (equal CAs).  Update section references
>    5055	   draft-ietf-anima-8366bis to latest version.  Remove reference to the
>    5056	   to-be-deprecated RFC 8366.  Align terms and notation with draft-ietf-
>    5057	   anima-8366bis.  Editorial (wording) updates.
>    5058	
>    5059	   -29: Clarify that each brski.jp link indicates a root resource (/)
>    5060	   (#335).  Clarify that Pledge uses IP link-local address of JP's
>    5061	   discovery response, instead of the UTF-8 encoded IP address literal
>    5062	   (#334).  Add example of Join Proxy offering multiple Registrars
>    5063	   (endpoints) (#333).  Updated CoAP request/response formatting of
>    5064	   examples.  Updated acknowledgements (#331).  Editorial updates.
>    5065	
>    5066	   -28: Cleanup of normative/informative references, setting each to
>    5067	   right category.  Bugfix and clarification in text around EdDSA Curve
>    5068	   selection.  Added section on additional information in COSE header
>    5069	   with 'iat' CWT timestamp example.  Updates to BRSKI Well-Known URIs
>    5070	   registry, including a rename of the "URI" column (#326).  Unify COSE
>    5071	   header parameters terminology (#330).  Text formatting and editorial
>    5072	   updates.
>    5073	
>    5074	   -27: Clarify x5bag for storing signing chain and Registrar removes
>    5075	   unprotected x5bag/x5chain (#324, #323, #230).  Clarify RPK use with
>    5076	   "placeholder" certificate.  Merged the very similar BRSKI-MASA
>    5077	   security considerations sections (#312).  Require CBOR format for
>    5078	   Pledge's/EST-client's telemetry (#309, #317).  Removed figure
>    5079	   captions from code examples for consistency (#315).  Add base
>    5080	   resource type (rt) for "ace.est" and related terminology (#314).
>    5081	   Update IEEE 802.1AR reference to 2018 version (#313).  Editorial
>    5082	   updates.
>    5083	
>    5084	   -26: Updated I-D/RFC references to newer versions.  Corrected "sub-
>    5085	   registry" term to official "registry", in IANA section.  Explicitly
>    5086	   imported terminology from [RFC7252].  Corrected "router" term in
>    5087	   Thread/MLE section, with clarifications, and [Thread] reference fix.
>    5088	   Moved references between "Informative" and "Normative" based on
>    5089	   what's required to implement all the optional features.  Removal of
>    5090	   some lingering legacy text.  Editorial improvements, bugfixes and
>    5091	   typo corrections.
>    5092	
>    5093	
>    5094	
>    5095	
>    5096	Richardson, et al.       Expires 31 August 2026                [Page 91]
>    5097	
>    5098	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    5099	
>    5100	
>    5101	   -25: Moved all software/library support info into Appendix A and
>    5102	   added "open source" section; Removed use of formal Extends/Amends
>    5103	   Update-tags (#303, #304); Moved Section 14 to Appendix E (#302);
>    5104	   Editorial improvements.
>    5105	
>    5106	   -24: Rephrased well-known URL requirement in 14.1 (#292, #293); Added
>    5107	   paragraph on future certificate formats like C509 (#281, #294); Add
>    5108	   formal specification for CoAP discovery of Join Proxy by Pledge,
>    5109	   instead of only showing examples (#296, #300); Enable mDNS discovery
>    5110	   of Join Proxy by Pledge (also in mesh networks) and list service name
>    5111	   to use (#297, #299); Add requirement to support content-format 287 in
>    5112	   /sen and /sren response (#295, #298).
>    5113	
>    5114	   -23: Removed Update tag for RFC 8366 (#285, #288); Introduced cBRSKI
>    5115	   acronym (#284, #286); Added Update tag for RFC 9148 (#283, #289);
>    5116	   Keep CoAP discovery as only mechanism and refer to future discovery
>    5117	   work (#279, #282, #290); Introduce formal CBOR diagnostics ellipsis
>    5118	   elision syntax (#281, #287); Support for multi-tier CAs by
>    5119	   introducing multipart-core /crts format (#275, #291); Terminology
>    5120	   updated for consistency with RFC 8366-bis (#274, #280); Rename
>    5121	   voucher media type to application/voucher+cose and register +cose SSS
>    5122	   (#264, #277); Editorial changes including section restructuring.
>    5123	
>    5124	   -22: Streamlined text to focus mostly on the default flow, with
>    5125	   optional functions moved to their own sections (#269, #273); For DTLS
>    5126	   1.3 client, use the record_size_limit extensions RFC 8449 (#270);
>    5127	   Editorial updates; Reference rfc6125bis updated to RFC 9525.
>    5128	
>    5129	   -11 to -21: (For change details see GitHub issueshttps://github.com/
>    5130	   anima-wg/constrained-voucher/issues , related Pull Requests and
>    5131	   commits.)
>    5132	
>    5133	   -10: Design considerations extended; Examples made consistent.
>    5134	
>    5135	   -08: Examples for cose_sign1 are completed and improved.
>    5136	
>    5137	   -06: New SID values assigned; regenerated examples.
>    5138	
>    5139	   -04: voucher and request-voucher MUST be signed; examples for signed
>    5140	   request are added in appendix; IANA SID registration is updated; SID
>    5141	   values in examples are aligned; signed cms examples aligned with new
>    5142	   SIDs.
>    5143	
>    5144	   -03: Examples are inverted.
>    5145	
>    5146	
>    5147	
>    5148	
>    5149	
>    5150	
>    5151	
>    5152	Richardson, et al.       Expires 31 August 2026                [Page 92]
>    5153	
>    5154	Internet-Draft         Constrained BRSKI (cBRSKI)          February 2026
>    5155	
>    5156	
>    5157	   -02: Example of requestvoucher with unsigned application/cbor is
>    5158	   added; attributes of voucher "refined" to optional; CBOR
>    5159	   serialization of vouchers improved; Discovery port numbers are
>    5160	   specified.
>    5161	
>    5162	   -01: application/json is optional, application/cbor is compulsory;
>    5163	   Cms and cose mediatypes are introduced.
>    5164	
>    5165	   -00: Initial version.
>    5166	
>    5167	Authors' Addresses
>    5168	
>    5169	   Michael Richardson
>    5170	   Sandelman Software Works
>    5171	   Email:[e-mail]
>    5172	
>    5173	
>    5174	   Peter van der Stok
>    5175	   vanderstok consultancy
>    5176	   Email:[e-mail]
>    5177	
>    5178	
>    5179	   Panos Kampanakis
>    5180	   Cisco Systems
>    5181	   Email:[e-mail]
>    5182	
>    5183	
>    5184	   Esko Dijk
>    5185	   IoTconsultancy.nl
>    5186	   Email:[e-mail]
>    5187	
>    5188	
>    5189	
>    5190	
>    5191	
>    5192	
>    5193	
>    5194	
>    5195	
>    5196	
>    5197	
>    5198	
>    5199	
>    5200	
>    5201	
>    5202	
>    5203	
>    5204	
>    5205	
>    5206	
>    5207	
>    5208	Richardson, et al.       Expires 31 August 2026                [Page 93]
>
> _______________________________________________
> Anima mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339