suggested certification test for post quantum preparation - unparseable keys in server jwks

[jogu]

The certification team would appreciate feedback on a suggested new test - in thinking about the rollout of post quantum algorithms, it seems like we should ensure that clients cope okay with a server jwks that contains a key they can't parse. This would mean servers could start listing post quantum keys (in addition to the current keys) in their jwks knowing the clients would not stop working.

Not sure how to do this test in practice - having an unparseable key in the server jwks_uri all the time seems most reliable so is I think my recommendation - having a specific test that adds a key to the jwks just for that test could work unreliably if the client is caching the jwks and/or openid-configuration contents.

The slightly annoying this is that this is only a 'should' in the spec as far as I can see, https://www.rfc-editor.org/rfc/rfc7517#section-5 :

Implementations SHOULD ignore JWKs within a JWK Set that use "kty" (key type) values that are not understood by them, that are missing required members, or for which values are out of the supported ranges.

There's not really any practical way we can make this only a 'warning' in the test suite (we can't see that the client is aborting because it found an unsupported key) so in practice we would be treating it as a 'must'.

[jogu]

To be very clear - I propose adding two invalid entries to the server jwks that the tests expose:

  {
    "kty": "AKP",
    "alg": "ML-DSA-9999",
    "kid": "unusable-pq-sig-key",
    "use": "sig",
    "pub": "Z0FOY29uZm9ybWFuY2UtdGVzdC1wbGFjZWhvbGRlci1wdWJsaWMta2V5"
  }
  {
    "kty": "OIDF-CONFORMANCE-UNSUPPORTED",
    "alg": "OIDF-CONFORMANCE-UNSUPPORTED",
    "kid": "unusable-unknown-sig-key",
    "use": "sig"
  }

with the expectation the client would ignore both of these and validate the RS256 id_token against the RSA key.

[RalphBragg]

+1, and worth flagging that this is not a theoretical edge case. We (Raidiam) have measured how JOSE/JWKS libraries behave when a published JWK Set contains a key type they do not recognise, across a broad range of libraries and languages, and a large share fail the entire set rather than ignoring the unknown key as RFC 7517 §5 recommends. We have also seen it cause a real, externally triggered production outage in a federated deployment: one party introduced a new key type and downstream relying parties on non-tolerant libraries stopped verifying every signature, including the existing classical ones, until it was diagnosed and rolled back. So the incompatibility is widespread and the impact is major, and the RFC's SHOULD is clearly not enough on its own. Making this a certification requirement is exactly the right lever. Happy to contribute a reproduction harness and our findings if useful.

[jogu]

Filip pointed out that the DCR tests should also try including a similar key in the client's jwks_uri

We should also cover unknown alg values I think.