ADEM Core Specification

3.1. Identifiers and their Semantics

Emblems are issued for assets by emblem issuers, which in turn are authorized by authorities. Both emblem issuers and authorities are organizations. This section specifies how assets and organizations are identified.¶

asset-identifier = domain-name | "[" IPv6 "]"

organization-identifier = "https://" domain-name

3.2. Token Encoding

Tokens MUST be encoded as a JWS [RFC7515] or as an unsecured JWT as defined in [RFC7519], Section 6, encoded either in compact serialization or as signed CBOR Web Token (CWT) [RFC8392]. Tokens encoded as JWS MUST only use JWS protected headers and MUST include the jwk header parameter. Any token MUST include the cty (content type) header parameter.¶

  purpose = "protective" | "indicative"

  distribution-method = "dns" | "icmp" | "udp"

{
  "alg": "ES512",
  "jwk": { ... },
  "cty": "adem-emb"
}

{
  "emb": {
    "dst": ["icmp"],
    "prp": ["protective"]
  },
  "iat": 1672916137,
  "nbf": 1672916137,
  "exp": 1675590932,
  "iss": "https://example.com",
  "assets": ["[2001:0db8:582:ae33::29]"]
}

5.1. Verification

Whenever a validator receives an emblem, they MAY check if it is valid. The validity of an emblem is defined with respect to a public key. A validity checking algorithm MUST returns the following values. The order of these values encodes the strength of the verification result.¶

1. UNSIGNED¶

2. INVALID¶

3. SIGNED-UNTRUSTED¶

4. SIGNED-TRUSTED¶

5. ORGANIZATIONAL-UNTRUSTED¶

6. ORGANIZATIONAL-TRUSTED¶

7. ENDORSED-UNTRUSTED¶

8. ENDORSED-TRUSTED¶

Given an input public key and an emblem with a set of endorsements, a verification algorithm takes the following steps:¶

1. If the emblem does not bear a signature, return UNSIGNED.¶

2. Run the signed emblem verification procedure (Section 6.2; results in one of SIGNED-TRUSTED, SIGNED-UNTRUSTED, or INVALID).¶

3. If previous procedure resulted in INVALID or the emblem does not include the iss claim, return the last verification procedure's result and the emtpy set of OIs.¶

4. Run the organizational emblem verification procedure (Section 6.3; results in one of ORGANIZATIONAL-TRUSTED, ORGANIZATIONAL-UNTRUSTED, INVALID).¶

5. If the previous procedure resulted in INVALID return INVALID and the empty set of OIs.¶

6. If all tokens include the same iss claim, return the strongest return value matching *-TRUSTED, the strongest return value matching *-UNTRUSTED provided that it is strictly stronger than the strongest return value matching *-TRUSTED, and the empty set of OIs.¶

7. Run the endorsed emblem verification procedure (Section 6.4; results in a set of OIs and one of ENDORSED-TRUSTED, ENDORSED-UNTRUSTED, INVALID).¶

8. If the previous procedure resulted in INVALID return INVALID and the empty set of OIs.¶

9. Return the strongest return value matching *-TRUSTED, the strongest return value matching *-UNTRUSTED provided that it is strictly stronger than the strongest return value matching *-TRUSTED, and the set of OIs returned by the endorsed emblem verification procedure.¶

Note that the endorsed emblem verification procedure resulting in INVALID is handled implicitly in step 8. As the procedure did not terminate in step 5, organizational verification must have been successful. Hence, INVALID cannot be the strongest return value, and an emblem not being accompanied by valid endorsements are downgraded to organizational emblems.¶

The set of OIs returned by the verification procedure encodes the OIs of endorsing parties where verification passed.¶

5.2. Protection

An emblem for which the verification procedure produces a result other than INVALID marks any asset whose address is identified by at least one of the emblem's AIs. Such an emblem signals that the respective asset is enjoys the specific protections of IHL.¶

Emblem issuers MUST only issue emblems for assets that are used only for protected purposes.¶

6.1. JWK Hashing

Context:¶

• Input: A JWK public key as per [RFC7517] in arbitrary encoding.¶

• Output: A hash of the JWK¶

Algorithm:¶

1. Parse the JWK as JSON object.¶

2. Drop the kid parameter from the JWK.¶

3. Compute the key's thumbprint using SHA-256 as per [RFC7638].¶

4. Return the digest in base32 encoding as per [RFC4648] in all lower-case and with trailing = removed.¶

