Digital Emblems - Architectural Considerations

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 5 May 2027.¶

Copyright Notice

Copyright (c) 2026 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

The DIEM working group is developing standards for digital emblems: a means for associating metadata with physical or virtual assets, often to indicate what treatment they should receive under some normative framework [CHARTER] [DIEM-REQS]. The use cases range from protections under International Humanitarian Law (IHL) to trade and logistics labeling, environmental designations, and diplomatic privileges.¶

The central claim of this document is that these use cases differ mainly in what they say, not in how it is said. A hospital, a pallet of smartphones, and a diplomatic pouch all need an identifier that a validator can learn, a way to retrieve statements about the identified asset, assurance that the statements come from the party entitled to make them, and in some cases confidentiality, third-party authorization, or offline operation. These are architectural concerns that can be addressed once. What differs between use cases is the dictionary of facts being conveyed, and that is the job of a profile.¶

An architecture document would ordinarily stay clear of protocol detail. In DIEM's case, several participants (including the author) have found it difficult to reason about the architecture without thinking concretely about the protocol it implies. This document therefore includes a strawman encoding (Section 16). The strawman is illustrative: it exists to show that the architecture can be realized with existing DNS machinery and to give the working group something concrete to criticize. Normative protocol specifications would follow in separate documents.¶

This revision substantially reworks draft-rosenberg-diem-architecture-00 in response to working group feedback, particularly from DNS practitioners who urged that DIEM lean on DNSSEC rather than duplicate its integrity guarantees at the application layer.¶

2. Conventions and Definitions

This document uses the terms "(digital) emblem", "asset", "emblem issuer", "authorizing entity", "validator", and "validation" as defined in [DIEM-REQS]. It also uses the following terms:¶

Profile:

A digital emblem profile as defined in [DIEM-REQS]: a specification of an emblem's data elements and their types, which are required or confidential, how validators interpret them, how emblems are discovered, and whether validation or authorization is required. In this architecture, a profile defines its data and selects among the discovery, validation, authorization, and confidentiality options described here; it does not define its own transport or trust machinery. Different profiles therefore share one validator implementation. One profile may serve several use cases (for example, a consignment profile used by both customs and recyclers), and one asset may carry emblems from several profiles. Section 13 lists what a profile specifies.¶

Emblem name:

The DNS owner name at which an asset's emblem records are published.¶

Emblem record:

A DNS resource record conveying all or part of an emblem. In the strawman, the EMBLEM RRType.¶

Facet:

A subset of an emblem's data that is retrieved, cached, or signed independently of the rest, and is therefore published as its own RRset (a separate RRType, or a separate owner name).¶

Key:

A registered identifier for one property in an emblem's dictionary, with a defined value type.¶

Code list:

An externally maintained controlled vocabulary (for example, ISO 3166-1 country codes [ISO3166] or UNECE Recommendation 20 unit codes) used as the type of a key's value.¶

Endorsement:

A statement by an authorizing entity that an emblem issuer is authorized to issue emblems of a given profile or scope, published as an RRset in the authorizing entity's own zone.¶

Visual mark:

An image of the physical emblem, sign, or logo associated with an emblem's profile or issuer, carried as an optional facet (Section 6.4). A visual mark depicts; it is not itself an emblem, and confers nothing.¶

Offline bundle:

A self-contained serialization of emblem RRsets, their RRSIGs, and the DNSSEC chain needed to validate them, suitable for transfer without network access.¶

3. Design Principles

One architecture, many profiles:

Use cases vary the data, not the plumbing. A validator that understands discovery, DNSSEC validation, and the common encoding can retrieve and authenticate any emblem, even one whose profile it cannot interpret. This avoids a family of disjoint per-use-case systems, which would multiply implementation cost and fragment the validator base.¶

Use the DNS for what it already does:

DNSSEC [RFC4033] [RFC4034] [RFC4035] [RFC9364] provides data origin authentication and integrity for RRsets, authenticated denial of existence, and a delegation model that maps naturally onto organizational boundaries. DIEM should rely on these rather than re-create them with application-layer signatures. Application-layer cryptography is reserved for what DNSSEC does not provide: confidentiality, cross-zone endorsement, and offline transfer.¶

Typed data:

Every key has a registered type, and every value can be checked against it. A validator must be able to tell malformed data from well-formed data, and to tell one property from another without reading free text. Externally maintained code lists are value types bound to keys, not free-standing records.¶

Query granularity equals record granularity:

Data that a validator needs to retrieve independently, or that changes on a different schedule, belongs in its own RRset. Data that is always used together belongs in one record. The DNS offers projection (by owner name and type) but no predicates, so the record layout is the query model.¶

Encryption, not audience-dependent answers:

Restricted fields are encrypted inside signed records, so that every validator receives the same cacheable, signed answer and only authorized validators can read the restricted parts. Serving different answers to authenticated clients is possible as a deployment option but is not the architectural primitive (see Section 9).¶

Neutral about normative frameworks:

