DNS Operations | M. Hoffmann |
Internet-Draft | Stichting NLnet Labs |
Intended status: Standards Track | January 22, 2020 |
Expires: July 25, 2020 |
Publishing Information for Entities Identified by Domain Names
draft-hoffmann-dnsop-names-as-identifiers-00
This 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2020.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119] [RFC8174] 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 [RFC1123].
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 [RFC3986] for this location via a set of URI [RFC7553] 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 [RFC1035] 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 [RFC8162] 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 [RFC4033]. 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.