idnits 2.17.1 draft-ietf-stir-certificates-14.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 (May 9, 2017) is 2543 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) -- Looks like a reference, but probably isn't: '0' on line 909 -- Looks like a reference, but probably isn't: '1' on line 910 -- Looks like a reference, but probably isn't: '2' on line 911 -- Possible downref: Non-RFC (?) normative reference: ref. 'ATIS-0300251' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSS' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR J. Peterson 3 Internet-Draft Neustar 4 Intended status: Standards Track S. Turner 5 Expires: November 10, 2017 sn3rd 6 May 9, 2017 8 Secure Telephone Identity Credentials: Certificates 9 draft-ietf-stir-certificates-14 11 Abstract 13 In order to prevent the impersonation of telephone numbers on the 14 Internet, some kind of credential system needs to exist that 15 cryptographically asserts authority over telephone numbers. This 16 document describes the use of certificates in establishing authority 17 over telephone numbers, as a component of a broader architecture for 18 managing telephone numbers as identities in protocols like SIP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 10, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Authority for Telephone Numbers in Certificates . . . . . . . 3 57 4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5 58 5. Enrollment and Authorization using the TN Authorization List 6 59 5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 7 60 5.2. Certificate Extension Scope and Structure . . . . . . . . 8 61 6. Provisioning Private Keying Material . . . . . . . . . . . . 8 62 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9 63 8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10 64 9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11 65 10. Certificate Freshness and Revocation . . . . . . . . . . . . 13 66 10.1. Acquiring TN Lists By Reference . . . . . . . . . . . . 14 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 70 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 72 14.2. Informative References . . . . . . . . . . . . . . . . . 17 73 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 The STIR problem statement [RFC7340] identifies the primary enabler 79 of robocalling, vishing, swatting and related attacks as the 80 capability to impersonate a calling party number. The starkest 81 examples of these attacks are cases where automated callees on the 82 PSTN rely on the calling number as a security measure, for example to 83 access a voicemail system. Robocallers use impersonation as a means 84 of obscuring identity; while robocallers can, in the ordinary PSTN, 85 block (that is, withhold) their caller identity, callees are less 86 likely to pick up calls from blocked identities, and therefore 87 appearing to call from some number, any number, is preferable. 88 Robocallers however prefer not to call from a number that can trace 89 back to the robocaller, and therefore they impersonate numbers that 90 are not assigned to them. 92 One of the most important components of a system to prevent 93 impersonation is the implementation of credentials which identify the 94 parties who control telephone numbers. With these credentials, 95 parties can assert that they are in fact authorized to use telephony 96 numbers, and thus distinguish themselves from impersonators unable to 97 present such credentials. For that reason the STIR threat model 98 [RFC7375] stipulates, "The design of the credential system envisioned 99 as a solution to these threats must, for example, limit the scope of 100 the credentials issued to carriers or national authorities to those 101 numbers that fall under their purview." This document describes 102 credential systems for telephone numbers based on [X.509] version 3 103 certificates in accordance with [RFC5280]. While telephone numbers 104 have long been part of the X.509 standard (X.509 supports arbitrary 105 naming attributes to be included in a certificate; the 106 telephoneNumber attribute was defined in the 1988 [X.520] 107 specification) this document provides ways to determine authority 108 more aligned with telephone network requirements, including extending 109 X.509 with a Telephone Number Authorization List certificate 110 extension which binds certificates to asserted authority for 111 particular telephone numbers, or potentially telephone number blocks 112 or ranges. 114 In the STIR in-band architecture specified in 115 [I-D.ietf-stir-rfc4474bis], two basic types of entities need access 116 to these credentials: authentication services, and verification 117 services (or verifiers). An authentication service must be operated 118 by an entity enrolled with the certification authority (CA, see 119 Section 5), whereas a verifier need only trust the trust anchor of 120 the authority, and have a means to access and validate the public 121 keys associated with these certificates. Although the guidance in 122 this document is written with the STIR in-band architecture in mind, 123 the credential system described in this document could be useful for 124 other protocols that want to make use of certificates to assert 125 authority over telephone numbers on the Internet. 127 This document specifies only the credential syntax and semantics 128 necessary to support this architecture. It does not assume any 129 particular CA or deployment environment. We anticipate that some 130 deployment experience will be necessary to determine optimal 131 operational models. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in RFC 138 2119 [RFC2119]. 140 3. Authority for Telephone Numbers in Certificates 142 At a high level, this specification details two non-exclusive 143 approaches that can be employed to determine authority over telephone 144 numbers with certificates. 146 The first approach is to leverage the existing subject of the 147 certificate to ascertain that the holder of the certificate is 148 authorized to claim authority over a telephone number. The subject 149 might be represented as a domain name in the subjectAltName, such as 150 an "example.net" where that domain is known to relying parties as a 151 carrier, or represented with other identifiers related to the 152 operation of the telephone network including Service Provider codes 153 (SPCs) such as OCNs or SPIDs via the TN Authorization List specified 154 in this document. A relying party could then employ an external data 155 set or service that determines whether or not a specific telephone 156 number is under the authority of the carrier identified as the 157 subject of the certificate, and use that to ascertain whether or not 158 the carrier should have authority over a telephone number. 159 Potentially, a certificate extension to convey the URI of such an 160 information service trusted by the issuer of the certificate could be 161 developed (though this specification does not propose one). 162 Alternatively, some relying parties could form bilateral or 163 multilateral trust relationships with peer carriers, trusting one 164 another's assertions just as telephone carriers in the SS7 network 165 today rely on transitive trust when displaying the calling party 166 telephone number received through SS7 signaling. 168 The second approach is to extend the syntax of certificates to 169 include a new attribute, defined here as TN Authorization List, which 170 contains a list of telephone numbers defining the scope of authority 171 of the certificate. Relying parties, if they trust the issuer of the 172 certificate as a source of authoritative information on telephone 173 numbers, could therefore use the TN Authorization List instead of the 174 subject of the certificate to make a decision about whether or not 175 the signer has authority over a particular telephone number. The TN 176 Authorization List could be provided in one of two ways: as a literal 177 value in the certificate, or as a network service that allows relying 178 parties to query in real time to determine that a telephone number is 179 in the scope of a certificate. Using the TN Authorization list 180 rather than the certificate subject makes sense when, for example, 181 for privacy reasons, the certificate owner would prefer not to be 182 identified, or in cases where the holder of the certificate does not 183 participate in the sort of traditional carrier infrastructure that 184 the first approach assumes. 186 The first approach requires little change to existing Public Key 187 Infrastructure (PKI) certificates; for the second approach, we must 188 define an appropriate enrollment and authorization process. For the 189 purposes of STIR, the over-the-wire format specified in 190 [I-D.ietf-stir-rfc4474bis] accommodates either of these approaches: 191 the methods for canonicalizing, signing, for identifying and 192 accessing the certificate and so on remain the same; it is only the 193 verifier behavior and authorization decision that will change 194 depending on the approach to telephone number authority taken by the 195 certificate. For that reason, the two approaches are not mutually 196 exclusive, and in fact a certificate issued to a traditional 197 telephone network service provider could contain a TN Authorization 198 List or not, were it supported by the CA issuing the credential. 199 Regardless of which approach is used, certificates that assert 200 authority over telephone numbers are subject to the ordinary 201 operational procedures that govern certificate use per [RFC5280]. 202 This means that verification services must be mindful of the need to 203 ensure that they trust the trust anchor that issued the certificate, 204 and that they have some means to determine the freshness of the 205 certificate (see Section 10). 207 4. Certificate Usage with STIR 209 [I-D.ietf-stir-rfc4474bis] Section 7.4 requires that all credential 210 systems used by STIR explain how they address the requirements 211 enumerated below. Certificates as described in this document address 212 the STIR requirements as follows: 214 1. The URI [RFC3986] schemes permitted in the SIP Identity header 215 "info" parameter, as well as any special procedures required to 216 dereference the URIs: while normative text is given below in 217 Section 7, this mechanism permits the HTTP [RFC7230], CID and SIP 218 URI schemes to appear in the "info" parameter. 220 2. Procedures required to extract keying material from the resources 221 designated by the URI: implementations perform no special 222 procedures beyond dereferencing the "info" URI. See Section 7. 224 3. Procedures used by the verification service to determine the 225 scope of the credential: this specification effectively proposes 226 two methods, as outlined in Section 3: one where the subject (or 227 more properly subjectAltName) of the certificate indicates the 228 scope of authority through a domain name, and relying parties 229 either trust the subject entirely or have some direct means of 230 determining whether or not a number falls under a subject's 231 authority; and another where an extension to the certificate as 232 described in Section 9 identifies the scope of authority of the 233 certificate. 235 4. The cryptographic algorithms required to validate the 236 credentials: for this specification, that means the signature 237 algorithms used to sign certificates. This specification 238 REQUIRES that implementations support both ECDSA with the P-256 239 curve (see [DSS]) and RSA PKCS#1 v1.5 (see [RFC3447] Section 8.2) 240 for certificate signatures. Implementers are advised that RS256 241 is mandated only as a transitional mechanism, due to its 242 widespread use in existing PKI, but we anticipate that this 243 mechanism will eventually be deprecated. 245 5. Finally, note that all certificates compliant with this 246 specification: 248 * MUST provide cryptographic keying material sufficient to 249 generate the ECDSA using P-256 and SHA-256 signatures 250 necessary to support the ES256 hashed signatures required by 251 PASSporT [I-D.ietf-stir-passport], which in turn follows JSON 252 Web Token (JWT) [RFC7519]. 254 * MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for 255 certificate signature verification. 257 This document also includes additional certificate-related 258 requirements: 260 o See Section 5.1 for requirements related to the certificate 261 policies extension. 263 o See Section 7 for requirements related to relying parties 264 acquiring credentials. 266 o See Section 10 and Section 10.1 for requirements related to 267 certificate freshness and the Authority Information Access (AIA) 268 certificate extension. 270 5. Enrollment and Authorization using the TN Authorization List 272 This document covers three models for enrollment when using the TN 273 Authorization List extension. 275 The first enrollment model is one where the CA acts in concert with 276 national numbering authorities to issue credentials to those parties 277 to whom numbers are assigned. In the United States, for example, 278 telephone number blocks are assigned to Local Exchange Carriers 279 (LECs) by the North American Numbering Plan Administrator (NANPA), 280 who is in turn directed by the national regulator. LECs may also 281 receive numbers in smaller allocations, through number pooling, or 282 via an individual assignment through number portability. LECs assign 283 numbers to customers, who may be private individuals or organizations 284 - and organizations take responsibility for assigning numbers within 285 their own enterprise. This model requires top-down adoption of the 286 model from regulators through to carriers. Assignees of E.164 287 numbering resources participating in this enrollment model should 288 take appropriate steps to establish trust anchors. 290 The second enrollment model is a bottom-up approach where a CA 291 requires that an entity prove control by means of some sort of test, 292 which, as with certification authorities for web PKI, might either be 293 automated or a manual administrative process. As an example of an 294 automated process, an authority might send a text message to a 295 telephone number containing a URL (which might be dereferenced by the 296 recipient) as a means of verifying that a user has control of 297 terminal corresponding to that number. Checks of this form are 298 frequently used in commercial systems today to validate telephone 299 numbers provided by users. This is comparable to existing enrollment 300 systems used by some certificate authorities for issuing S/MIME 301 credentials for email by verifying that the party applying for a 302 credential receives mail at the email address in question. 304 The third enrollment model is delegation: that is, the holder of a 305 certificate (assigned by either of the two methods above) might 306 delegate some or all of their authority to another party. In some 307 cases, multiple levels of delegation could occur: a LEC, for example, 308 might delegate authority to a customer organization for a block of 309 100 numbers used by an IP PBX, and the organization might in turn 310 delegate authority for a particular number to an individual employee. 311 This is analogous to delegation of organizational identities in 312 traditional hierarchical PKIs who use the name constraints extension 313 [RFC5280]; the root CA delegates names in sales to the sales 314 department CA, names in development to the development CA, etc. As 315 lengthy certificate delegation chains are brittle, however, and can 316 cause delays in the verification process, this document considers 317 optimizations to reduce the complexity of verification. 319 Future work might explore methods of partial delegation, where 320 certificate holders delegate only part of their authority. For 321 example, individual assignees may want to delegate to a service 322 authority for text messages associated with their telephone number, 323 but not for other functions. 325 5.1. Constraints on Signing PASSporTs 327 The public key in the certificate is used to validate the signature 328 on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions 329 specified in PASSporT [I-D.ietf-stir-passport]. This specification 330 supports constraints on the JWT claims, which allows the CA to grant 331 different permissions to certificate holders, for example those 332 enrolled from proof-of-possession versus delegation. A Certification 333 Policy and a Certification Practice Statement [RFC3647] are produced 334 as part of the normal PKI bootstrapping process, (i.e., the CP is 335 written first and then the CA says how it conforms to the CP in the 336 CPS). A CA that wishes to place constraints on the JWT claims MUST 337 include the JWT Claim Constraints certificate extension in issued 338 certificates. See Section 8 for information about the certificate 339 extension. 341 5.2. Certificate Extension Scope and Structure 343 This specification places no limits on the number of telephone 344 numbers that can be associated with any given certificate. Some 345 service providers may be assigned millions of numbers, and may wish 346 to have a single certificate that can be applied to signing for any 347 one of those numbers. Others may wish to compartmentalize authority 348 over subsets of the numbers they control. 350 Moreover, service providers may wish to have multiple certificates 351 with the same scope of authority. For example, a service provider 352 with several regional gateway systems may want each system to be 353 capable of signing for each of their numbers, but not want to have 354 each system share the same private key. 356 The set of telephone numbers for which a particular certificate is 357 valid is expressed in the certificate through a certificate 358 extension; the certificate's extensibility mechanism is defined in 359 [RFC5280] but the TN Authorization List extension is specified in 360 this document. 362 The subjects of certificates containing the TN Authorization List 363 extension are typically the administrative entities to whom numbers 364 are assigned or delegated. For example, a LEC might hold a 365 certificate for a range of telephone numbers. In some cases, the 366 organization or individual issued such a certificate may not want to 367 associate themselves with a certificate; for example, a private 368 individual with a certificate for a single telephone number might not 369 want to distribute that certificate publicly if every verifier 370 immediately knew their name. The certification authorities issuing 371 certificates with the TN Authorization List extensions may, in 372 accordance with their policies, obscure the identity of the subject, 373 though mechanisms for doing so are outside the scope of this 374 document. 376 6. Provisioning Private Keying Material 378 In order for authentication services to sign calls via the procedures 379 described in [I-D.ietf-stir-rfc4474bis], they must hold a private key 380 corresponding to a certificate with authority over the calling 381 number. [I-D.ietf-stir-rfc4474bis] does not require that any 382 particular entity in a SIP deployment architecture sign requests, 383 only that it be an entity with an appropriate private key; the 384 authentication service role may be instantiated by any entity in a 385 SIP network. For a certificate granting authority only over a 386 particular number which has been issued to an end user, for example, 387 an end user device might hold the private key and generate the 388 signature. In the case of a service provider with authority over 389 large blocks of numbers, an intermediary might hold the private key 390 and sign calls. 392 The specification RECOMMENDS distribution of private keys through 393 PKCS#8 objects signed by a trusted entity, for example through the 394 CMS package specified in [RFC5958]. 396 7. Acquiring Credentials to Verify Signatures 398 This specification documents multiple ways that a verifier can gain 399 access to the credentials needed to verify a request. As the 400 validity of certificates does not depend on the method of their 401 acquisition, there is no need to standardize any single mechanism for 402 this purpose. All entities that comply with 403 [I-D.ietf-stir-rfc4474bis] necessarily support SIP, and consequently 404 SIP itself can serve as a way to deliver certificates. 405 [I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the 406 Identity header which contains a URI for the credential used to 407 generate the Identity header; [I-D.ietf-stir-rfc4474bis] also 408 requires documents which define credential systems list the URI 409 schemes that may be present in the "info" parameter. For 410 implementations compliant with this specification, three URI schemes 411 are REQUIRED: the CID URI, the SIP URI, and the HTTP URI. 413 The simplest way for a verifier to acquire the certificate needed to 414 verify a signature is for the certificate be conveyed in a SIP 415 request along with the signature itself. In SIP, for example, a 416 certificate could be carried in a multipart MIME body [RFC2046], and 417 the URI in the Identity header "info" parameter could specify that 418 body with a CID URI [RFC2392]. However, in many environments this is 419 not feasible due to message size restrictions or lack of necessary 420 support for multipart MIME. 422 The Identity header "info" parameter in a SIP request may contain a 423 URI that the verifier dereferences. Implementations of this 424 specification are REQUIRED to support the use of SIP for this 425 function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and 426 HTTPS. 428 Note well that as an optimization, a verifier may have access to a 429 service, a cache or other local store that grants access to 430 certificates for a particular telephone number. However, there may 431 be multiple valid certificates that can sign a call setup request for 432 a telephone number, and as a consequence, there needs to be some 433 discriminator that the signer uses to identify their credentials. 435 The Identity header "info" parameter itself can serve as such a 436 discriminator, provided implementations use that parameter as a key 437 when accessing certificates from caches or other sources. 439 8. JWT Claim Constraints Syntax 441 Certificate subjects are limited to specific values for PASSporT 442 claims with the JWT Claim Constraints certificate extension; issuers 443 permit all claims by omitting the JWT Claim Constraints certificate 444 extension from the certificate's extension field [RFC5280]. The 445 extension is non-critical, applicable only to end-entity 446 certificates, and defined with ASN.1 [X.680][X.681][X.682][X.683] 447 later in this section. The syntax of the claims is given in 448 PASSporT; specifying new claims follows the procedures in 449 [I-D.ietf-stir-passport] (Section 8.3). 451 This certificate extension is optional, but if present, it constrains 452 the claims that authentication services may include in the PASSporT 453 objects they sign. Constraints are applied by issuers and enforced 454 by verifiers when validating PASSporT claims as follows: 456 1. mustInclude indicates claims that MUST appear in the PASSporT in 457 addition to iat, orig, and dest. The baseline claims of PASSporT 458 ("iat", "orig", and "dest") are considered to be permitted by 459 default and SHOULD NOT be included. If mustInclude is absent, 460 iat, orig, and dest MUST appear in the PASSporT. 462 2. permittedValues indicates that if the claim name is present, the 463 claim MUST contain one of the listed values. 465 Consider two examples with a PASSporT claim called "confidence" with 466 values "low", "medium", and "high": 468 o If a CA issues to an authentication service a certificate that 469 contains the mustInclude JWTClaimName "confidence", then an 470 authentication service MUST include the "confidence" claim in all 471 PASSporTs it generates; a verification service will treat as 472 invalid any PASSporT it receives with a PASSporT claim that does 473 not include the "confidence" claim. 475 o If a CA issues to an authentication service a certificate that 476 contains the permittedValues JWTClaimName "confidence" and a 477 permitted "high" value, then an authentication service will treat 478 as invalid any PASSporT it receives with a PASSporT claim that 479 does not include the "confidence" claim with a "high" value. 481 The JWT Claim Constraints certificate extension is identified by the 482 following object identifier (OID), which is defined under the id-pe 483 OID arc defined in [RFC5280] and managed by IANA (see Section 11): 485 id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 } 487 The JWT Claim Constraints certificate extension has the following 488 syntax: 490 JWTClaimConstraints ::= SEQUENCE { 491 mustInclude [0] JWTClaimNames OPTIONAL, 492 -- The listed claim names MUST appear in the PASSporT in addition 493 -- to iat, orig, and dest. If absent, iat, orig, and dest MUST 494 -- appear in the PASSporT. 495 permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } 496 -- If the claim name is present, the claim MUST contain one of 497 -- the listed values. 498 ( WITH COMPONENTS { ..., mustInclude PRESENT } | 499 WITH COMPONENTS { ..., permittedValues PRESENT } ) 501 JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF 502 JWTClaimPermittedValues 504 JWTClaimPermittedValues ::= SEQUENCE { 505 claim JWTClaimName, 506 permitted SEQUENCE SIZE (1..MAX) OF UTF8String } 508 JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName 510 JWTClaimName ::= IA5String 512 9. TN Authorization List Syntax 514 The subjects of certificates containing the TN Authorization List 515 extension are the administrative entities to whom numbers are 516 assigned or delegated. When a verifier is validating a caller's 517 identity, local policy always determines the circumstances under 518 which any particular subject may be trusted, but the purpose of the 519 TN Authorization List extension in particular is to allow a verifier 520 to ascertain when the CA has designated that the subject has 521 authority over a particular telephone number or number range. The 522 non critical Telephony Number (TN) Authorization List certificate 523 extension is included in the Certificate's extension field [RFC5280]. 524 The extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. 525 What follows is the syntax and semantics of the extension. 527 The subjects of certificates containing the TN Authorization List 528 extension are the administrative entities to whom numbers are 529 assigned or delegated. In an end entity certificate, TN 530 Authorization List indicates the TNs which the certificate has been 531 authorized. In a CA certificate, the TN Authorization List limits 532 the set of TNs for certification paths that include this certificate. 534 The Telephony Number (TN) Authorization List certificate extension is 535 identified by the following object identifier (OID), which is defined 536 under the id-pe OID arc defined in [RFC5280] and managed by IANA (see 537 Section 11): 539 id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } 541 The TN Authorization List certificate extension has the following 542 syntax: 544 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 546 TNEntry ::= CHOICE { 547 spc [0] ServiceProviderCode, 548 range [1] TelephoneNumberRange, 549 one [2] TelephoneNumber 550 } 552 ServiceProviderCode ::= IA5String 554 -- Service Provider Codes may be OCNs, various SPIDs, or other 555 -- SP identifiers from the telephone network 557 TelephoneNumberRange ::= SEQUENCE { 558 start TelephoneNumber, 559 count INTEGER (2..MAX) 560 } 562 TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*")) 564 The TN Authorization List certificate extension indicates the 565 authorized phone numbers for the call setup signer. It indicates one 566 or more blocks of telephone number entries that have been authorized 567 for use by the call setup signer. There are three ways to identify 568 the block: 570 1. Service Provider Codes as described in this document are a 571 generic term for the identifiers used to designate service 572 providers in the telepohone networks today. In North American 573 context, these would include Operating Company Numbers (OCNs) as 574 specified in [ATIS-0300251], related Service Provide Identifiers 575 (SPIDs), or other similar identifiers for service providers. 577 SPCs can be used to indirectly name all of the telephone numbers 578 associated with that identifier for a service provider, 580 2. Telephone numbers can be listed in a range (in the 581 TelephoneNumberRange format), which consists of a starting 582 telephone number and then an integer count of numbers within the 583 range, where the valid boundaries of ranges may vary according to 584 national policies, or 586 3. A single telephone number can be listed (as a TelephoneNumber). 588 Note that because large-scale service providers may want to associate 589 many numbers, possibly millions of numbers, with a particular 590 certificate, optimizations are required for those cases to prevent 591 certificate size from becoming unmanageable. In these cases, the TN 592 Authorization List may be given by reference rather than by value, 593 through the presence of a separate certificate extension that permits 594 verifiers to either securely download the list of numbers associated 595 with a certificate, or to verify that a single number is under the 596 authority of this certificate. For more on this optimization, see 597 Section 10.1. 599 10. Certificate Freshness and Revocation 601 Regardless of which of the approaches in Section 3 is followed for 602 using certificates, a certificate verification mechanism is required. 603 However, the traditional problem of certificate freshness gains a new 604 wrinkle when using the TN Authorization List extension with telephone 605 numbers or number ranges (as opposed to SPCs), because verifiers must 606 establish not only that a certificate remains valid, but also that 607 the certificate's scope contains the telephone number that the 608 verifier is validating. Dynamic changes to number assignments can 609 occur due to number portability, for example. So even if a verifier 610 has a valid cached certificate for a telephone number (or a range 611 containing the number), the verifier must determine that the entity 612 that signed is still a proper authority for that number. 614 To verify the status of such a certificate, the verifier needs to 615 acquire the certificate if necessary (via the methods described in 616 Section 7), and then would need to either: 618 a. Rely on short-lived certificates and not check the certificate's 619 status, or 621 b. Rely on status information from the authority (e.g., OCSP) 623 The tradeoff between short lived certificates and using status 624 information is that the former's burden is on the front end (i.e., 625 enrollment) and the latter's burden is on the back end (i.e., 626 verification). Both impact call setup time, but some approaches to 627 generating a short-lived certificate, like requiring one for each 628 call, would incur a greater operational cost than acquiring status 629 information. This document makes no particular recommndation for a 630 means of determinate certificate freshness for STIR, as this requires 631 further study and implementation experience. Acquiring online status 632 information for certificates has the potential to disclose private 633 information [RFC7258] if proper precautions are not taken. Future 634 specifications that define certificate freshness mechanisms for STIR 635 MUST note any such risks and provide countermeasures where possible. 637 10.1. Acquiring TN Lists By Reference 639 One alternative to checking certificate status for a particular 640 telephone number is simply acquiring the TN Authorization List by 641 reference, that is, through dereferencing a URL in the certificate, 642 rather than including the value of the TN Authorization List in the 643 certificate itself. 645 Acquiring a list of the telephone numbers associated with a 646 certificate or its subject lends itself to an application-layer 647 query/response interaction outside of certificate status, one which 648 could be initiated through a separate URI included in the 649 certificate. The AIA extension (see [RFC5280]) supports such a 650 mechanism: it designates an OID to identify the accessMethod and an 651 accessLocation, which would most likely be a URI. A verifier would 652 then follow the URI to ascertain whether the list of TNs are 653 authorized for use by the caller. 655 HTTPS is the most obvious candidate for a protocol to be used for 656 fetching the list of telephone numbers associated with a particular 657 certificate. This document defines a new AIA accessMethod, called 658 "id-ad-stirTNList", which uses the following AIA OID: 660 id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } 662 When the "id-ad-stirTNList" accessMethod is used, the accessLocation 663 MUST be an HTTPS URI. The document returned by dereferencing that 664 URI will contain the complete TN Authorization List (see Section 9) 665 for the certificate. 667 Delivering the entire list of telephone numbers associated with a 668 particular certificate will divulge to STIR verifiers information 669 about telephone numbers other than the one associated with the 670 particular call that the verifier is checking. In some environments, 671 where STIR verifiers handle a high volume of calls, maintaining an 672 up-to-date and complete cache for the numbers associated with crucial 673 certificate holders could give an important boost to performance. 675 11. IANA Considerations 677 This document makes use of object identifiers for the TN Certificate 678 Extension defined in Section 9, the TN by reference AIA access 679 descriptor defined in Section 10.1, and the ASN.1 module identifier 680 defined in Appendix A. It therefore requests that the IANA make the 681 following assignments: 683 o JWT Claim Constraints Certificate Extension in the SMI Security 684 for PKIX Certificate Extension registry: 686 http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 687 numbers-1.3.6.1.5.5.7.1 689 o TN Certificate Extension in the SMI Security for PKIX Certificate 690 Extension registry: http://www.iana.org/assignments/smi-numbers/ 691 smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 693 o TNS by reference access descriptor in the SMI Security for PKIX 694 Access Descriptor registry: http://www.iana.org/assignments/smi- 695 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48 697 o The TN ASN.1 module in SMI Security for PKIX Module Identifier 698 registry: http://www.iana.org/assignments/smi-numbers/smi- 699 numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0 701 12. Security Considerations 703 This document is entirely about security. For further information on 704 certificate security and practices, see [RFC5280], in particular its 705 Security Considerations. 707 13. Acknowledgments 709 Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave 710 Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided 711 key input to the discussions leading to this document. Russ Housley 712 provided some direct assistance and text surrounding the ASN.1 713 module. 715 14. References 716 14.1. Normative References 718 [ATIS-0300251] 719 ATIS Recommendation 0300251, "Codes for Identification of 720 Service Providers for Information Exchange", 2007. 722 [DSS] National Institute of Standards and Technology, U.S. 723 Department of Commerce, "Digital Signature Standard, 724 version 4", NIST FIPS PUB 186-4, 2013. 726 [I-D.ietf-stir-passport] 727 Wendt, C. and J. Peterson, "Personal Assertion Token 728 (PASSporT)", draft-ietf-stir-passport-11 (work in 729 progress), February 2017. 731 [I-D.ietf-stir-rfc4474bis] 732 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 733 "Authenticated Identity Management in the Session 734 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 735 (work in progress), February 2017. 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 739 DOI 10.17487/RFC2119, March 1997, 740 . 742 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource 743 Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, 744 . 746 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 747 Standards (PKCS) #1: RSA Cryptography Specifications 748 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 749 2003, . 751 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 752 Resource Identifier (URI): Generic Syntax", STD 66, 753 RFC 3986, DOI 10.17487/RFC3986, January 2005, 754 . 756 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 757 Housley, R., and W. Polk, "Internet X.509 Public Key 758 Infrastructure Certificate and Certificate Revocation List 759 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 760 . 762 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 763 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 764 DOI 10.17487/RFC5912, June 2010, 765 . 767 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 768 DOI 10.17487/RFC5958, August 2010, 769 . 771 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 772 Protocol (HTTP/1.1): Message Syntax and Routing", 773 RFC 7230, DOI 10.17487/RFC7230, June 2014, 774 . 776 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 777 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 778 2014, . 780 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 781 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 782 . 784 [X.509] ITU-T Recommendation X.509 | ISO/IEC 9594-8, "Information 785 technology - Open Systems Interconnection - The Directory: 786 Public-key and attribute certificate frameworks", 2012. 788 [X.680] ITU-T Recommendation X.680 | ISO/IEC 8824-1, "Information 789 Technology - Abstract Syntax Notation One: Specification 790 of basic notation", 2015. 792 [X.681] ITU-T Recommendation X.681 | ISO/IEC 8824-2, "Information 793 Technology - Abstract Syntax Notation One: Information 794 Object Specification", 2015. 796 [X.682] ITU-T Recommendation X.682 | ISO/IEC 8824-2, "Information 797 Technology - Abstract Syntax Notation One: Constraint 798 Specification", 2015. 800 [X.683] ITU-T Recommendation X.683 | ISO/IEC 8824-3, "Information 801 Technology - Abstract Syntax Notation One: 802 Parameterization of ASN.1 Specifications", 2015. 804 14.2. Informative References 806 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 807 Extensions (MIME) Part Two: Media Types", RFC 2046, 808 DOI 10.17487/RFC2046, November 1996, 809 . 811 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 812 Wu, "Internet X.509 Public Key Infrastructure Certificate 813 Policy and Certification Practices Framework", RFC 3647, 814 DOI 10.17487/RFC3647, November 2003, 815 . 817 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 818 Telephone Identity Problem Statement and Requirements", 819 RFC 7340, DOI 10.17487/RFC7340, September 2014, 820 . 822 [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", 823 RFC 7375, DOI 10.17487/RFC7375, October 2014, 824 . 826 [X.520] ITU-T Recommendation X.520 | ISO/IEC 9594-6, "Information 827 technology - Open Systems Interconnection - The Directory: 828 Selected Attribute Types", 2012. 830 Appendix A. ASN.1 Module 832 This appendix provides the normative ASN.1 [X.680] definitions for 833 the structures described in this specification using ASN.1, as 834 defined in [X.680] through [X.683]. 836 The modules defined in this document are compatible with the most 837 current ASN.1 specification published in 2015 (see [X.680], [X.681], 838 [X.682], [X.683]). None of the newly defined tokens in the 2008 839 ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE- 840 OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1 841 specifications referred to here. 843 This ASN.1 module imports ASN.1 from [RFC5912]. 845 TN-Module-2016 846 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 847 mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(88) } 849 DEFINITIONS EXPLICIT TAGS ::= BEGIN 851 IMPORTS 853 id-ad, id-pe 854 FROM PKIX1Explicit-2009 -- From [RFC5912] 855 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 856 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } 858 EXTENSION 859 FROM PKIX-CommonTypes-2009 -- From [RFC5912] 860 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 861 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } 863 ; 865 -- 866 -- JWT Claim Constraints Certificate Extension 867 -- 869 ext-jwtClaimConstraints EXTENSION ::= { 870 SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints 871 } 873 id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 } 875 JWTClaimConstraints ::= SEQUENCE { 876 mustInclude [0] JWTClaimNames OPTIONAL, 877 -- The listed claim names MUST appear in the PASSporT in addition 878 -- to iat, orig, and dest. If absent, iat, orig, and dest MUST 879 -- appear in the PASSporT. 880 permittedValues [1] JWTClaimPermittedValuesList OPTIONAL } 881 -- If the claim name is present, the claim MUST contain one of 882 -- the listed values. 883 ( WITH COMPONENTS { ..., mustInclude PRESENT } | 884 WITH COMPONENTS { ..., permittedValues PRESENT } ) 886 JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of 887 JWTClaimPermittedValues 889 JWTClaimPermittedValues ::= SEQUENCE { 890 claim JWTClaimName, 891 permitted SEQUENCE SIZE (1..MAX) OF UTF8String } 893 JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName 895 JWTClaimName ::= IA5String 897 -- 898 -- Telephone Number Authorization List Certificate Extension 899 -- 901 ext-tnAuthList EXTENSION ::= { 902 SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList 903 } 905 id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } 906 TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry 908 TNEntry ::= CHOICE { 909 spc [0] ServiceProviderCode, 910 range [1] TelephoneNumberRange, 911 one [2] TelephoneNumber 912 } 914 ServiceProviderCode ::= IA5String 916 -- Service Provider Codes may be OCNs, various SPIDs, or other 917 -- SP identifiers from the telephone network 919 TelephoneNumberRange ::= SEQUENCE { 920 start TelephoneNumber, 921 count INTEGER (2..MAX) 922 } 924 TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) 926 -- TN Access Descriptor 928 id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } 930 END 932 Authors' Addresses 934 Jon Peterson 935 Neustar, Inc. 937 Email: jon.peterson@neustar.biz 939 Sean Turner 940 sn3rd 942 Email: sean@sn3rd.com