Digital Emblems F. Linker Internet-Draft 30 June 2025 Intended status: Informational Expires: 1 January 2026 DIEM Use Cases and Requirements draft-linker-diem-requirements-latest 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. Copyright Notice Copyright (c) 2025 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 2. Conventions and Definitions 3. Use Cases and Requirements for Initial Scope 3.1. Digital Emblems under International Humanitarian Law 3.1.1. Requirements 4. Other Use Cases and Requirements 5. Requirements 5.1. Authenticity 5.2. Authorization 5.2.1. Decentralized Authorization 5.3. Accountability 5.4. Revocation 5.5. Undetectable Validation 5.6. Visual 5.7. Law Carrying 5.8. Proximity-Based Distribution 5.9. Physical Binding 5.9.1. Quantifiable 5.10. Identity Binding 6. Security Considerations 7. IANA Considerations 8. Normative References Acknowledgments Author's Address 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 of these certain 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 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, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgments TODO acknowledge. Author's Address Felix Linker Email: linkerfelix@gmail.com