ENUM Validation Token Format Definition
Extracted elements (23)
An RSA-based signature scheme was chosen because it does not inherently require a public key infrastructure: whether the Registry acts as a CA, accepts certs from a public CA, or uses pre-registered keys is a local policy choice with no mandated PKI hierarchy.
RSA-SHA1 is required for backward compatibility but RSA-SHA256 is added because recent cryptanalysis has cast doubt on SHA1 security. Registry local policy specifies acceptable algorithms, allowing operators to phase out weaker choices over time.
The 'enveloped' XML-DSIG signature mode is used to make the digital signature an integral part of the token so it travels with the token through intermediaries (e.g., Registrars) who may relay the token without any role in asserting the right-to-use.
The optional <tokendata> section is designed to simplify future revalidations: because Registrant identity does not change, a later revalidation only needs to re-check number ownership rather than repeating all initial validation steps.
XML was chosen as the token encoding format because tokens are embedded in XML-based Registry/Registrar protocols such as EPP, making XML the natural choice for interoperability with existing provisioning infrastructure.
The token concept may apply beyond ENUM to other registry use cases requiring proof of an underlying right, such as TLD sunrise phases (trademark verification) or Number Portability databases where similar right-to-use verification is required.
Validation Tokens are designed to be carried within EPP-based Registry/Registrar protocols; RFC 5076 defines the ENUM Validation Information Mapping for EPP. Exclusive XML canonicalization is specifically required to handle namespace inheritance when the token is embedded in such enclosing XML documents.
Exclusive XML canonicalization (W3C Exclusive C14N, referenced via RFC 3275) MUST be used when signing a Validation Token so that namespace declarations inherited from surrounding XML documents (e.g., an enclosing EPP envelope) do not invalidate the signature.
The Registry MUST define which signature algorithms and key sizes it will accept in Validation Tokens as part of its local policy.
To avert replay attacks, local policy MUST specify how long after <executionDate> a Token may be used to authorize a delegation.
Validation Entities MUST be able to embed X.509 certificates in the token signature, enabling signature verification without a separate key server.
Validation Entities MUST be able to sign tokens according to XML-DSIG, MUST support RSA-SHA1 and RSA-SHA256, and MUST support RSA key sizes of 1024 and 2048 bits.
When processing a delegation request, the Registry MUST verify that the information contained in the Token matches the delegation request, and MUST verify that the expirationDate (or its absence) conforms to Registry policy.
The optional <tokendata> element carries registrant contact information including organization, commercialregisternumber, title, firstname, lastname, address (with sub-fields streetName, houseNumber, postalCode, locality, countyStateOrProvince, ISOcountryCode), and up to 10 each of phone, fax, and email elements. ISOcountryCode uses ISO 3166-1:2006 alpha-2 codes.
The <validation> element is the mandatory core of a Validation Token, containing: a unique serial attribute, E164Number, optional lastE164Number (for number block validation), validationEntityID, registrarID, methodID, executionDate, and optional expirationDate. All dates are RFC 3339 full-date strings; a missing expirationDate indicates infinite validity.
The Validation Token is a signed XML document conveying that a Validation Entity (VE) has verified the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number. It is the sole artifact passed from the VE to the Registry to authorize ENUM domain delegation.
IANA registered four URNs under RFC 3688: namespace urn:ietf:params:xml:ns:enum-token-1.0, schema urn:ietf:params:xml:schema:enum-token-1.0, namespace urn:ietf:params:xml:ns:enum-tokendata-1.0, and schema urn:ietf:params:xml:schema:enum-tokendata-1.0. The IDs used in validationEntityID, registrarID, and methodID are subject to local policy and require no IANA registration.
A valid XML-DSIG signature is necessary but not sufficient for a valid Token. The Registry must additionally verify: (1) the signature uses approved transforms and cryptographic algorithms, (2) the signature references the <token> element (not a sub-element), and (3) the signing key belongs to an accredited VE.
Moving the Id='TOKEN' attribute from the <token> root element to any sub-element (e.g., <tokendata>) would make the signature worthless because the signature would no longer cover the complete token. The <Reference URI='#TOKEN'> combined with Id='TOKEN' on <token> guarantees full coverage.
The <registrarID> element in the Token prevents a malicious second Registrar from reusing an eavesdropped Token to register a domain under its own name; the Registry must verify that the registrarID matches the requesting Registrar.
Token content is not encrypted. If local policy requires confidentiality of the information in the token (e.g., registrant PII in <tokendata>), confidentiality must be provided by a separate mechanism outside this specification.
E164Number fields are XML tokens matching the pattern \+\d\d* with a maximum length of 20 characters. For number block validation, lastE164Number marks the end of the block; both numbers MUST be of identical length to avoid ambiguity.
The token core schema defines shortTokenType (1–20 chars) for serial, validationEntityID, registrarID, and methodID. The tokendata schema uses E115StringUb256 (1–256 chars, Unicode-safe) for contact name/address fields and TokenType (1–64 chars) for phone, fax, and email elements.