idnits 2.17.1 draft-ietf-acme-authority-token-tnauthlist-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 04, 2019) is 1606 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) == Unused Reference: 'ATIS-1000074' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC8588' is defined on line 583, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-acme-authority-token-03 == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-00 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational RFC: RFC 7340 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Wendt 3 Internet-Draft D. Hancock 4 Intended status: Standards Track Comcast 5 Expires: May 7, 2020 M. Barnes 6 Independent 7 J. Peterson 8 Neustar Inc. 9 November 04, 2019 11 TNAuthList profile of ACME Authority Token 12 draft-ietf-acme-authority-token-tnauthlist-05 14 Abstract 16 This document defines a profile of the Automated Certificate 17 Management Environment (ACME) Authority Token for the automated and 18 authorized creation of certificates for VoIP Telephone Providers to 19 support Secure Telephony Identity (STI) using the TNAuthList defined 20 by STI certificates. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. ACME new-order identifiers for TNAuthList . . . . . . . . . . 3 59 4. TNAuthList Identifier Authorization . . . . . . . . . . . . . 5 60 5. TNAuthList Authority Token . . . . . . . . . . . . . . . . . 7 61 5.1. "iss" claim . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.2. "exp" claim . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. "jti" claim . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.4. "atc" claim . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.5. Acquiring the token from the Token Authority . . . . . . 9 66 5.6. Token Authority Responsibilities . . . . . . . . . . . . 10 67 5.7. Scope of the TNAuthList token authority . . . . . . . . . 10 68 6. Validating the TNAuthList Authority Token . . . . . . . . . . 10 69 7. Usage Considerations . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Large number of Non-contiguous TNAuthList values . . . . 11 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 [RFC8555] is a mechanism for automating certificate management on the 82 Internet. It enables administrative entities to prove effective 83 control over resources like domain names, and automates the process 84 of generating and issuing certificates. 85 [I-D.ietf-acme-authority-token] extends ACME to provide a general 86 method of extending the authority and authorization of entities to 87 control a resource via a third party Token Authority beyond the 88 Certification Authority. 90 This document addresses the STIR problem statement [RFC7340] which 91 identifies the need for Internet credentials that can attest 92 authority for the originator of VoIP calls in order to detect 93 impersonation, which is currently an enabler for common attacks 94 associated with illegal robocalling, voicemail hacking, and swatting. 95 These credentials are used to sign PASSporTs [RFC8225], which can be 96 carried in using protocols such as SIP [RFC8224]. Currently, the 97 only defined credentials for this purpose are the certificates 98 specified in [RFC8226]. 100 [RFC8226] describes certificate extensions suitable for associating 101 telephone numbers and service provider codes with certificates. 102 Specifically, the TN Authorization List defined in [RFC8226] 103 Section 9, defines the ability to associate a STI certificate with a 104 specific set of Service Provider Codes (SPCs), Telephone Numbers 105 (TNs), or Telephone Number ranges (TN ranges). Typically, these 106 identifiers have been assigned to a Communications Service Provider 107 (CSP) that is authorized to use a set of telephone numbers or 108 telephone number ranges in association with a Service Provider Code 109 as defined in [RFC8226]. The SPC is a unique code or string managed 110 by a national regulatory body that has the authority over those code- 111 to-CSP associations. 113 This document will also incorporate the ability for a telephone 114 authority to authorize the creation of CA types of certificates for 115 delegation as defined in [I-D.ietf-stir-cert-delegation]. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. ACME new-order identifiers for TNAuthList 125 In [RFC8555], Section 7.4 defines the procedure that an ACME client 126 uses to order a new certificate from a Certification Authority. The 127 new-order request contains an identifier field that specifies the 128 identifier objects the order corresponds to. This draft defines a 129 new type of identifier object called TNAuthList. A TNAuthList 130 identifier contains the identity information to be populated in the 131 TN Authorization List of the new certificate. For the TNAuthList 132 identifier, the new-order request MUST include a type set to the 133 string "TNAuthList". The value of the TNAuthList identifier MUST be 134 set to the details of the TNAuthList requested. 136 The format of the string that represents the TNAuthList MUST be 137 constructed as a base64 [RFC4648] encoding of the TN Authorization 138 List certificate extension ASN.1 object. The TN Authorization List 139 certificate extension ASN.1 syntax is defined in [RFC8226] section 9. 141 An example of an ACME order object "identifiers" field containing a 142 TNAuthList certificate would look as follows, 144 "identifiers": [{"type":"TNAuthList","value":"F83n2a...avn27DN3=="}] 146 where the "value" object string represents the arbitrary length 147 base64 encoded string. 149 A full new-order request would look as follows, 151 POST /acme/new-order HTTP/1.1 152 Host: example.com 153 Content-Type: application/jose+json 155 { 156 "protected": base64url({ 157 "alg": "ES256", 158 "kid": "https://example.com/acme/acct/1", 159 "nonce": "5XJ1L3lEkMG7tR6pA00clA", 160 "url": "https://example.com/acme/new-order" 161 }), 162 "payload": base64url({ 163 "identifiers": [{"type:"TNAuthList","value":"F83n2a...avn27DN3=="}], 164 "notBefore": "2016-01-01T00:00:00Z", 165 "notAfter": "2016-01-08T00:00:00Z" 166 }), 167 "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g" 168 } 170 On receiving a valid new-order request, the CA creates an 171 authorization object containing the challenge that the ACME client 172 must satisfy to demonstrate authority for the identifiers specified 173 by the new order (in this case, the TNAuthList identifier). The CA 174 adds the authorization object URL to the "authorizations" field of 175 the order object, and returns the order object to the ACME client in 176 the body of a 201 (Created) response. 178 HTTP/1.1 201 Created 179 Replay-Nonce: MYAuvOpaoIiywTezizk5vw 180 Location: https://example.com/acme/order/1234 182 { 183 "status": "pending", 184 "expires": "2015-03-01T14:09:00Z", 186 "notBefore": "2016-01-01T00:00:00Z", 187 "notAfter": "2016-01-08T00:00:00Z", 188 "identifiers":[{"type:"TNAuthList", 189 "value":"F83n2a...avn27DN3=="}], 191 "authorizations": [ 192 "https://example.com/acme/authz/1234" 193 ], 194 "finalize": "https://example.com/acme/order/1234/finalize" 195 } 197 4. TNAuthList Identifier Authorization 199 On receiving the new-order response, the ACME client queries the 200 referenced authorization object to obtain the challenges for the 201 identifier contained in the new-order request as shown in the 202 following example request and response. 204 POST /acme/authz/1234 HTTP/1.1 205 Host: example.com 206 Content-Type: application/jose+json 208 { 209 "protected": base64url({ 210 "alg": "ES256", 211 "kid": " https://example.com/acme/acct/1", 212 "nonce": "uQpSjlRb4vQVCjVYAyyUWg", 213 "url": "https://example.com/acme/authz/1234", 214 }), 215 "payload": "", 216 "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps" 217 } 219 HTTP/1.1 200 OK 220 Content-Type: application/json 221 Link: ;rel="index" 223 { 224 "status": "pending", 225 "expires": "2018-03-03T14:09:00Z", 227 "identifier": { 228 "type:"TNAuthList", 229 "value":"F83n2a...avn27DN3==" 230 }, 232 "challenges": [ 233 { 234 "type": "tkauth-01", 235 "tkauth-type": "atc", 236 "token-authority": "https://authority.example.org/authz", 237 "url": "https://boulder.example.com/authz/asdf/0" 238 "token": "IlirfxKKXAsHtmzK29Pj8A" 239 } 240 ] 241 } 243 When processing a certificate order containing an identifier of type 244 "TNAuthList", a CA MUST use the Authority Token challenge mechanism 245 defined in [I-D.ietf-acme-authority-token] to verify that the 246 requesting ACME client has authenticated and authorized control over 247 the requested resources represented by the "TNAuthList" value. 249 The challenge "token-authority" parameter is optional and only used 250 in cases where the VoIP telephone network requires the CA to identify 251 the Token Authority. This is currently not the case for the SHAKEN 252 [ATIS-1000080] certificate framework governance, but may be used by 253 other frameworks. If a "token-authority" parameter is present, then 254 the ACME client MAY use the "token-authority" value to identify the 255 URL representing the Token Authority that will provide the TNAuthList 256 Authority Token response to the challenge. If the "token-authority" 257 parameter is not present, then the ACME client MUST identify the 258 Token Authority based on locally configured information or local 259 policies. 261 The ACME client MUST respond to the challenge by posting the 262 TNAuthList Authority Token to the challenge URL identified in the 263 returned ACME authorization object, an example of which follows. 265 POST /acme/authz/asdf/0 HTTP/1.1 266 Host: boulder.example.com 267 Content-Type: application/jose+json 269 { 270 "protected": base64url({ 271 "alg": "ES256", 272 "kid": "https://example.com/acme/acct/1", 273 "nonce": "Q_s3MWoqT05TrdkM2MTDcw", 274 "url": "https://boulder.example.com/acme/authz/asdf/0" 275 }), 276 "payload": base64url({ 277 "atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE" 278 }), 279 "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" 280 } 282 The specifics of the construction of the TNAuthList specific "atc" 283 token is defined in the next section. 285 5. TNAuthList Authority Token 287 The Telephone Number Authority List Authority Token (TNAuthList 288 Authority Token) is an extension of the ACME Authority Token defined 289 in [I-D.ietf-acme-authority-token]. 291 The TNAuthList Authority Token Protected header MUST comply with the 292 Authority Token Protected header as defined in 293 [I-D.ietf-acme-authority-token]. 295 The TNAuthList Authority Token Payload MUST include the mandatory 296 claims and MAY include the optional claims defined for the Authority 297 Token detailed in the next subsections. 299 5.1. "iss" claim 301 The "iss" claim is an optional claim. It can be used as a URL 302 identifying the Token Authority that issued the TNAuthList Authority 303 Token beyond the "x5u" Header claim that identifies the location of 304 the certificate of the Token Authority used to validate the 305 TNAuthList Authority Token. 307 5.2. "exp" claim 309 The "exp" claim contains the DateTime value of the ending date and 310 time that the TNAuthList Authority Token expires. 312 5.3. "jti" claim 314 The "jti" claim contains a unique identifier for this TNAuthList 315 Authority Token transaction. 317 5.4. "atc" claim 319 The "atc" claim is the only claim specifically defined in this 320 document. It contains a JSON object of three elements. 322 o a "tktype" key that is required with a string value equal to 323 "TNAuthList" to represent a TNAuthList profile of the authority 324 token [I-D.ietf-acme-authority-token] defined by this document. 326 o a "tkvalue" key with a string value equal to the TNAuthList 327 identifier "value" string which MUST contain the base64 encoding 328 of the TN Authorization List certificate extension ASN.1 object. 329 "tkvalue" is a required key and MUST be included. 331 o a "ca" key with a boolean value set to either true when the 332 requested certificate is allowed to be a CA cert for delegation 333 uses or false when the requested certificate MUST NOT be a CA cert 334 and only an end-entity certificate. "ca" is an optional key, if it 335 not included the "ca" value is considered false by default. 337 o a "fingerprint" key with a fingerprint value equal to the 338 fingerprint, as defined in [RFC4949], of the ACME account 339 credentials. Specifically, the fingerprint value is a secure one- 340 way hash of the Distinguished Encoding Rules (DER) form of the 341 public key corresponding to the key pair the SP used to create the 342 account with the ACME server. The fingerprint value consists of 343 the name of the hash function, which shall be 'SHA256' for this 344 specification, followed by the hash value itself. The hash value 345 is represented as a sequence of uppercase hexadecimal bytes, 346 separated by colons. The number of bytes is defined by the hash 347 function. "fingerprint" is a required key and MUST be included. 349 An example of the TNAuthList Authority Token is as follows, 350 { "typ":"JWT", 351 "alg":"ES256", 352 "x5u":https://authority.example.org/cert 353 } 355 { "iss":"https://authority.example.org/authz", 356 "exp":1300819380, 357 "jti":"id6098364921", 358 "atc":{"tktype":"TNAuthList", 359 "tkvalue":"F83n2a...avn27DN3==", 360 "ca":false, 361 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71: 362 D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} 363 } 365 5.5. Acquiring the token from the Token Authority 367 Following [I-D.ietf-acme-authority-token] Section 5, the authority 368 token should be acquired using a RESTful HTTP POST transaction as 369 follows 371 POST /at/account/:id/token HTTP/1.1 372 Host: authority.example.com 373 Content-Type: application/json 375 The request will pass the account id as a string in the request 376 parameter "id". This string will be managed as an identifier 377 specific to the authorities relationship with a CSP. There is 378 assumed to also be a corresponding authentication procedure that can 379 be verified for the success of this transaction. For example, an 380 HTTP authorization header containing a valid authorization 381 credentials as defined in [RFC2616] Section 14.8. 383 The body of the POST request MUST contain the "atc" JSON object that 384 should be embedded in the token that is requested, for example the 385 body should contain a JSON object as shown: 387 { 388 "atc":{"tktype":"TNAuthList", 389 "tkvalue":"F83n2a...avn27DN3==", 390 "ca":false, 391 "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3 \ 392 :BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} 393 } 395 The response to the POST request if successful MUST return a 200 OK 396 with a JSON body that contains the TNAuthList Authority Token as a 397 JSON object with a single key of "atc" and the base64 encoded string 398 representing the atc token. 400 An example successful response would be as follows: 402 HTTP/1.1 200 OK 403 Content-Type: application/json 405 {"atc": "DGyRejmCefe7v4N...vb29HhjjLPSggwiE"} 407 If the request is not successful, the response should indicate the 408 error condition. Specifically, for the case that the authorization 409 credentials are invalid, the response code MUST be 403 - Forbidden. 410 If the Account ID provided does not exist or does not match 411 credentials in Authorization header, the response MUST be 404 - 412 Invalid account ID. Other 4xx and 5xx responses SHOULD follow 413 standard [RFC2616] HTTP error condition conventions. 415 5.6. Token Authority Responsibilities 417 When the Token Authority creates the TNAuthList Authority Token, it 418 is the responsibility of the Token Authority to validate that the 419 information contained in the ASN.1 TNAuthList accurately represents 420 the SPC or telephone number resources the ACME client is authorized 421 to represent. 423 5.7. Scope of the TNAuthList token authority 425 Because this specification specifically involves the TNAuthList 426 defined in [RFC8226] which involves SPC, TNBlock, and individual TNs, 427 the client may also request an Authority Token with some subset of 428 its own authority the TNAuthList provided in the "tkvalue" element in 429 the "atc" JSON object. Generally, the scope of authority of 430 telephone numbers is that a communications service provider which is 431 represented by a particular SPC (e.g. OCN or SPID) is associated 432 with a particular set of different TN Blocks and/or TNs, although 433 more often the former. TNAuthList can be constructed to define a 434 limited scope of the TNBlocks or TNs either associated with an SPC or 435 with the scope of TN Blocks or TNs the client has authority over. 437 6. Validating the TNAuthList Authority Token 439 Upon receiving a response to the challenge, the ACME server MUST 440 perform the following steps to determine the validity of the 441 response. 443 o Verify that the token contained in the Payload "atc" field is an 444 TNAuthList Authority Token. 446 o Verify the TNAuthList Authority Token signature using the public 447 key of the certificate referenced by the token's "x5u" parameter. 449 o Verify that "atc" claim contains an identifier type of 450 "TNAuthList", 452 o Verify that the "atc" claim contains the equivalent base64 encoded 453 TNAuthList certificate extension string value as the Identifier 454 specified in the original challenge. 456 o Verify that the remaining claims are valid (e.g., verify that 457 token has not expired) 459 o Verify that the "atc" claim "fingerprint" is valid 461 o Verify that the "ca" claim boolean corresponds to the CSR request 462 for either CA certificate or end-entity certificate 464 If all steps in the token validation process pass, then the CA MUST 465 set the challenge object "status" to "valid". If any step of the 466 validation process fails, the "status" in the challenge object MUST 467 be set to "invalid". 469 7. Usage Considerations 471 7.1. Large number of Non-contiguous TNAuthList values 473 There are many scenarios and reasons to have various combinations of 474 SPCs, TNs, and TN Ranges. [RFC8226] has provided a somewhat 475 unbounded set of combinations. It's possible that a complex non- 476 contiguous set of telephone numbers are being managed by a CSP. Best 477 practice may be simply to split a set of non-contiguous numbers under 478 management into multiple STI certificates to represent the various 479 contiguous parts of the greater non-contiguous set of TNs, 480 particularly if length of the set of values in identifier object 481 grows to be too large. 483 8. Security Considerations 485 The token represented by this document obviously has the credentials 486 to represent the scope of a telephone number, a block of telephone 487 numbers, or an entire set of telephone numbers represented by a SPC. 488 The creation, transport, and any storage of this token MUST follow 489 the strictest of security best practices beyond the recommendations 490 of the use of encrypted transport protocols in this document to 491 protect it from getting in the hands of bad actors with illegitimate 492 intent to impersonate telephone numbers. 494 9. IANA Considerations 496 This document requests the addition of a new identifier object type 497 that can be present in the identifier field of the ACME authorization 498 object defined in [RFC8555]. 500 +------------+-----------+ 501 | Label | Reference | 502 +------------+-----------+ 503 | TNAuthList | RFCThis | 504 +------------+-----------+ 506 10. Acknowledgements 508 We would like to thank Richard Barnes and Russ Housley for valuable 509 contributions to this document. 511 11. References 513 11.1. Normative References 515 [I-D.ietf-acme-authority-token] 516 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 517 Challenges Using an Authority Token", draft-ietf-acme- 518 authority-token-03 (work in progress), March 2019. 520 [I-D.ietf-stir-cert-delegation] 521 Peterson, J., "STIR Certificate Delegation", draft-ietf- 522 stir-cert-delegation-00 (work in progress), July 2019. 524 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 525 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 526 Transfer Protocol -- HTTP/1.1", RFC 2616, 527 DOI 10.17487/RFC2616, June 1999, 528 . 530 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 531 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 532 . 534 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 535 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 536 . 538 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 539 Telephone Identity Problem Statement and Requirements", 540 RFC 7340, DOI 10.17487/RFC7340, September 2014, 541 . 543 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 544 "Authenticated Identity Management in the Session 545 Initiation Protocol (SIP)", RFC 8224, 546 DOI 10.17487/RFC8224, February 2018, 547 . 549 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 550 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 551 . 553 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 554 Credentials: Certificates", RFC 8226, 555 DOI 10.17487/RFC8226, February 2018, 556 . 558 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 559 Kasten, "Automatic Certificate Management Environment 560 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 561 . 563 11.2. Informative References 565 [ATIS-1000074] 566 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 567 of Asserted information using toKENs (SHAKEN) 568 ", January 2017. 571 [ATIS-1000080] 572 ATIS/SIP Forum NNI Task Group, "Signature-based Handling 573 of Asserted information using toKENs (SHAKEN) Governance 574 Model and Certificate Management 575 ", July 2017. 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, 580 DOI 10.17487/RFC2119, March 1997, 581 . 583 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 584 (PaSSporT) Extension for Signature-based Handling of 585 Asserted information using toKENs (SHAKEN)", RFC 8588, 586 DOI 10.17487/RFC8588, May 2019, 587 . 589 Authors' Addresses 591 Chris Wendt 592 Comcast 593 One Comcast Center 594 Philadelphia, PA 19103 595 USA 597 Email: chris-ietf@chriswendt.net 599 David Hancock 600 Comcast 602 Email: davidhancock.ietf@gmail.com 604 Mary Barnes 605 Independent 607 Email: mary.ietf.barnes@gmail.com 609 Jon Peterson 610 Neustar Inc. 611 1800 Sutter St Suite 570 612 Concord, CA 94520 613 US 615 Email: jon.peterson@neustar.biz