Re: [Anima] WGLC for draft-ietf-anima-jws-voucher-06 ends March 15th, 2023

[Toerless Eckert <[e-mail]>]

Here is my feedback / review of -06:

Thanks a lot for this work. Looks good. Now if we could just split up all the
hard work into simple small docs like this ;-))

Couple of hopefully easy to fix text nits. two simple process 'majors',
only maybe somewhat a point of discussion is to upgrade all refs from rfc8366 to
rfc8366bis - to make this JWS work immediately applicable to any extensions that
rfc8366 will bring.

Comments inline using output of idnits.

Cheers
    Toerless

---
idnits 2.17.1 

draft-ietf-anima-jws-voucher-06.txt:
-(579): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There is 1 instance of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The abstract seems to contain references ([RFC7515], [RFC8366]), which
     it shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  == The 'Updates: ' line in the draft header should list only the _numbers_
     of the RFCs which will be updated by this document (if approved); it
     should not include the word 'RFC' in the list.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (22 February 2023) is 21 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'THIS RFC' is mentioned on line 265, but not defined

  == Missing Reference: 'RFCxxxx' is mentioned on line 291, but not defined

  == Missing Reference: 'THING' is mentioned on line 291, but not defined

  == Outdated reference: A later version (-08) exists of
     draft-ietf-anima-brski-prm-07

  == Outdated reference: A later version (-20) exists of
     draft-ietf-anima-constrained-voucher-19


     Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	anima Working Group                                            T. Werner
3	Internet-Draft                                                Siemens AG
4	Updates: RFC8366 (if approved)                             M. Richardson
5	Intended status: Standards Track                Sandelman Software Works
6	Expires: 26 August 2023                                 22 February 2023

8	        JWS signed Voucher Artifacts for Bootstrapping Protocols
9	                    draft-ietf-anima-jws-voucher-06

11	Abstract

13	   [RFC8366] defines a digital artifact called voucher as a YANG-defined
14	   JSON document that is signed using a Cryptographic Message Syntax
15	   (CMS) structure.  This document introduces a variant of the voucher
16	   artifact in which CMS is replaced by the JSON Object Signing and
17	   Encryption (JOSE) mechanism described in [RFC7515] to support
18	   deployments in which JOSE is preferred over CMS.

20	   In addition to explaining how the format is created, the
21	   "application/voucher-jws+json" media type is registered and examples
22	   are provided.

nit: i think this second paragraph (20-22) is redundant here. Remove.

24	Status of This Memo

26	   This Internet-Draft is submitted in full conformance with the
27	   provisions of BCP 78 and BCP 79.

29	   Internet-Drafts are working documents of the Internet Engineering
30	   Task Force (IETF).  Note that other groups may also distribute
31	   working documents as Internet-Drafts.  The list of current Internet-
32	   Drafts is at https://datatracker.ietf.org/drafts/current/.

34	   Internet-Drafts are draft documents valid for a maximum of six months
35	   and may be updated, replaced, or obsoleted by other documents at any
36	   time.  It is inappropriate to use Internet-Drafts as reference
37	   material or to cite them other than as "work in progress."

39	   This Internet-Draft will expire on 26 August 2023.

41	Copyright Notice

43	   Copyright (c) 2023 IETF Trust and the persons identified as the
44	   document authors.  All rights reserved.

46	   This document is subject to BCP 78 and the IETF Trust's Legal
47	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
48	   license-info) in effect on the date of publication of this document.
49	   Please review these documents carefully, as they describe your rights
50	   and restrictions with respect to this document.  Code Components
51	   extracted from this document must include Revised BSD License text as
52	   described in Section 4.e of the Trust Legal Provisions and are
53	   provided without warranty as described in the Revised BSD License.

55	Table of Contents

57	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
58	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
59	   3.  Voucher Artifact with JSON Web Signature  . . . . . . . . . .   3
60	     3.1.  Voucher Representation in General JWS JSON Serialization
61	           Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   4
62	     3.2.  JWS Payload of Voucher in General JWS JSON
63	           Serialization . . . . . . . . . . . . . . . . . . . . . .   4
64	     3.3.  JWS Protected Header of Voucher in General JWS JSON
65	           Serialization . . . . . . . . . . . . . . . . . . . . . .   5
66	   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   5
67	   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
68	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
69	     6.1.  Media-Type Registry . . . . . . . . . . . . . . . . . . .   6
70	       6.1.1.  application/voucher-jws+json  . . . . . . . . . . . .   6
71	   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
72	   8.  Changelog [RFC Editor: please delete] . . . . . . . . . . . .   7
73	   9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
74	     9.1.  Example Pledge Voucher Request - PVR (from Pledge to
75	           Registrar)  . . . . . . . . . . . . . . . . . . . . . . .   7
76	     9.2.  Example Parboiled Registrar Voucher Request - RVR (from
77	           Registrar to MASA)  . . . . . . . . . . . . . . . . . . .   9
78	     9.3.  Example Voucher Response (from MASA to Pledge, via
79	           Registrar)  . . . . . . . . . . . . . . . . . . . . . . .  11
80	   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
81	     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
82	     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
83	   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
84	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

86	1.  Introduction

88	   "A Voucher Artifact for Bootstrapping Protocols" [RFC8366] defines a
89	   YANG-based data structure used in "Bootstrapping Remote Secure Key
                                    ^
nit: Full stop, start new sentence: "It is ..".

