idnits 2.17.1 draft-ietf-enum-validation-token-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 743. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 749. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 9, 2007) is 6098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (ref. '1') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 4051 (ref. '5') (Obsoleted by RFC 6931) -- Obsolete informational reference (is this intentional?): RFC 4930 (ref. '13') (Obsoleted by RFC 5730) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM -- Telephone Number Mapping O. Lendl 3 Working Group enum.at 4 Internet-Draft August 9, 2007 5 Intended status: Informational 6 Expires: February 10, 2008 8 ENUM Validation Token Format Definition 9 draft-ietf-enum-validation-token-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 An ENUM domain name is tightly coupled with the underlying E.164 43 number. The process of verifying whether the Registrant of an ENUM 44 domain name is identical to the Assignee of the corresponding E.164 45 number is commonly called "validation". This document describes an 46 signed XML data format -- the Validation Token -- with which 47 Validation Entities can convey successful completion of a validation 48 procedure in a secure fashion. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Data Requirements . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Digital Signature . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Field Descriptions . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. The Element . . . . . . . . . . . . . . . . . 5 60 4.2. The Element . . . . . . . . . . . . . . . . . 5 62 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Unsigned Token without Registrant Information . . . . . . 6 64 5.2. Signed token . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. Token Core Schema . . . . . . . . . . . . . . . . . . . . 9 68 6.2. Token Data Schema . . . . . . . . . . . . . . . . . . . . 10 70 7. Other applications of the Token concept . . . . . . . . . . . 12 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 Intellectual Property and Copyright Statements . . . . . . . . . . 17 85 1. Introduction 87 In the case where an ENUM (E.164 Number Mapping [1]) domain name 88 corresponds to an existing E.164 number [2] the delegation of this 89 domain needs to be authorized by the Assignee of the corresponding 90 E.164 number. In the role model described in [15] the entity which 91 performs this check is called the Validation Entity (VE). 93 By conveying an ENUM Validation Token - a signed XML document - to 94 the Registry a VE certifies that delegation requirements have been 95 met and are current. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [3]. 101 2. Data Requirements 103 In this model, the Token is the only piece of data passed from the VE 104 to the Registry. Therefore, the Token needs to contain as least as 105 much information as the Registry requires to grant the delegation of 106 the requested ENUM domain according to its registration policy. As 107 such, the Registry will need confirmation that 108 o the Token was created by an accredited VE, 109 o the Token's duration of validity conforms to the policy, 110 o the validation procedure employed has met minimum requirements as 111 set forth by policy, 112 o and that the Token is protected against tampering and replay 113 attacks. 115 Beyond such mandatory information, the Token may optionally include 116 number holder information, in particular to simplify future re- 117 validations. 119 For example, if initial validation requires the steps "Check the 120 identity of the Registrant" and "Check the ownership of an E.164 121 number" then a later revalidation only needs to re-check the 122 ownership as the identity of the Registrant does not change. 124 As the Token will be included (see e.g. [16]) in XML-based Registry/ 125 Registrar protocols like the Extensible Provisioning Protocol (EPP) 126 [13] it is a natural choice to use XML to encode Validation Tokens. 128 3. Digital Signature 130 According to the architecture model the propriety of an ENUM 131 delegation depends on the trust relationship between the Registry and 132 the VE. In general, an untrusted link between Registry and VE should 133 be assumed (for instance the Token is passed along with the 134 registration request by a Registrar, who might have no role in 135 asserting the right-to-use). Therefore, the Token must be protected 136 against forgery, tampering and replay-attacks. 138 A digital signature on the token 139 o asserts that the token was indeed generated by the indicated VE 140 (authenticity) 141 o guarantees that the token was not tampered with in transit 142 (integrity) 143 o enables auditing the validation process (non-repudiation). 145 The cryptographic signature on the token follows RFC 3275 (XML-DSIG 146 [4]). As tokens might be transmitted as part of an already XML based 147 protocol the exclusive XML canonicalization [9] MUST be used. This 148 transform guarantees that namespace declarations inherited from the 149 surrounding XML do not invalidate the signature. In order to make 150 the signature an integral part of the token the "enveloped"-signature 151 mode is employed. The signature covers all information contained in 152 the Token. 154 XML-DSIG offers a number of cryptographic algorithms for digesting 155 and signing documents and recommends SHA1/RSA-SHA1. Recent advances 156 in cryptanalysis have cast doubt on the security of SHA1 thus 157 rendering this recommendation obsolete (see e.g. the Security 158 Considerations of [14]). RFC 4051 [5] defines how additional 159 algorithms can be used with XML-DSIG. 161 Validation Entities MUST be able to sign tokens according to XML- 162 DSIG, MUST support RSA-SHA1 and RSA-SHA256 [5], MUST support RSA key 163 sizes of 1024 and 2048 bits, and MUST be able to embed X.509 [10] 164 certificates. The Registry MUST define which signature algorithms 165 and key sizes it will accept in Validation Tokens as part of its 166 local policy. 168 The choice of a RSA-based signature does not require a public key 169 infrastructure. Whether the Registry acts as a certification 170 authority, accepts certs from a public certification authority, or 171 only accepts pre-registered keys is a local policy choice. 173 4. Field Descriptions 175 The Validation Token is structured into three parts: the basic 176 validation information, additional information about the Registrant, 177 and the digital signature. The XML schema can be found in Section 6. 179 4.1. The Element 181 A token MUST contain a element which contains the 182 following: 183 o A single validation "serial" attribute identifying a validation 184 token for a certain VE. It must be unique per VE. 185 o A single element containing the underlying E.164 186 number in fully qualified (international) format. 187 o An optional element. If present it indicates 188 that the whole number block starting with up to and 189 including has been validated. To avoid 190 ambiguity, both numbers MUST be of the same length. 191 o A single element identifying the VE. 192 o A single element identifying the Registrar on whose 193 behalf the validation was performed. 194 o A single element identifying the method used by the VE 195 for validation. 196 o A single attribute containing the date of 197 validation formatted as "full-date" according to RFC 3339 [6]. 198 o An optional attribute marking the expiration date 199 of the validation token formatted as "full-date" according to RFC 200 3339. The Registry will automatically revoke the delegation at 201 this date unless a new Token has been submitted that extends the 202 lifetime of the validation. A missing expirationDate indicates 203 infinite validity of the Token. 205 The format and the uniqueness-constraints of these IDs is left to the 206 local policy of the Registry. 208 4.2. The Element 210 A token may contain a section containing information 211 about the number holder, consisting of the the following elements: 212 o A single element containing the full name of the 213 organization to which the Registrant is affiliated. 214 o A single element. If the Registrant is 215 a company, then this field can be used to uniquely identify this 216 company by its official registration number within the local 217 country. The interpretation of this field is thus country- 218 specific. 219 o A single element 220 o A single <firstname> element 221 o A single <lastname> element 222 o A single <address> section containing the following elements: 223 * A single optional <streetName> 224 * A single optional <houseNumber> 225 * A single optional <postalCode> 226 * A single optional <locality> 227 * A single optional <countyStateOrProvince> 228 * A single optional <ISOcountryCode> 229 o up to 10 <phone> elements containing full E.164 numbers 230 o up to 10 <fax> elements containing full E.164 numbers 231 o up to 10 <email> elements 233 All elements directly under <tokendata> are optional. The 234 <ISOcountryCode> element specifies the country using the alpha-2 235 country code from ISO 3166-1:2006 [11] (including updates published 236 by the 3166 Maintenance Agency). The definition of the first five 237 elements within the <address> element conforms to the second version 238 of the E.115 Computerized Directory Assistance [17]. 240 5. Examples 242 5.1. Unsigned Token without Registrant Information 244 This basic Token without any information about the Registrant and 245 without the cryptographic signature shows the basic layout of the 246 Token. 248 <?xml version="1.0" encoding="utf-8" standalone="no" ?> 249 <token xmlns="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN" 250 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 251 xsi:schemaLocation= 252 "urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd"> 253 <validation serial="acmeve-000002"> 254 <E164Number>+442079460200</E164Number> 255 <lastE164Number>+442079460499</lastE164Number> 256 <validationEntityID>ACME-VE</validationEntityID> 257 <registrarID>reg-4711</registrarID> 258 <methodID>42</methodID> 259 <executionDate>2007-05-08</executionDate> 260 <expirationDate>2007-11-01</expirationDate> 261 </validation> 262 </token> 264 5.2. Signed token 266 This example uses an X.509 based signature which includes the 267 certificate of the signing validation entity. Thus the validity of 268 the signature can be verified without the need for a key-server. A 269 valid signature is a necessary, but not sufficient condition for a 270 valid Token. Any entity evaluating a Token needs to check other 271 factors as well, e.g. the certificate and the XML schema. 273 <?xml version="1.0" encoding="utf-8" standalone="no" ?> 274 <token xmlns="urn:ietf:params:xml:ns:enum-token-1.0" Id="TOKEN" 275 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 276 xsi:schemaLocation= 277 "urn:ietf:params:xml:ns:enum-token-1.0 enum-token-1.0.xsd"> 278 <validation serial="acmeve-000001"> 279 <E164Number>+442079460123</E164Number> 280 <validationEntityID>ACME-VE</validationEntityID> 281 <registrarID>reg-4711</registrarID> 282 <methodID>42</methodID> 283 <executionDate>2007-05-08</executionDate> 284 </validation> 285 <tokendata xmlns="urn:ietf:params:xml:ns:enum-tokendata-1.0" 286 xsi:schemaLocation= 287 "urn:ietf:params:xml:ns:enum-tokendata-1.0 enum-tokendata-1.0.xsd"> 288 <contact> 289 <organisation>Example Inc.</organisation> 290 <commercialregisternumber>4711</commercialregisternumber> 291 <title>Dr. 292 Max 293 Mustermann 294
295 Main 296 10 297 1010 298 London 299 London 300 GB 301
302 +442079460123 303 mm@example.com 304 305 306 307 308 310 312 313 314 316 318 321 322 323 325 VxqsBxSNPFwPAUlCHts3g3DehcexnB1dqUz+GypLZ0k= 327 328 329 330 QKqphKRNPokVZFbenje+HZZV+RLrNweGnlWBw7ngAtH+rtuslR8LhMLmC4DlBb9V 331 HvKItl+7zLGm3VgYsqfHH8q3jCl1mFxUIuLlIPqtpJs+xAHAJDzZ+vmsF/q2IgrS 332 K0uMmKuU5V1gydDBOvIipcJx+PrPYyXYZSjQXkWknK8= 333 334 335 336 MIIDZjCCAs+gAwIBAgIBBDANBgkqhkiG9w0BAQQFADB0MQswCQYDVQQGEwJBVDEP 337 MA0GA1UEBxMGVmllbm5hMRQwEgYDVQQKEwtCT0ZIIENlcnRzLjEbMBkGA1UEAxMS 338 Q0VSVFMuYm9maC5wcml2LmF0MSEwHwYJKoZIhvcNAQkBFhJjZXJ0c0Bib2ZoLnBy 339 aXYuYXQwHhcNMDQwNzIwMTMxNTA5WhcNMDUwNzIwMTMxNTA5WjB/MQswCQYDVQQG 340 EwJBVDEKMAgGA1UECBMBLTEPMA0GA1UEBxMGVmllbm5hMR0wGwYDVQQKExRBY21l 341 IEVOVU0gVmFsaWRhdGlvbjEQMA4GA1UEAxMHYWNtZS1WRTEiMCAGCSqGSIb3DQEJ 342 ARYTbm9ib2R5QGVudW0tYWNtZS5hdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC 343 gYEArJPcjMFc54/zwztSdQXGxUtodJT9r1qGI2lQPNjLvtPJg93+7o5SIOsZGSpg 344 zWbztDAV5qc7PHZWUVIyf6MbM5qSgQDVrjNRhTosNtyqmwi23BH52SKkX3P7eGit 345 LmqEkiUZRxZhZ6upRbtcqvKSwmXitvW4zXZhkVHYJZ2HuMcCAwEAAaOB/DCB+TAJ 346 BgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0 347 aWZpY2F0ZTAdBgNVHQ4EFgQUyK4otTQtvv6KdSlMBOPT5Ve18JgwgZ4GA1UdIwSB 348 ljCBk4AUvfPadpm0HhmZx2iAVumQTwgnG2eheKR2MHQxCzAJBgNVBAYTAkFUMQ8w 349 DQYDVQQHEwZWaWVubmExFDASBgNVBAoTC0JPRkggQ2VydHMuMRswGQYDVQQDExJD 350 RVJUUy5ib2ZoLnByaXYuYXQxITAfBgkqhkiG9w0BCQEWEmNlcnRzQGJvZmgucHJp 351 di5hdIIBADANBgkqhkiG9w0BAQQFAAOBgQCB9CHBnIUhrdic4h5Ar4hdxjHSQkDH 352 sJWd+MYrNcuSrv3TIOsUkUgNpNNhmkZPtiXqfy3388IRdJtJiLWXSOb/XlZHOM9I 353 MvwKYwhcpQ9UdM/w7VpXQqf+CEj0XSyqxGw65UsHIOijgiG/WyhSj+Lzriw7CTge 354 P2iAJkJVC4t2XA== 355 356 357 358 359 361 6. Formal Syntax 363 The formal syntax of the validation token is specified using XML 364 schema notation [7] [8]. Two schemas are defined: The "token core 365 schema" contains mandatory attribute definitions, the "token data 366 schema" defines the format of the optional "tokendata" section. The 367 BEGIN and END tags are not part of the schema; they are used to note 368 the beginning and ending of the schema for URI registration purposes. 370 6.1. Token Core Schema 372 BEGIN 373 375 382 384 386 389 390 391 enum.at Validation Token core schema 392 393 395 397 398 399 400 401 402 404 405 406 407 408 410 412 413 414 416 418 420 422 424 425 427 428 430 432 433 434 436 438 439 440 441 442 443 END 445 6.2. Token Data Schema 447 BEGIN 448 450 455 456 457 458 459 460 462 463 464 465 466 467 469 470 471 472 473 474 476 477 478 479 480 481 483 484 485 487 489 491 493 495 497 498 500 501 502 505 507 509 511 513 515 517 519 521 522 524 525 526 527 528 530 531 532 533 534 536 537 END 539 7. Other applications of the Token concept 541 The concept of the validation token may be useful in other registry- 542 type applications where the proof of an underlying right is a 543 condition for a valid registration. 545 An example is a TLD (Top Level Domain) where registration is subject 546 to proof of some precondition, like a trade mark or the right in a 547 name. Such situations often arise during the introduction of a new 548 TLD, e.g. during a "sunrise" phase. 550 A Number Portability (NP) database faces very similar verification 551 issues. An NP system based on the Token concept could potentially be 552 superior to current methods, and aid in the convergence of NP and 553 ENUM. 555 8. IANA Considerations 557 This document uses URNs to describe XML namespaces and XML schemas 558 conforming to a registry mechanism described in RFC 3688 [12]. Four 559 URI assignments are requested. 560 1. Registration request for the Token namespace: 561 * URI: urn:ietf:params:xml:ns:enum-token-1.0 562 * Registrant Contact: See the "Author's Address" section of this 563 document. 564 * XML: None. Namespace URIs do not represent an XML 565 specification. 566 2. Registration request for the Token XML schema: 567 * URI: urn:ietf:params:xml:schema:enum-token-1.0 568 * Registrant Contact: See the "Author's Address" section of this 569 document. 570 * XML: See Section 6.1 of this document. 571 3. Registration request for the Token Data namespace: 572 * URI: urn:ietf:params:xml:ns:enum-tokendata-1.0 573 * Registrant Contact: See the "Author's Address" section of this 574 document. 575 * XML: None. Namespace URIs do not represent an XML 576 specification. 577 4. Registration request for the Token Data XML schema: 578 * URI: urn:ietf:params:xml:schema:enum-tokendata-1.0 579 * Registrant Contact: See the "Author's Address" section of this 580 document. 581 * XML: See Section 6.2 of this document. 583 The IDs used in the validationEntityID, RegistrarID, and methodID 584 elements are subject to local policy and thus do not require IANA 585 registration. 587 9. Security Considerations 589 The security of the Validation Token depends on the security of the 590 underlying XML DSIG algorithms. As such, all the security 591 considerations from [4] apply here as well. Two points from there 592 merit repetition: 594 Transforms are used to select the relevant data for signing and to 595 discard irrelevant information (e.g. pretty-printing and name-space 596 local names). 598 The element and attribute combined with the 599 Id="TOKEN" attribute in specifies that the signature should 600 cover the complete token. Moving the Id="TOKEN" attribute to e.g. 601 the element would make the signature worthless. 603 It is thus critical that the Registry does not only check whether the 604 Token passes a generic XML-DSIG signature check, but also that the 605 signature uses approved transforms and cryptographic algorithms and 606 references the element as well as that the certificate 607 belongs to an accredited VE. 609 The Token content is not encrypted. If local policy dictates that 610 the information contained within the token should be confidential 611 then this has to be handled through a different mechanism. 613 When processing a delegation request the Registry MUST verify that 614 the information contained in the Token matches the delegation 615 request. The element in the Token prevents a malicious 616 second Registrar from using an eavesdropped Token to register a 617 domain in his name. The Registry MUST verify that the 618 given (including the case of no given expiration 619 date) conforms to the Registry's policy. To avert replay attacks, 620 local policy MUST specify for how long after the 621 Token can be used to authorize a delegation. 623 10. Acknowledgements 625 The author would like to thank the following persons for their 626 valuable suggestions and contributions: Michael Haberler, Alexander 627 Mayrhofer, Bernie Hoeneisen, Michael Braunoeder, Staffan Hagnell, 628 Lawrence Conroy, Tony Rutkowski. 630 11. References 632 11.1. Normative References 634 [1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 635 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 636 Application (ENUM)", RFC 3761, April 2004. 638 [2] ITU-T, "The international public telecommunication numbering 639 plan", Recommendation E.164, May 1997. 641 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 642 Levels", BCP 14, RFC 2119, March 1997. 644 [4] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 645 Language) XML-Signature Syntax and Processing", RFC 3275, 646 March 2002. 648 [5] Eastlake, D., "Additional XML Security Uniform Resource 649 Identifiers (URIs)", RFC 4051, April 2005. 651 [6] Klyne, G. and C. Newman, "Date and Time on the Internet: 652 Timestamps", RFC 3339, July 2002. 654 [7] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML 655 Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, 656 May 2001. 658 [8] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C 659 REC REC-xmlschema-2-20010502, May 2001. 661 [9] Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML 662 Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 663 20020718, July 2002. 665 [10] International Telecommunications Union, "Information technology 666 - Open Systems Interconnection - The Directory: Public-key and 667 attribute certificate frameworks", ITU-T Recommendation X.509, 668 ISO Standard 9594-8, March 2000. 670 [11] International Organization for Standardization, "Codes for the 671 representation of names of countries and their subdivisions -- 672 Part 1: Country codes, 2nd edition", ISO Standard 3166, 673 November 2006. 675 [12] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 676 January 2004. 678 11.2. Informative References 680 [13] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 681 RFC 4930, May 2007. 683 [14] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 684 and Identifiers for RSA Cryptography for use in the Internet 685 X.509 Public Key Infrastructure Certificate and Certificate 686 Revocation List (CRL) Profile", RFC 4055, June 2005. 688 [15] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation Architecture", 689 RFC 4725, November 2006. 691 [16] Hoeneisen, B., "ENUM Validation Information Mapping for the 692 Extensible Provisioning Protocol", 693 draft-ietf-enum-validation-epp-06 (work in progress), 694 July 2007. 696 [17] ITU-T, "Computerized Directory Assistance Version 2", 697 Recommendation E.115v2, October 2005. 699 Author's Address 701 Otmar Lendl 702 enum.at GmbH 703 Karlsplatz 1/2/9 704 Wien A-1010 705 Austria 707 Phone: +43 1 5056416 33 708 Email: otmar.lendl@enum.at 709 URI: http://www.enum.at/ 711 Full Copyright Statement 713 Copyright (C) The IETF Trust (2007). 715 This document is subject to the rights, licenses and restrictions 716 contained in BCP 78, and except as set forth therein, the authors 717 retain all their rights. 719 This document and the information contained herein are provided on an 720 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 721 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 722 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 723 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 724 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 725 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 Intellectual Property 729 The IETF takes no position regarding the validity or scope of any 730 Intellectual Property Rights or other rights that might be claimed to 731 pertain to the implementation or use of the technology described in 732 this document or the extent to which any license under such rights 733 might or might not be available; nor does it represent that it has 734 made any independent effort to identify any such rights. Information 735 on the procedures with respect to rights in RFC documents can be 736 found in BCP 78 and BCP 79. 738 Copies of IPR disclosures made to the IETF Secretariat and any 739 assurances of licenses to be made available, or the result of an 740 attempt made to obtain a general license or permission for the use of 741 such proprietary rights by implementers or users of this 742 specification can be obtained from the IETF on-line IPR repository at 743 http://www.ietf.org/ipr. 745 The IETF invites any interested party to bring to its attention any 746 copyrights, patents or patent applications, or other proprietary 747 rights that may cover technology that may be required to implement 748 this standard. Please address the information to the IETF at 749 ietf-ipr@ietf.org. 751 Acknowledgment 753 Funding for the RFC Editor function is provided by the IETF 754 Administrative Support Activity (IASA).