The architecture conveys statements; it does not adjudicate them. Legal meaning (what an emblem entitles an asset to, who may authorize it) lives in profile data and in the frameworks that profiles reference.¶

4. Roles and Trust

The architecture has two active roles on the wire:¶

• An emblem issuer publishes emblem records in a DNS zone it controls (directly, or through a contracted DNS operator).¶

• A validator retrieves emblem records and validates them.¶

An authorizing entity, where a profile requires one, participates by publishing endorsements in its own zone, which validators either query or receive stapled to the emblem (Section 8). It does not need to be online during validation.¶

  authorizing entity       emblem issuer          validator
  (state, treaty body,     (hospital, maker,      (armed forces,
   NPPO, ministry ...)      shipper, MFA ...)      customs, recycler)
         |                        |                      |
         | endorsement            | emblem records       |
         | (own zone; queried     | (DNSSEC-signed,      |
         |  or stapled)           |  maybe delegated)    |
         v                        v                      |
  +--------------------------------------------+         |
  |                    DNS                     |<--------+
  | root -> TLD -> issuer zone -> emblem names |  query and
  +--------------------------------------------+  validate

Trust in an emblem's content derives from the DNSSEC chain of trust to the zone that publishes it. A validated EMBLEM RRset establishes that the holder of the zone's signing keys published that data, and nothing more. Whether that zone holder is entitled to make the statement is a separate question, answered by endorsements where a profile requires them and otherwise by the validator's own knowledge (a customs officer knows which shippers they deal with).¶

This model has a single technical root (the DNS root zone), but it does not create a central authority over emblems. No party needs another's permission to publish emblems in its own zone, and authorizing entities operate independently of one another. Profiles whose frameworks require it can place their own authorizing entities wherever the framework places them.¶

Three consequences deserve emphasis:¶

• DNSSEC authenticates the zone, not the real-world identity behind it. A lookalike domain (for example, one using Cyrillic "a" (U+0430) in place of Latin "a" (U+0061)) validates just as well as the genuine one. Profiles should carry cross-check identifiers (a GTIN, a container number, a registration number) that a validator can compare against the physical or contextual evidence in front of it, and endorsements help where a third party vouches for the issuer.¶

• In practice, many signed zones are signed by contracted operators rather than by registrants. The architecture treats the zone's signing keys as the issuer's voice, so issuers should choose operators accordingly.¶

• The architecture depends on DNSSEC deployment. An issuer needs a signed chain from the root to its emblem names, so an issuer whose TLD is not signed must publish under one that is. Validators must validate themselves or use a validating resolver they trust over a secure channel.¶

5. Naming and Discovery

example.org.                  NS   ordinary-dns.example.net.
_diem.example.org.            NS   ns1.diem-provider.example.
                              DS   ...

6. Data Model

An emblem is a dictionary: a set of key/value pairs, in which values may themselves be arrays or dictionaries. Every emblem identifies the profile that defines its keys.¶

/ external-registry pattern (illustrative): meaning only in text /
ISO 3166-1 - QA "flag state"
ISO 3166-1 - US "state of incorporation"

/ typed keys: the key carries the meaning, the code list the type /
{ "flag-state": "QA", "incorporated-in": "US" }

7. Hierarchy and Composition

Physical assets nest: devices in cartons, cartons on pallets, pallets in containers, containers on ships. Different parties attest to different levels. The architecture expresses this in two ways:¶

• Within one issuer's zone, by DNS hierarchy. An emblem name for a product class can have child names for individual items, so that class-wide data (model, hazard classification) is published once and item-specific data (serial number) is published per item.¶

• Across issuers, by reference. A shipper's consignment emblem refers to the manufacturer's emblems by domain name. Each referenced emblem is validated through its own zone's DNSSEC chain. Where the referencing party wants to fix exactly what it saw at the time (for example, a declaration to customs), the reference also carries a digest of the referenced RRset.¶

A validator walks as far as its task requires. A customs officer may validate only the shipper's consignment emblem; a recycler may validate a single device's battery facet back to the manufacturer; an audit may walk everything. Full walks of large consignments involve many queries, which caching, wildcards for homogeneous items, and offline bundles all mitigate.¶

8. Authorization and Endorsement

Some profiles require that an issuer be authorized by a third party: a state authorizing use of a protective emblem under IHL, a national plant protection organization authorizing a pallet producer to apply the ISPM 15 mark, a treaty secretariat recognizing a designated site. DNSSEC proves who published an emblem, not who authorized it. Endorsement fills that gap.¶

An endorsement is an RRset in the authorizing entity's own DNSSEC-signed zone. It names the endorsed issuer and the scope of the endorsement: the profile, the permitted purposes or designations, and a validity period. For example, hospital.example._endorse.health.gov.example might carry an ENDORSE record listing the protective purposes the ministry has authorized for hospital.example. The endorsement can also carry a digest of the issuer's DNSKEY RRset or key-signing key, in the manner of a DS record, so that it binds the zone as it was when endorsed: if the issuer's domain lapses and is re-registered, or its keys are replaced without the authorizing entity's knowledge, the endorsement no longer matches. (Binding to keys means the authorizing entity must re-endorse when the issuer rolls its key-signing key, so a profile chooses whether to bind to the zone name, the keys, or both.)¶

