Summary

  • RFC 5105 says explicitly that a valid signature is necessary but not sufficient for a valid ENUM Validation Token. The Registry must also verify the signed object, approved transforms and algorithms, accredited Validation Entity key, request match, Registrar binding, dates and replay policy.
  • The token reports a completed validation procedure. It is not the Registry's delegation decision, the EPP result, an authoritative DNS publication, a resolver observation or a completed communication.

A provisioning dashboard receives an XML document, validates its signature and turns the row green. The certificate is embedded. The digest matches. The signature value verifies. For a cryptographic subsystem, that is a useful and precise result.

For the ENUM delegation, it is only the beginning of a decision.

RFC 5105 defined the Validation Token for a particular institutional gap. An ENUM domain name is coupled to an E.164 telephone number. The entity asking for the domain cannot acquire a valid claim merely by being first to a registrar. Somebody must verify that the intended registrant is the number's Assignee, or is acting with the Assignee's authorization. The document calls that checker the Validation Entity, or VE.

The architecture already contains several principals. RFC 4725 distinguishes the E.164 Assignee, the ENUM Registrant, the Validation Entity, the Registrar, the Registry, the DNS service provider and the application service provider. Their records are related, but they are not interchangeable. The VE checks. The Registrar submits. The Registry maintains the master delegation database and authoritative zone. The DNS service provider serves the delegated zone. An application may later use a URI found there.

RFC 5105 gives the VE a portable statement. In its model, the signed token is the only validation data passed to the Registry. It therefore needs enough information for the Registry to apply its own registration policy: who performed the validation, for which number, on behalf of which Registrar, under which method, when it was executed and when it expires.

That is why the token is more than a detached signature. The mandatory validation element carries a serial that must be unique for that VE; an E.164 number; an optional last number defining the end of a block; a Validation Entity identifier; a Registrar identifier; a validation-method identifier; and an execution date. An expiration date is optional. The document also permits a separate optional contact section with organization, company-registration, name, address, phone, fax and email data.

Each field has a scope. The serial is unique per VE, not globally. A collector that stores only serial=000001 has discarded the namespace that made the identifier meaningful. A block claim begins at E164Number and ends at lastE164Number; both numbers must have the same length. A system that strips leading structure, changes normalization or expands the interval has changed the claim. The Registrar ID binds the token to the party on whose behalf validation was performed. The method ID names a locally governed procedure; it does not explain or validate the method by itself.

The signature protects this compound statement while it travels through parties that may not be trusted to assert the right to use the number. RFC 5105 uses XML Signature in enveloped mode. It requires exclusive XML canonicalization because a token may sit inside another XML protocol, and namespace declarations inherited from the outer document must not silently change the signed representation. The signature is intended to cover the complete token.

Those details expose the first operational trap: “XML signature valid” can be true for the wrong claim scope.

The security section points to the combination of Reference URI="#TOKEN" and Id="TOKEN" on the token element. That reference is what makes the signature cover the whole token. Move the ID to the optional contact data and a generic signature engine may still verify a mathematical relationship over that inner element. For the Registry's purpose, the signature has become worthless. The machine proved exactly what it was asked to prove; the surrounding system asked the wrong question.

RFC 5105 consequently requires more than a generic XML-DSIG check. The Registry must verify that approved transforms and cryptographic algorithms were used, that the signature references the token element, and that the key belongs to an accredited VE. In the signed example, the RFC makes the boundary unmistakable: a valid signature is a necessary, but not sufficient, condition for a valid token. It names certificate and XML-schema checks among the additional work.

This distinction is often lost when security components publish one boolean. A signature library can report that a public key validates a signature over a selected node. It cannot, without additional inputs, know whether the key holder remains accredited by this Registry, whether the certificate path was trusted at the decision time, whether the method ID is permitted for this number range, whether the token is fresh enough, or whether the request names the same Registrar and E.164 scope.

Even key trust is deliberately outside one universal rule. RFC 5105 says a Registry may act as a certification authority, accept certificates from a public CA, or accept only pre-registered keys. That is local policy. A certificate embedded in the token is therefore not self-authorizing. It supplies material for validation; it does not select the Registry's trust anchor or confer VE status on its subject.

The audit record needs the trust-store and accreditation epoch, not merely the certificate fingerprint. A key could have been accepted yesterday and removed today. A certificate can remain within its encoded validity interval while the VE loses accreditation under a contractual or policy process. Conversely, a later trust-store change should not automatically rewrite the evidence of a historical decision. The question is which policy and trust state governed when the Registry acted.

Dates create a second false shortcut. An executionDate says when validation occurred. An optional expirationDate says when that validation ends under the token's representation. If expiration is omitted, the format assigns infinite validity. Yet RFC 5105 immediately preserves Registry authority: the Registry must verify that the stated expiration, including its absence, conforms to policy. Local policy must also define how long after execution a token may authorize a delegation in order to prevent replay.

“Unexpired” is therefore not a complete authorization test. A token may carry no expiration while a Registry refuses indefinite validation. It may have a future expiration while the allowed presentation window after execution has already closed. It may be timely but bound to another Registrar. It may match the Registrar yet describe a method no longer accepted for the relevant class of number. Each conclusion needs the relevant policy version and clock.

The Registrar binding illustrates why integrity and authority differ. RFC 5105 assumes that a Registrar carrying the token may have no role in asserting right-to-use. Without a signed Registrar ID, another Registrar that observed the token might submit it in its own name. The Registry must compare the token with the actual delegation request. A perfect signature on a token naming Registrar A is evidence against authorizing a request submitted as Registrar B.

The E.164 match must be equally exact. The Registry needs to compare the requested ENUM domain with the number or closed number block in the token. A signature does not perform that comparison. Nor does it establish that the Assignee relationship remained unchanged after the VE performed its check. RFC 4725 treats recurring validation as a separate process precisely because number assignment and authorization can change during the life of a delegation.