Always good when coming from a german background to try to split sentences into
shorter ones or thinking about shorter sentences in english - and useful to do
re-reading acros any whole draft (not that i am the expert on this, i just
have been beaten over the head very often by reviewers for this).

90	   Infrastructure" [BRSKI] and "Secure Zero Touch Provisioning" [SZTP]
91	   to transfer ownership of a device from a manufacturer to a new owner
92	   (site domain).  That document provides a serialization of the voucher
93	   to JSON [RFC8259] with a signature according to the Cryptographic
94	   Message Syntax (CMS) [RFC5652].  The resulting voucher artifact has
95	   the media type "application/voucher-cms+json".

nit: I would move the sentence explaining where it's used to the end of the
paragraph as it interrupts the flow of explaining what it is..

97	   [I-D.ietf-anima-constrained-voucher] provides a serialization of the
98	   voucher to CBOR [RFC8949] with the signature format of COSE [RFC8812]
99	   and the media type "application/voucher-cose+cbor".

nit: These reference will just be RFC numbers, one this draft turns RFC, so it
will be a lot harder to immediately guess that the reason for this draft is to
support constrained environments. Suggest you add a sentence or two to explain
the purpose of this work in this respect.

nit: Its also not clear why this is mentioned here. E.g.: whats the relevance
to this draft ? Add another sentence or two.

101	   This document provides a serialization of the voucher to JSON
102	   [RFC8259] with the signature in form of JSON Web Signature (JWS)
103	   [RFC7515] and the media type "application/voucher-jws+json".  The
104	   encoding specified in this document is used by
105	   [I-D.ietf-anima-brski-prm] and may be more handy for use cases
106	   requiring signed JSON objects.

nit: Up to this point, and with quick lookahead through the rest of the document,
i think it is missing a good hard justification for this work.

Is there a good/hard example for JWS to reduce the need for otherwise unnecessary
CMS libraries ? I am not sure about this given how i think we always need CMS
for parsing of certificates - which i think we can never avoid ? Aka: Whatver
the best explanation is of reduction in code in this respect might be one useful
justification.

JWS using the sameencoding mechanisms as the voucher, hence reducing the
number of encodings == "programming languages" that need to be understood/used
by developers and operators troubleshooting. I guess this true but needs to be
put into better sentence(s).

In general: whatever benefits of this mechanism are that could help other adopters of solution
pick this option over other BRSKI option.

108	   This document does not extend the YANG definition of [RFC8366].

nit: s/extend/change/

110	   With the availability of different encoded vouchers, 

nit: differently

110	   it is up to an
111	   industry specific application statement to indicate/decide which
112	   voucher signature format is to be used.  There is no provision across
113	   the different voucher signature formats that a receiver could safely
114	   recognize which format it uses unless additional context is provided.
115	   For example, [BRSKI] provides this context via the media type for the
116	   voucher artifact.

nit: would suggest rewording 110-116 as follows:

applications that use voucher must either assume one specific voucher encoding
or indicate which voucher encoding is used through mechanism such as the
aforementioned media-types which are defined for all voucher encodings.

nit: i think "voucher and signature format" is better

116	   This document utilizes the optional "typ" (Type)
117	   Header Parameter of JWS [RFC7515] to provide information about the
118	   signed object.

nit: I think this is "introduces", but not "utilizes". As in: code right now
could ignore this field, right ?

nit: Migh want to write a sentence avbout what the Type field offers as benefit.
I guess it does allow to distinguish different Types while still keeping the
same media-type, but that does not help much if the mechanism to request/reply
a particular voucher format can only negotiate based on media-type. In that case,
every different JWS voucher option we want to invent might need a separate
media-type.

120	   This document should be considered an update to [RFC8366] in the
121	   category of "See Also" as per [I-D.kuehlewind-update-tag].  TODO:
122	   double check with RFC8366bis

major: I don't think this is an update to RFC8366 or RFC8366bis according to the
currently active semantic of update. This is because we are not changing any
encoding/extension point or the like of vouchers according to rfc8366. Instead
we are creating a derived "JWS Format Voucher Artefact". Maybe this is the wording
that cold be used in the initial explanation text. Something like

'rfc8366bis defines a "CMS Format Voucher Artefact" (RFC8366, Section 6.5). The
voucher is defined via YANG and CMS is the signature format. This document
defined a "JWS Format Voucher Artefact" using the voucher YANG definitions of
RFC866bis and replacing the CMS signature with a JWS signature.

Aka: Lets forget to even reference RFC8366 but only RFC8366. This allows us not
to have to explain how RFC8366bis is a superset/evolution of RFC8366 and how
even if we immediately only need RFC8366 YANG model for PRM, it of course is a lot
more flexible to specify applicability of the JWS signature for the whole RFC8366bis
superset of YANG options.

This is of course only best and true if there are not any incompatibilities between
JWS and any RFC8366bis YANG model details... But i couldn't think of what that could
be. Aka: should all be correct.

124	2.  Terminology

126	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
127	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
128	   "OPTIONAL" in this document are to be interpreted as described in
129	   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
130	   capitals, as shown here.

132	3.  Voucher Artifact with JSON Web Signature

134	   [RFC7515] defines the following serializations for JWS:

136	   1.  "JWS Compact Serialization" in Section 7.1 of [RFC7515]