Validators obtain an endorsement in one of two ways:¶

Queried:

The validator looks up the endorsement in the authorizing entity's zone and validates it with DNSSEC. Revocation is removal, bounded by TTL and signature lifetime. The cost is an extra query, which reveals to the authorizing entity's servers (through resolvers) that someone is interested in the issuer.¶

Stapled:

The issuer retrieves its own endorsement, with its RRSIGs and the DNSSEC chain from the root to the authorizing entity's zone, and publishes that serialization inside or alongside its emblem, much as a TLS server staples a certificate status response. A validator validates the stapled RRset against the chain it carries, with no query to the authorizing entity. A stapled endorsement cannot be recalled once copied, so its lifetime is that of its signatures. The authorizing entity controls that lifetime through the signature validity period it chooses for endorsement RRsets, and the issuer must refresh the staple before it expires. This suits profiles that require undetectable validation or offline operation.¶

Either way the endorsement is one object, signed one way, in one place. No second signature format is needed, and the authorizing entity's operational duty is the familiar one of maintaining a signed zone. Authorization that passes through several levels (a state authorizing a ministry, which endorses hospitals) is a chain of endorsements, each in its endorser's zone, and a staple can carry the whole chain.¶

Where the list of endorsed issuers is itself sensitive, the authorizing entity can name endorsements by a digest of the issuer's name and use a denial-of-existence method that resists enumeration (Section 9): a validator that knows the issuer can find the endorsement, but nobody can list all of them.¶

An authorizing entity that also wants its endorsements to be publicly auditable (so that issuing a secret endorsement is detectable) can log them in a transparency log as an addition; a profile can require this without the architecture depending on it.¶

A profile states whether it requires endorsement, which authorizing entities it recognizes and how validators learn of them, and whether queried endorsements, stapled endorsements, or both are acceptable. Because each authorizing entity's trust is anchored in a zone it controls, no global registry of authorities is needed.¶

9. Confidentiality and Selective Disclosure

Some emblem data is restricted: a consignment's declared value, the identity of a diplomatic courier, an issuer's internal forensic data. [DIEM-REQS] anticipates selective disclosure.¶

The architectural primitive is encryption of values inside signed records. An encrypted value is a COSE [RFC9052] encryption structure (COSE_Encrypt0 for a single recipient, COSE_Encrypt with recipient structures where several parties, such as origin and destination customs, need access), with keys distributed as the profile specifies (for example, using HPKE [RFC9180] [I-D.ietf-cose-hpke] to a public key that a customs authority publishes in its own zone). DNSSEC signs the ciphertext, so integrity covers restricted fields even for validators that cannot read them. This resolves an open question from the -00 draft (how encrypted subrecords participate in integrity protection): the signature covers what is published, which is the ciphertext.¶

The alternative of authenticated DNS views, in which the server authenticates the client and returns different data to different audiences, is not recommended as the general mechanism:¶

• It identifies validators to issuers' servers, which is unacceptable where inspection patterns are sensitive (and fatal to undetectable validation).¶

• Answers that differ per client cannot be shared through resolver caches, so the restricted tier becomes an application API with DNS framing.¶

• Standardizing mandatory client identification for DNS lookups creates a precedent that could be misused well beyond DIEM.¶

Profiles may still use authenticated access where audit of who looked is itself a requirement, but should do so knowingly.¶

Confidentiality also covers existence. Where the mere existence of an emblem name is sensitive, issuers use unguessable labels and a denial-of-existence method that does not reveal them. Plain NSEC allows zone walking and would expose such labels. Compact denial of existence [RFC9824] reveals nothing but requires online signing; offline-signed zones can use NSEC3 [RFC9276], whose hashed names resist enumeration when the labels themselves have high entropy. NSEC3 still reveals, through its type bitmaps, how many names in the zone hold emblem records, though not which names they are; issuers for whom that count is sensitive should use compact denial or add decoy names.¶

10. Offline and Constrained Validation

[DIEM-REQS] requires that the architecture not assume Internet access. DNSSEC data is self-authenticating: an RRset, its RRSIG, and the chain of DNSKEY and DS records up to a trust anchor can be validated anywhere, by anyone holding the root trust anchor and a clock.¶

An offline bundle serializes exactly that, following the pattern of the TLS DNSSEC chain extension [RFC9102] and the CHAIN query [RFC7901]. A full chain from the root is typically a few kilobytes, so a bundle fits in a large QR code, a high-capacity tag, or an accompanying document, and can be validated at a disconnected port or in the field. Signature algorithm choice matters here: newer algorithms, such as those based on elliptic curves, have much smaller keys and signatures than RSA (see [RFC8624] for current guidance), so issuers that expect their emblems to travel in bundles should prefer them. Bundle sizes will need revisiting as post-quantum algorithms, whose signatures are generally larger, come into use for DNSSEC. Its validity is bounded by the shortest RRSIG validity period it contains, which also bounds how long a removed emblem can be replayed. That includes the signatures of the root and TLD zones, which the issuer does not control and which typically last one to three weeks, so bundles have a limited shelf life and must be refreshed for long journeys. An offline validator also needs a trustworthy clock, since a validator whose clock can be set back will accept expired signatures.¶

