An Authenticated Digital EMblem - Core Specification

4.1. Identifiers and their Semantics

Emblems are issued for assets by protected parties and are backed by authorities. Both protected parties and authorities are organizations. This section specifies how assets and organizations are identified.¶

asset-identifier = address [ ":" port ]

address = domain-name | "[" IPv6 "]"

port = DIGIT+

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

4.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 or the kid header parameter. Any token MUST include the cty (content type) header parameter.¶

  purpose = "protective" | "indicative"

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

{
  "alg": "ES512",
  "kid": "4WICC9pZ5zh6m3sfNYwwLilHzNazbFoJU6Qe5ds_8pY",
  "cty": "adem-emb"
}

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

6.1. Verification

Whenever a verifier 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 8.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 8.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 8.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.¶

6.2. Protection

Any asset whose address is resolved within context of a valid emblem must be considered to be marked as protected under IHL. In certain contexts, this might apply to a wide range of assets. For example, a router could distribute emblems for its entire address space using ICMP using an IP range.¶

Assets MUST only mark as protected what is exposed to potential verifiers. For example, consider a gateway-router also running an intranet where not every node is internet-connected. The router must only distribute emblems for internet-connected nodes to verifiers not within the intranet, but may distribute emblems for the non-internet connected nodes within the intranet. But at the same time, verifiers must proceed with caution when changing their vantage point. If malware were to infect that router, it must check if assets now exposed to it are protected, too.¶

7.1. No Endorsements without iss

The procedures to verify organizational or endorsed emblems as specified in Section 8.3 and Section 8.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.¶

8.1. JWK Hashing

Context:¶

• Input: A JWK as per [RFC7517] in arbitrary encoding.¶
• Output: A cryptographically secure hash of the JWK¶

Algorithm:¶

1. Parse the JWK as JSON object.¶
2. Drop the kid parameter from the JWK.¶
3. Compute a canonical representation of the remaining JWK as per [RFC8785].¶
4. Compute the SHA-256 hash of the canonical representation¶
5. Return the hash in base32 encoding in all lower-case and with trailing = removed.¶

8.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.¶

8.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 5.¶
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.¶

8.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 5.¶
   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.¶

9.1. Token Order

As specified in Section 8.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.¶