138	   2.  "JWS JSON Serialization" in Section 7.2 of [RFC7515] - "General
139	       JWS JSON Serialization Syntax" in Section 7.2.1 of [RFC7515]
140	       - "Flattened JWS JSON Serialization Syntax" in Section 7.2.2 of
141	       [RFC7515]

143	   This document makes use of the "General JWS JSON Serialization
144	   Syntax" to support multiple signatures, as already supported by
145	   [RFC8366] for CMS-signed vouchers.

nit: do you need 134-141 ? You could simple write in 144: 
  Syntax" according to Section 7.2.1 of [RFC7517], 

147	   The [RFC8366] voucher data structure consists of a nested map, the
148	   outer map of which is:

150	       { "ietf-voucher:voucher" : { inner map }}

nit: All those things said with rfc8366 would be nice to upgrade to rfc8366 and check
if thats still all correct.  I think it is, but Michael would best have to ack.
 
152	   This outer map is considered the JWS Payload as described in
153	   Section 3 of [RFC7515].  A "JWS JSON Serialization Overview" is given
154	   in Section 3.2 of [RFC7515] and more details on the JWS
155	   serializations in Section 7 of [RFC7515].

157	3.1.  Voucher Representation in General JWS JSON Serialization Syntax

159	   The following figure gives an overview of the Voucher representation

nit: how is this "gives an overview" ? Isn't this "specifies the Voucher representation in compliance with the "General JWS JSON Serialization Syntax"

aka: you are allocating/defining "ietf-voucher:voucher" here, so it is a specification... ?! (i think)

160	   in "General JWS JSON Serialization Syntax":

162	       {
163	         "payload": "BASE64URL(ietf-voucher:voucher)",
164	         "signatures": [
165	           {
166	             "protected": "BASE64URL(UTF8(JWS Protected Header))",
167	             "signature": "base64encodedvalue=="

nit: i think you need to copy some notational text from rfc8366bis into some
earlier sections of this document to define the format BASE64URL and base64encodedvalue
before using them here.

168	           }
169	         ]
170	       }

172	            Figure 1: Voucher Representation in General JWS JSON
173	                            Serialization Syntax

nit: I think this caption should be somthing like

       Voucher representation using the General JWS JSON Serialization in JSON Syntax

175	3.2.  JWS Payload of Voucher in General JWS JSON Serialization

177	   The following figure depicts the decoded JWS Payload in JSON syntax:

nit: depicts an example of a decoded ??

179	       {
180	         "ietf-voucher:voucher": {
181	           "assertion": "logged",
182	           "serial-number": "0123456789",
183	           "nonce": "5742698422680472",
184	           "created-on": "2022-07-08T03:01:24.618Z",
185	           "pinned-domain-cert": "base64encodedvalue=="
186	         }
187	       }

189	                Figure 2: Decoded JWS Payload in JSON Syntax

191	3.3.  JWS Protected Header of Voucher in General JWS JSON Serialization

193	   The standard header parameters "typ" and "alg" as described in
194	   [RFC7515] are utilized in the protected header.  The "alg" header
195	   MUST contain the algorithm type used to create the signature, e.g.,
196	   "ES256".  The "typ" header SHOULD contain the value "TODO: voucher-
197	   jws+json", if present.

major: I don't think we should go with a "TODO" here past WGLC, please come up with a proposal.

199	   If X.509 (PKIX) certificates [RFC5280] are used, then the "x5c"
200	   parameter defined in Section 4.1.6 of [RFC7515] SHOULD be used to
201	   contain the certificate and chain.  Vouchers will often need all
202	   certificates in the chain, including what would be considered the
203	   trust anchor certificate, because intermediate devices (such as the
204	   Registrar) may need to audit the artifact, or end systems may need to
205	   pin a trust anchor for future operations.  Note, a trust anchor
206	   SHOULD be provided differently to be trusted.  This is consistent

nit: Sentence does not parse. "provided differently" - differently from what ?

207	   with Section 5.5.2 of [BRSKI].

209	   The following figure gives the decoded JWS Protected Header in JSON
210	   syntax:

nit: is this example or specification ? Seems like we want to specify the "voucher-jws+json" field,
but not suer about "alg". Seems like an example ? Maybe split into a spec picture and an
example picture, even if they just differ by "alg".

212	       {
213	         "alg": "ES256",
214	         "typ": "voucher-jws+json",
215	         "x5c": [
216	           "base64encodedvalue1==",
217	           "base64encodedvalue2=="
218	         ]
219	       }

221	               Figure 3: JWS Protected Header in JSON Syntax

223	4.  Privacy Considerations

225	   The Voucher Request reveals the IDevID of the component (Pledge) that

nit: s/The/A/

226	   is in the process of bootstrapping.

228	   This request occurs via HTTP-over-TLS, however, for the Pledge-to-
229	   Registrar TLS connection, the Pledge is provisinally accepting the
                                                   ^^^^^^^^^^^^
230	   Registrar server certificate.  Hence it is subject to disclosure by a
231	   Dolev-Yao attacker (a "malicious messenger")[onpath], as explained in

nit: If you want to include such fancy name-calling for an attack, you should also
add a reference for it. 

nit: Please make this explanation conditional, e.g.:will reveal the IDevID... if a
signaling mechanism such as that of BRSKI is used.

Aka: Exposure is not a property of the voucher concept but of the signaling using to
retrieve a voucher-request.

232	   Section 10.2 of [BRSKI].

234	   The use of a JWS header brings no new privacy considerations.

nit: s/header/signature/

