Digital Emblems - Use Cases and Requirements

Internet-Draft	DIEM Use Cases and Requirements	October 2026
Fainchtein, et al.	Expires 4 May 2027	[Page]

Abstract

Digital emblems allow an issuer to signal that an asset should be protected or treated in a specific way, using some normative framework. This document lists the requirements and use cases that an architecture for digital emblems must accommodate.¶

3. Requirements

The DIEM architecture will allow validators to discover and validate digital emblems that are associated with assets. This section contains the requirements that this architecture will address. They are based on use cases identified thus far (see Section 5), but note that not all use cases share all requirements. We categorize these requirements into: requirements on digital emblems and their format, on their discovery, on their validation, and other requirements.¶

The requirements for individual use cases are independent, and the requirements for one use case MUST NOT constrain, override, or otherwise affect the requirements of any other use case. Where a use case specifies a limited domain of application for a particular emblem (e.g. only digital or physical assets, a narrow scope of valid issuers or validators, or a specific discovery mechanism), such a limitation SHOULD be understood as reflecting current use case constraints only.¶

Drafts will likely address a subset of the requirements set out in this document, and there will likely be different digital emblem profiles, each of which will address one or more use cases. Whenever a profile addresses one use case's requirement, this must not be interpreted as that profile inheriting all limitations of the respective use case. Future or different drafts and profiles should be able to reuse any draft or parts thereof, in particular, when an addressed use case has a different or expanded domain of application.¶

3.1. Digital Emblem Requirements

3.1.1. Digital Emblem Format

Digital emblems MUST identify the marked asset and what kind of emblem they resemble. Beyond that, digital emblems MAY include other data, for example, an issuer or a validity window. To accommodate use cases requiring extensible data, a digital emblem architecture SHOULD introduce minimal size overhead except for fields required to fulfil other requirements in this document.¶

As of this writing, the DIEM charter requires that digital emblems MUST explicitly identify the marked asset by a Fully Qualified Domain Name (FQDN).¶

3.1.2. Emblem Semantics

Digital emblem profiles MUST specify the semantics of the emblem. It must be clearly stated how discovery and validation of a digital emblem should inform validator behavior.¶

3.2. Discovery Requirements

3.2.1. Discovery

Digital emblem profiles MUST specify how validators, given an asset, can check for the presence of a digital emblem. For example, verifying whether an FQDN has an emblem associated with it could be realized by fetching digital emblem-associated records for that FQDN.¶

3.2.2. Query Response

Digital emblem profiles MUST determine how servers must respond to queries for digital emblems. Specifically, they must determine the responsiveness and consistency requirements for emblems and provide explanations of how the chosen requirements apply and the rationales for their selection.¶

For responsiveness, a digital emblem profile can either require that all queries must be responded to (Assured Response), or can allow for selectively responding to a subset of incoming queries (Selective Response).¶

For consistency of response, digital emblem profiles must denote whether all queries for an asset's records (as denoted by its FQDN) must return all respective digital emblems associated with the asset (Consistent Content), or whether the inclusion of emblems in a response may vary based on specific requester attributes (Selective Content).¶

Note that as of this writing, neither the baseline definition for the minimum set of attributes that constitute a unique digital emblem nor the attributes needed to attain Consistent Content have been defined. Given the limited scope of this document, that definition as well as the mechanism to ensure its extensibility across newly defined emblem profiles will be outlined in the architecture document.¶

3.2.3. Removable

Some use cases require that digital emblems are removable. "Removing" an emblem means that one cannot determine whether an emblem ever was applied to a particular asset. This means, in particular, emblems do not count as removed when they become invalid, e.g., due to expiry.¶

Note that removability is a security requirement. Therefore, digital emblem profiles and drafts that address removability MUST specify a threat model for removability that specifies when and under what conditions it is acceptable that someone can learn after the fact that an emblem was applied.¶

3.2.4. Undetectable Validation

Some use cases require that digital emblem discovery and validation are undetectable. This requirement is motivated by emblems that mark their assets as protected and ask validators to not disrupt the marked asset. If emblem discovery were detectable, malicious parties could misuse the digital emblem as an intrusion detection system.¶

For specific digital emblem profiles, it may be acceptable that certain parties can detect emblem discovery and validation, for example, when the validator can hide in a sufficiently large anonymity set, or it is acceptable that the given party could detect the discovery or validation. Digital emblem profiles and drafts MUST specify a threat model for undetectable validation. This threat model must detail which parties can detect emblem discovery and validation, under which conditions, and to what extent.¶

