]>
Publishing Information for Entities Identified by Domain NamesStichting NLnet Labsmartin@nlnetlabs.nlInternetDNS OperationsThis memo describes a mechanism to publish information related to an entity
identified through a domain name via the Domain Name System (DNS). In
particular, this mechanism allows publishing the location of topical
documents describing the entity and relationships with other entities. An
example application is the publishing of additional requirements for PKI
certification authorities.Various networking applications operate on entities that need to be
addressed globally. Domain names have been designed to serve as such
globally unique identifiers for the Internet. They have a number of
advantages. They are human readable and reasonably easy to memorize, can
be acquired relatively cheaply and with little administrative hassle. Not
least of all, they are accompanied by an entire system to publish and
query information related to them: the Domain Name System (DNS).This document describes a simple framework that uses the DNS to discover
various aspects of entities identified by domain names: It allows to
publish the location of documents and express relationships with other
entities. Because an entity may serve different purposes, both documents
and relationships can be expressed for different topics.This concept can for example be used for enriching PKI with additional
information conveying policies certification authorities adhere to or
properties they are guaranteed to have by so-called trust schemes vouching
for them. This use case is described below.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 when, and only when, they appear in all
capitals, as shown here.In principle, any domain name can be used as an identifier for an entity.
However, for interoperability with existing infrastructure the name
SHOULD follow the preferred name syntax described in .In order to allow an identifier to be used for multiple purposes,
statements can be published for multiple topics. A topic is chosen by
prepending a two-label topic identifier to the name. An entity identifier
extended in such a way is called the "qualified identifier."First, the underscore label "_topic" is prepended to the domain name to
mark the name as a qualified identifier. Second, the name of the topic is
prepended, i.e., it is added as the label furthest away from the root
label.This topic name needs to be chosen on a bilateral basis between involved
parties. It MUST be a label in preferred name syntax. In particular, this
means that it MUST NOT begin with an underscore.The location to one or more documents related to a specific topic is
announced by publishing the URI for this location via a set of
URI records under the qualified identifier.If multiple URIs are published, all documents they point to are assumed to
have the same content. The priority and weight fields of the record data
govern the order in which URIs are considered. Before attempting to access
any of the location, a client discards all URIs with schemes it cannot or
wishes not to use. Of the remaining set, it MUST use a URI with the
lowest-numbered priority it can reach. It SHOULD select from a set of URIs
with equal priority by weighing the probability according to the weight
value of the record data.An entity can claim that is has a relationship with some other entity
within the context of a certain topic. What that exactly means depends on
the topic in question. Typically, expressing this relationship is a claim
that the entity somehow appears in the document published by the target
entity for this particular topic. Thus, these relationships can be used as
claims that are to be verified via the published topical document.An entity expresses this relationship by publishing a PTR
record under the qualified identifier pointing to the qualified identifier
of the target identity. It can point to a target with a different topic.
What that means depends on the specific application.An entity is free to publish more then one PTR record for a qualified
identifier if it claims to have a relationship with more than one entity.In some cases, a document published by an entity for a certain topic is
being signed to establish its authenticity. In these cases, a client needs
to discover the acceptable certificates used by the entity. This can be
achieved by publishing one or more SMIMEA records under the
qualified identifier.The mechanism described for SMIMEA records is used to limit the
certificates that can be used for signing the published documents.In PKI it is sometimes desirable to enforce additional requirements on
certification authorities (CAs) such as membership in certain organizations
or minimal policies. Such requirements are often guaranteed via third
parties called "trust schemes." These schemes publish a so
called "trust list", a list of the issuer certificates of those CAs that
are recognized as members of the trust scheme.If both the CA and the trust scheme choose domain names as identifiers for
themselves and include these names in SubjectAltName extensions of
their respective certificates, they can publish statements both about the
claimed membership of a CA in a particular scheme and about the location as
well as the signing certificates for the trust list.Assume we have a CA and a trust scheme that have chosen "ca.example.com"
and "scheme.example.com" as their identifiers, respectively. Assume further
that the agreed upon topic name is "trustscheme". The CA can then claim it
is a member of the trust scheme by publishing the following record:trustscheme._topic.ca.example.com. IN PTR \
trustscheme._topic.scheme.example.com.
The scheme in turn can publish the location of its trust list as well as
limitations for the certificates used to sign the trust list (with the
record data of the SMIMEA record omitted for clarity):trustscheme._topic.scheme.example.com. IN URI \
0 0 https://www.example.com/trustscheme.xml
trustscheme._topic.scheme.example.com. IN SMIMEA ...
In order to guarantee the authenticity of the information published, the
resource records published need to be secured via DNSSEC . If
a document type that allows signing is referred to via a URI resource
record, the SMIMEA mechanism should be used to allow users to verify the
legitimacy of the certificate used for signing.The node name "_topic" should be added to the "Underscored and Globally
Scoped DNS Node Names" registry for the RR type PTR, SMIMEA, and URI.