nit: ... compared to the use of CMS signaure.

236	5.  Security Considerations

238	   The issues of how [RFC8366] vouchers are used in a [BRSKI] system is
239	   addressed in Section 11 of [BRSKI].  This document does not change
240	   any of those issues, it just changes the signature technology used
241	   for voucher request and response artifacts.

243	   Section 9 of [SZTP] deals with voucher use in Secure Zero Touch
244	   Provisioning, for which this document also makes no changes to
245	   security.

nit: add reference  to section in BRSKI-PRM which likely is most important because
that is where JWS voucher is actually planned to be used, and its security
considerations are somewhat different from BRSKI if i remember  correctly.

247	6.  IANA Considerations

249	6.1.  Media-Type Registry

251	   This section registers the "application/voucher-jws+json" in the
252	   "Media Types" registry.

254	6.1.1.  application/voucher-jws+json

I don't think you need to sub-section the request into 6.1.1, keep it in 6.1

But replace 251-252 with something like:

This document registers a new media type in the "Media Types"
registry [RFC6838].  IANA is asked to register the following:

256	   Type name:  application
257	   Subtype name:  voucher-jws+json
258	   Required parameters:  none
259	   Optional parameters:  none
260	   Encoding considerations:  JWS+JSON vouchers are JOSE objects
261	                             signed with one or multiple signers.
262	   Security considerations:  See section [Security Considerations]
263	   Interoperability considerations:  The format is designed to be
264	     broadly interoperable.
265	   Published specification:  [THIS RFC].
266	   Applications that use this media type:  ANIMA, 6tisch, and other
267	     zero-touch bootstrapping/provisioning solutions
268	   Additional information:
269	     Magic number(s):  None
270	     File extension(s):  .vjj
271	     Macintosh file type code(s):  none
272	   Person & email address to contact for further information:  IETF
273	     ANIMA WG
274	   Intended usage:  LIMITED
275	   Restrictions on usage:  NONE
276	   Author:  ANIMA WG
277	   Change controller:  IETF
278	   Provisional registration? (standards tree only):  NO

280	7.  Acknowledgments

282	   We would like to thank the various reviewers for their input, in
283	   particular Steffen Fries, Ingo Wenda, ...TODO Support in PoC
284	   implementations Hong Rui Li and He Peng Jia, ...TODO

nit: Remove TODO. Once you get additional reviews, e.g.: IESG, AD and the like,
i have started to put in parenthesis the role from which the review was done
No need to include names of foks you've listed below as contributors (e.g.: Steffen, myself)

286	   [RFC Editor: please delete] TODO: ...

288	8.  Changelog [RFC Editor: please delete]

290	   *  Added adoption call comments from Toerless.  Changed from
291	      [RFCxxxx] to [THING] style for some key references.

293	   *  Updated references "I-D.ietf-anima-brski-async-enroll" switched to
294	      "I-D.ietf-anima-brski-prm"

296	   *  Switch from "JWS Compact Serialization" to "General JWS JSON
297	      Serialization", as focus is now on "General JWS JSON
298	      Serialization"

300	   *  Include Voucher representation in "General JWS JSON Serialization"
301	      syntax

303	   *  Include examples A1, A2, A3 using "General JWS JSON Serialization"

305	   *  Added optional "typ": "voucher-jws+json" header parameter to JWS
306	      objects

308	   *  Examples folded according to RFC8792, Single Backslash rule

310	   *  Restructuring and clean-up, preparation for WGLC

312	   *  Included feedback from shepherd review

314	   -- back

316	9.  Examples

318	   These examples are folded according to [RFC8792] Single Backslash
319	   rule.

321	9.1.  Example Pledge Voucher Request - PVR (from Pledge to Registrar)

323	   The following is an example request sent from a Pledge to the
324	   Registrar, in "General JWS JSON Serialization".

326	   =============== NOTE: '\' line wrapping per RFC 8792 ================

328	   {
329	     "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC\
330	   1udW1iZXIiOiIwMTIzNDU2Nzg5Iiwibm9uY2UiOiI2R3RuK1pRS04ySHFERlZrQkV4Wk\
331	   xRPT0iLCJjcmVhdGVkLW9uIjoiMjAyMi0wNy0wOFQwODo0MDo0Mi44MjBaIiwicHJveG\
332	   ltaXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk\
333	   1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQU\
334	   xCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlNRG\
335	   N3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1UW\
336	   5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldGcG\
337	   JsSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCaz\
338	   E2Sy9pNzlvUmtLNVliZVBnOFVTUjgvdXMxZFBVaVpITXRva1NkcUtXNWZuV3NCZCtxUk\
339	   w3V1JmZmVXa3lnZWJvSmZJbGx1cmNpMjV3bmhpT1ZDR2plekI1TUIwR0ExVWRKUVFXTU\
340	   JRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREhEQU9CZ05WSFE4QkFmOEVCQU1DQjRBd1\
341	   NBWURWUjBSQkVFd1A0SWRjbVZuYVhOMGNtRnlMWFJsYzNRdWMybGxiV1Z1Y3kxaWRDNX\
342	   VaWFNDSG5KbFoybHpkSEpoY2kxMFpYTjBOaTV6YVdWdFpXNXpMV0owTG01bGREQUtCZ2\
343	   dxaGtqT1BRUURBZ05JQURCRkFpQnhsZEJoWnEwRXY1SkwyUHJXQ3R5UzZoRFlXMXlDTy\
344	   9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm8vZ0dOMC9qd3pKWjBTbD\
345	   JoNHhJWGsxIn19",
346	     "signatures": [{
347	       "protected": "eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVNU\
348	   1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeE\
349	   thVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQ0\
350	   FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3Q1\
351	   FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZRF\
352	   ZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRtbG\
353	   paVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpjRU\
354	   VYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2TX\
355	   gyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcxaG\
356	   MyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1CYU\
357	   FGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQW9HQ0NzR0\
358	   FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBRE\
359	   JFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnWE\
360	   NtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il0sInR5cC\
361	   I6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9",
362	       "signature": "abVg4TDGzSTjVHkQlNeIW3ABu5ZXdMl1cEqwcIAlHFW4BrlGbO\
363	   -DRTKfyCOGxSW49-ktJcrVlYgKqC4xmZoy0Q"
364	     }]
365	   }