3.3. Validation Requirements

3.3.1. Validation

Some use cases require that digital emblems be validated. When a profile specifies validation procedures, those procedures MUST ensure that the emblem was issued for the respective asset. Some use cases MAY use unvalidated digital emblems.¶

The digital emblem architecture MUST allow individual profiles and drafts to support validation of all the digital emblem's data or a defined subset. This ensures digital emblems can support static or dynamic data without having to account for the pain of frequent re-signing of dynamic data if its validation is not required by a given digital emblem profile.¶

3.3.2. Authorization

For some use cases, issuing a digital emblem requires authorization by third parties. When a digital emblem profile requires authorization, it MUST define a trust model that describes how validators can discover authorities and how the system selects authorities. The generalized digital emblem architecture MUST NOT assume that Internet access is available or required so that individual digital emblem profiles can choose to take a dependency on Internet access or not. For example, a given digital emblem profile MAY use a PKI or the DNS as a root of trust if desired, but the generalized digital emblem architecture cannot mandate this or other options and MUST make this a point of extensibility.¶

Any authorization mechanism MUST account for the possibility of compromise of cryptographic key material, for example, by specifying revocation mechanisms or using short-lived credentials.¶

3.4. Other Requirements

3.4.1. Extensibility

The digital emblem architecture should be extensible. The initial work should not preclude future extensions, and individual standards should be designed to be as general as possible.¶

4. Extensions

In this section, we sketch how the digital emblem architecture could be extended by future standards to accommodate more use cases, but it is not a comprehensive list.¶

4.1. Data Formats

Emblems for additional use cases may be defined via new profiles in future standards, potentially including new types of atomic data elements requiring additional specification.¶

4.2. Asset Identifier Discovery

It may be non-obvious for some use cases to learn the identifiers associated with an asset, and thus impossible to discover emblems associated with that asset. To accommodate such use cases, one could specify means to discover identifiers for different types of assets.¶

4.3. Implicit Discovery

An alternative approach to the above problem would be to bind emblems implicitly to the marked asset. Implicit binding could identify the marked asset by the emblem's location. For example, if emblems were distributed via NFC, the marked asset could be the asset to which the NFC chip was attached. As of this writing, the current charter scope requires that digital emblems explicitly identify their asset, but such discovery mechanisms could be investigated in future WG work.¶

4.4. Confidentiality

Some use cases may contain confidential or sensitive data, and may require mechanisms to protect such data. For example, this could be realized with encryption of the general emblem data format that will be part of the architecture or by only serving emblems over channels with access control mechanisms.¶

4.5. Proof of Presence

Since emblems themselves are unable to directly protect assets against attack, emblems which indicate that assets are entitled to protections may require a mechanism through which violations of their laws or provisions can be verified forensically. This would be particularly relevant in cases where emblems can be applied and removed dynamically. These proofs of presence are defined at three different levels, listed from weakest to strongest.¶

Level 1 - presence and validation possible: Establishing that a validator was able to obtain the emblem at the time of violation. That is, forensically demonstrating or proving that the emblem was discoverable and could be validated at the time of an alleged violation.¶

Level 2 - presence, validation possible, and access: Establishing Level 1 and additionally that the validator accessed the digital emblem.¶

Level 3 - presence, validation possible, access, and validation: Establishing Level 2 and that the validator validated the emblem upon accessing it. This level of proof can only be provided by the validator.¶

Note that Levels 2 and 3 are intended to be mutually exclusive requirements with undetectable validation (Section 3.2.4). An example from the Diplomatic Pouches use case, described in Section 5.2, illustrates the Level 3 proof of presence requirement, and how it in some cases may need to be part of a chain of custody and/or accompanied by additional security measures to provide adequate security guarantees.¶

5. Use Cases

Different use cases have different requirements. The purpose of this document is to list the requirements that will be addressed with the initial architecture. The use cases overlap and would benefit from a DIEM architecture developed to provide the requirements listed above, though some may require additional extensions. We alphabetically list use cases here so that relevant stakeholders can provide input on whether their use case would indeed benefit from a DIEM architecture, and invite participants to provide use cases or details that we have missed.¶

We provide auxiliary material under Informative References.¶

5.1. Basel Convention

Regulates the trans-boundary movement of hazardous wastes. Use cases are functionally identical to OPCW and IAEA.¶

5.2. Diplomatic Pouches (1961 Vienna Convention on Diplomatic Relations)

