idnits 2.17.1 draft-kaplan-stir-cider-00.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 (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DMARC' is mentioned on line 148, but not defined == Missing Reference: 'DNS' is mentioned on line 161, but not defined == Missing Reference: 'AXFR' is mentioned on line 1063, but not defined == Missing Reference: 'IXFR' is mentioned on line 1063, but not defined == Missing Reference: 'DNS-NOTIFY' is mentioned on line 1063, but not defined ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X660.1997' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STIR BOF Group H. Kaplan 3 Internet Draft 4 Intended status: Standards Track July 15, 2013 5 Expires: January 30, 2013 7 A proposal for 8 Caller Identity in a DNS-based Entrusted Registry (CIDER) 9 draft-kaplan-stir-cider-00 11 Abstract 13 This document describes a proposal for providing a database service 14 for authentication information for Caller-ID E.164 numbers, 15 nationally-specific number codes, and email-style names used in 16 communication requests (such as call setup, instant messages). The 17 model proposed uses a DNS service as a Registry for cryptographic 18 public-keys. The database service solution is called CIDER. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 15, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction..................................................3 61 2. CIDER Overview................................................4 62 3. Terminology...................................................6 63 3.1. New Terminology..........................................6 64 4. Background Information........................................8 65 4.1. Benefits and Drawbacks to Using DNS......................8 66 4.2. Relation to ITU and National Number Authorities..........9 67 4.3. Open Numbering Plans....................................10 68 5. Caller-ID vs. DNS Delegation and Authority Models............11 69 5.1. Email-style Registries..................................12 70 5.2. E.164 and Number Code Registries........................12 71 6. Assignee Roles and Actions...................................13 72 6.1. Key Agents and Third-Party Private Agents...............14 73 7. Using CIDER for Caller-ID Verification.......................15 74 7.1. CIDER DNS Client Requirements...........................15 75 7.2. Information Needed by the Caller-ID Verifier............16 76 7.3. Generating the CIDER DNS query..........................16 77 7.3.1 Query for Email-style Identity 16 78 7.3.2 Query for E.164-based Identity 16 79 7.3.3 Query for Number Code-based Identity 17 80 7.4. Processing the DNS Answer...............................17 81 8. DNS Binding..................................................18 82 8.1. Subdomain Namespace.....................................18 83 8.2. Resource Record Type for Key Storage....................18 84 8.3. TXT Record Format.......................................18 85 9. Security Considerations......................................19 86 9.1. Privacy of Assignee.....................................19 87 10. Open Issues.................................................19 88 11. IANA Considerations.........................................20 89 12. Acknowledgments.............................................20 90 13. References..................................................20 91 13.1. Normative References...................................20 92 13.2. Informative References.................................20 93 Author's Address.................................................21 94 Appendix A. Possible Deployment Model...........................21 95 Appendix B. Requirements for a CAPP Mechanism...................23 97 1. Introduction 99 For many years the identity of the calling party (i.e., Caller-ID) 100 of voice communications has been made available to the callee, and 101 has been assumed to be generally accurate/reliable. Not only do end 102 users expect this to be the case, but also applications such as 103 calling-name (CNAM) services, call-back services, and voice-mail 104 account access, have depended on the validity of the Caller-ID. 105 Even some forms of call rate-control and Denial-of-Service (DoS) 106 attack prevention between service providers depend on valid Caller- 107 IDs. The ability to spoof Caller-IDs enables numerous fraud and 108 abuse scenarios. 110 Unfortunately, this problem already exists and is exacerbated by the 111 presence of Internet-based calling services. While a small volume 112 of Caller-ID spoofing has occurred for many years on the PSTN, it 113 was infrequent enough to handle through manual investigation, and 114 could be largely ignored as being merely isolated cases. Lately, 115 however, the frequency has increased to a point that national 116 regulators are becoming concerned (e.g., [fcc-doc]), the media have 117 been reporting on it, and service providers themselves have been DoS 118 attacked using invalid Caller-IDs. 120 There are several causes for the increase in Caller-ID spoofing: the 121 decrease in cost for making calls, the large number of inexpensive 122 products capable of generating spoofed Caller-IDs, and the growing 123 number of entry points/paths into the trust network upon which 124 Caller-ID reputability has always depended. 126 Spoofing a Caller-ID is possible because to-date there has been no 127 means to validate a Caller-ID; instead the assumption has been that 128 the received Caller-ID came from trustworthy upstream providers, in 129 a chain-of-trust based on the PSTN model. Some PBXs are also 130 allowed to generate whatever Caller-IDs they wish across PRI 131 circuits, based on the belief that they can be trusted due to the 132 relative cost, complexity, and physical hurdle of getting a PRI 133 trunk. 135 The original assumption of Caller-ID reputability that was based on 136 the PSTN trust model no longer holds. Therefore, in order to keep 137 Caller-IDs valid in a less trustworthy interconnection model, a 138 means of verifying Caller-IDs must be deployed that works with the 139 model. Replacing the current PSTN-style interconnection model 140 itself is not realistic. 142 One approach for verifying Caller-IDs relies on public-key 143 cryptography, whereby the originator signs some information in the 144 call setup message using a private key, and the receiver verifies 145 the signature using the public key. For example the solutions 146 described in [RFC4474], [draft-4474bis], and [draft-ikes]. These 147 approaches are conceptually similar to those employed by [DKIM] and 148 [DMARC], which have been created to address a similar issue for 149 email. 151 Regardless of the solution used, there needs to be a way for: 152 (1) the originator to have a private/public key pair that is 153 trusted by everyone else to prove the originator can claim the 154 Caller-ID 155 (2) any receiver of the originator's message to be able to 156 retrieve the public key the originator used, and 157 (3) the receiver to verify the private key was used to sign for 158 the given Caller-ID 160 This document describes a model for achieving those needs. It does 161 so by using the Domain Name System [DNS], as a database for mapping 162 source identities to public keys with an authority structure. The 163 DNS tree nodes have no direct identifying information - they do not 164 identify the carrier or end-user that was assigned each E.164 165 number, for example. The general model and architecture is named 166 "CIDER". 168 2. CIDER Overview 170 At a high-level, CIDER provides a database infrastructure using DNS 171 for storing and retrieving public keys to authenticate source 172 identities in communication messages, for example SIP or XMPP 173 requests. Instead of being told by the message originator where the 174 verifier should get a full certificate and then having the verifier 175 check that the certificate is signed by a common trusted third-party 176 for the specific identity being claimed, CIDER retrieves the public 177 key directly from DNS and relies on the DNS authority model to 178 control authorization of the public keys for source identities. 180 CIDER currently covers three types of identities: international 181 E.164 numbers, nationally-specific number codes, and email-style 182 names. Each type uses a different anchor to its domain name, and 183 thus can be deployed in different ways. The DNS infrastructure used 184 for each may be the public DNS infrastructure, or local private DNS 185 instances populated with the same data. They can even be used in a 186 restricted "federation" model, whereby only specific entities have 187 access to the CIDER data: the public keys and other associated data. 189 For domain-based identities, CIDER follows the [DKIM] model of using 190 each identity domain's DNS zone with a defined node name and key 191 selector to hold the public key. The DKIM "key selector" is called 192 a CIDER "key index" in this document, because it is syntactically 193 different. The subdomain node name prefixed to the source's domain 194 name is also different ("_cidkey" vs. "_domainkey"), and the TXT 195 Resource Record format is more constrained than DKIM's. 197 For E.164 numbers and number codes, CIDER uses a reverse-dotted 198 notation similar to ENUM for the DNS structure. The top of the 199 domain tree hierarchy (the anchor) for the E.164 and number code 200 entries is still TBD - it could be one single root anchor for all 201 country-codes, or it could be a different anchor per country-code or 202 geopolitical region or whatever. 204 In order to simplify discussion and explanation in this document, 205 the domain 'cid.example.org' is used to describe a common top-level 206 anchor domain for both E.164-based and number code-based identity 207 entries. In practice they could be different, with E.164 using 208 'cid.example.org' and number codes using 'cid.example.net', to have 209 separate authorities for E.164-based numbering vs. number codes. 211 The structure of CIDER's DNS hierarchy for the E.164-based and 212 number-code-based domains follows a reverse-dotted notation of the 213 E.164 numbering format, so that for example the +1 "country-code" 214 would be the subdomain '.1.cid.example.org', whereas that for the 215 +49 German country-code would be '.9.4.cid.example.org'. 216 Nationally-specific number codes would be prefixed with their 217 country-code, so that for example "911" in the North American 218 Numbering Plan country-code 1 would be the domain 219 "1.1.9.1.example.org". 221 The public keys in CIDER's DNS tree nodes have no direct identifying 222 information - they do not identify the carrier or end-user that was 223 assigned each E.164 number. 225 The public keys could be unique per E.164 number entry, or they 226 could be the same public key for all E.164 entries belonging to the 227 same end entity. This is purely an administrative choice of the 228 owner. For example a carrier that is assigned millions of E.164 229 entries might re-use the same public-key in all of them. Or it can 230 use one public key for every thousand E.164 numbers, or whatever. 231 It's up to the individual end-entities that were assigned the E.164 232 numbers to decide what to populate their assignee DNS identity entry 233 nodes with. 235 If an organization explicitly desires to make itself known, it can 236 put its name into some to-be-defined DNS Resource Record for its 237 E.164 number identity entry node; such may be the case for corporate 238 1-800 numbers, for example. The organization can decide, on a 239 number-by-number basis, whether to make itself known or not for that 240 E.164 number in the CIDER DNS tree. 242 It should be noted that although the public key entries installed in 243 the CIDER DNS tree are unique for every E.164 number (or group of 244 numbers), they do not need to be maintained/stored by the 245 organizations that uploaded them. Unlike credentials used with 246 SSL/TLS, for example, the public keys are not transmitted by their 247 servers to client hosts using certificates; rather, the keys are 248 only retrieved by the verifiers when validating the Caller-ID 249 signatures, and that's done through DNS. The signers themselves 250 only need to know the private key, to which the public key is paired 251 to for any given E.164 number. Furthermore, the originators can use 252 the exactly the same private key for every E.164 number they sign 253 for, by uploading the same public key into every E.164 node they are 254 assigned in the CIDER DNS. 256 3. Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in RFC 2119. The 261 terminology in this document conforms to RFC 2828, "Internet 262 Security Glossary". 264 It is assumed the reader is already generally familiar with E.164 265 numbers, Public-key cryptography concepts, Domain Name System (DNS), 266 and DNS Security (DNSSEC). 268 This document uses the term "identity" instead of "identifier" with 269 regards to verifying source identity. The reason for this is that 270 it is not the syntactic encoding of an E.164 digit string, number 271 code, or email-style name that are being verified - it's the 272 canonical E.164 phone-number, number code, or email-style name 273 that's being verified. In other words CIDER is used for verifying a 274 logical entity, not a specific representation; and the logical 275 entity is not a specific human user or SIP agent/device, but rather 276 a phone-number or number code or email-style name. 278 3.1. New Terminology 280 Caller-ID: the identity of the originator of a communications 281 request; for example the From header field in a SIP INVITE call 282 setup request or MESSAGE instant message request. 284 E.164 number: a phone number in international E.164 format, which is 285 understood by the originating and receiving entities to represent a 286 globally unique number. This definition includes numbers that are 287 not technically "E.164" numbers, such as toll-free 1-800 numbers in 288 North America. 290 Number code: a nationally-specific number which is not representable 291 as an E.164 number. Examples of number codes include two or three 292 digit emergency service numbers, N11-type numbers in NANP, and 293 inter-carrier common short codes. 295 Email-style name: a 'user@domain' format identifier, for which the 296 user portion is scoped to the domain portion, and the domain portion 297 is a classic, public domain name; removing or changing the domain 298 portion would fundamentally change the identity of the user. 300 Source identity: the E.164 number, number code, or email-style name 301 used for identifying the originator of a message to the receiving 302 user; i.e., the identity used for "Caller-ID". 304 Identity entry: the DNS name entry representing an E.164-based 305 number, nationally-specific number code, or email-style domain name. 307 CIDER Registry: an instance of a DNS hierarchy used for storage and 308 retrieval of public keys for source identities. A CIDER Registry 309 may be for an entire E.164-based country-code tree, or just for 310 portions of one, or just for a single domain name. 312 CIDER Registrar: the organization that owns, manages, and is 313 authoritative for a CIDER Registry. 315 CIDER Assignee: the organization/entity that the CIDER Registrar 316 allows to populate specific identity entries with public key data, 317 can grant/rescind Key Agents, and permanently transfer ("donate") 318 the identity entry to another Assignee. This could be a carrier or 319 service provider for E.164 numbers, for example. 321 Key Agent: an organization/entity that the CIDER Assignee grants 322 access to upload public key data only, for one or more of the 323 Assignee's identity entry nodes. This could be an Enterprise or 324 service provider customer of a carrier, for example. 326 Third-Party Private Agent: an organization/entity that can upload 327 public key data for an identity, but not directly to the Registry - 328 only via a true CIDER Assignee, and thus the Registrar knows nothing 329 about the Third-Party Private Agent. This could be an Enterprise or 330 end-user, for example. 332 4. Background Information 334 4.1. Benefits and Drawbacks to Using DNS 336 A database model to hold public keys used for caller-id verification 337 could be accessed using a protocol other than DNS. Examples include 338 HTTP, LDAP, or even DIAMETER. CIDER uses DNS for the following 339 reasons: 341 o The DNS architecture has demonstrated massive intrinsic 342 scalability, by allowing branches of the database tree to be 343 run on separate physical servers and separate, independent 344 adminsitration. 345 o The DNS protocol is extremely efficient, with no extra round- 346 trip delays creating connections or resolving hostnames. 347 o The DNS protocol allows tight control over retransmission 348 timers and timeout behavior from the application layer, because 349 it runs on UDP. 350 o The DNS protocol has well-established practice for highly 351 effective geographic redundancy techniques, such as through 352 anycasting because it runs over UDP. 353 o The DNS protocol has well-established and effective caching in 354 local servers, and techniques are available to have local 355 copies of a DNS tree. 356 o The DNS protocol and architecture provide a seamless, global 357 service, but have well-established and highly effective 358 practice for delegation of authority, which is useful for 359 country-code level separation of authority for E.164 numbers 360 and nationally-specific number codes. 361 o The DNS protocol already defines the encoding syntax and 362 semantics for many of the functions needed. 363 o DNS is already used very widely by services employing DKIM for 364 email signing/verification for a similar purpose as would be 365 needed for email-style domain-based caller-id identities. 366 o Some service providers already use DNS for Private ENUM for 367 CNAM, number portability, and communication request routing 368 purposes. 369 o Virtually all clients/hosts have DNS querying capabilities 370 today; and there are many DNS server vendors, including a 371 widely popular open-source implementation (BIND). 373 There are some drawbacks to using DNS, however: 374 o DNS typically uses UDP, so if the query or response are larger 375 than the MTU size between the client and server, fragmentation 376 will occur. The base DNS maximum message size is 512 bytes, 377 but CIDER requires [EDNS0] be used, which allows larger message 378 sizes; so the real issue is for message sizes over ~1460 bytes. 379 The current CIDER entries would not typically be that large, 380 even if DNSSEC is being used. 382 o Deploying a private registry using DNS is more complicated 383 because it runs over UDP and has no defined mechanism to 384 enforce access control on the queries. Private and federated 385 DNS has been deployed, but it usually requires using private IP 386 Addresses and VPN-style access to the servers. 387 o The DNS query model does not support providing a different 388 resource record(s) for different querying agents. In other 389 words, it does not give a different answer depending on who 390 asks the question. There are widely-used work-around behaviors 391 for this today, but they are not standardized. 392 o No changes to the underlying DNS protocol are envisioned. 393 Should they be needed, some members of the IETF treat the DNS 394 protocol, architecture, and its instantiation in the public 395 Internet for domain name resolution, all as one monolithic, 396 inter-dependent usage. Therefore, any changes required of the 397 protocol have to also work for the Internet domain name 398 resolution infrastructure as rooted-in/controlled-by 399 IANA/ICANN. Even if a DNS extension were created for purely 400 private use, the IAB has essentially stated they fear the 401 public domain name infrastructure is so brittle that it would 402 collapse if the extensions were accidentally sent to a public 403 DNS server. 405 [Note: If the STIR Working Group decides future extensions to the 406 DNS protocol would be needed, there is a way to achieve this: we 407 could copy the DNS RFCs into new documents, give the protocol a new 408 name ("NDNS" for "Not DNS"?) and a new default UDP port number other 409 than 53. Such a concept seems silly, but it would give us the same 410 benefits without the drawback of having to worry about "The DNS" 411 collapsing due to a few unexpected bytes in a query packet.] 413 4.2. Relation to ITU and National Number Authorities 415 A concern has been raised that using E.164 numbers in a DNS 416 hierarchy would be problematic because the ITU should be responsible 417 for delegating E.164 country-codes, and national authorities should 418 be responsible for managing their country-code numbers. The fear is 419 that deploying CIDER without the ITU and national authorities 420 approving and managing it would lead to claims of inappropriate 421 subverting of the E.164 numbering system; or fears that for CIDER to 422 work correctly would require such approval and management. 424 This document section explains why such concerns are either 425 unfounded, or apply equally to any database model used for caller-id 426 verification of E.164 numbers, whether it be DNS or otherwise. 428 With regards to approval, there is already precedent for the IETF to 429 use names defined by other organizations in DNS: the top-level 430 country domain names are based on a list defined by ISO, for 431 example. 433 With regards to subverting the E.164 numbering system, this document 434 makes no claim that a specific CIDER registry, or top domain root 435 for it, is in fact authoritative for the E.164 number space. In 436 fact, although this document uses the term "E.164" to describe the 437 tree structure and assignment model, all that is truly described is 438 how a DNS domain may create subdomain names with Resource Records 439 that could be used by others to retrieve public keys. It is up to 440 the users of the registry/domain to decide whether to believe it 441 represents E.164 numbers, and to use it for identities in call- 442 control scenarios. The same CIDER model could be used, for example, 443 to deploy a public key storage/retrieval mechanism for a private 444 phone-numbering plan; or even digit-based names that have nothing to 445 do with phone numbers, such as Autonomous System numbers or 446 Enterprise OIDs. 448 The CIDER service described in this document does not dictate who 449 will be registrars, although existing authorities and operators 450 might be reasonable candidates. All CIDER needs, however, is for 451 some organization to manage the domain tree for a given E.164-based 452 namespace, to decide what entities get to populate the public key 453 entries for its branch nodes, and for verifiers to use that 454 organization's domain tree for retrieving the public keys and trust 455 them to be correct. In other words, any organization can be the 456 Registrar and create its own CIDER DNS registry with its own domain 457 as the anchor of the tree, and so long as both signers and verifiers 458 use that organization's registry and it is accurate, then CIDER 459 works. 461 This is no different than what occurs for the web-pki model of 462 third-party Certificate Authorities (CAs). If you trust a CA, then 463 you trust that the certificates it signs are for the domain/host 464 names contained in the certificate, even though CAs are not 465 authoritative for DNS domain name assignments. The IETF has a 466 mechanism for tying web-pki certificates to the actual authority of 467 DNS names: DANE is that mechanism; but without DANE verification, 468 the web-pki model is purely based on trusting the CAs to be accurate 469 with regards to domain/host name assignments. Therefore, any 470 caller-id verification model that is not ultimately controlled by 471 the numbering authorities for the E.164 number space would have the 472 same issues as CIDER. 474 4.3. Open Numbering Plans 476 The E.164 number model is technically an open numbering plan, 477 meaning it does not specify a fixed number of digits. In some 478 countries, the national numbering plan has a fixed number (e.g., 479 North America does), but in others it is left open (e.g., Germany). 480 For CIDER, this has implications if the source identity could be 481 more digits than the CIDER Registrar knows about and has granted 482 upload access to a CIDER Assignee for. 484 For example, in Germany not only is the numbering plan open, but the 485 number assignment model is as well: an Enterprise is given a single 486 phone number, and the Enterprise can then add a variable number of 487 digits at the end for their specific lines/users. For routing 488 purposes, the carriers only need to route on the assigned number 489 portion, and the Enterprise's PBX can route the final leg to the 490 user based on the whole number. 492 If the Enterprise can also claim the longer number sequence as a 493 caller-id, but the CIDER Registrar only has entries for the assigned 494 portion, then verification will fail. 496 This document does not specify a solution to this problem, but 497 leaves it as an open issue to be decided upon. There are at least 498 two potential solutions we can choose from: 499 o CIDER could specify that Assignees can upload information to 500 create subdomains within their assigned E.164 identity entry 501 node. For example, let the Enterprise notify the carrier of 502 the extra digits and their public keys, and the carrier in turn 503 uploads it to the Registry. 504 o We could require the SIP/XMPP/SS7 message information include 505 the number of significant digits to use, so that CIDER is only 506 queried for the assigned number portion; and have the TXT RR 507 for the assigned number indicate that it's an open number. 509 5. Caller-ID vs. DNS Delegation and Authority Models 511 The concept of delegation and authority is somewhat confusing when 512 referring to CIDER, because the terms are used in two different 513 ways: one is the delegation and authority model of DNS 514 subdomains/zones, and the other is delegation and authority model 515 for caller-id identities and their public keys. 517 CIDER makes a clear distinction between which entities are allowed 518 to provision public keys into specific entries in the CIDER 519 Registry, versus which entities own, control, administer and are 520 authoritative for the DNS domains/zones in the hierarchy of the 521 Registry. 523 In other words, the CIDER Registry is split into two distinct 524 aspects: the entities that own the Registry and thus the DNS 525 domains/zones used to access those public keys, and the entities 526 that are assigned rights to upload public key information for their 527 assigned identity entries in the DNS-based Registry. The former are 528 called "CIDER Registrars", and the latter are "CIDER Assignees". 530 5.1. Email-style Registries 532 For email-style domain-based identities, CIDER uses the DKIM model 533 of storing and retrieving the public keys from the identity domain's 534 DNS zone. For example, if the source identity is 535 "alice@example.com", then the DNS zone "example.com" is used, and 536 thus uses the supplied domain name, to follow the typical DNS 537 delegation and authority model for its contents. Each domain is 538 thus it own CIDER Registrar as well as its own CIDER Assignee, and 539 there is no distinction between the delegation and authority model 540 for DNS versus the caller-id identities and public keys. 542 If a domain owner wishes to allow another entity to use its domain 543 name for caller-id verification, however, the owner can follow the 544 same model as that defined in the next section for E.164 and number 545 code registries. For example, if "example.com" wishes to allow a 546 contracted third-party company to generate calls using 547 "example.com", it can continue to be the CIDER Registrar for 548 "example.com" and make the other company a CIDER Assignee for it as 549 well. 551 5.2. E.164 and Number Code Registries 553 For E.164 and number codes, the details for delegation and authority 554 are separated. There is a CIDER Registrar which is the DNS 555 authority for domains/zones/nodes, and the Registrar allows CIDER 556 Assignees to upload public keys into specific identity entry nodes 557 representing the E.164/number-codes. 559 While it is tempting to consider using the DNS subdomain delegation 560 model for delegating DNS zones for specific E.164-based ranges or 561 specific numbered entries to the carriers or end users to which the 562 numbers are assigned. CIDER does not depend on such a DNS 563 delegation model, and in fact it is expected such a DNS delegation 564 model will not be used in practice; this is due to both the need to 565 maintain privacy of who the carrier or end-user is for each number, 566 and because the number portability behavior in some national 567 numbering plans would make such a model untenable. 569 For example, from a DNS and DNSSEC perspective, the DNS zone 570 authority for each of the subdomains within 'cid.example.org' (the 571 country-code CIDER Registrars) could be the national numbering plan 572 administrator for each country-code, possibly determined by the ITU 573 to be authoritative for the anchor 'cid.example.org'. 575 Below the country-code level domain, each nation and national number 576 authority can decide how they choose to delegate DNS zone authority, 577 or not to. There is no requirement to delegate out DNS zone 578 authority below the national country-code level whatsoever, nor any 579 prohibition from doing so; the country-code authority can be the DNS 580 authority for the entire E.164 number space of DNS domains/nodes 581 under their country-code level. [Note: for North America, the DNS 582 delegation could be separated by area-codes; to give Canada's area- 583 codes a different authority from those in the USA, for example] 585 In fact, having a single DNS authority might have some advantages: 586 it prevents people from learning how many numbers each carrier has, 587 and it reduces the time for caller-id verification because the 588 DNSSEC authority signing chain is shorter. Since most calls are 589 national calls, the verifying systems can use a local cache of the 590 national numbering administrator's certificate to verify the 591 certificate of most E.164 caller-ids. 593 The important distinction is that it does not matter who manages the 594 CIDER DNS registry for a given country-code - what's important is 595 that the CIDER Registrar allows the entities which are assigned the 596 E.164 numbers (the CIDER Assignees) to upload their public keys into 597 their respective E.164-based nodes. 599 For example the CIDER Registrar can allow a SIP service provider to 600 be the Assignee for a set of the Registry's E.164 entries, so that 601 the service provider can upload the public keys it wishes to use for 602 its caller-ids. From a DNS perspective, however, the Registrar is 603 still the singular authority of the DNS zones/nodes for those E.164- 604 based nodes. The domain tree and its zones/nodes "belong" to the 605 Registrar from a DNS perspective. 607 6. Assignee Roles and Actions 609 As explained previously, CIDER creates a distinction between the DNS 610 authority (the CIDER Registrar) vs. an entity allowed to upload 611 public keys (the CIDER Assignee). 613 For every identity entry in the DNS tree (i.e., leaf node), the 614 Registry has one and only one CIDER Assignee. The Assignee may be 615 the Registrar itself, as would usually be the case for email-style 616 domain-based identity CIDER Registries for example. For E.164-based 617 identities, the Assignee probably is the service provider/carrier 618 assigned the number by the national numbering authority for the 619 given country-code. 621 The Assignee has controlled access to the Registry for performing 622 the actions it can take. This may be through a web portal, or even 623 via email or fax; if the STIR Working Group decides to continue with 624 CIDER, however, the author strongly recommends that a specific 625 protocol be defined for this purpose in another document: a CIDER 626 Assignee Publishing Protocol (CAPP). For example, CAPP could be 627 either an HTTP/SOAP/XML or HTTP/REST type protocol. CAPP would be 628 useful for DKIM and DNS in general, and as an alternative for 629 Dynamic DNS [DDNS]. Requirements for CAPP are given in Appendix B. 631 An Assignee can add, modify, or remove public key entries from its 632 identity node(s) in the Registry, and thereby affect the available 633 TXT RR entries. Depending on how open numbering assignment is 634 handled (currently an open issue in this document), the Assignee 635 might be able to add, modify, or remove subdomain/additional-digit 636 identities below the one the Registrar granted it access to, if the 637 Registrar allows it. 639 If the Registrar allows it, an Assignee can permanently transfer 640 control of its identity node to another Assignee, which is called 641 "donating" its identity in this document. Such would be the case 642 for number porting in certain countries, for example. 644 An Assignee can also grant/rescind access to Key Agents for its 645 identity entries(s), if the Registrar supports such a model, as 646 described in the next section. 648 6.1. Key Agents and Third-Party Private Agents 650 One of the use-cases a Caller-ID verification mechanism needs to 651 support is that of enabling a third-party to assert someone else's 652 Caller-ID for outbound calls/communications. An example of this 653 need is outsourced call-centers making calls on behalf of a company, 654 or even a doctor using her personal mobile phone to make calls with 655 her medical office's number as her Caller-ID. 657 CIDER supports this in two ways: by either having the CIDER 658 Registrar support an Assignee and one or more designated Key Agents 659 for the same identity entry, or by having the Registrar only know 660 about the CIDER Assignee and having the third-parties upload their 661 public keys through the Assignee as Third-Party Private Agents. 663 The difference between a Key Agents and Third-Party Private Agents 664 is one of involvement with the Registrar and Registry. If a 665 Registrar supports Key Agents, then the Assignee has to grant this 666 role, and the Registrar has to know about them, have credentials for 667 them, etc. With Third-Party Private Agents, however, the Registrar 668 knows nothing about it - the third-party uploads public keys to the 669 Assignee directly (e.g., using CAPP), which then uploads them to the 670 Registry in the same manner as its own public keys (again using 671 CAPP). 673 From a Caller-ID verifier's perspective - from the data it can view 674 in the retrieved Resource Records - there is no difference between 675 Assignee, Key Agents or Third-Party Private Agents. In fact the 676 verifier can't even discern who the Assignee is. 678 7. Using CIDER for Caller-ID Verification 680 CIDER specifies a key retrieval mechanism The mechanics of Caller-ID 681 verification that use the key is left for definition by a separate 682 document. One example of such a mechanism is defined in [draft- 683 ikes]. This section defines the information a verifier CIDER client 684 needs in order to retrieve the appropriate public key for a 685 verification mechanism, and how the retrieval is performed. 687 7.1. CIDER DNS Client Requirements 689 A Caller-ID verifier acting as a CIDER DNS client MUST implement DNS 690 over UDP using [EDNS0] in order to handle message sizes larger than 691 512 bytes. The client MUST be prepared to receive DNSSEC responses, 692 unknown RRs, etc. 694 If the verifier supports email-style identities, it MUST be able to 695 query DNS servers which resolve public Internet DNS names. 697 If the verifier supports E.164-base identities, it is RECOMMENDED 698 that the client be configurable to use different DNS server(s) for 699 this purpose, separate from the one(s) used for other identity 700 types. The client SHOULD also support being configurable for using 701 a different anchor domain name for this purpose, separately from the 702 one used for number code identities. 704 If the verifier supports number code-based identities, it is 705 RECOMMENDED that the client be configurable to use a different DNS 706 server(s) for this purpose, separate form the one(s) used for other 707 identity types. The client SHOULD also support being configurable 708 for using a different anchor domain name for this purpose, 709 separately from the one used for E.164-based identities. 711 The client MAY be a recursive resolver, but it is strongly 712 RECOMMENDED that it be a stub resolver and allow the DNS servers to 713 resolve on its behalf. Otherwise, it will be difficult to use such 714 a client in access-restricted CIDER deployments, such as private or 715 federated ones. For example if the CIDER Registry is a private one 716 for one or more nations. (see Appendix A) 718 7.2. Information Needed by the Caller-ID Verifier 720 For CIDER to function properly, a Caller-ID verifier needs to know 721 the following information: 722 o The source identity value 723 o The source identity type: domain-based, E.164-based, or number 724 code-based 725 o The public key index value 727 The public key index value identifies which of several possible 728 public keys for a given source identity should be used for verifying 729 the message. 731 The source identity value need not be the whole source identity as a 732 URI or 'user@domain' string - it only needs to be the information 733 used for the CIDER query as defined in the next section. 735 7.3. Generating the CIDER DNS query 737 In order to generate a CIDER DNS query, the CIDER verifier performs 738 slightly different actions depending on the source identity type, as 739 defined in these sections. 741 7.3.1 Query for Email-style Identity 743 For an email-style source identity, the verifier CIDER client takes 744 the 'user@domain' string and ignores the "user@" portion. The 745 remaining domain name becomes the base of the DNS query key. The 746 verifier prepends the CIDER public key index value as a subdomain, 747 followed by the subdomain "_cidkey", in front of the domain name. 749 For example, if the source identity being verified is 750 "alice@example.com" with a public key index value of 3, the DNS 751 query key becomes "3._cidkey.example.com". 753 The verifier then issues a DNS query with the above query key to the 754 public Internet DNS. 756 7.3.2 Query for E.164-based Identity 758 For an E.164-based source identity, the verifier CIDER client takes 759 the international E.164 digit string, removes any leading '+' or 760 visual separators, puts dots (".") between each digit, and reverses 761 the order of digits. The verifier then appends the E.164-based 762 CIDER Registrar domain name to the end, and prepends the CIDER 763 public key index value as a subdomain, followed by the subdomain 764 "_cidkey". 766 For example, if the source identity being verified is "+16035551010" 767 with a public key index value of 2, and a CIDER Registrar domain for 768 the country-code 1 of "1.cid.example.org", then the DNS query key 769 becomes "2._cidkey.0.1.0.1.5.5.5.3.0.6.1.cid.example.org". 771 The verifier then issues a DNS query with the above query key to 772 either the public Internet DNS, or to the DNS server provisioned for 773 such a purpose. 775 7.3.3 Query for Number Code-based Identity 777 For a nationally-specific number code-based source identity, the 778 verifier CIDER client takes the number code digit string, prepends 779 the country-code the number code is nationally-specific for, puts 780 dots (".") between each digit, and reverses the order of digits. 781 The verifier then appends the Number-code CIDER Registrar domain 782 name to the end, and prepends the CIDER public key index value as a 783 subdomain, followed by the subdomain "_cidkey". 785 For example, if the source identity being verified is "911" for the 786 country-code 1, with a public key index value of 2, and a Number- 787 code CIDER Registrar domain of "cid.example.org", then the DNS query 788 key becomes "2._cidkey.1.1.9.1.cid.example.org". 790 The verifier then issues a DNS query with the above query key to 791 either the public Internet DNS, or to the DNS server provisioned for 792 such a purpose. 794 7.4. Processing the DNS Answer 796 Based on the DNS binding format defined in Section 8, a successful 797 CIDER DNS query will produce a DNS answer with a TXT RR as defined 798 in Section 8.3. The verifier needs to parse the TXT RR, to verify 799 the version is "CIDER1", the key-type is "rsa" or some token the 800 verifier understands, and to base64 decode the public key data. 802 If the version is not "CIDER1", or the key-type is not one the 803 verifier understands, or the public key cannot be decoded or is not 804 of a key size the verifier supports, then the verifier should treat 805 it as a failure. If the public key is empty, the verifier should 806 treat it as a failure. If the DNS answer is 'not found', the 807 verifier should treat it as a failure. If the DNS query times out, 808 the client should try any alternate servers it is provisioned for; 809 if there are no more, it should treat it as a failure. 811 The action to take for a CIDER query failure is dependent on local 812 policy and not defined in this document. 814 8. DNS Binding 816 A binding using DNS TXT records as a key service is hereby defined. 817 All implementations MUST support this binding. 819 8.1. Subdomain Namespace 821 All CIDER keys are stored in a subdomain named "_cidkey", with a 822 node name of the key index value. Given an email-style source 823 identity of "alice@example.com" and a key index of "3", the DNS 824 query will be for "3._cidkey.example.com". Given an E.164 source 825 identity of "16035551010" and a key index of "1", the DNS query will 826 be for "1._cideky.0.1.0.1.5.5.5.3.0.6.1.cid.example.org". Given a 827 nationally-specific number code for "911" in the North-American 828 Numbering Plan region (country-code 1), and a key index of "6", the 829 DNS query will be for "6._cidkey.1.1.9.1.cid.example.org". 831 8.2. Resource Record Type for Key Storage 833 The DNS Resource Record type used in this specification is a TXT 834 Resource Record (RR). A later extension of this standard may define 835 another RR type. 837 Strings in a TXT RR MUST be concatenated together before use with no 838 intervening whitespace. TXT RRs MUST be unique for a particular key 839 index value; that is, if there are multiple records in an RRset, the 840 results are undefined. 842 8.3. TXT Record Format 844 The TXT RR used for the CIDER key MUST follow the format specified 845 in this section, in order to provide future extension capability. 846 No whitespace is allowed in this format, and all values are case- 847 sensitive. The format is based on the following ABNF: 849 txt-record = version-param SEMI key-param [ SEMI txt-param ] 850 version-param = "v=" "CIDER1" 851 key-param = key-type SEMI key-data 852 key-type = "k=" ("rsa" / hyphenated-word) 853 key-data = "p=" DQUOTE [ base64 ] DQUOTE 855 The version identifies the TXT record content syntax and semantics, 856 which for this document is defined as "CIDER1". 858 The key-type identifies the CIDER public key's (the "p=" value) 859 type, which for this specification uses the "rsa" key type to 860 indicate that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey 861 [RFC3447] is being used in the key-data's value. Future 862 specifications may define other key types by assigning thi field a 863 different value, but still using the "CIDER1" version. 865 The key-data identifies the CIDER public key value, in base64 866 encoded form. An empty value (the literal string 'p=""'), means the 867 public key for this index is not usable or has been explicitly 868 revoked as opposed to simply removed. This might be useful if the 869 CIDER DNS authority wishes to prevent use of a specific key index 870 node entry for some time period of time by having an essentially 871 empty TXT RR, as opposed to deleting the entry and re-using it when 872 the next public key is uploaded by the assigned party. 874 9. Security Considerations 876 The same security considerations as described in [DKIM] apply to 877 CIDER; in particular Sections 8.2, 8.3, 8.4, 8.6, and 8.7 of [DKIM]. 879 9.1. Privacy of Assignee 881 For E.164-based CIDER Registries, privacy of assignee is a concern. 882 The concern stems from the need to keep the assignee of an E.164 883 number unknown in general - to prevent simple scripts from being 884 used to walk the CIDER DNS tree and learn what E.164 numbers are 885 assigned to which carrier, for example. An example of why this 886 needs to remain private is that using such knowledge one could learn 887 how many subscribers a publicly-traded mobile provider has gained or 888 lost in a quarter, and be able to buy or sell stock based on such 889 knowledge in advance of the provider's quarterly-reported 890 statements. 892 Such information could be easily learned if only one a few public 893 keys are used by a carrier for all of its numbers in the CIDER 894 Registry. To defend against such abuse, it is strongly RECOMMENDED 895 that assignees only re-use the same public key for a limited number 896 of CIDER entries. For example a large assignee might use the same 897 public key for a thousand or ten thousand of its E.164 numbers. 899 It should be noted that this security concern is not specific to 900 using DNS - any open-access database protocol would be vulnerable to 901 a script querying all entries. Controlled-access databases would be 902 of less concern, but CIDER can also be used in a controlled-access 903 model. 905 10. Open Issues 907 - How to handle open numbering plan assignment country-codes. 909 11. IANA Considerations 911 This document makes no request of IANA yet. 913 12. Acknowledgments 915 The general concept of using DNS in an ENUM model for caller-id 916 verification has been discussed in the IETF for many years. Thanks 917 to Dave Crocker for pointing out the DKIM similarities and usage, 918 and for reviewing the draft in detail. 920 Funding for the RFC Editor function is provided by the IETF 921 Administrative Support Activity (IASA). 923 13. References 925 13.1. Normative References 927 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 928 2671, August 1999. 930 [DDNS] Wellington, B., "Secure Domain Name System (DNS) Dynamic 931 Update", RFC 3007, November 2000. 933 [ITU.X660.1997] "Information Technology - ASN.1 encoding rules: 934 Specification of Basic Encoding Rules (BER), Canonical 935 Encoding Rules (CER) and Distinguished Encoding Rules (DER)", 936 ITU-T Recommendation X.660, 1997. 938 [RFC3447] Jonsson, J., and Kaliski, B., "Public-Key Cryptography 939 Standards (PKCS) #1: RSA Cryptography Specifications Version 940 2.1", RFC 3447, February 2003. 942 13.2. Informative References 944 [fcc-doc] http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-11- 945 1089A1.doc 947 [draft-ikes] Kaplan, H., "An Identity Key-based and Effective 948 Signature for Origin-Unknown Types", draft-kaplan-stir-ikes- 949 out-00, July 2013. 951 [RFC4474] Peterson, J., and Jennings, C., "Enhancements for 952 Authenticated Identity Management in the Session Initiation 953 Protocol (SIP)", RFC 4474, August 2006. 955 [draft-4474bis] Peterson, J., Jennings, C., and Rescorla, E., 956 "Authenticated Identity Management in the Session Initiation 957 Protocol (SIP)", draft-jennings-dispatch-rfc4474bis-00, May 958 2013. 960 [DKIM] Allman, E., et al, "DomainKeys Identified Mail (DKIM) 961 Signatures", RFC 4871, May 2007. 963 Author's Address 965 Hadriel Kaplan 966 Email: hadrielk@yahoo.com 968 Appendix A. Possible Deployment Model 970 In order to understand how CIDER could work in the real world, this 971 section provides an example of how CIDER could be deployed in the 972 North American Numbering Plan (NANP). This was chosen for the 973 example because the NANP is one of the most complicated numbering 974 models in the World: it has 24 member countries and territories, 975 full number portability for both fixed and mobile line numbers in 976 certain countries, separate numbering authorities (e.g., CRTC/CNA 977 and NANC/NANPA), and multi-tiered numbering assignment/delegation 978 behavior. 980 Today, the entire +1 NANP is administered by the North American 981 Numbering Plan Administrator (NANPA), but certain functions are 982 handled by separate organizations: the Canadian Number Administrator 983 (CNA) handles certain functions for Canadian area-codes, for 984 example, and the USA and Canada each have a separate administrator 985 for their respective number portability databases. Within each 986 country, numbers are officially assigned in blocks to legally- 987 authorized carriers, who then (unofficially) assign them to their 988 customers: non-carrier service providers, enterprises, and 989 consumers. For the countries in NANP that support number 990 portability, the original carrier "donates" the ported number to 991 another carrier, and the number portability database is updated with 992 a mapping of the ported number to an assigned switch number: the 993 Location Routing Number (LRN). Numbers are not portable across 994 countries within the NANP, and are not portable in certain cases 995 even within a country. 997 One way CIDER could be deployed in the NANP is by having NANPA be 998 the CIDER Registrar for the country-code 1 top domain, and delegate 999 DNS domains for country-specific area-codes to their respective 1000 country administrators. For example, NANPA could be the CIDER 1001 Registrar for '.1.cid.example.org', but then delegate authority of 1002 the DNS subdomains '.4.0.2.1.cid.example.org', 1003 '.6.3.2.1.cid.example.org', etc., (representing the Canadian area 1004 codes 204, 236, etc.) to the CRTC/CNA if they wish it. Thus the 1005 CRTC/CNA would be the CIDER Registrar for those area-code branches 1006 of the number tree. 1008 An alternative would be to have a private organization be the CIDER 1009 Registrar for the +1 country-code using its own domain for the 1010 Registry, such as '.1.example.org'. This would only be useful if 1011 carriers/service-providers agreed to use this Registry, of course, 1012 but this might make sense as a way to get the effort started and 1013 eventually transition it over to NANPA. 1015 One specific model for who the Registrar could be would be to use 1016 the same administrator as that used for number portability. 1017 Currently the US-based FCC selects a company to run the NPAC (Number 1018 Portability Administration Center) for the US, and the CRTC selects 1019 one for Canada; they could contract the CIDER Registrar role to the 1020 same companies they contract number portability administration to. 1021 This has some obvious benefits, but also some drawbacks with regard 1022 to federal regulatory involvement and monopoly-type power/position 1023 for the contracted vendor(s). 1025 Regardless of whom the Registrar is and what the Registry top domain 1026 name is, the officially assigned carriers for numbers would be 1027 designated as the Assignees of their respective number identity 1028 nodes. They can upload public keys for those number nodes, in order 1029 to perform the role of caller-id signers. When they assign numbers 1030 to their customers, they could either add them as Key Agents in the 1031 Registry, or handle them as Private Agents, as described in Section 1032 6.1. In practice, it's likely they would only add their customers 1033 as Key Agents if the "customers" were service providers, but 1034 otherwise handle customers as Third-Party Private Agents. 1036 When a number is ported from one carrier to another, the Assignee 1037 carrier would transfer assignee control by "donating" their identity 1038 to the other carrier, as described in Section 6. This would need to 1039 occur at the same general time as porting the number in the number 1040 portability databases, and would need to take effect within 15 1041 minutes. 1043 Having a defined protocol between the Assignee and the Registry, for 1044 publishing the keys into identity nodes, would help this process 1045 greatly. This would be implemented in the same carrier back-office 1046 systems that are used today for number porting, for example. 1048 From a DNS query access perspective, it is likely that the CIDER 1049 Registry for NANP begin as a private database model. Only 1050 authorized entities would be able to query the CIDER Registry, 1051 either using IPSEC/VPN-style access, or by having each carrier have 1052 a local read-only copy of the CIDER Registry. 1054 Most carriers would likely have such local copies of the Registry, 1055 in servers they deploy within their core call control network, to 1056 reduce verification time and control availability/reliability. All 1057 500 million current NANP numbers instantiated in a CIDER Registry 1058 would fit in ~500GB, which even laptops have sufficient storage for. 1059 It would only take two or three modern high-end servers to fit it 1060 all in *RAM*, let alone hard-drive/flash. 1062 For carriers to have local copies of the Registry, they could use 1063 [AXFR], [IXFR], and [DNS-NOTIFY]; or a more-efficient protocol could 1064 be defined for this purpose. Modern DNS servers offer more than 1065 just the legacy DNS-based zone transfer/update protocols, and the 1066 newer protocols could be investigated for re-use for CIDER local 1067 copying. 1069 If each national CIDER Registry is not publicly accessible for DNS 1070 querying on the public Internet, this causes some issues for 1071 international call scenarios. The goal of CIDER is to enable 1072 caller-id verification even for international calls/communications. 1073 This is still achievable, however, because there aren't that many 1074 country-codes and national numbering plans - there are approximately 1075 ~160 such in the World. 1077 Therefore, it is reasonable for each national CIDER Registry to have 1078 a private, controlled connection to every other national Registry, 1079 creating a full mesh of connections. The private connections could 1080 be used to either provide server resolution of private DNS queries 1081 on behalf of the local nation's carriers' verification clients, or 1082 for the local nation's Registrar to itself have a local copy of the 1083 CIDER Registry of other nations, using the same protocol mechanics 1084 as the carriers use for their local Registry copies. Even 10 1085 Billion number entries in a CIDER Registry read-only database would 1086 only consume ~10 Terabytes of storage, which is achievable for 1087 reasonable cost today. In practice, each national Registry would 1088 likely use a hybrid model: performing DNS queries to nations that 1089 are infrequent callers, while having local copies of Registries of 1090 frequent calling nations. 1092 Appendix B. Requirements for a CAPP Mechanism 1094 In order for CIDER to be usable in large scale across many carriers, 1095 there needs to be a defined protocol for how CIDER Assignees perform 1096 their allowed actions to the Registry. This document describes such 1097 a protocol as CIDER Assignee Publishing Protocol (CAPP), and this 1098 section gives the requirements for such a protocol, as input to 1099 another document to specify the CAPP protocol itself. Some of the 1100 requirements are based on the actions described in Section 6. 1102 Requirements for CAPP: 1103 o It must support the add, modify, and delete actions for CIDER 1104 identity node data. 1105 o It may only support handling the data in an opaque/blob 1106 manner. For example CAPP may only support uploading a TXT RR 1107 text string, instead of explicitly handling the public key 1108 value, version, and key type as discrete elements. This way 1109 it's not specific to CIDER usage. 1110 o It should support the add, modify, or delete actions for other 1111 DNS Resource Record types, or at least be extensible to do so 1112 in the future. This would allow non-CIDER usage, as well as 1113 allow extending CIDER for other number mapping use-cases: such 1114 as CNAM, number portability, or request routing purposes. 1115 o When adding new public key data (or a new TXT RR), it should 1116 be possible for the Assignee not to specify the key index 1117 (i.e., subnode) value for the new record, and instead for the 1118 server to return the new value it allocates. This is useful 1119 for Third-Party Private Agent model, where the Third-Party may 1120 not know the next available index value to use. 1121 o It should support a means of adding new data and returning the 1122 new key index value in separate transactions - or at least in 1123 some manner that allows for multiple minutes of time to pass 1124 between the addition of data and returning of new index value. 1125 o When adding new data, it must allow the Assignee to define an 1126 expiration time for the data. This is useful for the Third- 1127 Party Agent model described in Section 6.1, for example. 1128 o It must allow the Assignee to permanently transfer the 1129 Assignee role to another party, called "donate" in this 1130 document. 1131 o It should allow the Assignee to grant/rescind another entity 1132 the role of Key Agent for a given identity entry node, 1133 permanently or with an expiration time. 1134 o It must support an action/transaction model that allows for 1135 database atomicity, consistency, isolation, and durability 1136 (ACID). 1137 o It should provide a means for the Assignee to add or modify 1138 multiple identity node entries using one TXT RR (or one public 1139 key) in one transaction. This is a useful optimization for 1140 carriers that have millions of numbers, and re-use public keys 1141 across them. To support ACID more easily, however, this might 1142 be done using an indirection model. 1143 o It must specify distinct failure and error results, in a 1144 machine-consumable fashion. 1145 o It must support a means of logging each transaction 1146 (action/result) on both the client and server side such that 1147 both sides can easily reference the same event; for example by 1148 encoding transaction identifiers and timestamps in the CAPP 1149 protocol messages. 1150 o It must support a means for the Registry server to 1151 authenticate a client Assignee; for example using credentials 1152 of a username/password digest-challenge model. 1153 o It must support a means for the client Assignee to 1154 authenticate the Registry server; for example by using TLS 1155 server-side certificates. 1156 o It must support a means of preventing eavesdropping and 1157 repudiation, for example by using TLS.