DIEM Architecture

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 4 May 2027.¶

Copyright Notice

Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document presents a DNS and DNSSEC forward architecture. That is, it assumes DNSSEC is required and defines an architecture in which different components or building blocks can be combined to achieve the needs of a particular use case, but where all of them are primarily realized using DNS and employ DNSSEC signing and validation. For each building block or set of blocks introduced we reference the set of requirements it meets and identify other blocks with which it would likely be used or implemented. This is intended to enable the construction of Digital Emblems that accommodate various granularity and temporality requirements. Note:Digital Emblem protocols that do not use/require DNSSEC signing and validation thereof should specify how they handle emblem validation (to the extent required for their intended use cases). Among the variations discussed in this document are cases where¶

• All of the DE's key information provided within DNS ();¶

• DE uses DNS pointers to resources outside of DNS that contain the emblem's key information (Section 8);¶

• DE primarily consists of a single RR (Section 4);¶

• DE consists of a bundle of separated RR's (RRSet) where each RR contains one or more pieces of the DE's core information ();¶

(Note:This list is not intended to be all inclusive.)¶

2. Conventions and Definitions

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.¶

3. Assumptions

This document presents a DNS and DNSSEC forward architecture. That is, it assumes DNSSEC is required and defines an architecture in which different components are primarily realized using DNS and DNSSEC. * Cryptographic validation of Digital Emblems is required and is performed using DNSSEC. * Given the use of DNSSEC, all cases must meet the assured response requirement and a baseline version of consistent contentoutlined in [USE_CASES] Section 3.2.2. We discuss this in more detail and present a mechanism for supporting selective disclosure in Section 5.¶

4. DNS Structures of Digital Emblems

Decisions have to be made when designing the protocol and applying it for a given use case. Generally speaking we recommend using a configuration that simplifies discovery and record maintenance but offer considerations for other approaches.¶

• Single RR w/everything vs multi RR/RRSet with each RR containing one or more pieces of core information¶

• Type(s) of RR(s) used within the Digital Emblem¶

  • TXT vs no TXT¶

5. Zone Cut Structure for Digital Emblems

Since we assume the use of DNSSEC, or rather that all RRs/RRsets making up a digital emblem are DNSSEC signed, the authoritative server cannot deny the existence of any associated RRs/RRsets. As such, the only way to selectively disclose information within a digital emblem is for the authoritative server to hold two versions of any RRs that contain sensitive information or pointers thereto. Specifically:¶

• One that contains the sensitive information or pointers thereto (hidden RR). The hidden RR should only be presented if mutual authentication succeeds, and the requestor identity's membership in the set of authorized identities can be verified. Moreover, given the sensitivity of its contents, the hidden RR should be encrypted.¶

• One of the same type and for the same FQDN that only includes the basic and/or non-sensitive emblem information (default RR). This version of the RR should be returned by the Authoratative server if mutual authentication is not used, or if the requester's identity and/or authorization to see the sensitive content cannot be verified.¶

It is recommended that only RRtype(s) where the default RR does not indicate that sensitive details have been redacted or intentionally excluded from its contents be chosen.¶

6. Digital Emblem Naming Structure

To ensure Digital Emblems and all of their associated records can be realized, underscored naming of attribute leaves [RFC8552] should be used. Specifically, we propose the use of following underscored attribute names:¶

• _diem to denote a Digital Emblem.¶

• _authorizers as a subdomain of _diem (i.e. _authorizers._diem) to denote the set of authorizers for a Digital Emblem.¶

• etc As noted in Section 10, the standardization of these attributes and of their associated RRtypes will require registration in the appropriate IANA registry.¶

7. Authentication and DNSSEC Architecture of DE's

TODO¶

8. Emblems that are not Fully Contained in DNS

TODO¶

9. Discovery

10. Use of IANA Registries

If the use of underscored attribute leaves proposed in Section 6 is to be adopted, all underscored names and their associated RRtypes will need to be added to the appropriate registry. (TODO: Update if consensus to use underscored naming is reached, remove otherwise.)¶

11. Architecture for Authorizing Entities

~~~ goat
{::include diagrams/Authorizers_Pt2-auth.svg}
~~~
{: #authStruct title="Basic Structure for Authorization by an External Entity"}

Digital Emblems that require authorization from one or more entities outside of their zone should include an Authorizers field indicating the full list of entities that have authorized the issuance and use of a Digital Emblem. As illustrated in the figure above, each authorizer entry should contain the following fields.¶

• The Authorizer's common name (<AUTH_NAME>);¶

• The Authorizer's FQDN (<AUTH_FQDN>);And¶

• A collision resistant hash of all constraints the Authorizer has put on their authorization of the Digital Emblem, accompanied by a version number associated with the constraint set signed by the Authorizer (signed(HASH(constraints))).¶

To enable this the Authorizer publishes a DNSSEC signed authorization RR/RRset at the subdomain <DE_Name>.authorized.<AUTH_FQDN>. Within the RR/RRset they publish the version number of the current constraint set as well as the start and end date indicating the timeframe over which their authorization is valid. The authorizer then computes the hash of their constraints and signs over this, the constraint version number and the start and end dates of their authorization. To finalize the authorization, the authorizer sends the signed constraints hash and versioning metadata to the bearer, who then uses this to update the set of authorizers within the Digital Emblem. Note:To ease transitions from one set of constraints to another, or to handle reissuance of the authorization upon its expiration, Authorizers may host multiple authorization RRs/RRsets for the same emblem.¶

12. Security Considerations

TODO Security¶

13. IANA Considerations

This document has no IANA actions.¶

14. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses