Which keys should be used to sign and verify Status List Tokens ?

[Denisthemalice]

In section 5 (Status List Token) the text states:

A Status List Token embeds the Status List into a token that is cryptographically signed and protects the integrity of the Status List.

This sentence does not state which key should be used to sign or to verity the Status List Token.

Using JOSE, the "iss" (issuer) claim identifies the principal that issued the JWT. The iss" claim is not present in the list of claims from section 5.1 (Status List Token in JWT Format).

Section 8.3 which is about "Validation Rules" states:

3. Validate the Status List Token:

   1. Validate the Status List Token by following the rules defined
      in section 7.2 of [RFC7519] for JWTs

However, in section 7.2 from RFC 7519, the single "occurrence of "iss" is in the following sentence:

Some applications may include case-insensitive information in a case-sensitive value, such as including a DNS name as part of the "iss" (issuer) claim value.

The text does not say that the content of "iss" claim shall be used and does not specific against which value it shall match.

Let us make a parallel with OCSP, section 4.2.2.2 from RFC 6960 which states:

4.2.2.2. Authorized Responders
The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary, however, to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following:

• sign the OCSP responses itself, or
• explicitly designate this authority to another entity

There is no similar text in the draft. It is thus assumed that the signer of the Status List Tokens are the Issuers and not the List Issuers.

From a security point of view, using two different entities is better because the key used by the Issuer to issue Referenced Tokens does not need to be communicated or exposed to the Status Issuer. If the Status Issuer sends to the Issuer hash values to be signed by the Issuer, the risk would be that the hash value to be signed does not correspond to a Status List Token but to Referenced Token.

RFC 2560 has been replaced by RFC 6960 precisely to solve the issue of using the same key for two different purposes.

If the keys are different, this indeed complexiflies the PKI, but this path has already be opened when drafting OCSP in particular by defining id-kp-OCSPSigning in an extended key usage certificate extension.

If the List Issuer would use its own key to sign, then it makes sense to consider it as an entity which is different from the Issuer, otherwise it doesn't.

There would be other consequences to consider like 4.2.2.2.1. Revocation Checking of an Authorized Responder.
What about an extended key usage certificate extension that would be called id-kp-TSLSigning ?

[c2bo]

The rationale currently states that "the specification shall not specify key resolution or trust frameworks".

There are many different mechanisms that the different ecosystems use to verify tokens. We expect this to be defined in the environment that uses the status list (and likely re-use existing mechanisms). Some options we have seen are:

• x5c claim embedded in the token
• iss claim is a url and keys are served via .well-known
• trust lists
• same key as referenced token

We could be more explicit in that regard in the implementation considerations?

[Denisthemalice]

You wrote:

The rationale currently states that "the specification shall not specify key resolution or trust frameworks".

It is as if you were writing:

"the specification does not specify how two implemenations can interoperate."

:-)

As currently described, the Status List Token cannot be verified.

To draw a parallel with OCSP, in RFC 6960, the roles of the CA and of the OCSP Responder are crystal clear.
In this draft, the respective roles of the Issuer and of the Status Issuer are unclear.

When the List Issuer is different from the Issuer, what kind of information should be exchanged between these two entities ?

You wrote:

We could be more explicit in that regard in the implementation considerations?

• Clarify the respective roles of the Issuer and of the Status Issuer when they are different entities.

• Permit the use of different private keys to sign Referenced Tokens and Status List Tokens.

• Explain how the Relying Party can find out which public key it shall use to verify a Status List Token.
  The following cases should be considered:

     1.  same key as Referenced Token
     2.  iss claim in the Status List Token
     3.  x5c claim embedded in the Status List Token