Internet-Draft DIEM Use Cases and Requirements June 2025
Linker Expires 1 January 2026 [Page]
Workgroup:
Digital Emblems
Internet-Draft:
draft-linker-diem-requirements-latest
Published:
Intended Status:
Informational
Expires:
Author:
F. Linker

DIEM Use Cases and Requirements

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://felixlinker.github.io/diem-requirements/draft-linker-diem-requirements.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-linker-diem-requirements/.

Discussion of this document takes place on the Digital Emblems Working Group mailing list (mailto:diem@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/diem. Subscribe at https://www.ietf.org/mailman/listinfo/diem/.

Source for this draft and an issue tracker can be found at https://github.com/felixlinker/diem-requirements.

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 1 January 2026.

Table of Contents

1. Introduction

TODO Introduction

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. Use Cases and Requirements for Initial Scope

3.1. Digital Emblems under International Humanitarian Law

The Geneva Conventions and their Additional Protocols constitute the core of International Humanitarian Law (IHL) and establish legal rules on the conduct of armed conflict. Some assets enjoy certain specific protections under IHL, including that they must not be attacked, and IHL codifies four types of protective emblems for armed conflict, which inform other parties that marked assets benefit from one or several of these specific protections. Note that assets enjoy there protections irrespective of whether they are marked with the respective emblem. The emblem only serves to inform others of these protections.

  • The emblems of the Red Cross, Red Crescent, and Red Crystal are applied to assets of the medical services as well as the assets of certain humanitarian operations.

  • The Blue Shield emblem is applied to cultural property.

  • The emblem for the protection of civil defense is applied to certain assets for the protection of the civilian population against the dangers of hostilities or disasters.

  • The dangerous forces emblem is applied to works or installations containing dangerous forces, i.e., dams, dikes, and nuclear generating facilities.

3.1.1. Requirements

Digital emblems under IHL MUST identify the issuing party and MUST provide a means for authorization by third parties. Additionally, this use case has the following requirements:

  • Authenticity

  • Authorization and Decentralized Authorization

  • Accountability

  • Revocation

  • Undetectable Validation

4. Other Use Cases and Requirements

The focus of the initial DIEM efforts does not include the following use cases. They are listed here for documentation and future reference. The requirements of these use cases are not complete and would need to be investigated further when addressing the use cases.

4.1. Marking of Hazardous Materials

The Organization for the Prohibition of Chemical Weapons (OPCW), the International Atomic Energy Agency (IAEA), and the Basel Convention require that certain, dangerous materials are marked during shipment. Concretely:

  • The OPCW requires marking of Schedule 1 chemicals.

  • The IAEA administers several treaties related to the shipment of atomic fuels and wasters across borders.

  • The Basel Convention regulates the trans-boundary movement of hazardous wastes.

An emblem MUST provide a description, location, date, and quantity. The description MUST be accessible only by authorized parties, e.g., customs agencies or material handlers.

4.2. Marking of Brand-Associated Shipments

World Intellectual Property Organization (WIPO) administers treaties, in particular the Madrid Protocol, that allow brands to mark their shipments with an emblem so that customs agents can identify legitimate products.

An emblem MUST identify the copyright/brand image, provide a textual description of the shipment, and a chain-of-custody/provenance.

4.3. Marking of Civil Aviation Flights

The International Civil Aviation Organization (ICAO) requires that civil aviation flights are protected and that one can verify them to not be dual-use, e.g., not carrying military cargo.

An emblem MUST carry a geographic description of the flight plan, its current location, and a textual description of the flight including its manifest, identifying characteristics, e.g., tail number. An emblem may need to also reference a flight manifest.

5. Requirements

5.1. Authenticity

Validators MUST be able to verify that an emblem was issued for the respective bearer, issued by the claimed issuer (where applicable), and that none of its associated data was changed.

5.2. Authorization

Validators MUST be able to verify that an emblem issuer was authorized to issue the emblem. Authorizing parties MAY limit what emblems an issuer can issue, e.g., they MAY limit issuance to certain bearers.

5.2.1. Decentralized Authorization

Anyone MUST be able to authorize an issuer.

5.3. Accountability

Emblem issuance and authorization of issuers (where applicable) MUST be attributable to issuers and authorizing parties. Authorizing parties and emblem issuers MUST NOT be able to repudiate that they issued an emblem or authorization.

5.4. Revocation

Emblems and authorizations (where applicable) MUST be revokable within reasonable windows of time. Depending on the design, it may suffice to rely on expiration of short-lived emblems and authorization effectively as a revocation mechanism.

5.5. Undetectable Validation

Emblem issuers MUST NOT be able to detect whether someone is requesting or validating emblems issued by them.

5.6. Visual

An emblem MUST be capable of carrying a visual representation of the physical emblem it represents.

5.7. Law Carrying

An emblem MUST carry an unambiguous indication of the international law or laws conferring the semantics of the emblem.

5.8. Proximity-Based Distribution

An emblem MUST be presentable using an in-band, proximity-based protocol such as a QR code or RFID.

5.9. Physical Binding

An emblem MUST be possible to associate with physical assets, e.g., buildings, vehicles, or containers.

5.9.1. Quantifiable

An emblem MUST be possible to associate with a range or specific quantity of associated, physical assets.

5.10. Identity Binding

An emblem MUST be possible to associate with a person or group of people.

6. Security Considerations

TODO Security

7. IANA Considerations

This document has no IANA actions.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

TODO acknowledge.

Author's Address

Felix Linker