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: [email protected]
Please remove the "+ietf", that was an old idea that didn't work out too well.
621 Esko Dijk
622 Email: [email protected]
624 Steffen Fries
625 Siemens AG
626 Email: [email protected]
628 Authors' Addresses
630 Thomas Werner
631 Siemens AG
632 Email: [email protected]
634 Michael Richardson
635 Sandelman Software Works
636 Email: [email protected]
Thank you so much.
EOF
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