6.2. Signed Emblem Verification Procedure

Context:¶

• Input: An emblem, a set of endorsements, and a trusted public key.¶

• Output: SIGNED-TRUSTED, SIGNED-UNTRUSTED, or INVALID.¶

Algorithm:¶

1. Ignore all endorsements including an iss claim different to the emblem's iss claim. A defined iss claim is understood to be different to an undefined iss claim.¶

2. Verify every signature.¶

3. Verify that all endorsements form a consecutive chain where there is a unique root endorsement and the public key which verifies the emblem is transitively endorsed by that root endorsement.¶

4. Verify that no endorsement expired.¶

5. Verify that all endorsements bear the claim end=true except for the emblem signing key's endorsement.¶

6. Verify that the emblem is valid with regard to every endorsement.¶

7. If any of the aforementioned verification steps fail, return INVALID. If there is a token signed by the trusted input public key, return SIGNED-TRUSTED. Otherwise, return SIGNED-UNTRUSTED.¶

Distribution methods MAY indicate an order of tokens to guide clients assembling the chain of endorsements in step 3. Whenever such an order is specified, clients MAY immediately reject a set of tokens as invalid if the indicated order does not yield a valid chain of endorsements.¶

6.3. Organizational Emblem Verification Procedure

Context:¶

• Assumptions: Signed emblem verification has been performed and did not return INVALID. Every token as part of the input includes the iss claim.¶

• Input: An emblem, a set of endorsements, and a trusted public key.¶

• Output: ORGANIZATIONAL-TRUSTED, ORGANIZATIONAL-UNTRUSTED, or INVALID.¶

Algorithm:¶

1. Ignore all endorsements including an iss claim different to the emblem's iss claim.¶

2. Verify that the top-most endorsement's iss claim value (its OI) is configured correctly as specified in Section 4.¶

3. If the aforementioned verification step fails, return INVALID. If the top-most endorsing key is equal to the trusted input public key, return ORGANIZATIONAL-TRUSTED. Otherwise, return ORGANIZATIONAL-UNTRUSTED.¶

6.4. Endorsed Emblem Verification Procedure

Context:¶

• Assumptions: Organizational emblem verification has been performed and did not return INVALID. There are emblems as part of the input including an iss claim different to the emblem's iss claim.¶

• Input: An emblem, a set of endorsements, and a trusted public key.¶

• Output: ENDORSED-TRUSTED, ENDORSED-UNTRUSTED, or INVALID, and a set of OIs.¶

Algorithm:¶

1. Ignore all endorsements including an iss claim equal to the emblem's iss claim.¶

2. For every endorsement:¶

   1. Verify its signature.¶

   2. Verify that it endorses the top-most endorsing key with the same iss claim as the emblem.¶

   3. Verify that it did not expire.¶

   4. Verify that it bears the claim end=true.¶

   5. Verify that the emblem is valid with regard to this endorsement.¶

   6. Implementations SHOULD verify that the endorsement's iss claim value (its OI) is configured correctly as specified in Section 4.¶

   7. Should any of the aforementioned verification steps fail, ignore this endorsement.¶

3. If there are no endorsements remaining after the last step, return INVALID and the empty set of OIs. If in the set of remaining endorsements, there is an endorsement with a verification key equal to the trusted input public key, return ENDORSED-TRUSTED. Otherwise, return ENDORSED-UNTRUSTED. In both the latter cases, also return the set of all iss claims of the remaining endorsements.¶

7.1. No Endorsements without iss

The procedures to verify organizational or endorsed emblems as specified in Section 6.3 and Section 6.4 assume that the emblem's iss claim is defined. Practically speaking, this implies that parties 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 offers two beneficial security properties:¶

• Parties cannot equivocate their keys, i.e., they need to commit to a consistent set of keys.¶

• Parties cannot deny having used certain root public keys.¶

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

7.2. Token Order

As specified in Section 6.2, clients MAY reject sets of tokens as invalid if the order of tokens as indicated by the sending client does not yield a valid chain of endorsements. This allows an adversary to force rejection of a set of tokens by altering, e.g., sequence numbers on non-integrity protected channels such as UDP.¶

However, this does not constitute a new attack. Such adversaries could flip a bit in the emblem's signature, rendering the set of tokens invalid, too.¶

7.3. Key Identifiers

Key identifiers were designed such that they commit to the identified key, i.e., key identifiers must provide strong collision-resistance. This is ensured by computing it using SHA-256.¶