Digital emblems can protect diplomatic pouch shipments, diplomatic couriers, and diplomatic envoys. All three of these are protected under the 1961 Vienna Convention on Diplomatic Relations [VIENNACONV], which states that they may not be stopped, delayed, or inspected. This creates the paradox that the validity of their credentials must be evaluated, yet doing so has historically compromised the very rights that are intended to be signaled. Diplomatic markings have also been misappropriated as cover for the smuggling of drugs and other contraband. Digital emblems, which can be validated instantaneously, at a distance, and without interrupting the subject, address both of these problems, while streamlining and automating customs and immigration processes.¶

The use case for diplomatic pouches involves the following entities: - Point of Entry Country/Customs Agent(s): Validator - Origin Country or Accredited Organization: Issuer and Authorizing entity - Diplomat: Agent of Country or Accredited Organization - Pouch: Asset¶

As noted in Section Section 4.5, a Level 3 proof of presence record could help demonstrate, for the benefit of the customs service, that customs agent(s) in a point of entry country validated the diplomatic pouch. To that end, the proof of presence record of processing a diplomatic pouch's digital emblem could include the following information.¶

Specific point of entry¶
Time/Date of arrival at point of entry¶
Identifier(s) of customs agent(s) validating the pouch¶
A baseline record establishing the emblem's existence and accessibility (or a pointer thereto)¶
Record of the customs agent's attempt to validate the digital emblem and its result signed by the customs agent(s)¶

5.2.1. Limitations of proof of presence:

As indicated in Section Section 4.5, Level 3 proof of presence alone does not provide proof that no tampering with the diplomatic pouch or inspection of its contents has occurred. This is because a proof of presence neither provides a chain of custody nor any mechanisms to detect tampering should it occur. For this reason, Level 3 proof of presence may be used alongside or as part of an attested chain of custody and/or accompanied by the use of physical mechanisms for tamper-proofing a physical asset. Any such chain of custody specification or anti-tampering mechanism is out of the scope of the DIEM WG.¶

5.3. International Atomic Energy Agency (IAEA)

IAEA administers several treaties, especially related to the controlled shipment of atomic fuels and wastes across borders. Similar use case as OPCW.¶

5.4. International Civil Aviation Organization (ICAO)

Requires protection of civil aviation flights and the ability to assert that they are not dual-use (i.e., not carrying military cargo). Digital emblem would carry a geographic description of the flight plan, its current location, and an indicator of its identity (i.e., tail number). Potential need for the emblem to reference a limited or partially redacted flight manifest.¶

5.5. Protective Emblems under the Geneva Conventions, their Additional Protocols, and the 1954 Hague Convention

5.5.1. Background

The Geneva Conventions and their Additional Protocols constitute the core of International Humanitarian Law (IHL). Some assets enjoy certain specific protections under IHL, including that they must not be attacked. In addition to recognizing other signs, 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 or special protections. In other words, protective emblems under IHL signal the applicability of a specific or special protection under IHL. Namely, these emblems are:¶

The emblems of the Red Cross, Red Crescent, and Red Crystal, defined in the Geneva Conventions and Additional Protocol III of the Geneva Conventions [GCI1949] [APIII2005]¶
The Blue Shield emblem, defined in the 1954 Hague Convention [HAGUE1954]¶
The international distinctive sign of civil defence, defined in Additional Protocol I of the Geneva Conventions [API1977]¶
The dangerous forces special sign, defined in Additional Protocol I of the Geneva Conventions [API1977]¶

However, these emblems can currently only be used to mark physical assets, and there is no way to mark digital, network-connected infrastructure that enjoys the same protections. A digital emblem using the DIEM architecture could address this gap, and resolutions from UNESCO and the International Conference of the Red Cross and Red Crescent have expressed support for such a digital emblem [RCRCRES] [UNESCORES].¶

5.5.2. Domain Model and Stakeholders

In the context of digital protective emblems under IHL, emblems will mark assets that are digital services and that solely serve protected purposes (for example, a medical unit, a cultural site, or an installation containing dangerous forces). Such emblems will be issued by the party controlling the marked service, and they signal that these assets must be respected and protected. Emblems must only be issued by entities that have been authorized to bear a digital emblem or other distinctive sign under international law. Such authorizations must be issued by a state, other party to an armed conflict, or other entity competent under international law.¶

For digital protective emblems under IHL, validators will typically be armed forces under the command of either state or non-state actors. In situations of armed conflict, all such actors are under an obligation to check whether assets subject to military activities bear an emblem. Similarly, other cyber operators, whilst not necessarily obligated under IHL, may choose to respect assets bearing the emblem. Concretely, we can assume that they will typically first identify an asset that they plan to engage with and then check whether that asset bears an emblem.¶

