IANA Registration for vCard Enumservice
updated by
- rfc-6118 — Update of Legacy IANA Registrations of Enumservices
Extracted elements (14)
The ENUM record itself does not need to contain personal information; it only points to a location where access to personal information could be granted. This separation allows the record to be privacy-neutral (e.g., pointing to an anonymous hosting provider) while still enabling vCard retrieval.
The use of HTTP in this Enumservice allows built-in authentication, authorization, and session control mechanisms (e.g., HTTP Digest Authentication) to restrict access to vCards and even synthesize different vCards based on the client's identity, making access control feasible without additional protocol machinery.
Clients fetching the vCard from the resource indicated by the Enumservice SHOULD expect access to be restricted, and comprehension of the data provided may vary depending on the client's identity.
Considerations for limiting information exposure SHOULD include serving information only to entities of the user's choice and/or limiting the comprehension of the information provided based on the identity of the requestor.
HTTPS SHOULD be preferred over HTTP if the deployed authentication/authorization mechanisms are prone to eavesdropping and replay attacks.
If access restrictions on the vCard resource are deployed, standard HTTP authentication, authorization, and state management mechanisms (as described in RFCs 2617 and 2695) MUST be used to enforce those restrictions.
Users MUST carefully consider the information they provide in the resource identified by the ENUM record as well as in the record itself, including serving information only to entities of the user's choice and/or limiting comprehension based on requestor identity.
Information published in ENUM records could reveal associations between E.164 numbers and their owners, especially if URIs contain personal identifiers or domain names for which ownership information is easily obtainable.
Linking telephone numbers to Personally Identifiable Information (PII) via vCards provides a "reverse lookup" from number to owner. Publication of such PII is covered by data-protection law in many jurisdictions and in most cases requires the explicit consent of the affected individual.
The vCard Enumservice has type "vcard", no subtype, and supports URI schemes "http" and "https". It indicates that the resource identified is a plain vCard per RFC 2426, accessible via HTTP or HTTPS. Intended usage is COMMON.
This document registers the Enumservice "vCard" (type "vcard", no subtype) using URI schemes "http" and "https" in the IANA Enumservice registry, per the process defined in RFC 3761.
ENUM deployments using this Enumservice together with DNSSEC should consider using Minimally Covering NSEC Records (RFC 4470) to prevent zone walking, as vCard PII data constitutes a rich target for such attempts.
ENUM records pointing to third-party resources can be provisioned on purpose by the ENUM domain owner, so any assumption about the association between a number and an entity could be completely bogus unless identity verification is in place.
Since ENUM uses DNS — a publicly available database — any information contained in records provisioned in ENUM domains must be considered public. Even after revoking the DNS entry and removing the referred resource, copies of the information could still be available.