Initial validation, revalidation and revocation are different events. RFC 4725 says an ENUM delegation must track the E.164 assignment. If recurring validation succeeds, the delegation may persist. If it fails, the delegation must be suspended, either through an explicit Registry interaction or automatically when validation expires, subject to any local grace period. A previously signed success cannot overrule a later failed revalidation merely because its bytes still verify.

That lifecycle gives the serial a modest but important role. Per-VE uniqueness can help a Registry distinguish one token from another and detect reuse within the correct namespace. It is not a universal transaction ID and does not prove that the token was consumed only once. A defensible replay ledger joins VE identity, serial, exact token hash, Registrar, number scope, execution date, decision time and the Registry's allowed-use window. It also records whether a prior request was rejected, accepted, superseded or revoked.

Optional contact data should not be allowed to blur the core. Those elements can simplify later revalidation, but every child under tokendata is optional. An organization name or email address may be useful supporting context; it is not a substitute for the signed mandatory validation fields or a current Assignee check. The token content is not encrypted. A system that needs confidentiality must provide it through another mechanism instead of assuming the signature hides personal information.

This matters because confidentiality and authenticity solve different problems. Encryption can conceal the token in transit but say nothing about who created it unless paired with authentication. A signature can authenticate covered content while exposing every field to an intermediary. Transport encryption can protect one hop yet leave a copied token replayable later. The evidence model should say which property existed on which path.

Algorithm labels create another temporal boundary. RFC 5105 required support for RSA-SHA1 and RSA-SHA256 and already noted that cryptanalysis had cast doubt on older SHA-1 recommendations. It left acceptable algorithms and key sizes to Registry policy. A parser recognizing an algorithm URI does not prove that the Registry currently permits it. Historical interoperability support, contemporary security acceptance and the algorithm used by this token are three different records.

Exclusive canonicalization is similarly precise but limited. It can produce stable signed input despite surrounding namespace context. It does not make the XML semantically correct, the schema current, the referenced node appropriate or the business claim true. Canonicalization answers how a representation is normalized for a digest. It does not decide what the representation is allowed to authorize.

After token evaluation comes another set of boundaries. RFC 5076 defines an EPP extension framework for adding, changing, removing and retrieving ENUM validation information. The extension can transport validation records within provisioning commands. A successful EPP response is evidence about that protocol transaction. It is not retroactive proof that every embedded token check was correct, nor is it yet a cache-bypassed observation of the authoritative DNS.

A Registry decision can authorize a delegation before the zone change is published. A database row can exist while generation or distribution fails. Authoritative servers can publish while recursive caches retain an older view. A resolver can obtain a NAPTR record while the named URI is incorrect or the endpoint is unreachable. An application can reach the endpoint and still fail to complete the intended communication. The original signature has no authority over these later systems.

RFC 3761 describes the ENUM lookup machinery that maps E.164-derived domain names toward URIs. That machinery becomes relevant only after a delegation and DNS data exist. The Validation Token is evidence used in deciding whether the delegation may be created or retained. It is not a miniature DNSSEC proof, an authoritative-zone snapshot or a service-health result.

The narrowness is a feature. If a Registry records each transition separately, an incident can be answered without pretending one layer controls the next. Investigators can determine whether the VE signed the wrong number, whether a valid token named the wrong Registrar, whether the Registry accepted an obsolete method, whether an EPP change failed, whether authoritative publication lagged, or whether resolution succeeded but the application did not.

The alternative is one status called “validated.” That word can mean that an identity check ran, that an XML signature verified, that a token passed local policy, that a Registry accepted a request, that an EPP command returned success, that a delegation appeared, or that a resolver observed it. When all of those are compressed into one boolean, the organisation cannot locate authority or failure.

A useful decision ledger starts with immutable inputs. Preserve the exact token bytes and a hash, because reparsing and reserialization can alter XML. Record the XML parser and schema version, the resolved ID and referenced node, transform chain, canonicalized digest input, signature and digest algorithms, signature result, certificate path, trust anchors and revocation evidence. State whether the optional contact section was exposed and under which confidentiality control.

Then record the institutional scope. Capture the VE identity and accreditation state at decision time; the signed VE, Registrar and method identifiers; token serial; exact E.164 start and optional block end; execution and expiration dates; local presentation window; policy version; and normalized delegation request. Emit separate comparisons for signer accreditation, request match, Registrar match, number scope, method permission, date acceptance and replay history.

Finally, keep outcomes as their own receipts: Registry authorization or rejection with reason; EPP transaction ID and result; resulting delegation record; authoritative publication serial or observation; resolver observation with vantage and cache state; returned ENUM data; endpoint attempt; and application result. Clock uncertainty and later revocation must remain visible. A later layer may reference an earlier receipt, but it should not rewrite it.

This is where the RFC aligns with Heng Lu's reality-layer discipline. The signature has real value because it stays inside its claim. It proves a protected statement from a key under defined cryptographic conditions. It becomes dangerous only when an institution lets that clean mathematical result borrow authority from policy, registry operation or running service.

Running-code primacy does not mean ignoring the signed document. It means asking what actually ran at every transition. Did the intended token node verify under an accepted algorithm? Was the key accredited under the Registry's current rules? Did the request match? Did the Registry decide? Did the provisioning command commit? Did the authoritative zone publish? Could independent resolvers see it? Each answer is valuable because none is forced to impersonate the next.

The leadership question is not whether to trust cryptography. It is how much authority to assign to a cryptographic result. RFC 5105 supplies the answer in its own example: signature validity is necessary, not sufficient. A secure organisation should preserve that sentence in its data model.

Sources