5.5.3. Requirements

The purpose of a digital emblem is to prevent disruptions of assets by informing validators that marked assets enjoy protection under IHL. Digital emblems will only be able to do so when validators are willing to pay attention to them. As validators intend to engage with assets that are not protected under IHL, this will only be the case when they are confident that their targets cannot fake protection and that they do not alert their target. Therefore, digital protective emblems under IHL require validation for authenticity (Section 3.3.1) that is undetectable (Section 3.2.4).¶

At the same time, digital protective emblems under IHL should fit well into the existing framework of IHL and not put emblem issuers at increased risk. First, IHL requires that emblem issuers must seek authorization from a competent authority prior to issuing emblems (see Section 3.3.2 and Section 5.5.2). The authorization must be decentralized, i.e., there must be no central authorities that govern the use or distribution of digital emblems. Second, bearing an emblem can increase the risk of targeted attacks. We require that emblem issuers must be able to individually assess that risk and remove emblems whenever they see the risks as outweighing the benefits, i.e., we require that digital emblems are removable (Section 3.2.3).¶

Beyond the DIEM architecture as described in this document, digital protective emblems under IHL would benefit from discovery mechanisms other than the DNS, as not all assets may have domain names associated with them.¶

5.6. Organization for the Prohibition of Chemical Weapons (OPCW)

Emblem would include the UN packaging symbol, and identify the UN Packaging Code, Proper Shipping Name, four-digit UN hazardous material identification number, GHS Class 6.1 Toxic Substances pictogram, any other applicable GHS pictogram, the Chemical Abstracts Service registry number, the IUPAC chemical name, the quantity, and Consignee and Consignor details. In addition, the place, date, and volume of production may be required. The OPCW also employs diplomatic pouches for its equipment, and its staff are protected in the same way as couriers or diplomats while on mission.¶

5.8. Press

Journalists in conflict zones use protective markings that indicate their status as non-combatants. Assets belonging to the press, such as cameras and satellite terminals, could be digitally marked, and protective markings in conflict zones could be digitized.¶

5.9. Ramsar Convention on the Wetlands

The Convention on Wetlands of International Importance especially as Waterfowl Habitat "provides the single most global framework for intergovernmental cooperation on wetland issues" and it features a list of geographic areas designated by Member States. A digital emblem for the geographic areas potentially requires¶

Indication of location¶
Access to presence or absence of Ramsar designation of a specified location¶
Textual description¶
Ability to validate the presence or absence of Ramsar designation¶

5.11. United Nations Food and Agriculture Organization (FAO)

Among other things is responsible for the International Plant Protection Convention (IPPC) and International Standards for Phytosanitary Measures standards including ISPM 15 that requires wood packaging materials (pallets, crates, dunnages) to be debarked, heat-treated or fumigated with methyl-bromide, and stamped or branded with a compliance mark known as a "wheat stamp."¶

5.12. United Nations Peacekeepers

Peacekeepers' blue helmets may require protective marking in a theater for the duration of a deployment, or may be more specifically and individually located using GPS and dynamic DNS, as with shipments of sensitive goods, diplomatic pouches, and couriers and envoys. The invalid_treatment flag could be used in conjunction with the contact TXT record to report strays. Barracks and other facilities can be denoted using polygonal LOC records for the TIME of their use.¶

5.13. World Customs Organization (WCO)

Specifies "Harmonized Systems" codes [HARMONIZED] that classify items such as livestock, arms and ammunition, chemicals, plastics, machinery, foodstuffs, etc. They also provide a system for labeling origin of items and valuation of items, all enforced by numerous international trade agreements between individual nations and groups of nations.¶

5.14. World Health Organization (WHO)

Similar to the use case of the Red Cross, Red Crystal, and Red Crescent.¶

5.15. World Intellectual Property Organization (WIPO)

WIPO administers 26+ treaties with different protections for different things. Brands that are protected under international law (e.g., Madrid Protocol) can mark their shipments with an emblem allowing customs agents to positively identify legitimate products.¶

8. References

8.1. Normative References

[CHARTER]: "Digital Emblems", 27 May 2025, <https://datatracker.ietf.org/doc/charter-ietf-diem/01/>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2. Informative References

