Internet DRAFT - draft-hoffmann-dnsop-names-as-identifiers
draft-hoffmann-dnsop-names-as-identifiers
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
Abstract
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.
Status of This Memo
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 Notice
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
Hoffmann Expires July 25, 2020 [Page 1]
Internet-Draft names-as-identifiers January 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Identifiers and Topics . . . . . . . . . . . . . . . . . . . 3
4. Discovery of Published Documents . . . . . . . . . . . . . . 3
5. Expressing Relationships with Other Entities . . . . . . . . 3
6. Publishing Associated Certificates . . . . . . . . . . . . . 4
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
10. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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.
2. Requirements Notation
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.
Hoffmann Expires July 25, 2020 [Page 2]
Internet-Draft names-as-identifiers January 2020
3. Identifiers and Topics
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.
4. Discovery of Published Documents
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.
5. Expressing Relationships with Other Entities
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.
Hoffmann Expires July 25, 2020 [Page 3]
Internet-Draft names-as-identifiers January 2020
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.
6. Publishing Associated Certificates
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.
7. Example
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.
Hoffmann Expires July 25, 2020 [Page 4]
Internet-Draft names-as-identifiers January 2020
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 ...
8. Security Considerations
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.
9. IANA Considerations
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.
10. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<https://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
Hoffmann Expires July 25, 2020 [Page 5]
Internet-Draft names-as-identifiers January 2020
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record", RFC 7553,
DOI 10.17487/RFC7553, June 2015,
<https://www.rfc-editor.org/info/rfc7553>.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
Associate Certificates with Domain Names for S/MIME",
RFC 8162, DOI 10.17487/RFC8162, May 2017,
<https://www.rfc-editor.org/info/rfc8162>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Author's Address
Martin Hoffmann
Stichting NLnet Labs
Email: martin@nlnetlabs.nl
Hoffmann Expires July 25, 2020 [Page 6]
