An Authentic Digital, Distinctive EMblem (ADEM) - Message Format and Authorization Model

Introduction International Humanitarian Law (IHL) awards specific protections to certain assets, in particular, medical facilities. These protections require that assets must be respected and protected, and that assets must not be disrupted. The distinctive emblems recognized under IHL, for example, the Red Cross, can signal an asset's status under IHL. But naturally, these emblems are visual and are thus limited to assets with which one interacts primarily physically, e.g., buildings. There is currently no way to signal over the network layer that a network-connected asset enjoys specific protections, which can be a channel of disruption, however. This draft addresses the above problem and specifies a message format and authorization model for the distinctive emblems so that they can be conveyed over the network layer. Other drafts will specify how these messages will be sent and how assets will be identified as enjoying specific protections under IHL.

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.

Asset: An asset is a network-connected service that enjoys the specific protections under IHL.
Emblem: An emblem is a message which signals that an asset enjoys specific protections under IHL.
Emblem issuer: An emblem issuer is an organization that issues emblems.
Authority: An authority is an organization that authorizes other organizations as being eligible to issue emblems.
Endorsement: An endorsement associates a public key with an identity, and hence, resembles the idea of a certificate. When signed by an authority, it asserts that the authorized issuer can generally issue claims of protection.
Token: An emblem or an endorsement.
Organization: An emblem issuer or authority.
Validator: A validator is someone who discovers and validates digital emblems.

Beyond these terms, we use the terms "claim", "claim key", "claim value", and "CWT Claims Set" as defined in , and "header parameter" as defined in .

Overview This document specifies the digital message format and authorization model for an authentic digital, distinctive emblem recognized under IHL. Emblems signal that one or more assets enjoy specific protections under IHL, and endorsements encode that one organization authorizes another to issue emblems. Both emblems and endorsements are called tokens and encoded as signed CBOR Web Tokens (CWTs) . Emblems are signed by emblem issuers and endorsements are signed by emblem issuers and authorities. Emblem issuers and authorities are identified by a domain name. Endorsements allow for authenticating public key material for verifying token signatures. Endorsements can be validated in two ways. First, a validator may already know an authentic public key for the issuer, e.g., from another endorsement. In this case, they can validate the endorsement's signature straightforwardly. Second, endorsements can be configured as trust anchors (see ). Trust anchor endorsements allow a validator to authenticate an endorsement's verification key out-of-band, using Certificate Transparency (CT) logs . Furthermore, trust anchor endorsements allow a validator to verify that an endorsement's issuer controls the domain name identifying them. In the following, we describe (i) how to encode public key material for the use in ADEM as COSE_Keys (), (ii) the format of tokens (), and (iii) how emblems and associated endorsements are validated (). This draft does not specify how tokens are presented, and how they identify which asset enjoys specific protections under IHL. Different types of assets, e.g., a patient database and a network-connected medical device, use different network channels and digital emblems should both be conveyed over the respective channels and use identifiers for the marked assets that match these channels.

Requirements ADEM was designed to provide the following requirements. We highlight three requirements in particular that informed the writing of this draft.

Digital emblems should be usable for a wide range of network-connected services. We thus encode emblems in binary, as CWTs, so that they can - in principle - be integrated into many existing, different protocols.
The use of the distinctive emblems requires authorization by a competent authority, typically a state. States are the ultimate authority under IHL and must be able to operate independently of one another. Authorities thus require no further authentication, integration into root trust stores, or anything similar. Instead, we require that authorities commit to their public key material so that they can be held accountable when issuing fraudulent endorsements (see and ).
As explained in , the validation of digital, distinctive emblems should be undetectable. While this draft alone cannot provide undetectable validation, we ensure that undetectable validation is not precluded. In particular, we designed the emblem message format and authorization so that an emblem and associated endorsements can be validated mostly without follow-up queries (see also ).

Organization Identifiers Emblems are issued for assets by emblem issuers, which in turn are authorized by authorities. Emblem issuers and authorities are identified by Uniform Resource Identifiers (URIs) of the following form, which we call organization identifiers (OIs). The scheme MUST be https. The authority component MUST contain a fully qualified domain name (FQDN), which MUST be represented in all lower-case. The path, query, and fragment components MUST be empty, and the URI MUST NOT end with a trailing slash. Concretely, an OI has the syntax:

Public Key Material Public keys are encoded as COSE_Key structures . We identify keys using key identifiers, which are 32-byte SHA-256 COSE Key Thumbprints, computed as specified in . To force computation and thus verification of key identifiers, COSE_Key structures SHOULD NOT contain the kid parameter (label 2). Implementations that encode key material MUST NOT include the kid parameter, but implementations consuming key material SHOULD accept and ignore the kid parameter. Key identifiers are encoded as CBOR byte strings when used within CBOR objects. When a textual representation is required, key identifiers are encoded using base32 as specified in , in lowercase and without trailing = characters.

Public Key Commitment Organizations can bind some of their public keys to their OI, and we specify a public key commitment mechanism in this section to achieve that. For a public key to be bound to an OI, there MUST be an X.509 certificate that:

MUST NOT be revoked
MUST be logged in the Certificate Transparency logs
- Note that log inclusion requires a valid certificate chain that leads to one of the log's accepted root certificates. Clients are RECOMMENDED to verify that this chain is valid and that none of the certificates along it have been revoked.
MUST be valid for at least all the following domains while not considering wildcards in the certificate subject (<OI> is understood to be a placeholder for the domain name in the organization's OI):
- <OI>
- For the textual representation <KID> of the bound public key's key identifier, as specified in : <KID>.adem-configuration.<OI>

We intentionally do not specify how clients should check a certificate's revocation status. It is RECOMMENDED that clients use offline revocation checks that are provided by major browser vendors, for example, OneCRL or CRLite by Mozilla, or CRLSet by Chrome.

Tokens

Token Encoding Tokens MUST be encoded as CWTs secured by a COSE_Sign1 structure , and tokens MUST include the COSE_Sign1 CBOR tag 18. The COSE payload MUST be present and MUST contain the CBOR-encoded CWT Claims Set. External additional authenticated data MUST be the zero-length byte string. The CWT Claims Set MUST be a CBOR map. Registered CWT claims use their integer claim keys from ; claims defined by this document use the text-string claim keys shown below.

Token Types There are two types of tokens: emblems and endorsements. Furthermore, endorsements can be configured as trust anchors for an issuer, which allows their validation without obtaining further authentic public key material. To facilitate validation, tokens MUST include the typ (label 16, see ) header parameter, which MUST be a string media type value following the syntax of adem-type below. The structured suffix +cwt indicates that tokens are encoded as CWTs . The parameter emblem= indicates whether the token is an emblem ("1") or an endorsement ("0"), and the presence of the parameter trust-anchor indicates whether an endorsement is configured as a trust anchor (see ). The parameter trust-anchor is intended to aid parsing and validation of tokens and thus need not be validated itself. It SHOULD only be present if emblem=0.

Common Token Fields Both emblems and endorsements use the following protected header parameters and CWT claims. Implementations generating tokens MUST NOT include header parameters or CWT claims beyond those referenced in this document. The COSE protected header MUST include the alg (label 1), kid (label 4), and typ (label 16, see above) header parameters. The alg value identifies the signature algorithm. The kid value MUST equal the key identifier of the verification key as specified in . The COSE unprotected header MUST be empty.

Claim	Claim key	Status	Semantics	CBOR type
`ver`	`"ver"`	REQUIRED	Version counter	uint, value 1
`iat`	6	OPTIONAL	Issued-at time, as per	NumericDate
`nbf`	5	REQUIRED	Not-before time, as per	NumericDate
`exp`	4	REQUIRED	Expiration time, as per	NumericDate
`iss`	1	RECOMMENDED	Organization issuing the token	tstr containing an OI
`prp`	`"prp"`	REQUIRED	Emblem purposes	uint

The token version counter ver MUST be an unsigned integer in the range 0 to 255, encoded as a CBOR unsigned integer. This document specifies version 1. For an emblem, iss identifies the organization signaling protection; for an endorsement, it identifies the endorsing organization. The prp claim identifies the kind of emblem recognized under IHL as a bitmap and MUST be non-zero. Each bit, as indicated below, corresponds to a particular use of emblems recognized under IHL. Values MAY be combined, using bit-wise OR, to indicate the use of multiple emblems at the same time. Consequently, the value of the prp field MUST be between 1 and 31. The semantics of the prp claim differ between emblems and endorsements and will be specified later.

Value	Explanation
`0b_0000_0001`	Protective use of the red cross, red crescent, or red crystal emblem to signal protection under IHL.
`0b_0000_0010`	Indicative use of the red cross, red crescent, or red crystal emblem to signal an affiliation with the International Red Cross and Red Crescent Movement.
`0b_0000_0100`	Identification of works and installations containing dangerous forces, such as dams, dykes, and nuclear electrical generating stations.
`0b_0000_1000`	Identification of civil defence organizations and their protected personnel and assets.
`0b_0001_0000`	Identification of cultural property protected under IHL.

Emblems An emblem's CWT Claims Set includes the common claims defined in and the additional claim defined in the table below.

Claim	Claim key	Status	Semantics	CBOR type
`assets`	`"assets"`	REQUIRED	Assets marked as protected	array

The assets claim contains asset identifiers. Their syntax, encoding, and matching semantics will be defined in separate drafts that specify discovery and distribution of tokens. The asset identifier in the example below is illustrative. An emblem's prp claim specifies how the asset is marked. For example, when the claim has value 1, it indicates that the asset is marked with the digital equivalent to the emblems of the Red Cross, Red Crescent, and Red Crystal.

Example For example, an emblem might comprise the following protected header and CWT Claims Set, shown in CBOR diagnostic notation. Protected header: Claims Set:

Endorsements Endorsements are encoded as signed CWTs. Endorsements assert two statements: that a public key is affiliated with an organization, identified by an OI, and that this organization is authorized to issue emblems for their assets. An endorsement's CWT Claims Set includes the common claims defined in and the additional claims defined in the table below. Sometimes, endorsements are configured as trust anchors, which means that they can be validated without obtaining authentic public key material of the issuer. Endorsements are trust anchors whenever they include the log claim, and we further specify trust anchor configurations below.

Claim	Claim key	Status	Semantics	CBOR type
`sub`	2	RECOMMENDED	Endorsed organization, identified by their OI	tstr
`cnf`	8	REQUIRED	Confirmation method for the subject's public key ; further specified below	map
`end`	`"end"`	REQUIRED	Endorsed key can endorse further	bool
`log`	`"log"`	see below	Trust anchor configuration	array of maps as below

An endorsement's cnf claim MUST be a CBOR map that contains exactly the confirmation method kid (key 3) corresponding to the presenter's proof-of-possession key . The kid value MUST be a public key thumbprint as per . The endorsement's sub claim identifies the presenter. We say that an endorsement endorses a token if the endorsement's cnf claim contains the key identifier of the token's verification key, and its sub claim equals the token's iss claim. Note that the latter includes the possibility of both sub and iss being undefined. An endorsement's prp claim constrains what kind of emblems the endorsed organization may issue. Each bit set in the prp claim gives the endorsed organization permission to issue the respective emblem. An emblem is thus valid with respect to an endorsement if the bit-wise AND of the endorsement's prp claim and the emblem's prp claim is equal to the emblem's prp claim.

Trust Anchor Configuration Endorsements MAY contain the log claim. If they do, they are trust anchors. Trust anchor endorsements allow a validator to authenticate the endorsement's verification key out-of-band and check that the issuer controls their own OI (see ). This is achieved by binding the endorsement's verification key to the issuer OI with a certificate stored in CT logs. The log claim identifies the CT logs that contain this binding certificate. The value of log is an array of CBOR maps, each of which identifies a CT log entry that stores a certificate committing to the endorsement's verification key as per . This standard supports log entries of both standard CT logs as specified in and tiled CT logs as specified in .

Entry	Map key	Status	Semantics	CBOR type
`id`	`"id"`	REQUIRED	The CT log's ID	bstr
`hash`	`"hash"`	see below	The binding certificate's leaf hash in the log	bstr
`index`	`"index"`	see below	The binding certificate's log entry index in the log	uint

For logs implementing , a map in log MUST include the hash entry and MUST NOT include the index entry. For logs implementing , a map in log MUST include the index entry and MUST NOT include the hash entry.

Validation Whenever a validator receives a set of tokens, they SHOULD validate it. Validation returns one or more of the following values and a set of OIs. The set of OIs returned by the validation procedure encodes the OIs of endorsing organizations for which validation passed.

INVALID
SIGNED
ORGANIZATIONAL
ENDORSED

Given a set of tokens and a set of public keys, validation takes the following steps.

For every public key, compute its key identifier as described in .
For every token, perform the following steps:
1. Verify the token's typ protected header parameter following .
2. Verify the token's signature using the public key whose key identifier computed in the previous step matches the kid header parameter.
3. Verify the token's nbf and exp claims.
4. Should any of the aforementioned validation steps fail, discard this token.
Identify the emblem among the remaining tokens by its typ protected header parameter. Verify that there is only one emblem and that it contains the assets claim. If this check fails, return INVALID. All other tokens are endorsements.
Run the signed emblem validation procedure (; results in one of SIGNED or INVALID).
If the previous procedure resulted in INVALID or the emblem does not include the iss claim, return the last validation procedure's result and the empty set of OIs.
Run the organizational emblem validation procedure (; results in one of ORGANIZATIONAL, INVALID).
If the previous procedure resulted in INVALID, return INVALID and the empty set of OIs.
Run the endorsed emblem validation procedure (; results in a set of OIs and one of ENDORSED, INVALID).
If the endorsed emblem validation procedure resulted in INVALID, return SIGNED, ORGANIZATIONAL and the empty set of OIs. Otherwise, return SIGNED, ORGANIZATIONAL, ENDORSED, and the OIs returned by the endorsed emblem validation procedure.

Algorithms

Signed Emblem Validation Procedure Context:

Assumptions: All input tokens' signatures, and nbf and exp claims were validated.
Input: An emblem and a set of endorsements.
Output: SIGNED or INVALID.

Algorithm:

Consider all endorsements including an iss claim equal to the emblem's iss claim. An omitted iss claim is not equal to an included iss claim but equal to an omitted iss claim.
If there are no such endorsements, return SIGNED. Otherwise, verify that all such endorsements form a consecutive chain where there is a unique root endorsement and the public key which was used to verify the emblem's signature is transitively endorsed by that root endorsement.
Verify that all such endorsements bear the claim end=true except for the endorsement endorsing the emblem's verification key, the end claim of which MAY be false.
Verify that the emblem is valid with regard to every such endorsement.
If any of the aforementioned validation steps fail, return INVALID. Otherwise, return SIGNED.

Organizational Emblem Validation Procedure Context:

Assumptions: All input tokens' signatures, and nbf and exp claims were validated. Signed emblem validation has been performed and did not return INVALID. The emblem includes the iss claim.
Input: An emblem and a set of endorsements.
Output: ORGANIZATIONAL or INVALID.

Algorithm:

Consider all endorsements including an iss claim equal to the emblem's iss claim.
If either (a) there are no such endorsements, or (b) these endorsements do not form a linear chain, or (c) the top-most endorsement of that chain has no log claim, return INVALID.
Verify the top-most endorsement's verification public key by using its iss claim and log claim as specified in . If verification fails, return INVALID. Otherwise, return ORGANIZATIONAL.

Endorsed Emblem Validation Procedure Context:

Assumptions: All input tokens' signatures, and nbf and exp claims were validated. Organizational emblem validation has been performed and did not return INVALID.
Input: An emblem and a set of endorsements.
Output: ENDORSED or INVALID, and a set of OIs.

Algorithm:

For all endorsements that contain an iss claim which is different to the emblem's iss claim:
1. Verify that it endorses the top-most endorsement with the same iss claim as the emblem.
2. Verify that it bears the claim end=true.
3. Verify that the emblem is valid with regard to this endorsement.
4. Verify the endorsement's verification public key by using its iss claim and log claim as specified in .
5. Should any of the aforementioned validation steps fail, discard this endorsement.
If no endorsement passed the checks above, return INVALID and the empty set of OIs. Otherwise, return ENDORSED and the set of all iss claims of endorsements that passed the above checks.

Security Considerations

Interpreting Validation Results Validators SHOULD NOT accept emblems resulting only in SIGNED without authenticating their verification keys out of band. In such cases, validators should aim to authenticate the respective public keys via other, out-of-band methods. Signed emblems are supported for cases of emergency where an emblem issuer is able to distribute one or more public keys, but might not be able to set up a signing infrastructure linking their assets to their OI via a trust anchor endorsement.

Accountability TODO

No Endorsements without iss The procedures to verify organizational or endorsed emblems as specified in and assume that the emblem's iss claim is defined. Practically speaking, this implies that one can only go beyond pure public key authentication (where public keys need to be authenticated out-of-band) by stating an OI. The constraints on well-configured OIs offer two beneficial security properties:

Organizations cannot equivocate their keys, i.e., they need to commit to a consistent set of keys.
Organizations cannot deny having used keys for signing trust anchor endorsements.

These properties stem from organizations needing to include a hash of their key in a TLS certificate, and consequently, in certificate transparency logs.

Undetectable Validation TODO

IANA Considerations TODO