]>

linkerfelix@gmail.com

Applications and Real-Time Digital Emblems The ADEM Core Specification specifies the message format and authorization model for digital, distinctive emblems. This document specifies how such emblems can be used to mark domain names and how they can be conveyed over the DNS. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Digital Emblems Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction specifies the message format and authorization model of digital emblems recognized under International Humanitarian Law (IHL); in particular, it specifies the use of CBOR Web Tokens (CWTs) and COSE_Key structures for digital, distinctive emblems. This draft specifies how such emblems can mark fully qualified domain names (FQDNs) using the DNS and the new IHLE DNS resource record (RR) type.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. DNS terminology and message fields are used as defined in .

The IHLE Resource Record The IHLE (International Humanitarian Law Emblem) DNS RR type is used to mark an FQDN with a digital, distinctive emblem . The type value for the IHLE RR is TODO.

IHLE RDATA Wire Format The RDATA for an IHLE RR consists of a single variable-length Token field. The Token field MUST contain a CWT that either encodes an ADEM token or a COSE_Key structure containing ADEM-related public key material as specified in . The field consumes all octets indicated by RDLENGTH. It MUST contain exactly one complete CBOR data item and MUST NOT contain trailing data. When an IHLE RR contains an emblem, the emblem's assets claim MUST be an array (major type 4) of UTF-8 strings (major type 3). Each string in this array MUST be an FQDN . Relative names, i.e., without a terminating empty label, are permitted and MUST be interpreted relative to the empty root label.

IHLE RDATA Presentation Format The presentation format of the RDATA portion MUST represent the Token field as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text.

Additional Section Processing When a name server receives a query whose QNAME is the owner name of an IHLE RRset in the QCLASS, it MUST include that RRset in the Additional section of the response, unless the RRset is already included in the Answer section. This requirement applies regardless of the query's QTYPE. The server MUST NOT include only a subset of the IHLE RRset. If the transport's size limit prevents the complete RRset from being included, the server MUST set the TC bit; the complete response returned following retry over a transport that permits a larger response MUST include the entire RRset.

DNSSEC Considerations ADEM tokens already are signed objects. Thus, signing IHLE RRsets using DNSSEC is optional. An IHLE RRset may be signed with DNSSEC, for example, because it is part of a signed zone. Successful DNSSEC validation of the RRset, though, MUST NOT be treated as successful validation of any ADEM token it contains or as establishing trust in public key material for ADEM validation.

Discovering and Validating IHLE Emblems For distribution over the DNS, assets are identified by FQDNs. To retrieve an asset's digital emblems, validators can perform a general DNS lookup, as specified in , with the asset's FQDN as QNAME, an arbitrary QTYPE, and the QCLASS IN. When validators receive a set of tokens and public keys over the DNS, they validate it as follows:

1. Validate the set of tokens and public keys according to .
2. If the validation procedure returns a result other than INVALID, verify that the queried FQDN occurs in the emblem's assets claim value using simple, case-insensitive string comparison.

Semantics of IHLE Emblems A valid emblem that marks an FQDN signals that this domain name and services associated with this domain name are used for purposes protected under IHL. It signals that the domain name and services associated with that domain name should be respected, protected, and not disrupted. Intuitively speaking, the emblem has the function of a stop sign and signals that one should not use a domain name as part of an operation to disrupt services. The emblem does not signal that systems which are identified by the domain name, e.g., via A or AAAA records, enjoy the same specific protections as the domain name itself. For example, it could be that a domain name has an A record which contains an IP address that routes to a multi-tenant database server, and tenants are identified by the domain name. That database server requires queries to include the domain of the tenant and, by itself, may not be protected. Nevertheless, if one were to only discover this database server via a domain name that is marked with an emblem, there should be no reason to disrupt that database server.

Security Considerations TODO

IANA Considerations TODO

Normative References In times of armed conflict, the protective emblems of the red cross, red crescent, and red crystal are used to mark physical assets. This enables military units to identify assets as respected and protected under international humanitarian law. This draft specifies the format and trust architecture of a protective, digital emblem to network-connected infrastructure. Such emblems mark assets as protected under IHL analogously to the physical emblems. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.

Acknowledgments TODO acknowledge.