Offline bundles take over the role that application-layer signed objects (such as signed CBOR) played in earlier thinking, without introducing a second signature system.¶

11. Lifecycle, Removal, and Forensics

Removal:

Some profiles require that an emblem be removable ([DIEM-REQS]). Removing the records stops new validators from finding them, but signed copies remain valid until their RRSIGs expire, and caches may hold them until their TTLs expire. Profiles that need prompt removal should use short signature validity periods and TTLs, which in practice means online signing, and which limits the shelf life of offline bundles accordingly. An emblem's own validity period is a different thing: it bounds the issuer's statement, while signature lifetimes bound how long a copy can be replayed, and only the latter governs removal. Profiles should also be candid in their threat models that the DNS is not forgetful: passive DNS collectors may retain records indefinitely, which matters for the "learn after the fact" aspect of removability.¶

Archival:

Removal from the DNS is not deletion. Most use cases expect the issuer to archive emblems, with lifespan rules set by the profile. Some archived data is public forensic record; some is internal (for example, the identity of the staff member who created a record) and may be published only in encrypted form or not at all.¶

Proof of presence:

A validated DNSSEC response is a portable, third-party-verifiable record that the zone's key signed a given emblem with a validity period covering a given time. A validator that retains the response (with the DNSKEYs then in effect) holds evidence supporting Level 1 proof of presence in the terms of [DIEM-REQS]. Level 2 (that a validator accessed the emblem) would need records of access, for example server-side logs where a profile accepts that access is observable, and Level 3 must come from the validator's own signed records; both are outside the DNS data itself.¶

12. Undetectable Validation

The IHL use case requires that validation be undetectable by the asset's operator ([DIEM-REQS]). Several mechanisms contribute, and none is sufficient alone:¶

• Resolver mediation: an issuer's authoritative server sees queries from resolvers, not from validators. Large shared resolvers and Oblivious DoH [RFC9230] enlarge or obscure the population of query sources. EDNS Client Subnet [RFC7871] works against this; validators should use resolvers that do not send it, or opt out with a source prefix length of zero.¶

• Limiting other observers: encrypted transports protect the path to the resolver, and QNAME minimisation [RFC9156] keeps parent zones from learning the full name. Neither hides the query from the issuer's own authoritative server.¶

• Caching: a cached answer generates no query at all.¶

• Self-contained answers: if everything needed for validation (including stapled endorsements, Section 8) arrives in one response, no follow-up query to the issuer or authorizing entity reveals interest.¶

• Query indistinguishability: if the query that retrieves an emblem is one that ordinary clients make anyway, retrieving the emblem reveals nothing. For a network service, the emblem can travel in a record that clients already request when connecting, such as the asset's HTTPS record [RFC9460]. Techniques of this kind place emblem data in the asset's own zone, so they cannot be combined with delegating emblems to a separate server through a zone cut, and they should not require changes to recursive resolvers, which would delay deployment.¶

This document recommends a baseline that works with today's DNS: validators query through large shared resolvers that do not send client subnet information, over encrypted transports, and issuers publish self-contained emblems with stapled endorsements and TTLs long enough for caching to be effective. Against an issuer that watches its own authoritative server, this baseline hides who is validating but not that someone is, and only when the resolver's population is large enough to blend in. Query indistinguishability is the only measure that hides the act of validation itself, so a profile whose threat model includes that adversary should require such a technique and accept its deployment constraints.¶

A profile that requires undetectable validation must state its threat model ([DIEM-REQS]) in terms of which of these it relies on.¶

13. Defining a Profile

Because the architecture leaves the use-case-specific choices to profiles, a profile specification has a predictable shape. A profile specifies:¶

Data:

Its keys, each with a type (preferably in CDDL), and which are required, which are critical, and which are confidential; and which common keys and code lists it reuses.¶

Layout:

How its data divides into facets, which facets are static and which dynamic, and the expected TTLs and signing arrangements for each (Section 6.6).¶

Naming and discovery:

How validators learn emblem names for its assets, and whether names are derived from the asset's name, conveyed out of band, or deliberately unguessable (Section 5).¶

Hierarchy:

Whether its emblems refer to emblems of other issuers or profiles, and whether references carry digests (Section 7).¶

Authorization:

Whether endorsement is required, which authorizing entities it recognizes and how validators learn of them, and whether queried or stapled endorsements are acceptable (Section 8).¶

Confidentiality:

Which values are encrypted, to whom, and how recipients' keys are found (Section 9).¶

Lifecycle:

Removal expectations, the signature lifetimes and TTLs that follow from them, archival rules, and the level of proof of presence it supports (Section 11).¶

Threat model:

