DIEM

Summary

The DIEM (Digital Emblems) working group met at IETF 126. The session covered administration and logistics, an update on the ITU-T Study Group 17 liaison, a status update on the Working Group Last Call (WGLC) for the use cases and requirements document, and an extensive discussion on architectural directions and protocol-level dimensions for digital emblems.

Key Discussion Points

1. Liaison Statement from ITU-T Study Group 17

Sarah Jennings provided an update on the liaison with ITU-T Study Group 17 regarding two new work items (xstr.dm-assets and xstr.dm) initiated in December 2025. The working group replied in April 2026, outlining IETF activities and inviting ITU-T members to participate. Jim Reid noted that the next Study Group 17 meeting is scheduled for early September, which will likely produce subsequent activities relevant to IETF 127.

2. Changes in Use Cases and Requirements Document

Felix Linke presented Changes in Use Cases and Requirements Document for draft-ietf-diem-requirements.

Key updates in versions -02 and -03 include:

Clarifying that use cases should not restrict one another.
Introducing greater flexibility to digital emblem formats and validation requirements.
Adding concepts such as assured or selective response, and consistent or selective content.
Refining the text on the "removability" requirement and removing some restrictive normative language.
Elaborating on details for diplomatic pouches and International Humanitarian Law (IHL) emblems.

Rohan Mahy reminded the group that the WGLC for draft-ietf-diem-requirements ends on July 30, and urged participants to send reviews to the mailing list.

3. Sequencing of Architecture and Protocol Work

The chairs asked the working group how to proceed with the sequencing of the architecture and protocol deliverables.

Felix Linke, Orie Steele, and Allison Mankin advocated for working on the architecture and protocol documents in parallel to ensure the architecture remains practical and grounded.
Charles Eckel (AD) supported this approach, noting that parallel work on the protocol must not delay the progress of the core architecture.
A formal poll was taken, showing strong support for parallel development (see Decisions).

4. Architecture Prompt and Technical Dimensions

Rohan Mahy presented the Chair's architecture prompt slides and Arch dimensions to trigger discussion on several architectural design dimensions:

Information Categorization: Organizing data into fields for the issuer, asset identification, asset handling (e.g., CITES), emblem type, and emblem instance.
DNS Delivery Mechanisms: Options discussed included using TXT records, creating a new Resource Record (RR) type, splitting data across multiple RR types, or using an SVCB/HTTPS URI pointer.
- James Mozley, Tommy Jensen, and Jim Reid strongly argued against TXT records due to issues with size and clutter at the zone apex (citing mit.edu as a real-world example of overloaded TXT records).
- Tommy Jensen relayed a remote comment from Peter Koch emphasizing that "versioned" RR types are historically unsuccessful and violate transparency principles outlined in RFC 3597.
- Jim Reid and Tommy Jensen favored using a new RR type or using SVCB records for indirection to web-based services.
Validation & Verification: Incorporating DNSSEC, DANE certificates, JSON/CBOR Web Tokens, or Web PKI.
- Allison Mankin highlighted DNSSEC's value in providing both source authentication and authenticated proof of non-existence (NSEC/NSEC3).
- Felix Linke and Daniel Gillmor raised concerns that DNSSEC alone does not address application-layer authorization (e.g., verifying whether an entity has the legal authority to display a Red Cross emblem). Rahel Fainchtein argued that DNSSEC could still be extended or utilized to build these authorization mechanisms.
- Dan York shared data from the Internet Society's Pulse platform showing that only about 39% of global DNS queries currently undergo validation.
- Alex Rosenberg argued that standard validation statistics are less critical because validation will be executed by dedicated emblem-validation clients rather than random DNS resolvers.
Rooting of DNS Records: Storing records under a dedicated domain (dm.arpa), the issuer's domain, or the asset's domain.
- Jim Reid argued against dm.arpa due to the complexity of getting international bodies (like ICAO or UNESCO) to coordinate delegations at their operational speed.
- James Mozley suggested placing records under a designated label like _dm under the issuer or asset domain to avoid apex resolution issues.
- Laura Scalone inquired about the discovery of DIEM names and whether a global registry would be necessary. Tommy Jensen and Allison Mankin clarified the distinction between discovering asset identifiers and discovering an asset's emblem once the name is known.
Asset Types: The charter explicitly focuses on assets identified by a Fully Qualified Domain Name (FQDN). Tommy Jensen and Orie Steele advised sticking closely to FQDN-based assets to avoid over-engineering. Rohan Mahy noted the architecture should still maintain flexibility for future non-FQDN extensions (e.g., IPs, ASNs, data at rest/flight) without fully defining them now.
Other Operational Dimensions: Discussion touched on offline support, undetectable validation, logging/traceability, and selective disclosure. Nic Williams suggested considering a "disaster recovery" or delegation scenario where an organization loses access to its primary DNS infrastructure but needs to authorize emergency personnel to display emblems.

Decisions and Action Items

Decisions

The Working Group agreed to develop the architecture and protocol documents in parallel, provided it does not delay the primary architectural deliverable.

Session Polls

Poll 1: Is the WG happy to work on the architecture and protocol documents in parallel?
- Yes: 11
- No: 0
- No Opinion: 2
- Total Responses: 30

Action Items

Rohan Mahy to send detailed DNSSEC deployment and validation statistics to the mailing list.
Jim Reid to post a technical explanation to the list outlining why TXT records are discouraged for this type of application.
Tommy Jensen to coordinate with chairs and relevant DNS experts regarding the scope and applicability of using SVCB/DDDS records for emblem indirection.
All WG Participants to review and submit feedback for draft-ietf-diem-requirements before the WGLC closes on July 30.

Next Steps

Conclude the Working Group Last Call on draft-ietf-diem-requirements on July 30.
Begin drafting early architectural and protocol proposals as separate, parallel efforts.
Plan a virtual interim meeting between IETF 126 and IETF 127 to review architectural drafts.

Automatic IETF Minutes