Conceptual Model for Digitized Emblems
draft-bwbh-digital-emblem-model-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bill Woodcock , Brian Haberman , Casey Deccio | ||
| Last updated | 2024-11-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bwbh-digital-emblem-model-01
Network Working Group B. Woodcock
Internet-Draft PCH
Intended status: Informational B. Haberman
Expires: 25 May 2025 JHU/APL
C. Deccio
Brigham Young University
21 November 2024
Conceptual Model for Digitized Emblems
draft-bwbh-digital-emblem-model-01
Abstract
This document describes the conceptual models of use for digital
emblems.
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 25 May 2025.
Copyright Notice
Copyright (c) 2024 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.
Woodcock, et al. Expires 25 May 2025 [Page 1]
Internet-Draft Digital Emblem Models November 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Roles and Relationships . . . . . . . . . . . . . . . . . . . 4
3. Discovery and Access Control . . . . . . . . . . . . . . . . 4
4. Digital Emblem Data Model . . . . . . . . . . . . . . . . . . 5
5. Digital Emblem Functional Requirements . . . . . . . . . . . 6
5.1. Goals and Non-goals . . . . . . . . . . . . . . . . . . . 6
5.2. Issuance . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Validation and Display . . . . . . . . . . . . . . . . . 8
5.4. Binding of Issuer to Digital Emblem . . . . . . . . . . . 10
5.5. Binding of Digital Emblem to Asset . . . . . . . . . . . 11
5.6. Distribution Mechanisms . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Digital emblems are intended to be modern counterparts to the visual
markings which have historically been used to comply with marking
requirements found in international law. Digital emblems provide
mechanisms for authentication, access control, dynamic data and
bidirectional data flows, revocation, non-repudiatability, and the
inclusion of external data, rich media, and many other benefits which
are difficult or impossible to convey with a rattle-can and a
stencil.
Although there are many different marks, applied by many different
parties, for many different purposes, the task of marking, per se, is
simply one of conveying information between parties. As long as a
protocol is capable of conveying any information parties agree to use
it for, it succeeds. If it is too prescriptive, or tries too hard to
anticipate and circumscribe uses, it fails.
Many use-cases for digital counterparts to physical markings have
been documented [I-D.haberman-digital-emblem-ps]. This document
distills the common technological requirements of those use-cases
into a single harmonized set of requirements; the superset of
requirements which are common to multiple intergovernmental
organizations and multiple bodies of international law. From this
set of common requirements is derived a conceptual models of digital
emblems.
Woodcock, et al. Expires 25 May 2025 [Page 2]
Internet-Draft Digital Emblem Models November 2024
1.1. Conventions
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.
1.2. Terminology
* _Asset:_ A person, place, or thing that is designated by a state
or other recognized entity as having certain legal protections.
* _Digital Emblem._ A digital embodiment of the protections granted
for an asset, consisting of attributes that definitively describe
the asset using electronic means. These attributes collectively
associate the emblem to the asset based on legal or similar
normative framework and inform recipients of the emblem as to how
they should treat the asset.
* _Authenticity:_ A characteristic that demonstrates a) the positive
association between a digital emblem to the asset that it
describes, using its attributes and b) that the digital emblem
itself is the original and has not been tampered with.
* _Authorization:_ The act of granting legitimacy to the creation of
a digital emblem for an asset, either directly by an entity that
is officially recognized to do so, or indirectly, by an entity
that has been recognized by an already-recognized entity.
* _Validation:_ The act of verifying both the authenticity and
authorization of a digital emblem using one or more ultimately
trusted sources as the root(s) for authenticity and/or
authorization.
* _Discovery:_ The process of definitely determining whether a
digital emblem exists for a given asset, or learning digital
emblems and their corresponding assets.
* _Issuer:_ The entity that has created a digital emblem.
* _Validator:_ An entity performing validation of a digital emblem.
Woodcock, et al. Expires 25 May 2025 [Page 3]
Internet-Draft Digital Emblem Models November 2024
2. Roles and Relationships
The _issuer_ of a digital emblem is the entity that wants to
communicate to third parties that the associated asset has certain
legal protections. It does this by creating the digital emblem,
digitally signing it in such a way that it can be _validated_ for
both _authorization_ and _authenticity_, and making it discoverable
via a distribution mechanism.
The _validator_ is the ultimate consumer of a digital emblem; it is
an entity wanting to inquire as to whether a given asset has legal
protections. This entity needs some way to _discover_ the digital
emblem associated with the asset in question and to _validate_ it.
Figure 1 illustrates these roles.
+--------+
| Issuer |
+----+---+
|
Signature |<------------------+
| |
+----+----+ | +-----------+
| Digital | Validation +-| Validator |
| Emblem | | +-----------+
+----+----+ |
| |
Attributes |<------------------+
|
+---+---+
| Asset |
+-------+
Figure 1: Digital Emblem Relationships
3. Discovery and Access Control
A distribution mechanism is used by the issuer to make a digital
emblem for an asset discoverable to a validator. It is referenced by
an unambiguous identifier appropriate for that mechanism. Example
identifiers include a domain name or a Uniform Resource Locator
(URL). The distribution mechanism may be access-controlled, and it
may require that validators authenticate themselves in order to gain
access to an emblem. A physical representation of a digital emblem
may be used by the issuer to direct validators to the digital emblem
by displaying or to to communicate the digital emblem itself. Thus,
a physical representation may be either a non-unique embodiment of
the emblem, or it may be a signpost directing validators to a digital
Woodcock, et al. Expires 25 May 2025 [Page 4]
Internet-Draft Digital Emblem Models November 2024
emblem via a separate distribution mechanism.
4. Digital Emblem Data Model
A digital emblem consists of attributes that unambiguously describe
the asset with which it is associated, as well as the considerations
it is to be given, including legal and other protections. These take
the form of a bundle of related records appropriate for the
distribution mechanism employed, and discoverable at the specified
identifier. The attributes comprising the records bind the record to
the asset. They convey information regarding the asset and its
handling which may not be presently anticipated by current
implementors. Figure 2 illustrates the record bundles for issuers
and assets. Figure 3 shows the channels used to convey the
information to a validator.
+------------------------+ +----------------------------+
| Issuer | | Asset |
+------------------------+ +----------------------------+
+===| Visual representation |======| Temporal scope of validity |===+
|| | Identification of law | | Spatial scope of validity | ||
|| | Contact information | | SI unit of size or weight | ||
|| | Handling flags | | WCO standard quantity | ||
|| | Issuer's signature | | ISO 4217 unit of currency | ||
|| | Third-party signatures | | Names and serial numbers | ||
|| +------------------------+ | Distinguishing marks | ||
|| | External references | ||
|| +----------------------------+ ||
|| ||
|| Standardized digital emblem data elements ||
|| ||
+====================================================================+
Figure 2: Issuer and Asset Bundles and Binding
--- Data at rest ----------------->
+--------+ --- Data in flight --------------->
| Issuer | --- In-band network response ----->
+--------+ --- Passive RF transponder ------->
--- Active RF transponder --------> +-----------+
--- Active RF beacon -------------> | Validator |
--- Passive optical marking ------> +-----------+
+-------+ --- Active optical transponder --->
| Asset | --- Active optical beacon -------->
+-------+ --- Active audio transponder ----->
--- Active audio beacon ---------->
Woodcock, et al. Expires 25 May 2025 [Page 5]
Internet-Draft Digital Emblem Models November 2024
Figure 3: Communication channels conveying digital emblem data to
validators
Digital emblem data bundles may be presented as part of an
interactive session between issuer and validator, as for instance in
the case that the validator MUST be authenticated in real time, or
may receive variable information. Digital emblem data bundles may
also be presented as static data or unidirectional data flows, which
may facilitate offline validation. Digital emblems should be
agnostic as to the mode by which they are communicated to validators,
but implementors may wish to consider methods which encompass both
interactive and offline validation, transmission of the whole digital
emblem data bundles or redirective links to them, and should prefer,
wherever possible, to implement digital emblems above already-
standardized lower-level transmission protocols, without requiring
exceptions or revisions to those protocols to accommodate digital
emblem payloads. A number of the anticipated possible distribution
mechanisms are noted in the diagram above.
5. Digital Emblem Functional Requirements
5.1. Goals and Non-goals
* It MUST be possible to bind a digital emblem to a person, place,
thing, digital data at rest, digital data in transit, or an online
service (collectively referred to as assets).
* Putting aside any legal or regulatory restrictions, any entity MAY
issue a digital emblem under their own authority and imprimatur
without the approval or participation of any other party.
* Non-goal: The binding of assets and emblems will always be
fraught, and markings of any kind MAY be replicated outside the
control or intention of a their original author. No protocol can
limit the actions of people in the physical world, and thus this
protocol focuses on improving the communication channel which
allows validators to determine the authenticity of the original
emblem (not of a physical representation of the emblem) and the
information needed to determine the authenticity of the binding.
5.2. Issuance
* A digital emblem consists of a set of one or more data elements
united by a common label.
Woodcock, et al. Expires 25 May 2025 [Page 6]
Internet-Draft Digital Emblem Models November 2024
* It SHOULD be possible for a single uniquely-named digital emblem
to incorporate data elements which are also used in other digital
emblems issued by the same issuer, or other digital emblems issued
by other issuers.
* It SHOULD be possible to organize digital emblems in a
hierarchical namespace, in which each node of the namespace MAY
contain a bundle of records representing a single digital emblem.
* It MUST be possible for parties controlling portions of the
hierarchical namespace to receive delegations of that space from
others above them in the hierarchy, and to perform delegations to
others who are then by definition below them in the hierarchy.
* Any hierarchy of cryptographic signatures used to authenticate
digital emblems SHOULD be one and the same as the hierarchy of the
namespace.
* Issuers MUST be free to compose digital emblem of the elements
which best fit their uses. No element type SHOULD be a required
member of the set. <!---
* A digital emblem MUST be capable of displaying a visual
representation of any physical emblem which it supplements or
replaces. This MUST be in scalable vector format. The preferred
aspect-ratio is between 1:1 and 2:1, but MUST NOT exceed 3:1 or
1:3. The emblem MAY be presented in two versions, one for display
against a light background, the other for display against a dark
background. The emblem MUST utilize a transparent background, if
it is not a contiguous convex rectangle of the same extent as the
file. The emblem MAY utilize variable transparency, and
implementations which display it MUST support display of variable
transparency. The visual representation MUST be entirely self-
contained, and may not contain any external references, such as to
Internet-hosted webfonts or linked URLs. All current embodiments
are anticipated to be static visual images, without animation or
sound. While it SHOULD generally be possible to include digital
emblem elements from other areas of the digital emblem hierarchy,
visual representations MAY only be used within their own cone, or
cones linked by an outbound intra-organizational Digital Emblem
Peer (DEP) signature. For example, the United Nations logotype
might be included as a visual representation within any digital
embem in any cone which the UN has signed with an intra-
organizational DEP, but may not be used within the cone of
CopyCatCo. --->
Woodcock, et al. Expires 25 May 2025 [Page 7]
Internet-Draft Digital Emblem Models November 2024
* A visual representation SHOULD be included in any digital emblem
bundle which the issuer has reason to believe may be viewed by a
human. If a visual representation is included it MUST be in
scalable vector format.
* It SHOULD be possible to use a redirection to include-by-reference
a bundle of records under a different namespace node, in order to
allow for the use of common sets without duplicating them (and
keeping them synchronized when updated) to different parts of the
hierarchy. If the redirections contain language tags, this MAY
also be a way to allow good localization support without
cluttering the top level of the digital emblem. It could contain
these redirectors, for different language-codes, which would
expand into the set of records supporting that language. If
someone doesn't speak Turkish, they could ignore all the redirects
that were Turkish-language-specific.
* It SHOULD be possible for an issuer to authenticate potential
validators, and respond with different digital emblem data, or no
data, depending upon the identity of the validator.
* It SHOULD be possible for an issuer to specify periods of validity
for digital emblems (TTL) and the cryptographic signatures over
them, independently of the period of validity of the subject of
the digital emblem. For example, it SHOULD be possible to issue a
digital emblem which is signed with a key which has a validity
period which extends one year into the future and one year in the
past, indicating that an asset SHOULD arrive at its destination
five days from now, and it SHOULD be possible to mark that digital
emblem as cacheable by validators for a period of one day.
* Issuers SHOULD have the option to make downward delegations within
the hierarchical namespace within their control subject to
discovery by validators or not subject to discovery, at their
option. Upward walking of the hierarchy SHOULD always be
available to any validator.
5.3. Validation and Display
* It SHOULD be possible for a validator and an issuer to conduct a
cryptographically private conversation, such that third parties
are not able to easily discern what asset the query regards, nor
what answer is returned. <!---
* Verifier implementations MUST display the visual emblem first,
followed by the name of the emblem, followed by a textual
description with hyperlinks to the bodies of protective law,
followed by the content protected by the emblem. This ordering
Woodcock, et al. Expires 25 May 2025 [Page 8]
Internet-Draft Digital Emblem Models November 2024
MAY be temporal, or spatially top-to-bottom, in the direction of
text reading, or front-to-back, in order of preference. The
emblem is not a license, and implementations MUST NOT require user
interaction to proceed through these steps, except as MAY normally
be needed to "scroll through" or read content. The emblem SHOULD
be distinguished from the content it protects, without requiring
any modal interaction on the part of the user. --->
* Verifier implementations MUST display the visual representation if
it is included in the digital emblem bundle.
* All text within digital emblems SHOULD be rendered in its native
script, and common transliterations MAY also be provided, all
identified by language tag and script [BCP47]. The native script
version SHOULD always take precedence but validators MAY, at the
user’s option, display only appropriate transliterations, if they
exist.
* It SHOULD be possible to determine authoritatively whether a
digital emblem is associated with an IP address or ASNs by
querying relevant portions of the hierarchical namespace.
* In the event that a digital emblem does not exist at a node in the
hierarchical namespace, it SHOULD be possible to prove that due
diligence has been exercised, and that a negative answer was
received at a specific time.
* Offline validation SHOULD be possible, provided a sufficient
portion of the digital emblem bundle is present, and all necessary
parent signatures/delegations are cached by the validator in then-
valid form.
* As DEP signatures SHOULD be asymmetric, it MAY be desirable to
also support discovery of outbound DEP signatures performed from a
node in the namespace hierarchy. i.e. to be able to discover what
other nodes the current node has provided DEP signatures for.
* If the digital emblem hierarchical namespace exists within another
namespace, sharing a root of trust, it MAY be useful to create a
registry which allows the publication of tops of digital emblem
cones within the larger namespace, to assist verifiers in locating
the authentic tops of the digital emblem namespace cones they’re
interested in.
Woodcock, et al. Expires 25 May 2025 [Page 9]
Internet-Draft Digital Emblem Models November 2024
* Until verification tools are widespread, it MAY be useful to have
a backwards-compatible mechanism of displaying digital emblem
information in a less-secure context, for instance web browsers
which are incapable of verifying digital emblem content might
still be capable of displaying it, with an indication that it has
not been verified.
5.4. Binding of Issuer to Digital Emblem
* It MUST be possible to cryptographically verify that the content
of a digital emblem is complete and has not been modified.
* It MUST be possible to cryptographically authenticate the issuing
party of a Digital Emblem.
* At any level of the digital emblem namespace hierarchy, it MUST be
possible to use a DEP record to contextualize the issuing party of
a Digital Emblem in terms of a "web of trust" consisting of other
related organizations, other emblem issuers within the same
organization, or other authenticated entities which can "vouch
for" the legitimacy of the issuing party in a cross-signing web-
of-trust, with the nature of the relationship between the
namespace node and the signing entity characterized using a small
standardized set of relationship types. These SHOULD include the
ability to denote one cone of the hierarchy as functionally
identical to another (in the event that two cones within the
namespace, neither of which is within the other, are functionally
identical or under common control and policy; intra-organizational
signatures which indicate that two cones are under common control
and vouch for each other, but have different function and policy;
and inter-organizational signatures which indicate that the other
organization vouches for this one, in the sense of being a known
and trusted partner, for instance. Inter-organizational DEP
relationships can be used to differentiate intended organizations
from typosquatting impersonators. Some potential relationships
which might be encoded in a DEP record include: Treaty signatory,
P&I recognizer, Organizational parent, Organizational peer,
Organizational child, License grantor, Visa / entry grantor, Work-
permit grantor, Residence-permit grantor, Employment certifier,
Overflight right grantor, Permission to enter territorial waters
grantor, Know-Your-Customer data verifier.
Woodcock, et al. Expires 25 May 2025 [Page 10]
Internet-Draft Digital Emblem Models November 2024
* It MUST be possible to specify the formal name of the TREATY or
international law referenced by the marking: "1961 Vienna
Convention on Diplomatic Relations” “The Convention on Wetlands”
If the treaty or body of law has a commonly-used informal name,
that MAY be provided as a second text string. The name SHOULD be
provided in the native script of the title of the treaty, and
common transliterations MAY also be provided, identified by
language tag and script [BCP47].
* It MUST be possible to indicate the canonical URL of a public copy
of the treaty or international law referenced by the marking.
* It MUST be possible to identify the TREATY ORGANIZATION
responsible for administering the relevant body of international
law.
* If a specific PROTECTION is being invoked under international law,
it MUST be possible to include a brief description of the legal
protection being invoked: "Anti-counterfeiting" "Diplomatic
courier" "Endangered species transport" "Fissionable materials
transport"
* It MUST be possible to identify one or more authoritative points
of CONTACT of the digital emblem issuer. It SHOULD be possible to
include fields such as person or role name, email, phone, and
postal address. If multiple CONTACT parties are identified, they
SHOULD also be distinguished as to purpose.
5.5. Binding of Digital Emblem to Asset
* It SHOULD be possible to bind a digital emblem to an online
service by FQDN, IPv4 address, IPv6 address, IP/port combination,
URL, ASN, or combinations of those.
* Binding of digital emblems to assets SHOULD be accomplished by
using digital emblem elements to describe the asset, assets, or
class of assets to which the digital emblem is bound, using
parameters appropriate to the type of asset, the context of
communication, and the shared understanding of the issuer and the
verifier.
* Common descriptive elements SHOULD be sufficiently standardized
such that they can be displayed by most verification terminals,
software, or devices.
* It MUST be possible for a digital emblem to reference arbitrary
externally-hosted media via URLs. References to image URLs (i.e.
images which do not contain text) do not need language tags. URLs
Woodcock, et al. Expires 25 May 2025 [Page 11]
Internet-Draft Digital Emblem Models November 2024
to, for instance, PDFs of treaty documents, SHOULD contain the
language label indicating the language of text included within the
PDF document.
* The framework of descriptive elements SHOULD NOT be so
prescriptive as to preclude the communication of arbitrary
structured data in formats understood in common by digital emblem
issuers and verifiers, but unanticipated by the digital emblem
protocol or its authors.
* It MUST be possible to specify a temporal scope of validity for a
Digital Emblem, composed of one or more temporal periods of
validity.
* It MUST be possible to define temporal scopes and periods of
validity which are independent of other time periods inherited
from other parts of the protocol stack, such as the TTLs or the
validity periods of digital signatures used to authenticate the
digital emblem.
* Each temporal period of validity MUST be of non-negative length;
that is, for each one, its end time may not precede its start
time.
* Temporal periods of validity MAY be overlapping, and the areas of
overlap shall be treated as positive, not negative.
* It MUST be possible to specify a spatial scope of validity for a
Digital Emblem, composed of one or more volumetric regions of
validity.
* Volumetric regions of validity MAY be overlapping, and the areas
of overlap shall be treated as positive, not negative.
* Volumetric regions of validity MUST be convex and not sufficiently
complex or unconventional as to startle improvident interpretation
code. Principle of least astonishment applies.
* For reasons of compatibility with other systems, it MUST be
possible to denote volumetric regions of validity as either or
both of a lat/lon/alt/rad or by locating the vertices of a
geometric solid. Both systems MAY be used within the same digital
emblem, and geometric solids are presumed to have precedence over
lat/lon/alt/rad spheres.
* It MUST be possible to associate one or more temporal scopes of
validity with one or more spatial scopes of validity.
Woodcock, et al. Expires 25 May 2025 [Page 12]
Internet-Draft Digital Emblem Models November 2024
* It MUST be possible to describe multiple separate and independent
sets of temporal/spatial validities within the same digital
emblem.
* When a marked asset is identified as a numbered member of an
enumerated set, it SHOULD be possible to convey its individual
number as well as the size of the set. i.e. “crate 2 of 5.”
* It MUST be possible to denote a quantity, currency, weight or
measure using customs-recognized standards, in the format of a
paired numerical quantity and named unit, followed by an optional
numerical precision in the same units. The unit MAY consist of an
ISO 4217 currency code, an SI base unit of length or mass ("m" or
"kg"), a WCO unit of quantity (m2, m3, l, kWh, u), or one of the
following: persons, pouches, vehicles, aircraft, watercraft,
spacecraft, ANY. The quantity and precision (each of which MAY be
of value 0) MAY possess an optional floating decimal place.
Precision should be understood to be +/- the previous value. In
conjunction with a Digital Emblem, this could be used, depending
on context, to connote a number of vehicles traveling together in
convoy, a number of persons in a delegation, a number of
diplomatic pouches in a shipment, a quantity or valuation of goods
being proffered to customs, an area under protection,
etc. Multiple QTY RRs MAY be associated with the same DNS label,
but have no defined precedence or order.
* It MUST be possible to denote a period of validity, by specifying
a duration OR a start AND end date OR date and time OR the word
ANY. The format of dates, times, and durations must be consistent
with [RFC3339]. When start and end date and times are used, start
is first, and end is second. A duration MUST stand alone and may
not be paired with a date. A date represents the point in time
immediately preceding and including the named date, but subsequent
to and not including the previous period of the same resolution.
* It MUST be possible to define the FORM of the instance of the
emblem. Is it a physical plaque, a nametag, an RFID transponder,
a painted QRcode, a file on digital storage, a badge attached to a
shipping crate, text embroidered onto a garment? Ideally this
SHOULD be a reference to a common registry.
* It MUST be possible to indicate the TYPE of asset to which the
digital emblem is bound. Is it a building, a diplomatic courier, a
web site, and email server, files on a flash thumb drive, the
contents of a shipping crate? Ideally this SHOULD be a reference
to a common registry.
Woodcock, et al. Expires 25 May 2025 [Page 13]
Internet-Draft Digital Emblem Models November 2024
* It MUST be possible to NAME the asset to which the digital emblem
is bound using a proper noun name of the thing, if it has one,
such as "Richard Smith" or "Amiens Cathedral”. Names SHOULD be
rendered in their native script, and common transliterations MAY
also be provided, identified by language tag and script [BCP47].
* It MUST be possible to state the unique SERIAL number of the thing
being protected, if it has one.
* It MUST be possible to provide a textual DESCRIPTION of
identifying characteristics: "A painting of a standing woman in
Elizabethan dress, 92cm wide by 188 cm high, in a gold-leaf wooden
frame."
* It MUST be possible to provide a textual DESCRIPTION of uniquely
identifying characteristics: "Initials 'RH' scratched into lower
right corner" "Two brown birthmarks of 4mm and 3mm above left
eyebrow"
* It SHOULD be possible to indicate in a simple flag if the digital
emblem is problematically no longer known to be physically
proximate to the asset it marks (i.e. they may have become
separated from each other).
* It SHOULD be possible to indicate in a simple flag if a physical
embodiment of the digital embem is problematically no longer in a
known location (i.e. it has been stolen / lost / separated from
its asset).
* It SHOULD be possible to indicate in a simple flag if the asset is
problematically no longer in a known location (i.e. it has been
stolen / kidnapped / lost).
* It SHOULD be possible to indicate in a simple flag if the asset
has had its legal protections violated. (For instance, a
diplomatic pouch has been opened by unauthorized parties.) In a
more elaborate form, this could include time and position, if
known, and other details about the violation.
* It SHOULD be possible to indicate if the issuer requests that
informational updates regarding the progress or status of the
asset be sent to the specified contact.
* It SHOULD be possible to indicate the preferred treatment of an
asset which is outside its spatial or temporal window of
certificate validity. (For instance, a diplomatic envoy whose
remit is for Argentina from January 1, 2025 through December 31,
2026, but whose digital emblem is scanned in Brazil: should they
Woodcock, et al. Expires 25 May 2025 [Page 14]
Internet-Draft Digital Emblem Models November 2024
receive any special status? For instance, a shipment of medical
aid which arrives at a customs checkpoint a year late: should it
be returned to sender, forwarded onward to its destination,
confiscated, destroyed, donated to a good cause?)
* It SHOULD be possible for properly-authenticated mobile assets, or
the physical instantiations of digital emblems affixed to them, to
update the location record associated with the digital emblem
instance or the asset or both, in real-time or near-real-time,
provided a sufficient communications channel back to the issuer
exists.
5.6. Distribution Mechanisms
* Issuers / servers SHOULD attempt to deliver all records associated
with a single digital emblem as a bundle or blob or single
transaction, rather than requiring validators to make multiple
queries or guess what records to ask for within a node of the
namespace hierarchy.
* Issuers / servers MAY wish to include the chain of parent
signatures up to the unitary root of trust, within the digital
emblem record blob, so as to facilitate offline validation by
validators which have only the root signature cached.
* It SHOULD be possible for issuers to push new and updated digital
emblems to relevant verifiers or trusted intermediary caches, when
appropriate, with cryptographic authentication of both parties and
encrypted transport between them.
6. IANA Considerations
This document makes no requests of the IANA.
7. Security Considerations
TBD.
8. Contributors
Moez Chakchouk arranged and conducted many of the use-case interviews
with intergovernmental treaty organizations responsible for bodies of
international law.
9. Acknowledgments
10. Normative References
Woodcock, et al. Expires 25 May 2025 [Page 15]
Internet-Draft Digital Emblem Models November 2024
[BCP47] Best Current Practice 47,
<https://www.rfc-editor.org/info/bcp47>.
At the time of writing, this BCP comprises the following:
Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
2006, <https://www.rfc-editor.org/info/rfc4647>.
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/info/rfc5646>.
[I-D.haberman-digital-emblem-ps]
Haberman, B., Jensen, T., and B. Woodcock, "Problem
Statement for Digitized Emblems", Work in Progress,
Internet-Draft, draft-haberman-digital-emblem-ps-03, 18
November 2024, <https://datatracker.ietf.org/doc/html/
draft-haberman-digital-emblem-ps-03>.
[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>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[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>.
Authors' Addresses
Bill Woodcock
PCH
Email: woody@pch.net
Brian Haberman
JHU/APL
Email: brian@innovationslab.net
Casey Deccio
Brigham Young University
Email: casey@byu.edu
Woodcock, et al. Expires 25 May 2025 [Page 16]