Its adversaries, including whether validation must be undetectable and by whom (Section 12), and whether unvalidated emblems may be used at all.¶

Interpretation:

The treatments it may request (Section 6.3), the citation schemes it expects for their legal basis, what a validated emblem means for a validator acting under the profile's normative framework, and what a validator should do when an expected emblem is absent or fails validation.¶

A profile specification therefore needs no protocol design of its own. The worked examples in Section 17 are informal sketches of four such profiles.¶

14. Validation Outline

Validation proceeds in the same way for every profile; only the final interpretation is profile-specific. In outline, a validator:¶

1. obtains the emblem name (or an offline bundle) for the asset;¶

2. retrieves the emblem records it needs, or extracts them from the bundle;¶

3. validates them with DNSSEC, treating bogus data as absent and, unless the profile permits unvalidated emblems, treating unsigned data as absent;¶

4. checks that the emblem identifies the asset in front of it, by FQDN and by whatever cross-check identifiers the profile defines;¶

5. identifies the profile, checks each value against its key's type, and rejects the emblem if it contains a critical key the validator does not understand;¶

6. checks validity periods;¶

7. where the profile requires authorization, validates the endorsement (queried or stapled) and checks that its scope covers the emblem;¶

8. follows references to other emblems as far as its task requires, checking digests where present;¶

9. decrypts any confidential values it is entitled to read; and¶

10. interprets the result under the profile, optionally retaining the validated responses as evidence (Section 11).¶

Steps 1 through 9 need no profile-specific code beyond the profile's key and type definitions, which a validator can load as data.¶

15. Meeting the Requirements

The following table summarizes how the architecture addresses the requirements of [DIEM-REQS].¶

16. Strawman Encoding

This section is illustrative. It sketches one way to realize the architecture so that the working group can evaluate it; it is not a specification.¶

17. Example Use Cases

The following examples are sketches. Names, keys, and values are illustrative. Emblem dictionaries are shown in CBOR diagnostic notation with text keys and text enumerated values (both of which would be integers in an encoding, Section 16), using the elision ... of [I-D.ietf-cbor-edn-literals] for long values. Country codes beginning with "X" are user-assigned placeholders.¶

/ EMBLEM at _diem.records.hospital.example /
{
  "profile": "ihl-protective",
  "purpose": ["protective-red-cross"],
  "asset":   "records.hospital.example",
  "treatment": [{"prohibit": "attack"}],
  "basis":   [{"scheme": "uri",
               "id":   32("https://ihl-databases.icrc.org/..."),
               "text": 38(["en", "GC I, Art. 19"])}],
  "valid":   [1(1793491200), 1(1801440000)],
  "issuer-name": 38(["en", "Example General Hospital"]),
  "mark":    "_mark._diem.records.hospital.example",
  "endorsement": {                / stapled, from the ministry /
    "by":     "health.gov.example",
    "staple": h'...'   / ENDORSE RRset, RRSIGs, chain from root /
  }
}

/ ENDORSE at 3q9v...._endorse.health.gov.example (stapled above) /
{
  "profile": "endorsement",
  "issuer":  "hospital.example",
  "endorsed-profile": "ihl-protective",
  "scope":   ["protective-red-cross", {"prohibit": "attack"}],
  "valid":   [1(1793491200), 1(1801440000)],
  "dnskey-digest": h'...',     / binds the hospital's current KSK /
  "mark-digest":   h'...'      / the mark the hospital may display /
}

/ EMBLEM at _mark._diem.records.hospital.example /
/ (visual mark facet: an image of the distinctive emblem) /
{
  "profile":    "mark",
  "asset":      "records.hospital.example",
  "media-type": "image/svg+xml",
  "image":      h'...'   / <SVG of Red Cross emblem> /
}

x1.models._diem.maker.example.              EMBLEM  (class: model X1)
sn-35791a7c.x1.models._diem.maker.example.  EMBLEM  (one device)

/ EMBLEM at x1.models._diem.maker.example (static, offline-signed) /
{
  "profile": "product-class",
  "asset":   "x1.models._diem.maker.example",
  "gtin":    "00614141999996",
  "model":   "X1",
  "dangerous-goods": {
    "un-number": "3481",  / Li-ion batteries in equipment /
    "class":     "9"
  },
  "battery-chemistry": "li-ion",
  "battery-energy": [4([-1, 185]), "WHR"],   / 18.5 watt-hours /
  "recycling": 32("https://maker.example/recycle/x1"),
  "origin":    "VN",
  "mid-us":    "VNEXAMAK123HAN",     / US manufacturer ID /
  "radio-auth": {"fcc-id": "2AEXAX1"},
  "components": [
    {"part": "battery-cell",
     "attestation": "cell.x1.supply._diem.maker.example",
     "digest": h'5e1b...'},
    {"part": "display",
     "attestation": "disp.x1.supply._diem.maker.example",
     "digest": h'c07a...'}
  ]
}