367	               Figure 4: Example Pledge Voucher Request - PVR

369	9.2.  Example Parboiled Registrar Voucher Request - RVR (from Registrar
370	      to MASA)

372	   The term parboiled refers to food which is partially cooked.  In
373	   [BRSKI], the term refers to a Pledge voucher-request (PVR) which has
374	   been received by the Registrar, and then has been processed by the
375	   Registrar ("cooked"), and is now being forwarded to the MASA.

377	   The following is an example Registrar voucher-request (RVR) sent from
378	   the Registrar to the MASA, in "General JWS JSON Serialization".  Note
379	   that the previous PVR can be seen in the payload as "prior-signed-
380	   voucher-request".

382	   =============== NOTE: '\' line wrapping per RFC 8792 ================

384	   {
385	     "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC\
386	   1udW1iZXIiOiIwMTIzNDU2Nzg5IiwiaWRldmlkLWlzc3VlciI6IkJCZ3dGb0FVVkF1TT\
387	   NNLzlMK1NpNk5EQ09Ea1RsKy9CeGhzPSIsIm5vbmNlIjoiNkd0bitaUUtOMkhxREZWa0\
388	   JFeFpMUT09IiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6ImV5SndZWGxzYj\
389	   JGa0lqb2laWGxLY0ZwWVVtMU1XRnAyWkZkT2IxcFlTWFJqYlZaNFpGZFdlbVJFY0RKaU\
390	   0xWnFZVWRXZVVscWNEZEpiazVzWTIxc2FHSkRNWFZrVnpGcFdsaEphVTlwU1hkTlZFbD\
391	   ZUa1JWTWs1Nlp6VkphWGRwWW0wNWRWa3lWV2xQYVVreVVqTlNkVXN4Y0ZKVE1EUjVVMG\
392	   hHUlZKc1duSlJhMVkwVjJ0NFVsQlVNR2xNUTBwcVkyMVdhR1JIVm10TVZ6bDFTV3B2YV\
393	   UxcVFYbE5hVEIzVG5rd2QwOUdVWGRQUkc4d1RVUnZNRTFwTkRSTmFrSmhTV2wzYVdOSV\
394	   NuWmxSMngwWVZoU05VeFlTbXhhTW14NlpFaEthR05wTVdwYVdFb3dTV3B2YVZSVmJFcF\
395	   JhbEp4VVRCT1FsZFhiRzVSV0dSS1VXdEdibE5WWkVKWFJtc3pUVzFLYVZkck1VSmlNR1\
396	   JFVVROR1NGVXdNREJQVlVwQ1ZGVk9UbEpHVmpSU1dIQkNWV3RLYmxSc1drTlJWemxPVV\
397	   RKemVFNVdSblZXYm5Cb1ZucFdjMWw2VGs1bFJWSlZVVlY0UTFvd05WZFJhMFpxVkZWS1\
398	   IxUnVRbXRTTVZZMFVraHdRbFJyU201VWJGcERVVlV4VGxGdGVGTmlSMDE2Vld0U1VsWk\
399	   ZSbXhTYm1OM1pWVXhSVkpZYkU1U1IwNHpWRzF3Ums1Rk1WVlRiVVpIWkhwQ05sUlZVa1\
400	   psVlRGRldUTmtUMkZyVlRCVVZsSkxXVlV4UlU1SWFFWmxhMFpUVVcxa1QxWnJTa0ppTU\
401	   RGRVlYcEZNVlZYTlZkbGJVWllUbGQ0YWswd01UUlNSbEpDVkVWS2JsUnNXa05SVjA1T1\
402	   VXdGFUMk5IVWtoV1dHaElVa1ZHV0ZGdFpFOVdhMHBDVkZVeFJVMUdTakpaYkdSSFkwZE\
403	   tjMU50ZUdGTmJYZzJXa1ZvUzJGSFRuRlJiSEJPVVdzeFNGRnViSGhTTVU1T1RrUnNRbG\
404	   93VmtoUk1FNTRVakZPVGs1RWJFSmtNRlpKVVZSQ1NsRlZTa05oZWtVeVUzazVjRTU2Yk\
405	   haVmJYUk1UbFpzYVZwV1FtNVBSbFpVVldwbmRtUllUWGhhUmtKV1lWWndTVlJZVW5aaE\
406	   1VNXJZMVYwV0U1WFduVldNMDVEV2tOMGVGVnJkek5XTVVwdFdtMVdXR0V6Ykc1YVYwcD\
407	   JVMjFhU21KSGVERmpiVTV3VFdwV00ySnRhSEJVTVZwRVVqSndiR1ZyU1RGVVZVbDNVak\
408	   JGZUZaWFVrdFZWa1pZVkZWS1VsSXdUa1JqTUdSQ1ZWWldSMUZ1WkU1UmEwcHVXak5LUT\
409	   Fvd1ZrZFJiRVpxVWtWb1JWRlZPVU5hTURWWFUwWkZORkZyUm0xUFJWWkRVVlV4UkZGcV\
410	   VrSmtNVTVDVjFWU1YxVnFRbE5SYTFaR1pERkJNRk5YVW1waVZscDFXVlpvVDAxSFRuUl\
411	   NibXhOVjBaS2MxbDZUbEprVjAxNVlrZDRhVll4V2pGWk0ydDRZVmRTUkU1WVZtRlhSaz\
412	   VFVTBjMVMySkdiM2xpU0hCclUwVndiMWt5YTNoTlJuQlpWR3BDVDJGVVZqWlpWbVJYWk\
413	   Vad1dFNVljRTFXTUc5M1ZFY3dNV0pIVWtWUlZYUkRXakprZUdGSGRIRlVNVUpTVlZWU1\
414	   Fsb3dOVXBSVlZKRFVtdEdjRkZ1YUhOYVJVcHZWMjVGZDFKWVdURlRhM2Q1VlVoS1dGRX\
415	   pValZWZWxwdlVrWnNXRTFZYkVSVWVUbFRXVmhXYVdORlRUTlVWMFpLVWtka1NtRkZSaz\
416	   FWTUhCcFdqQjRkVm95YUdsWmEwWnVUVWRTYWxZd1dsWldiVGgyV2pCa1QwMURPWEZrTT\
417	   NCTFYycENWR0pFU205T1NHaEtWMGR6ZUVsdU1Ua2lMQ0p6YVdkdVlYUjFjbVZ6SWpwYm\
418	   V5SndjbTkwWldOMFpXUWlPaUpsZVVvMFRsZE5hVTlzYzJsVVZXeEtVV2wwVlZFd1RrSl\
419	   pWVTV1VVZoa1NsRnJSbTVUVldSQ1YwYzFWMkZ1VGxaT1ZURkNZakJrUkZFelJraFZNRE\
420	   F3VDFWS1FsUlZUazVTUkVJMFVUTndRbE5yU201VWJGcERVVlpzVlZGWGRFZFZhekZUVm\
421	   xoa1JtUXhiRVZXYkVaU1V6QlNRbVZGZEdoV2VsWjFWVEl4YzJSV2IzZFVibHBxWW10R0\
422	   5GSnVjRUpXYTBwdVZHeGFRMUZWTVU1U1IzUjNZMGRLZEZwRmRHaFdlbFoxVm10a1YyVn\
423	   RVa1pVYTBwT1VUQkdXVkpHVWtwbFJURkZWMWhrVDFKRlJYaFVhMUphWlVVMVIySXhiRV\
424	   ZsYlhNeFZERlNjbVZGTVhGVVdHaE9ZV3N3ZUZReFVsWk9WbVJ4VVd4T1RsVllUak5STV\
425	   VaYVVrWmFVbFZWWkVaa01IQkRWbFpTUmxack1VTlVWV1JDVFZaV1JsRXlaRE5VVms1MF\
426	   lraFdZVTFJUW5kWmJURnJVa2RKZWxOdVpFNVZhekV6VWxaR1dsSkdXbEpWVlZwR1pEST\
427	   VNMVJXVWtwbGF6VkZWbFJLVDJWdFl6RlVWa3BxWkRCYVVsZFZVbGRWVmtaRlVrVkZNVk\
428	   15UmxoT1Z6VlVZbGQ0TVZkcVFsTmlSMUowWWtkd1lWWkZTbUZVVlVwT1VqQktOV05WWk\
429	   ZSVVZGRTFVVmRrUmxJd1RrUmpWV1JVVkZSUk5WRllaRVpUUlVWM1UxVkdRMUY2WXpWaV\
430	   IyeG9WVzFPUTJGc2NHcFNWVlpaWkhwa2VWWlhWbWhrYmxKSVUydEdNVk5FVW5kaGVsSk\
431	   tUa1JLTWxsVlNrNWpNVlY0VFZkc1RWSkZUa1JVUjNSWFlVaFNWbFpxU1hoaVdGcG9Vek\
432	   JPTWxSWVozbFhVM1JVVkZka1VrOUhXbTFrTUhkNVRUTnZlbFpGYkZkUmJHUnhXa1pTUT\
433	   JWck1VUmpNR1JFVVROT1NGRldSbFpTYTBvelVsZGtRMUZxYUZoVFJtTjRZVWROZVZKWV\
434	   VtdFNNVm8yV2tWTk1XVnRSbGhXYmxKaFZucFdObFJHWkV0TlJYaDBUbGQ0YTFKSE9ERl\
435	   VhMUpTWldzeFEwOUZaRUpOVmxaclUxaGtVbGRWTVVOWlZVWkhVbXhHVFdGck5UWlZSbm\
436	   QyVlRGM2RtRXlPVEZoYkVZellXMWpNVkpVVm0xa2JtUnFWMWRLVGxGck1VaFJWRVpXV2\
437	   tWd1VsVlZNVTVSVnpsSVVUQk9lbEl3UmxKV1ZWcERaREF4UkZSVlJUQlNNRVY0VmxkU1\
438	   JXUXdWa05ZUXprelZWVldRbVF3YkVsYU1GSkNVekJLYmxvelJtOWhNbkJRVlVaR1VsSk\
439	   ZSbTVVYTJoQ1VrVktSbEZYYkVOa1ZFNHpWV3RLVFdNd2NFNVZSRlo2VkZSQk0wMUZaM0\
440	   pXVlZwNVpWVTFWazV0WkV4bGEzaFFWVzFPUjJWV1NsTlVNbmg0WTFWb2NGb3diRzVYUl\
441	   U1MFUydDRWV1ZyVm5Oa2ExRjVZMGM1VEU1dFVqUk9iWGQ0V0VNNU1XVlhNVlZpYlVwU1\
442	   VrVlNiVk50ZUdoa1NGWlpUV3hLZGxRd1ZUbEpiREJ6U1c1U05XTkRTVFpKYmxwMlpGZE\
443	   9iMXBZU1hSaGJtUjZTekp3ZW1JeU5HbE1RMHBvWWtkamFVOXBTa1pWZWtreFRtbEtPU0\
444	   lzSW5OcFoyNWhkSFZ5WlNJNkltRmlWbWMwVkVSSGVsTlVhbFpJYTFGc1RtVkpWek5CUW\
445	   5VMVdsaGtUV3d4WTBWeGQyTkpRV3hJUmxjMFFuSnNSMkpQTFVSU1ZFdG1lVU5QUjNoVF\
446	   Z6UTVMV3QwU21OeVZteFpaMHR4UXpSNGJWcHZlVEJSSW4xZGZRPT0iLCJjcmVhdGVkLW\
447	   9uIjoiMjAyMi0wNy0wOFQwODo0MDo0Mi44NDhaIn19",
448	     "signatures": [{
449	       "protected": "eyJ4NWMiOlsiTUlJQm96Q0NBVXFnQXdJQkFnSUdBVzBlTHVJRk\
450	   1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQU\
451	   xCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweE9UQTVNVE\
452	   V3TWpNM016SmFGdzB5T1RBNU1URXdNak0zTXpKYU1GUXhFekFSQmdOVkJBb01DazE1UW\
453	   5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhMakFzQmdOVkJBTU1KVkpsWjJsem\
454	   RISmhjaUJXYjNWamFHVnlJRkpsY1hWbGMzUWdVMmxuYm1sdVp5QkxaWGt3V1RBVEJnY3\
455	   Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ2eFZ2QXZxVHoxWlVpdU5XaFhwUXNrYV\
456	   B5N0FISFFMd1hpSjBpRUx0NnVOUGFuQU4wUW5XTVlPXC8wQ0RFaklrQlFvYnc4WUtxan\
457	   R4SkhWU0dUajlLT295Y3dKVEFUQmdOVkhTVUVEREFLQmdnckJnRUZCUWNESERBT0JnTl\
458	   ZIUThCQWY4RUJBTUNCNEF3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnWXIyTGZxb2FDS0\
459	   RGNFJBY01tSmkrTkNacWRTaXVWdWdJU0E3T2hLUnEzWUNJRHhuUE1NbnBYQU1UclBKdV\
460	   BXeWNlRVIxMVB4SE9uKzBDcFNIaTJxZ3BXWCIsIk1JSUJwRENDQVVtZ0F3SUJBZ0lHQV\
461	   cwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bG\
462	   MzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MH\
463	   hPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXpBUkJnTlZCQW\
464	   9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQm\
465	   xSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCT2t2a1RIdT\
466	   hRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDZcL1NjWTVQSmlidm\
467	   dIVEIrRlwvUVRqZ2VsSEd5MVlLcHdjTk1jc1N5YWpSVEJETUJJR0ExVWRFd0VCXC93UU\
468	   lNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSFwvQkFRREFnSUVNQjBHQTFVZERnUVdCQlRvWk\
469	   lNelFkc0RcL2pcLytnWFwvN2NCSnVjSFwvWG1qQUtCZ2dxaGtqT1BRUURBZ05KQURCR0\
470	   FpRUF0eFEzK0lMR0JQSXRTaDRiOVdYaFhOdWhxU1A2SCtiXC9MQ1wvZlZZRGpRNm9DSV\
471	   FERzJ1UkNIbFZxM3loQjU4VFhNVWJ6SDgrT2xoV1V2T2xSRDNWRXFEZGNRdz09Il0sIn\
472	   R5cCI6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9",
473	       "signature": "0fzuqVdyhemWsu_HQeF-CmQwJeLp9IStNf-bWZwz6SojrEOR4a\
474	   Dq6VStyG8eWXjGHNZiRyyLJo7RP1rKatuS2w"
475	     }]
476	   }

