idnits 2.17.00 (12 Aug 2021) /tmp/idnits14647/draft-ietf-anima-jws-voucher-03.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (7 March 2022) is 68 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFCxxxx' is mentioned on line 262, but not defined == Missing Reference: 'THING' is mentioned on line 262, but not defined == Outdated reference: A later version (-03) exists of draft-ietf-anima-brski-prm-02 == Outdated reference: A later version (-17) exists of draft-ietf-anima-constrained-voucher-16 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Updates: RFC8366 (if approved) T. Werner 5 Intended status: Standards Track Siemens AG 6 Expires: 8 September 2022 7 March 2022 8 JWS signed Voucher Artifacts for Bootstrapping Protocols 9 draft-ietf-anima-jws-voucher-03 11 Abstract 13 RFC8366 defines a digital artifact called voucher as a YANG-defined 14 JSON document that has been signed using a Cryptographic Message 15 Syntax (CMS) structure. This memo introduces a variant of the 16 voucher structure in which CMS is replaced by the JSON Object Signing 17 and Encryption (JOSE) mechanism described in RFC7515 to better 18 support use-cases in which JOSE is preferred over CMS. 20 In addition to explaining how the format is created, MIME types are 21 registered and examples are provided. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 8 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. JSON Web Signatures - General JWS JSON Serialization 59 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Unprotected Header . . . . . . . . . . . . . . . . . . . 4 61 3.2. Protected Header . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Voucher Representation in General JWS JSON Serialization 63 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Media-Type Registry . . . . . . . . . . . . . . . . . . . 6 68 6.1.1. application/voucher-jws+json . . . . . . . . . . . . 6 69 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 74 A.1. Example Pledge Voucher Request - PVR (from Pledge to 75 Registrar) . . . . . . . . . . . . . . . . . . . . . . . 9 76 A.2. Example Parboiled Registrar Voucher Request - RVR (from 77 Registrar to MASA) . . . . . . . . . . . . . . . . . . . 10 78 A.3. Example Voucher Response (from MASA to Pledge, via 79 Registrar) . . . . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 "A Voucher Artifact for Bootstrapping Protocols", [RFC8366] describes 85 a voucher artifact used in "Bootstrapping Remote Secure Key 86 Infrastructure" [BRSKI] and "Secure Zero Touch Provisioning" [SZTP] 87 to transfer ownership of a device from a manufacturer to an owner. 88 That document defines the base YANG module, and also the initial 89 serialization to JSON [RFC8259], with a signature provided by 90 [RFC5652]. 92 Other work, [I-D.ietf-anima-constrained-voucher] provides a mapping 93 of the YANG to CBOR [RFC8949] with a signature format of COSE 94 [RFC8812]. 96 This document provides an equivalent mapping of JSON format with the 97 signature format as JSON Web Signature (JWS) [RFC7515]. The encoding 98 specified in this document is required for [I-D.ietf-anima-brski-prm] 99 and may be required and/or preferred in other use cases, for example 100 when JWS is already used in other parts of the use case, but CMS is 101 not. 103 This document does not extend the YANG definition of [RFC8366] at 104 all, but accepts that other efforts such as 105 [I-D.richardson-anima-voucher-delegation], 106 [I-D.friel-anima-brski-cloud], and [I-D.ietf-anima-brski-prm] do. 107 This document supports signing any of the extended schemas defined in 108 those documents and any new documents that may appear after this one. 110 With the availability of different encoded vouchers, 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 MIME-Type for the 116 voucher payload. 118 This document should be considered an Update to [RFC8366] in the 119 category of "See Also" as per [I-D.kuehlewind-update-tag]. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. JSON Web Signatures - General JWS JSON Serialization Syntax 131 [RFC Editor: please delete] /* TODO: ... */ 133 [RFC7515] defines two serializations: the "JWS Compact Serialization" 134 and the "JWS JSON Serialization". 136 The [RFC8366] JSON structure consists of a nested map, the outer part 137 of which is: 139 { "ietf-voucher:voucher" : { some inner items }} 141 this is considered the JSON payload as described in [RFC7515] section 142 3. 144 A JWS JSON Serialization Overview is given by [RFC7515] in section 145 3.2 and section 7.2.1 provides more details. It works out to: 147 [RFC Editor: please delete] /* 148 TODO: ... 149 */ 151 There are a number of attributes. They are: 153 3.1. Unprotected Header 155 [RFC Editor: please delete] /* TODO: ... */ 157 3.2. Protected Header 159 The standard "typ" and "alg" values described in [RFC7515] are 160 expected in the protected headers. 162 It remains to be determined (XXX), what values, if any, should go 163 into the "typ" header, as in the [BRSKI] use cases, there are 164 additional HTTP MIME type headers to indicate content types. 166 The "alg" should contain the algorithm type such as "ES256". 168 If PKIX [RFC5280] format certificates are used then the [RFC7515] 169 section 4.1.6 "x5c" certificate chain SHOULD be used to contain the 170 certificate and chain. Vouchers will often need all certificates in 171 the chain, including what would be considered the trust anchor 172 certificate because intermediate devices (such as the Registrar) may 173 need to audit the artifact, or end systems may need to pin a trust 174 anchor for future operations. This is consistent with [BRSKI] 175 section 5.5.2. 177 3.3. Voucher Representation in General JWS JSON Serialization Syntax 178 { 179 "payload": { 180 "ietf-voucher:voucher": { 181 "assertion": "logged", 182 "serial-number": "0123456789", 183 "nonce": "5742698422680472", 184 "created-on": "2022-03-02T03:01:24.618Z", 185 "pinned-domain-cert": "base64encodedvalue==" 186 } 187 }, 188 "signatures": [ 189 { 190 "protected": { 191 "x5c": [ 192 "base64encodedvalue==" 193 ], 194 "alg": "ES256" 195 }, 196 "signature": "base64encodedvalue==" 197 } 198 ] 199 } 201 Figure 1: Voucher Representation in General JWS JSON 202 Serialization Syntax 204 4. Privacy Considerations 206 The Voucher Request reveals the IDevID of the component (Pledge) that 207 is on-boarding. 209 This request occurs over HTTP-over-TLS, however the Pledge to 210 Registrar transaction is over a provisional TLS session, and it is 211 subject to disclosure via by a Dolev-Yao attacker (a "malicious 212 messenger")[onpath]. This is explained in [BRSKI] section 10.2. 214 The use of a JWS header brings no new privacy considerations. 216 5. Security Considerations 218 The issues of how [RFC8366] vouchers are used in a [BRSKI] system is 219 addressed in section 11 of that document. This document does not 220 change any of those issues, it just changes the signature technology 221 used for vouchers and voucher requests. 223 [SZTP] section 9 deals with voucher use in Secure Zero Touch 224 Provisioning, and this document also makes no changes to security. 226 6. IANA Considerations 228 6.1. Media-Type Registry 230 This section registers the 'application/voucher-jws+json' in the 231 "Media Types" registry. 233 6.1.1. application/voucher-jws+json 235 Type name: application 236 Subtype name: voucher-jws+json 237 Required parameters: none 238 Optional parameters: none 239 Encoding considerations: JWS+JSON vouchers are JOSE objects 240 signed with one signer. 241 Security considerations: See Security Considerations, Section 242 Interoperability considerations: The format is designed to be 243 broadly interoperable. 244 Published specification: THIS RFC. 245 Applications that use this media type: ANIMA, 6tisch, and other 246 zero-touch imprinting systems 247 Additional information: 248 Magic number(s): None 249 File extension(s): .vjj 250 Macintosh file type code(s): none 251 Person & email address to contact for further information: IETF 252 ANIMA WG 253 Intended usage: LIMITED 254 Restrictions on usage: NONE 255 Author: ANIMA WG 256 Change controller: IETF 257 Provisional registration? (standards tree only): NO 259 7. Changelog 261 * Added adoption call comments from Toerless. Changed from 262 [RFCxxxx] to [THING] style for some key references. 264 * Updated references "I-D.ietf-anima-brski-async-enroll" switched to 265 "I-D.ietf-anima-brski-prm" 267 * Switch from "JWS Compact Serialization" to "General JWS JSON 268 Serialization", as focus is now on "General JWS JSON 269 Serialization" 271 * Include Voucher representation in "General JWS JSON Serialization" 272 syntax 274 * Include examples A1, A2, A3 using "General JWS JSON Serialization" 276 8. References 278 8.1. Normative References 280 [BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 281 and K. Watsen, "Bootstrapping Remote Secure Key 282 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 283 May 2021, . 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, 288 . 290 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 291 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 292 2015, . 294 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 295 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 296 May 2017, . 298 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 299 Interchange Format", STD 90, RFC 8259, 300 DOI 10.17487/RFC8259, December 2017, 301 . 303 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 304 "A Voucher Artifact for Bootstrapping Protocols", 305 RFC 8366, DOI 10.17487/RFC8366, May 2018, 306 . 308 [SZTP] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 309 Touch Provisioning (SZTP)", RFC 8572, 310 DOI 10.17487/RFC8572, April 2019, 311 . 313 8.2. Informative References 315 [I-D.friel-anima-brski-cloud] 316 Friel, O., Shekh-Yusef, R., and M. Richardson, "BRSKI 317 Cloud Registrar", Work in Progress, Internet-Draft, draft- 318 friel-anima-brski-cloud-04, 6 April 2021, 319 . 322 [I-D.ietf-anima-brski-prm] 323 Fries, S., Werner, T., Lear, E., and M. C. Richardson, 324 "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in 325 Progress, Internet-Draft, draft-ietf-anima-brski-prm-02, 4 326 March 2022, . 329 [I-D.ietf-anima-constrained-voucher] 330 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 331 Dijk, "Constrained Bootstrapping Remote Secure Key 332 Infrastructure (BRSKI)", Work in Progress, Internet-Draft, 333 draft-ietf-anima-constrained-voucher-16, 14 February 2022, 334 . 337 [I-D.kuehlewind-update-tag] 338 Kuehlewind, M. and S. Krishnan, "Definition of new tags 339 for relations between RFCs", Work in Progress, Internet- 340 Draft, draft-kuehlewind-update-tag-04, 12 July 2021, 341 . 344 [I-D.richardson-anima-voucher-delegation] 345 Richardson, M. and W. Pan, "Delegated Authority for 346 Bootstrap Voucher Artifacts", Work in Progress, Internet- 347 Draft, draft-richardson-anima-voucher-delegation-03, 22 348 March 2021, . 351 [onpath] "can an on-path attacker drop traffic?", n.d., 352 . 355 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 356 Housley, R., and W. Polk, "Internet X.509 Public Key 357 Infrastructure Certificate and Certificate Revocation List 358 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 359 . 361 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 362 RFC 5652, DOI 10.17487/RFC5652, September 2009, 363 . 365 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 366 "Handling Long Lines in Content of Internet-Drafts and 367 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 368 . 370 [RFC8812] Jones, M., "CBOR Object Signing and Encryption (COSE) and 371 JSON Object Signing and Encryption (JOSE) Registrations 372 for Web Authentication (WebAuthn) Algorithms", RFC 8812, 373 DOI 10.17487/RFC8812, August 2020, 374 . 376 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 377 Representation (CBOR)", STD 94, RFC 8949, 378 DOI 10.17487/RFC8949, December 2020, 379 . 381 Appendix A. Examples 383 These examples are folded according to [RFC8792] Single Backslash 384 rule. 386 A.1. Example Pledge Voucher Request - PVR (from Pledge to Registrar) 388 The following is an example request sent from a Pledge to the 389 Registrar, in "General JWS JSON Serialization". 391 { 392 "payload": 393 "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7ImNyZWF0ZWQ 394 tb24iOiIyMDE5LTAyLTE4VDA3OjM5OjAzLjAwMFoiLCJub25jZSI6IjU 395 3NDI2OTg0MjI2ODA0NzIifX0", 396 "signatures":[ 397 { 398 "protected": 399 "eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlCMmpDQ0FZQ2dBd0lCQWd 400 JR0FXZWdkY1NMTUFvR0NDcUdTTTQ5QkFNQ01EMHhDekFKQmdOVkJBWVR 401 Ba0ZSTVJVd0V3WURWUVFLREF4S2FXNW5TbWx1WjBOdmNuQXhGekFWQmd 402 OVkJBTU1Ea3BwYm1kS2FXNW5WR1Z6ZEVOQk1DQVhEVEU0TVRJeE1qQXp 403 NamcxTVZvWUR6azVPVGt4TWpNeE1qTTFPVFU1V2pCU01Rc3dDUVlEVlF 404 RR0V3SkJVVEVWTUJNR0ExVUVDZ3dNU21sdVowcHBibWREYjNKd01STXd 405 FUVlEVlFRRkV3b3dNVEl6TkRVMk56ZzVNUmN3RlFZRFZRUUREQTVLYVc 406 1blNtbHVaMFJsZG1salpUQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDl 407 Bd0VIQTBJQUJNVkdHOFo1cGpmNWpYbnlyVXJYeVoxa1BncUJlM05YdTF 408 kVEFEZStyL3Y2SnpJSGwzNTVJZ2NIQzNheHBpYnFKTS9iV1JhRXlqcWN 409 DSmo0akprb3dDdWpWVEJUTUN3R0NTc0dBUVFCZ3U1U0FnUWZEQjF0WVh 410 OaExYUmxjM1F1YzJsbGJXVnVjeTFpZEM1dVpYUTZPVFEwTXpBVEJnTlZ 411 IU1VFRERBS0JnZ3JCZ0VGQlFjREFqQU9CZ05WSFE4QkFmOEVCQU1DQjR 412 Bd0NnWUlLb1pJemowRUF3SURTQUF3UlFJZ1d0UHpJSVhZMml4UlhKdEV 413 4S0VoaFpkYTRYK0VwbFpvbUVJMnpBMGRzam9DSVFDM0pwUW1SWE1Hbi9 414 wNEJ1OWl6aWk5MmVjbFR4NC9PNHJsbTdNeUxxa2hkQT09Il19", 415 "signature": 416 "xURZmcWSFaBD2cNkr37azT9osWfzTZ_veCsVho3fwdD6NR4ghL61VJm 417 Y_ra0a42SvoW2Tu4XlldzzD8VDtCCDg" 418 } 419 ] 420 } 422 Figure 2: Example Pledge Voucher Request - PVR 424 A.2. Example Parboiled Registrar Voucher Request - RVR (from Registrar 425 to MASA) 427 The term parboiled refers to food which is partially cooked. In 428 [BRSKI], the term refers to a Pledge voucher-request (PVR) which has 429 been received by the Registrar, and then has been processed by the 430 Registrar ("cooked"), and is now being forwarded to the MASA. 432 The following is an example Registrar voucher-request (RVR) sent from 433 the Registrar to the MASA, in "General JWS JSON Serialization". Note 434 that the previous PVR can be seen in the payload as "prior-signed- 435 voucher-request". 437 { 438 "payload": 439 "eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2b3VjaGVyIjp7InNlcmlhbC1 440 udW1iZXIiOiIwMTIzNDU2Nzg5Iiwibm9uY2UiOiI1NzQyNjk4NDIyNjg 441 wNDcyIiwicHJpb3Itc2lnbmVkLXZvdWNoZXItcmVxdWVzdCI6ImV5Snd 442 ZWGxzYjJGa0lqb2laWGxLY0ZwWVVtMU1XRnAyWkZkT2IxcFlTWFJqYlZ 443 aNFpGZFdlbVJFY0RKaU0xWnFZVWRXZVVscWNEZEpiVTU1V2xkR01GcFh 444 VWFJpTWpScFQybEplVTFFUlRWTVZFRjVURlJGTkZaRVFUTlBhazAxVDJ 445 wQmVreHFRWGROUm05cFRFTktkV0l5TldwYVUwazJTV3BWTTA1RVNUSlB 446 WR2N3VFdwSk1rOUVRVEJPZWtscFpsZ3dJaXdpYzJsbmJtRjBkWEpsY3l 447 JNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2FHSkhZMmxQYVVwR1ZYcEp 448 NVTVwU1hOSmJtY3hXWGxKTmxkNVNrNVRWV3hEVFcxd1JGRXdSbHBSTW1 449 SQ1pEQnNRMUZYWkVwU01FWllXbGRrYTFreFRrMVVWVVoyVWpCT1JHTlZ 450 aRlJVVkZFMVVXdEdUbEV3TVVWTlNHaEVaV3RHUzFGdFpFOVdhMHBDVjF 451 aU1FtRXdXbE5VVmtwV1pEQldNMWRWVWxkVlZrWk1Va1ZHTkZNeVJsaE9 452 WelZVWWxkNE1WZHFRazlrYlU1MVVWaG9SMlZyUmxkUmJXUlBWbXRLUWx 453 SVk1VVmhNMEozV1cweGExTXlSbGhPVnpWWFVqRmFObHBGVms5UmF6RkV 454 VVlpvUlZaRlZUQlVWbEpLWlVVeGNWRlljRTVoYldONFZGWmFkbGRWVWp 455 aaGVsWlFWa2QwTkZSWGNFNWxSVEZ4VkZSR1VGWkdWVEZXTW5CRFZUQXh 456 VbU16WkVSVlZteEZWbXhHVWxJd1ZqTlRhMHBXVmtWV1YxUlZTazVTTUV 457 WNFZsVldSRm96WkU1Vk1qRnpaRlp2ZDJOSVFtbGlWMUpGV1dwT1MyUXd 458 NVk5VV0dSR1ZWWnNSVlpzUmxKU2ExWXpZak5rVGxaRmJEWlVhMUpXVFd 459 zMU5scDZWazVWYlU0elVteEdXbEpHV2xKVlZWSkZVVlJXVEZsV1l6Rml 460 iRTUwWWtoV1lVMUdTbk5hUnpGellXeHdWVkZzY0U1UmF6RklVVzVzZUZ 461 JeFRrNU9SR3hDV2pCV1NGRXdUbmhTTVU1T1RrUnNRbVF3VmtsUlZFSkt 462 VVlZLVGxaclpFaFBSbTh4WTBkd2JVNVhjRmxpYm14NVZsaEtXV1ZXYjN 463 oaE1VSnVZMVZLYkUwd05WbGtWRVpyVmtWR1JWcFRkSGxNTTFreVUyNXd 464 TbE5IZDNwT1ZGWktXakpPU1ZGNlRtaGxTRUp3V1c1R1MxUlRPV2xXTVV 465 wb1VsaHNjV05YVGtSVGJXOHdZV3R3Y21JelpFUmtWM0JYVmtWS1ZWUlZ 466 Uak5TTUU1VVl6QmtRbFZXUmtOYU0xVXhWVEJHYmxWWFdrVlJha1l3VjF 467 ab1QyRkZlRmxWYlhocVRURkdNVmw2U25OaVIwcFlWbTVXYW1WVVJuQmF 468 SVTB4WkZad1dWVlVXbEJXUmtWM1ZGaHdRbFpGU201VWJGcEpWVEZXUmx 469 KRlVrSlRNRXB1V2pOS1Exb3dWa2RSYkVacVVrVkdjVkZWT1VOYU1EVlh 470 VMFpGTkZGclJtMVBSVlpEVVZVeFJGRnFVa0prTUU1dVYxVnNUR0l4Y0V 471 wbGJXOTNVbFZHTTFOVlVsUlJWVVl6Vld4R1Nsb3haREJWU0hCS1UxWm9 472 XazF0YkRSVmJHaExaRVZXTkZNd1ZtOWhSbkJyV1ZSU1dVc3dWbmRpUm5 473 CMllsVldTazF1Y0VKTlIxSjZZVzA1UkZOV1JrUk5NSEIzVlZjeFUxZEZ 474 NVWhpYVRsM1RrVktNVTlYYkRaaFYyczFUVzFXYW1KR1VqUk9RemxRVGt 475 oS2MySlVaRTVsVlhoNFlUSm9hMUZVTURsSmJERTVJaXdpYzJsbmJtRjB 476 kWEpsSWpvaWVGVlNXbTFqVjFOR1lVSkVNbU5PYTNJek4yRjZWRGx2YzF 477 kbWVsUmFYM1psUTNOV2FHOHpabmRrUkRaT1VqUm5hRXcyTVZaS2JWbGZ 478 jbUV3WVRReVUzWnZWekpVZFRSWWJHeGtlbnBFT0ZaRWRFTkRSR2NpZlY 479 xOSIsImNyZWF0ZWQtb24iOiIyMDIyLTAzLTAyVDAzOjAxOjI0LjQ2Nlo 480 ifX0", 481 "signatures":[ 482 { 483 "protected": 484 "eyJ4NWMiOlsiTUlJQm96Q0NBVXFnQXdJQkFnSUdBVzBlTHVJRk1Bb0d 485 DQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzN 486 NeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkR 487 RVEFlRncweE9UQTVNVEV3TWpNM016SmFGdzB5T1RBNU1URXdNak0zTXp 488 KYU1GUXhFekFSQmdOVkJBb01DazE1UW5WemFXNWxjM014RFRBTEJnTlZ 489 CQWNNQkZOcGRHVXhMakFzQmdOVkJBTU1KVkpsWjJsemRISmhjaUJXYjN 490 WamFHVnlJRkpsY1hWbGMzUWdVMmxuYm1sdVp5QkxaWGt3V1RBVEJnY3F 491 oa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ2eFZ2QXZxVHoxWlVpdU5 492 XaFhwUXNrYVB5N0FISFFMd1hpSjBpRUx0NnVOUGFuQU4wUW5XTVlPXC8 493 wQ0RFaklrQlFvYnc4WUtxanR4SkhWU0dUajlLT295Y3dKVEFUQmdOVkh 494 TVUVEREFLQmdnckJnRUZCUWNESERBT0JnTlZIUThCQWY4RUJBTUNCNEF 495 3Q2dZSUtvWkl6ajBFQXdJRFJ3QXdSQUlnWXIyTGZxb2FDS0RGNFJBY01 496 tSmkrTkNacWRTaXVWdWdJU0E3T2hLUnEzWUNJRHhuUE1NbnBYQU1UclB 497 KdVBXeWNlRVIxMVB4SE9uKzBDcFNIaTJxZ3BXWCIsIk1JSUJwRENDQVV 498 tZ0F3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJ 499 CZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEd 500 VeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHhPVEE1TVRFd01qTTN 501 NekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXpBUkJnTlZCQW9NQ2s 502 xNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZ 503 CQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXd 504 FSEEwSUFCT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc 505 1d3VLUURqaWV4MDZcL1NjWTVQSmlidmdIVEIrRlwvUVRqZ2VsSEd5MVl 506 LcHdjTk1jc1N5YWpSVEJETUJJR0ExVWRFd0VCXC93UUlNQVlCQWY4Q0F 507 RRXdEZ1lEVlIwUEFRSFwvQkFRREFnSUVNQjBHQTFVZERnUVdCQlRvWkl 508 NelFkc0RcL2pcLytnWFwvN2NCSnVjSFwvWG1qQUtCZ2dxaGtqT1BRUUR 509 BZ05KQURCR0FpRUF0eFEzK0lMR0JQSXRTaDRiOVdYaFhOdWhxU1A2SCt 510 iXC9MQ1wvZlZZRGpRNm9DSVFERzJ1UkNIbFZxM3loQjU4VFhNVWJ6SDg 511 rT2xoV1V2T2xSRDNWRXFEZGNRdz09Il0sImFsZyI6IkVTMjU2In0", 512 "signature": 513 "zvtnaEDpOqL49XnYVRbLxVAaZCMRtDiaLqMeFSH3UsjHdz4FT0lFywV 514 7-5inMpafXTnqqxnD2Gpr3ClUXUyAJg" 515 } 516 ] 517 } 519 Figure 3: Example Parboiled Registrar Voucher Request - RVR 521 A.3. Example Voucher Response (from MASA to Pledge, via Registrar) 523 The following is an example voucher response from MASA to Pledge via 524 Registrar, in "General JWS JSON Serialization". 526 { 527 "payload": 528 "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJsb2 529 dnZWQiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlI 530 joiNTc0MjY5ODQyMjY4MDQ3MiIsImNyZWF0ZWQtb24iOiIyMDIyLTAz 531 LTAyVDAzOjAxOjI0LjYxOFoiLCJwaW5uZWQtZG9tYWluLWNlcnQiOiJ 532 NSUlCcERDQ0FVbWdBd0lCQWdJR0FXMGVMdUgrTUFvR0NDcUdTTTQ5Qk 533 FNQ01EVXhFekFSQmdOVkJBb01DazE1UW5WemFXNWxjM014RFRBTEJnT 534 lZCQWNNQkZOcGRHVXhEekFOQmdOVkJBTU1CbFJsYzNSRFFUQWVGdzB4 535 T1RBNU1URXdNak0zTXpKYUZ3MHlPVEE1TVRFd01qTTNNekphTURVeEV 536 6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk 537 5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRCWk1CTUdCeXFHU000O 538 UFnRUdDQ3FHU000OUF3RUhBMElBQk9rdmtUSHU4UWxUM0ZISjFVYUk3 539 K1dzSE9iMFVTM1NBTHRHNXd1S1FEamlleDA2L1NjWTVQSmlidmdIVEI 540 rRi9RVGpnZWxIR3kxWUtwd2NOTWNzU3lhalJUQkRNQklHQTFVZEV3RU 541 Ivd1FJTUFZQkFmOENBUUV3RGdZRFZSMFBBUUgvQkFRREFnSUVNQjBHQ 542 TFVZERnUVdCQlRvWklNelFkc0Qvai8rZ1gvN2NCSnVjSC9YbWpBS0Jn 543 Z3Foa2pPUFFRREFnTkpBREJHQWlFQXR4UTMrSUxHQlBJdFNoNGI5V1h 544 oWE51aHFTUDZIK2IvTEMvZlZZRGpRNm9DSVFERzJ1UkNIbFZxM3loQj 545 U4VFhNVWJ6SDgrT2xoV1V2T2xSRDNWRXFEZGNRdz09In19", 546 "signatures": [ 547 { 548 "protected": 549 "eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1B 550 b0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd 551 1lEVlFRS0RBeEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRG 552 twcGJtZEthVzVuVkdWemRFTkJNQjRYRFRFNE1ERXlPVEV3TlRJME1 553 Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTFVRUJoTUNR 554 VkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQ 555 TFVRUF3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbm 556 JtbHVaeUJMWlhrd1dUQVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJ 557 Cd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFIwWlcrNGIxR1d5ZG1X 558 czJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0dCS 559 Eh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QX 560 dDZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh 561 4XC90elVvUVwvU3N5ZEwzMERRSU5FdGNOOW1DVFhQQWlFQXZJYjNv 562 K0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2FFS2JzVkRpV 563 T0iXSwiYWxnIjoiRVMyNTYifQ", 564 "signature": 565 "vyge3GENm1BNcijXT5VH7A8CJWW7wPzH61u2VCfR8E9v8H8Yr3g9 566 irYz4q5sYj2UnOVIh-hG_ogrZR0Tct_Vzw" 567 } 568 ] 569 } 571 Figure 4: Example Voucher Response 573 Authors' Addresses 575 Michael Richardson 576 Sandelman Software Works 577 Email: mcr+ietf@sandelman.ca 579 Thomas Werner 580 Siemens AG 581 Email: thomas-werner@siemens.com