/ EMBLEM at sn-35791a7c.x1.models._diem.maker.example /
{
  "profile": "product-item",
  "asset":   "sn-35791a7c.x1.models._diem.maker.example",
  "serial":  "35791A7C",
  "made":    1(1790812800)
}

/ EMBLEM at p-20261031-0042._diem.pallets.example /
{
  "profile":   "ispm15",
  "asset":     "p-20261031-0042._diem.pallets.example",
  "country":   "VN",          / ISO 3166-1 alpha-2 /
  "producer":  "000123",      / registration number from the NPPO /
  "measure":   "HT"           / ISPM 15 treatment: heat /
}
/ ENDORSE at pallets.example._endorse.nppo.gov.example /

/ EMBLEM at c-7f3k9q2m._diem.forwarder.example /
{
  "profile":    "consignment",
  "asset":      "c-7f3k9q2m._diem.forwarder.example",
  "hs-code":    "851713",          / smartphones /
  "hts-us":     "8517130000",
  "origin":     "VN",
  "container":  "EXMU1234569",     / ISO 6346 /
  "seal":       "EX4471029",
  "packages":   [1, "PX"],         / UNECE Rec. 21: pallet /
  "gross-mass": [4([0, 725]), "KGM"],
  "transport": {
    "bill-of-lading":   "EXSC260098812",
    "carrier":          "EXSC",
    "vessel":           "EXAMPLE STAR",
    "voyage":           "042E",
    "port-of-lading":   "VNSGN",   / UN/LOCODE /
    "port-of-unlading": "USLAX"
  },
  "valuation":  16(...),           / encrypted to customs /
  "parties":    16(...),           / encrypted: seller, buyer, /
                                   / importer of record, bond, /
                                   / ship-to, consolidator,    /
                                   / stuffing location         /
  "contents": [
    {"emblem": "p-20261031-0042._diem.pallets.example"},
    {"emblem": "x1.models._diem.maker.example", "count": 1400,
     "items-digest": h'9a0c...'}   / digest of the item name list /
  ]
}

/ LOC at c-7f3k9q2m._live._diem.forwarder.example /
/ (shared online-signed zone, TTL 300)              /

/ plaintext of "valuation" /
{
  "method":     "transaction-value",   / customs valuation method /
  "related-party": false,
  "incoterm":   "FOB",                   / ICC Incoterms rule /
  "invoice":    "INV-2026-10-4471",
  "unit-price": [4([-1, 4125]), "USD"],  / 412.50 /
  "quantity":   1400,
  "total":      [4([2, 5775]), "USD"],   / 577,500 /
  "freight":    [4([2, 32]), "USD"],     / 3,200 /
  "insurance":  [4([0, 1155]), "USD"],   / 1,155 /
  "additions":  []                       / no assists or royalties /
}

/ EMBLEM at k7q2-9xwm-4hd3._pouch._diem.mfa.gov.example /
{
  "profile":       "diplomatic-pouch",
  "asset":         "k7q2-9xwm-4hd3._pouch._diem.mfa.gov.example",
  "sending-state": "XA",                     / ISO 3166-1 /
  "consignee":     "embassy.xa.example",     / receiving mission /
  "seal":          "XA-2026-114357",   / matches physical seal /
  "pieces":        3,
  "gross-mass":    [4([-1, 184]), "KGM"],    / 18.4 kg /
  "courier":       16(...),       / to receiving state /
  "treatment":     [{"prohibit": "open"}, {"prohibit": "detain"}],
  "basis":         [{"scheme": "uri",
                     "id":   32("https://legal.un.org/..."),
                     "text": 38(["en", "VCDR, Art. 27(3)"])}],
  "valid":         [1(1793750400), 1(1794355200)]
}

/ EMBLEM at r4nq-8w2k-c7tz._p._diem.mission.example /
{
  "profile":  "peacekeeping-personnel",
  "asset":    "r4nq-8w2k-c7tz._p._diem.mission.example",
  "mission":  "mission.example",
  "status":   "peacekeeper",
  "valid":    [1(1793491200), 1(1801267200)],
  "treatment": [{"prohibit": "attack"}, {"prohibit": "detain"}]
}

/ EMBLEM at _diem.mission.example (the mission itself) /
{
  "profile":  "peacekeeping-mission",
  "asset":    "mission.example",
  "contact":  32("https://mission.example/report"),
  "if-invalid": [{"request": "report"}, {"request": "hold"}]
}

18. Security Considerations

DNSSEC provides integrity and origin authentication for emblem data only if validators actually validate. Validators must perform DNSSEC validation themselves, or use a resolver they trust over a secure channel, and must treat bogus emblem data as absent. Unsigned emblem data must also be treated as absent unless the profile permits unvalidated emblems, in which case it carries no assurance of origin or integrity.¶

An emblem is a statement by a zone holder. Validators must not infer authorization from publication; where a profile requires authorization, the validator must validate the endorsement as well. Lookalike and typosquatted domains are not addressed by DNSSEC; cross-check identifiers and endorsements mitigate them.¶

Removal is bounded by signature lifetimes and caching, and passive DNS collection means that removed emblems may remain known. Profiles with removability requirements must account for both.¶

