Validation Rules (section 8.3)

[Denisthemalice]

In section 8.3 (Validation Rules), the text states:

8.3. Validation Rules

The text states:

If the validation was successful, the Relying Party MUST
perform the following validation steps to evaluate the status of the
reference token:

(...)

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 and section 7.2 of
      [RFC8392] for CWTs

Section 7.2 from RFC 7519 does not say which key SHALL be used to verify the signature of the Status List Token. Section 8.3 from this document is also silent. In order to be able to interoperate, additional information needs to be added into the document.

The simplest (and the less secure approach) is to use the same private key to sign Referenced Tokens and Status List Tokens. This corresponds to the case where the Status issuer is the Issuer.

A more secure approach is to use of different private keys to sign Referenced Tokens and Status List Tokens. This corresponds to the case where the Status issuer is an entity that has been authorized by the Issuer to issue Status List Tokens. This approach should be RECOMMENDED.

In RFC 5280, a CRL issuer can be nominated by a CA by the issuance of a PKC that contains the cRLSign bit set in the key usage extension (Section 4.2.1.3 from RFC 5280). Since the role of a CRL issuer and of a Status issuer are different, the same bit cannot be used.

In the key usage extension of a PKC, it becomes necessary to define an additional bit that can apply to a Status issuer nominated by an Issuer and to register that additional bit at IANA.

At the moment, in RFC 5280, the following Object Identifier is defined:
{joint-iso-itu-t(2) ds(5) certificateExtension(29) keyUsage(15)}
OID dot notation: 2.5.29.15

      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
      KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

The next usable bit is (9).

The following line should be happened to this list:

sLTSign (9)

{joint-iso-itu-t(2) ds(5) certificateExtension(29) keyUsage(15) sLTSign(9)}

OID dot notation: 2.5.29.15.9

With the following explanation:

The sLTSign bit is asserted when the subject public key can be used for verifying signatures on Status List Tokens.

A specific section dedicated to this extension should be added so that it can be referenced in the IANA registration template.

After these explanations, we can now come back to a text change proposal for section 8.3 (Validation Rules).

Text change proposal for section 8.3.

8.3. Validation Rules

The text states:

If the validation was successful, the Relying Party MUST
perform the following validation steps to evaluate the status of the
reference token:

(...)

3. Identify the public key to be used to verify the signature
   of Status List Token

If no iss claim, nor an x5c claim, is present in the Status List Token and unless a specific local rule applies, the Relying Party MUST verify the Status List Token using the same key that has been used to verify the Referenced Token. This approach is NOT RECOMMENDED.

If the iss claim is present in the JOSE Header, the JWT Claims, or the COSE Header, a Relying Party can use this parameter to obtain a JSON Web Key to use in the verification process. It should be noticed that, according to RFC 7519, the processing of this claim is generally application specific. Unless the processing of this claim is made in a specific environment or context, this approach is not interoperable.

If the "x5c" claim is present in the JWT Claims, a Relying Party SHOULD use this parameter to obtain a JSON Web Key to use in the verification process. The "x5c" claim is an array of strings that contains an x.509 certificate chain, in order from the root certificate authority to the signing certificate.

The last certificate of the chain can be either the certificate of the Issuer or of the Status Issuer. In the later case, the key usage extension (defined in section 4.2.1.3 from RFC 5280) MUST be present and MUST contain an additional bit defined in section 9 of this document.

Once it has been verified that the whole chain is valid and that no certificate of the chain has been revoked, the public key from the last certificate of the chain MUST be used to validate the Status List Token. This approach is RECOMMENDED.

2. Validate the Status List Token by following the rules defined in section 7.2 of [RFC7519] for JWTs and section 7.2 of [RFC8392] for CWTs

3. Check for the existence of the required claims as defined in Section 5.1 and Section 5.2 depending on token type

A text proposal for defining the sLTSign bit is provided in a subsequent issue.

[paulbastian]

Section 7.2 of RFC7519 refers to RFC7515 (JWS), which gives some possbilities to encode the public key, e.g. "x5c" or "jwk"

[Denisthemalice]

This is not the point.

RFC 5280 provides all the information that is necessary to allow interoperability
when CRLs are being used and when the Issuer is different from the CRL issuer.

I would like this document to include all the information that is necessary to allow interoperability
when TSLs are being used and when the Issuer is different from the Status issuer.

[paulbastian]

Is there any difference in this issue to #235 ?