[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/