Encrypted values protect confidentiality, but metadata remains visible: the emblem name, the profile, the size of the ciphertext, and the timing of queries. Unguessable labels, with compact denial or NSEC3 rather than plain NSEC, reduce enumeration risk.¶

Full audits of hierarchical emblems cause many queries; offline bundles and caching mitigate this, and profiles should state what depth of validation they expect.¶

Validity checks depend on time. A validator whose clock is wrong, or can be set back by an attacker, will accept expired signatures and replayed emblems, which matters most for offline validators.¶

Validators that display images supplied by issuers face two risks: the image may mislead a person (a lookalike mark, or a mark that contradicts the emblem's data), and the image format may attack the software that renders it. Validators should display only visual marks that meet the conditions of Section 6.4, render them with a restricted renderer, and never let a visual mark override the emblem's data.¶

As with physical emblems, displaying a digital emblem may increase an asset's risk in some contexts. Profiles should consider this when specifying discovery and removal.¶

19. Privacy Considerations

Emblems are published so that they can be read, and the privacy questions concern who learns what beyond the emblem's intended content [RFC6973].¶

Validators:

Each query reveals interest in an asset to the validator's resolver and, through the resolver, to the issuer's authoritative servers and to any authorizing entity whose endorsement is queried. For some profiles this is harmless; for others the pattern of inspections is itself sensitive. Section 12 describes the available mitigations and their limits.¶

Issuers:

An issuer's emblem names can reveal its inventory, its customers, or its operations. Enumeration of a zone (by NSEC walking) or of an authorizing entity's endorsements exposes them in bulk, which unguessable labels and enumeration-resistant denial address (Section 9).¶

Assets that are people:

[DIEM-REQS] includes people among the assets an emblem can mark. An emblem name that stays fixed is a persistent identifier: anyone who scans it once can recognize the person later, link sightings, and watch whether the emblem is still published. Profiles that mark people should use unguessable names that change on a schedule suited to the use case, keep personal data out of emblems or encrypt it, avoid publishing location in plaintext, and avoid cross-references that link one person's emblems together. The issuer can observe where and when a person's emblem is validated, and a profile should say whether that is intended.¶

Encrypted values:

Encryption hides content but not size, timing, or the set of recipients a profile defines. A value encrypted to a recipient today may be read by anyone who obtains that recipient's key later, and emblems are retained by caches, passive DNS collectors, and validators long after removal (Section 11). Profiles should not encrypt data whose later disclosure would be harmful unless that risk is acceptable.¶

20. IANA Considerations

This document has no IANA actions. A specification realizing it would request the EMBLEM and ENDORSE RRTypes and create registries for common keys, profile identifiers, and code-list identifiers.¶

21. Informative References

[API]

"Protocol Additional to the Geneva Conventions of 12 August 1949, and relating to the Protection of Victims of International Armed Conflicts (Protocol I)", 1977, <https://ihl-databases.icrc.org/en/ihl-treaties/api-1977>.

[CHARTER]

"Digital Emblems", 27 May 2025, <https://datatracker.ietf.org/doc/charter-ietf-diem/01/>.

[DIEM-REQS]

Fainchtein, R. A., Linker, F., Rosenberg, A., Deccio, C., and A. Mankin, "Digital Emblems - Use Cases and Requirements", Work in Progress, Internet-Draft, draft-ietf-diem-requirements-05, 1 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-diem-requirements-05>.

[HS]

World Customs Organization, "Harmonized Commodity Description and Coding System", n.d., <https://www.wcoomd.org/en/topics/nomenclature/overview.aspx>.

[I-D.brand-indicators-for-message-identification]

Blank, S., Goldstein, P., Loder, T., Zink, T., Bradshaw, J., Brotman, A., and W. Chuang, "Brand Indicators for Message Identification (BIMI)", Work in Progress, Internet-Draft, draft-brand-indicators-for-message-identification-15, 31 October 2026, <https://datatracker.ietf.org/doc/html/draft-brand-indicators-for-message-identification-15>.

[I-D.ietf-cbor-edn-literals]

Bormann, C., "Concise Diagnostic Notation (CDN)", Work in Progress, Internet-Draft, draft-ietf-cbor-edn-literals-29, 31 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-cbor-edn-literals-29>.

[I-D.ietf-cose-hpke]

Tschofenig, H., Jones, M. B., Steele, O., Daisuke, A., and L. Lundblade, "Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE)", Work in Progress, Internet-Draft, draft-ietf-cose-hpke-27, 12 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-27>.

[I-D.svg-tiny-ps-abrotman]

Brotman, A. and J. T. Adams, "SVG Tiny Portable/Secure", Work in Progress, Internet-Draft, draft-svg-tiny-ps-abrotman-13, 31 October 2026, <https://datatracker.ietf.org/doc/html/draft-svg-tiny-ps-abrotman-13>.

[I-D.woodcock-faltstrom-external-registry-rrtypes]

Woodcock, B. and P. Fältström, "External-Registry DNS Resource Record Types: UNECE and ISO", Work in Progress, Internet-Draft, draft-woodcock-faltstrom-external-registry-rrtypes-01, 9 September 2026, <https://datatracker.ietf.org/doc/html/draft-woodcock-faltstrom-external-registry-rrtypes-01>.

[ISO3166]

International Organization for Standardization, "ISO 3166 -- Country Codes", n.d., <https://www.iso.org/iso-3166-country-codes.html>.

[ISO4217]

International Organization for Standardization, "ISO 4217 -- Currency Codes", n.d., <https://www.iso.org/iso-4217-currency-codes.html>.

[ISPM15]

International Plant Protection Convention, "ISPM 15: Regulation of wood packaging material in international trade", n.d., <https://www.ippc.int/en/publications/640/>.

[RFC1876]

Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, DOI 10.17487/RFC1876, January 1996, <https://www.rfc-editor.org/rfc/rfc1876>.

[RFC3597]

Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/rfc/rfc3597>.

[RFC4033]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/rfc/rfc4033>.

[RFC4034]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/rfc/rfc4034>.

[RFC4035]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/rfc/rfc4035>.

[RFC4501]

Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, <https://www.rfc-editor.org/rfc/rfc4501>.

[RFC4592]

Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <https://www.rfc-editor.org/rfc/rfc4592>.

[RFC5646]

Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.

[RFC6698]

Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/rfc/rfc6698>.

[RFC6895]

Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/rfc/rfc6895>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC7553]

Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, <https://www.rfc-editor.org/rfc/rfc7553>.

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/rfc/rfc7858>.