478	        Figure 5: Example Parboiled Registrar Voucher Request - RVR

480	9.3.  Example Voucher Response (from MASA to Pledge, via Registrar)

482	   The following is an example voucher response from MASA to Pledge via
483	   Registrar, in "General JWS JSON Serialization".

485	   =============== NOTE: '\' line wrapping per RFC 8792 ================

487	   {
488	     "payload": "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2\
489	   dnZWQiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjoiZGRoSGQ4Ml\
490	   FpUGtzMDBTck1USTlEUT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDctMDdUMTc6NDc6MD\
491	   EuODkwWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F3SUJBZ0lHQV\
492	   cwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bG\
493	   MzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MH\
494	   hPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXpBUkJnTlZCQW\
495	   9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQm\
496	   xSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCT2t2a1RIdT\
497	   hRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2NZNVBKaWJ2Z0\
498	   hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXdFQi93UUlNQV\
499	   lCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0JCVG9aSU16UW\
500	   RzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkdBaUVBdHhRMy\
501	   tJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUURHMnVSQ0hsVn\
502	   EzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
503	     "signatures": [{
504	       "protected": "eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU\
505	   1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeE\
506	   thVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQj\
507	   RYRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQT\
508	   FVRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRU\
509	   F3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQV\
510	   RCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOF\
511	   IwWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0\
512	   dCSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSX\
513	   pqMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU\
514	   5FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2\
515	   FFS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In\
516	   0",
517	       "signature": "y1HLYBFlwouf42XWSKUWjeYQHnG2Q6A4bjA7hvTkB3z1dPwTUl\
518	   jPHtuN2Qex6gDxTfaSiKeoXGsOD4JWOgQJPg"
519	     }]
520	   }