[API1977]: International Committee of the Red Cross, "Protocol Additional to the Geneva Conventions of 12 August 1949, and relating to the Protection of Victims of International Armed Conflicts (Protocol I)", 8 June 1977, <https://ihl-databases.icrc.org/assets/treaties/470-AP-I-EN.pdf>.
[APIII2005]: International Committee of the Red Cross, "Protocol Additional to the Geneva Conventions of 12 August 1949, and relating to the Adoption of an Additional Distinctive Emblem (Protocol III)", 8 December 2005, <https://ihl-databases.icrc.org/assets/treaties/615-AP-III-EN.pdf>.
[BLUEHELMET]: Doctors Without Borders, "The Practical Guide to Humanitarian Law", n.d., <https://guide-humanitarian-law.org/content/article/3/peacekeeping/>.
[BLUESHIELD]: United Nations Educational, Scientific and Cultural Organization, "Enhanced Protection - Cultural Property of Highest Importance to Humanity", n.d., <https://www.unesco.org/en/heritage-armed-conflicts/enhanced-protection-cultural-property-highest-importance-humanity>.
[CUSTOMARY]: International Committee of the Red Cross, "Customary IHL - IHL Databases", n.d., <https://ihl-databases.icrc.org/en/customary-ihl>.
[DIPLOMAT]: Cornell Law School - Legal Information Institute, "Personnel of Foreign Governments and International Organizations and Special Treatment for Returning Individuals", n.d., <https://www.law.cornell.edu/cfr/text/19/148.83>.
[GCI1949]: International Committee of the Red Cross, "Geneva Convention for the Amelioration of the Condition of the Wounded and Sick in Armed Forces in the Field", 12 August 1949, <https://ihl-databases.icrc.org/assets/treaties/365-GC-I-EN.pdf>.
[HAGUE1954]: United Nations Educational, Scientific and Cultural Organization, "Convention for the Protection of Cultural Property in the Event of Armed Conflict", 14 May 1954, <https://unesdoc.unesco.org/ark:/48223/pf0000082464>.
[HARMONIZED]: World Customs Organization, "Harmonized System", n.d., <https://www.wcotradetools.org/en/harmonized-system>.
[IHL-GUIDE]: "", n.d., <https://guide-humanitarian-law.org/content/article/3/right-of-humanitarian-initiative/>.
[ISPM15]: International Plant Protection Convention, Food and Agriculture Organization of the United Nations, "International Standards for Phytosanitary Measures No. 15: Regulation of Wood Packaging Material in International Trade", n.d., <https://www.ippc.int/static/media/files/publication/en/2019/02/ISPM_15_2018_En_WoodPackaging_Post-CPM13_Rev_Annex1and2_Fixed_2019-02-01.pdf>.
[PRESS]: Reporters Without Borders, "RSF Resource for Journalists' Safety", n.d., <https://safety.rsf.org/appendix-i-protection-of-journalists-in-war-zones/>.
[RAMSAR]: Convention on Wetlands Secretariat, "The Convention on Wetlands", n.d., <https://www.ramsar.org>.
[RCRCRES]: 34th International Conference of the Red Cross and Red Crescent, "Protecting Civilians and Other Protected Persons and Objects Against the Potential Human Cost of ICT Activities During Armed Conflict", Document prepared by the International Committee of the Red Cross in consultation with the International Federation of Red Cross and Red Crescent Societies , October 2024, <https://rcrcconference.org/app/uploads/2024/10/34IC_R2-ICT-EN.pdf>.
[REDCROSS]: International Committee of the Red Cross, "The Protection of the Red Cross / Red Crescent Emblems", n.d., <https://www.icrc.org/en/doc/assets/files/other/protection_emblems.pdf>.
[UNESCORES]: United Nations Educational, Scientific and Cultural Organization, "Resolutions Adopted During the 16th Meeting of the High Contracting Parties to the 1954 Hague Convention", 1 December 2025, <https://unesdoc.unesco.org/ark:/48223/pf0000396721.locale=en>.
[UNMODELREGS]: United Nations Economic and Social Council, "UN Model Regulations on the Transport of Dangerous Goods", n.d., <https://unece.org/transport/dangerous-goods/un-model-regulations-rev-23>.
[VIENNACONV]: United Nations, "Vienna Convention on Diplomatic Relations", n.d., <https://treaties.un.org/pages/Viewdetails.aspx/?src=TREATY&mtdsg_no=III-3&chapter=3&clang=en>.
[WHITEFLAG]: Whiteflag Foundation, "Whiteflag Specification", n.d., <https://standard.whiteflagprotocol.org/>.