[RFC7871]

Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, <https://www.rfc-editor.org/rfc/rfc7871>.

[RFC7901]

Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI 10.17487/RFC7901, June 2016, <https://www.rfc-editor.org/rfc/rfc7901>.

[RFC8484]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/rfc/rfc8484>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8624]

Wouters, P. and O. Sury, "Algorithm Implementation Requirements and Usage Guidance for DNSSEC", RFC 8624, DOI 10.17487/RFC8624, June 2019, <https://www.rfc-editor.org/rfc/rfc8624>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9102]

Dukhovni, V., Huque, S., Toorop, W., Wouters, P., and M. Shore, "TLS DNSSEC Chain Extension", RFC 9102, DOI 10.17487/RFC9102, August 2021, <https://www.rfc-editor.org/rfc/rfc9102>.

[RFC9156]

Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, <https://www.rfc-editor.org/rfc/rfc9156>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

[RFC9230]

Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. Wood, "Oblivious DNS over HTTPS", RFC 9230, DOI 10.17487/RFC9230, June 2022, <https://www.rfc-editor.org/rfc/rfc9230>.

[RFC9250]

Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/rfc/rfc9250>.

[RFC9276]

Hardaker, W. and V. Dukhovni, "Guidance for NSEC3 Parameter Settings", BCP 236, RFC 9276, DOI 10.17487/RFC9276, August 2022, <https://www.rfc-editor.org/rfc/rfc9276>.

[RFC9364]

Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/rfc/rfc9364>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9824]

Huque, S., Elmerot, C., and O. Gudmundsson, "Compact Denial of Existence in DNSSEC", RFC 9824, DOI 10.17487/RFC9824, September 2025, <https://www.rfc-editor.org/rfc/rfc9824>.

[UNECE20]

United Nations Economic Commission for Europe, "Recommendation No. 20: Codes for Units of Measure Used in International Trade", n.d., <https://unece.org/trade/uncefact/cl-recommendations>.

[UNMODELREGS]

United Nations, "UN Recommendations on the Transport of Dangerous Goods, Model Regulations", n.d., <https://unece.org/transport/dangerous-goods/un-model-regulations-rev-24>.

[VCDR]

"Vienna Convention on Diplomatic Relations", 1961, <https://legal.un.org/ilc/texts/instruments/english/conventions/9_1_1961.pdf>.

Changes from draft-rosenberg-diem-architecture-00

This section is to be removed before publishing as an RFC.¶

• Adopted DNSSEC as the integrity layer, replacing application-layer hashing of emblem records.¶

• Replaced "signed" and "informational" fields with static and dynamic facets in separate RRsets.¶

• Replaced the Merkle-tree hierarchy with DNS naming plus cross-zone references with optional digests.¶

• Added typed keys and external code lists as value types.¶

• Added treatment (requested actions with an open legal basis) as a common key.¶

• Added visual marks, displayed only when endorsed or canonical.¶

• Added endorsement (as RRsets in the authorizing entity's zone, queried or stapled), confidentiality, offline bundles, lifecycle, and undetectable validation sections.¶

• Added what a profile specifies, and an outline of validation common to all profiles.¶

• Added Privacy Considerations.¶

• Added a strawman EMBLEM encoding using deterministic CBOR.¶

• Added worked examples for IHL, logistics and customs, diplomatic pouches, and peacekeeping.¶

Acknowledgments

The author thanks the participants of the DIEM working group for their drafts and comments.¶

Author's Address