WG Review: Digital Emblems (diem)

The IESG <iesg-secretary@ietf.org> Thu, 08 May 2025 16:18 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@mail2.ietf.org
Received: from [10.244.8.181] (unknown [104.131.183.230]) by mail2.ietf.org (Postfix) with ESMTP id 01A032675800; Thu, 8 May 2025 09:18:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Review: Digital Emblems (diem)
X-Test-IDTracker: no
X-IETF-IDTracker: 12.39.2
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <174672111575.1129817.1748150057824362168@dt-datatracker-58d4498dbd-6gzjf>
Date: Thu, 08 May 2025 09:18:35 -0700
Message-ID-Hash: EA332XWSXFSZGT75O327A6HJQDGNW6X4
X-Message-ID-Hash: EA332XWSXFSZGT75O327A6HJQDGNW6X4
X-MailFrom: iesg-secretary@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf-announce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: diem@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: iesg@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/joj3JlhpxZQWC-5EoT_89LUzFTo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-announce-owner@ietf.org>
List-Post: <mailto:ietf-announce@ietf.org>
List-Subscribe: <mailto:ietf-announce-join@ietf.org>
List-Unsubscribe: <mailto:ietf-announce-leave@ietf.org>

A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg@ietf.org) by 2025-05-18.

Digital Emblems (diem)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Russ Housley <housley@vigilsec.com>
  Martin Thomson <mt@lowentropy.net>

Assigned Area Director:
  Orie Steele <orie@or13.io>

Applications and Real-Time Area Directors:
  Orie Steele <orie@or13.io>
  Andy Newton <andy@hxr.us>

Mailing list:
  Address: diem@ietf.org
  To subscribe: https://mailman3.ietf.org/mailman3/lists/diem.ietf.org/
  Archive: https://mailarchive.ietf.org/arch/browse/diem

Group page: https://datatracker.ietf.org/group/diem/

Charter: https://datatracker.ietf.org/doc/charter-ietf-diem/

# Introduction & Background

Emblems such as the Red Cross, Red Crescent, Red Crystal, and Blue Shield can
be symbols of protection governed by International Humanitarian Law (IHL).
Emblems can also be identified by other laws, agreements, or standards. There
is a need to present emblems through digital communication channels. Emblems
presented in such ways are called digital emblems. Digital emblems extend the
range of identifying marks from the physical (visual and tactile) to the
digital realm.

"To bear an emblem" means to present and be identified by a digital emblem.
The entity that bears the emblem is the bearer or emblem holder.
This is often a separate entity from the creator or original designer of the
emblem. "To validate an emblem" means to confirm the authenticity or
legitimacy of a particular symbol or design, often by checking its details
against a known standard or reference point. Validation may include ensuring
that the bearer has not forged, stolen, or tampered with an emblem. Emblems
may be observed by validators without the knowledge of the bearer presenting
the emblem, or may be presented to a specific validator upon request.
Cryptographic verification may or may not be used based on the in-place
security mechanisms of the communication channel bearing the emblem. Which
attributes an emblem contains, and how a digital emblem is secured and
presented impacts how a validator interprets and trusts the assertions made
within the emblem.

The DIEM WG will define an architecture and discovery mechanism enabling
digital emblems to be presented and validated across applications and
platforms in a cohesive way.

# Initial Scope

The DIEM WG will develop an initial DNS-based discovery mechanism and
associated validation procedure for digital emblems that explicitly identify
their bearer by a Fully Qualified Domain Name (FQDN). The design of discovery
mechanisms using proximity-based protocols such as QRCodes, NFC, or Bluetooth
is out-of-scope. The discovery mechanism and validation procedures must allow
for validators to be undetectable as validators. The DIEM WG is not required
to describe object level securing mechanisms, in the case that existing
protocol level securing mechanisms are sufficient, for example DNSSEC.

The DIEM WG will seek advice from DNS experts in DNSOP and DNSSD WGs on
proposed solutions.

The DIEM WG will not produce any standards track generic serialization
formats, standards track extensions to the DNS, cryptographic primitives, or
digital signature schemes.

The DIEM WG will investigate, analyze, and evaluate application-layer
serialization formats focusing on data structures that match the initial
scope's discovery mechanism (e.g., DNS records or structured fields in DNS)
as well as the respective securing mechanisms for digital emblems.

# Deliverables

The DIEM WG will work on the following deliverables for the defined scope
strictly in this order:

1. Use cases and requirements that can be addressed by the initial scope
(Informational) 2. An extensible architecture containing a taxonomy,
information model, and overall information flows (Informational) 3. A
protocol specification describing the validation and discovery of digital
emblems using DNS (Proposed Standard or Experimental)

Milestones:

  Jul 2025 - Adopt a draft addressing use cases and requirements

  Nov 2025 - Working group last call for use cases and requirements