Network Working Group R. A. Fainchtein Internet-Draft JHU/APL Intended status: Informational A. Mankin Expires: 6 May 2027 Packet Clearing House 2 November 2026 DIEM Architecture draft-fainchtein-diem-architecture-00 Abstract TODO Abstract About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://rahelFain.github.io/Diem-Architecture/draft-Fainchtein-DIEM- Architecture.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fainchtein-diem- architecture/. Source for this draft and an issue tracker can be found at https://github.com/rahelFain/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 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Fainchtein & Mankin Expires 6 May 2027 [Page 1] Internet-Draft DIEM Architecture November 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. DNS Structures of Digital Emblems . . . . . . . . . . . . . . 3 5. Zone Cut Structure for Digital Emblems . . . . . . . . . . . 4 6. Digital Emblem Naming Structure . . . . . . . . . . . . . . . 4 7. Authentication and DNSSEC Architecture of DE's . . . . . . . 4 8. Emblems that are not Fully Contained in DNS . . . . . . . . . 5 9. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. DNS Contained Emblem Discovery . . . . . . . . . . . . . 5 9.2. External DE Discovery . . . . . . . . . . . . . . . . . . 5 10. Use of IANA Registries . . . . . . . . . . . . . . . . . . . 5 11. Architecture for Authorizing Entities . . . . . . . . . . . . 5 11.1. Validation Procedure of ExtraZonal Authorization . . . . 6 11.2. Revoking Authorization . . . . . . . . . . . . . . . . . 6 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 14.1. Normative References . . . . . . . . . . . . . . . . . . 7 14.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 Fainchtein & Mankin Expires 6 May 2027 [Page 2] Internet-Draft DIEM Architecture November 2026 (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 content outlined 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 Fainchtein & Mankin Expires 6 May 2027 [Page 3] Internet-Draft DIEM Architecture November 2026 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 Fainchtein & Mankin Expires 6 May 2027 [Page 4] Internet-Draft DIEM Architecture November 2026 8. Emblems that are not Fully Contained in DNS TODO 9. Discovery 9.1. DNS Contained Emblem Discovery 9.2. External DE 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="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 (); * The Authorizer's 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 .authorized.. 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, Fainchtein & Mankin Expires 6 May 2027 [Page 5] Internet-Draft DIEM Architecture November 2026 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. 11.1. Validation Procedure of ExtraZonal Authorization To validate an emblem that is authorized by an external Authorizer, the validator must ensure that all of the following conditions hold: 1. DNSSEC validation of all RRs/RRsets within the Digital Emblem succeeds. 2. The emblem is authorized by an authorizer the validator trusts. 3. An Authorization RR/RRset exists at .authorized., where is the FQDN of the trusted Authorizer. 4. At least one authorization RR/RRset at .authorized. can be validated. That is: * DNSSEC validation of the RR/RRset succeeds; * The version number noted in the Digital Emblem's authorizer record matches the constraint set version number; * The validity period of the authorization record has begun but not ended; * The Digital Emblem's use and/or claims comply with all of the constraints noted in the constraint set;And * The Hash of the constraint set and signature over it match those provided in the Digital Emblem's authorizer record. If any of the conditions are not met, validation of the Digital Emblem has failed and the validator MUST reject it. 11.2. Revoking Authorization Based on the procedures described in Section 11 and Section 11.1, an Authorizer can revoke their authorization of a Digital Emblem by removing the authorization RR(s)/RRset(s) located at .authorized.. Fainchtein & Mankin Expires 6 May 2027 [Page 6] Internet-Draft DIEM Architecture November 2026 12. Security Considerations TODO Security 13. IANA Considerations This document has no IANA actions. 14. References 14.1. Normative References [CHARTER] "Digital Emblems", 27 May 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, . [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and Implementation Notes for DNS Security (DNSSEC)", RFC 6840, DOI 10.17487/RFC6840, February 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . Fainchtein & Mankin Expires 6 May 2027 [Page 7] Internet-Draft DIEM Architecture November 2026 [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, . [USE_CASES] "Digital Emblems - Use Cases and Requirements", 6 July 2026, . 14.2. Informative References [DANCE-CLIENT-AUTH] "TLS Client Authentication via DANE TLSA records", 28 October 2026, . Acknowledgments TODO acknowledge. Authors' Addresses Rahel A. Fainchtein JHU/APL Email: rahel.fainchtein@jhuapl.edu Allison Mankin Packet Clearing House Email: allison@pch.net Fainchtein & Mankin Expires 6 May 2027 [Page 8]