522	                     Figure 6: Example Voucher Response

524	10.  References

526	10.1.  Normative References

528	   [BRSKI]    Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
529	              and K. Watsen, "Bootstrapping Remote Secure Key
530	              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
531	              May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

533	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
534	              Requirement Levels", BCP 14, RFC 2119,
535	              DOI 10.17487/RFC2119, March 1997,
536	              <https://www.rfc-editor.org/rfc/rfc2119>.

538	   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
539	              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
540	              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

542	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
543	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
544	              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

546	   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
547	              Interchange Format", STD 90, RFC 8259,
548	              DOI 10.17487/RFC8259, December 2017,
549	              <https://www.rfc-editor.org/rfc/rfc8259>.

551	   [RFC8366]  Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
552	              "A Voucher Artifact for Bootstrapping Protocols",
553	              RFC 8366, DOI 10.17487/RFC8366, May 2018,
554	              <https://www.rfc-editor.org/rfc/rfc8366>.

556	   [SZTP]     Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
557	              Touch Provisioning (SZTP)", RFC 8572,
558	              DOI 10.17487/RFC8572, April 2019,
559	              <https://www.rfc-editor.org/rfc/rfc8572>.

561	10.2.  Informative References

563	   [I-D.ietf-anima-brski-prm]
564	              Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI
565	              with Pledge in Responder Mode (BRSKI-PRM)", Work in
566	              Progress, Internet-Draft, draft-ietf-anima-brski-prm-07,
567	              21 February 2023, <https://datatracker.ietf.org/doc/html/
568	              draft-ietf-anima-brski-prm-07>.

