ENUM Validation Token Format Definition
RFC 5105
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
Show full document text