ENUM Validation Token Format Definition
RFC 5105

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                           O. Lendl
Request for Comments: 5105                                       enum.at
Category: Standards Track                                  December 2007

                ENUM Validation Token Format Definition

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   An ENUM domain name is tightly coupled with the underlying E.164
   number.  The process of verifying whether the Registrant of an ENUM
   domain name is identical to the Assignee of the corresponding E.164
   number is commonly called "validation".  This document describes a
   signed XML data format -- the Validation Token -- with which
   Validation Entities can convey successful completion of a validation
   procedure in a secure fashion.

Table of Contents

   1. Introduction ....................................................2
   2. Data Requirements ...............................................2
   3. Digital Signature ...............................................3
   4. Field Descriptions ..............................................4
      4.1. The <validation> Element ...................................4
      4.2. The <tokendata> Element ....................................5
   5. Examples ........................................................6
      5.1. Unsigned Token without Registrant Information ..............6
      5.2. Signed Token ...............................................6
   6. Formal Syntax ...................................................8
      6.1. Token Core Schema ..........................................9
      6.2. Token Data Schema .........................................10
   7. Other Applications of the Token Concept ........................12
   8. IANA Considerations ............................................12
   9. Security Considerations ........................................13
   10. Acknowledgements ..............................................14
   11. References ....................................................14
      11.1. Normative References .....................................14
      11.2. Informative References ...................................15

Lendl                       Standards Track                     [Page 1]
RFC 5105                 ENUM Validation Token             December 2007

1.  Introduction

   In the case where an ENUM (E.164 Number Mapping [1]) domain name
   corresponds to an existing E.164 number [2], the delegation of this
   domain needs to be authorized by the Assignee of the corresponding
   E.164 number.  In the role model described in [15], the entity that
   performs this check is called the Validation Entity (VE).

   By conveying an ENUM Validation Token -- a signed XML document -- to
   the Registry, a VE certifies that delegation requirements have been
   met and are current.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

2.  Data Requirements

   In this model, the Token is the only piece of data passed from the VE
   to the Registry.  Therefore, the Token needs to contain at least as
   much information as the Registry requires to grant the delegation of
   the requested ENUM domain according to its registration policy.  As
   such, the Registry will need confirmation that:

   o  the Token was created by an accredited VE,

   o  the Token's duration of validity conforms to the policy,

   o  the validation procedure employed has met minimum requirements as
      set forth by policy,

   o  and that the Token is protected against tampering and replay
      attacks.

   Beyond such mandatory information, the Token may optionally include
   number holder information, in particular, to simplify future
   revalidations.

   For example, if initial validation requires the steps "Check the
   identity of the Registrant" and "Check the ownership of an E.164
   number", then a later revalidation only needs to re-check the
   ownership as the identity of the Registrant does not change.

   As the Token will be included (see e.g., [16]) in XML-based Registry/
   Registrar protocols like the Extensible Provisioning Protocol (EPP)
   [13], it is a natural choice to use XML to encode Validation Tokens.

Lendl                       Standards Track                     [Page 2]
RFC 5105                 ENUM Validation Token             December 2007

3.  Digital Signature

   According to the architecture model the propriety of an ENUM
   delegation depends on the trust relationship between the Registry and