570	   [I-D.ietf-anima-constrained-voucher]
571	              Richardson, M., Van der Stok, P., Kampanakis, P., and E.
572	              Dijk, "Constrained Bootstrapping Remote Secure Key
573	              Infrastructure (BRSKI)", Work in Progress, Internet-Draft,
574	              draft-ietf-anima-constrained-voucher-19, 2 January 2023,
575	              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
576	              constrained-voucher-19>.

578	   [I-D.kuehlewind-update-tag]
579	              Kühlewind, M. and S. Krishnan, "Definition of new tags for
580	              relations between RFCs", Work in Progress, Internet-Draft,
581	              draft-kuehlewind-update-tag-04, 12 July 2021,
582	              <https://datatracker.ietf.org/doc/html/draft-kuehlewind-
583	              update-tag-04>.

585	   [onpath]   "can an on-path attacker drop traffic?", n.d.,
586	              <https://mailarchive.ietf.org/arch/msg/saag/
587	              m1r9uo4xYznOcf85Eyk0Rhut598/>.

589	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
590	              Housley, R., and W. Polk, "Internet X.509 Public Key
591	              Infrastructure Certificate and Certificate Revocation List
592	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
593	              <https://www.rfc-editor.org/rfc/rfc5280>.

595	   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
596	              RFC 5652, DOI 10.17487/RFC5652, September 2009,
597	              <https://www.rfc-editor.org/rfc/rfc5652>.

599	   [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
600	              "Handling Long Lines in Content of Internet-Drafts and
601	              RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
602	              <https://www.rfc-editor.org/rfc/rfc8792>.

604	   [RFC8812]  Jones, M., "CBOR Object Signing and Encryption (COSE) and
605	              JSON Object Signing and Encryption (JOSE) Registrations
606	              for Web Authentication (WebAuthn) Algorithms", RFC 8812,
607	              DOI 10.17487/RFC8812, August 2020,
608	              <https://www.rfc-editor.org/rfc/rfc8812>.

610	   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
611	              Representation (CBOR)", STD 94, RFC 8949,
612	              DOI 10.17487/RFC8949, December 2020,
613	              <https://www.rfc-editor.org/rfc/rfc8949>.

615	Contributors

617	   Toerless Eckert
618	   Futurewei Technologies Inc.
619	   Email: [e-mail]

Please remove the "+ietf", that was an old idea that didn't work out too well.

621	   Esko Dijk
622	   Email: [e-mail]

624	   Steffen Fries
625	   Siemens AG
626	   Email: [e-mail]

628	Authors' Addresses

630	   Thomas Werner
631	   Siemens AG
632	   Email: [e-mail]

634	   Michael Richardson
635	   Sandelman Software Works
636	   Email: [e-mail]


Thank you so much.
EOF