Key publication needs to be reworked (x509_url and jwk_url)

Issue #703 resolved
Brian Campbell created an issue

See for some initial points of confusion and concern.

Based on some subsequent discussion (kinda captured in call notes at and and thinking, I believe there are a number of things that need to be accomplished here:

  • reasonable parity between what can be done with jwk_url and x509_url
  • facilitate a reasonable method of key rollover
  • simultaneous support for multiple algorithms (the OP at least needs this)
  • ability to represent a certificate chain

The current jwk_url covers all of those except for the certificate chain one, which clearly is out of scope for jwk. The x509_url is different for client and OP and really doesn't cover the needed use cases. Thus, I think it makes sense to model the x509 endpoint (loosely) off of how jwk_url works and add the ability to optionally have certification chains.

I'll propose two general ways of doing that.

First would be to define a kid parameter on the x509_url that is the identifier of the key (and corresponds to the kid in the jwk_url). The kid parameter would be required and the endpoint would return the PEM encoded certificate or certificates in the chain associated with the key identifier. A connect x509_url with a kid parameter then effectively becomes an x5u as defined in JWS and JWE. A side benefit (to my eyes anyway) of this is that it converges on the use of kid to identity keys rather than a mix of kid and x5t.

The other approach would be to allow the x509_url to represent multiple certs and certificate chains. The latter means we couldn't rely on the "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" strings to delimit the content (short of defining some rules about figuring it out from issuer and subject, which I think we should avoid). So a JSON encoding is probably the way to go and the endpoint ends up returning some collection of x5c values - maybe named by kid (with the convergence benefit mentioned above) or by x5t. Or just an array of x5c and leave the x5t to key mapping as an exercise for the consuming party. Or something along those lines. FWIW, Google seems to be doing something not to dissimilar to this concept at

That's a pretty abstract description but hopefully sufficient to facilitate some discussion. But I can elaborate and/or work up some examples, if need be.

Comments (13)

  1. Brian Campbell reporter

    On the 21-Jan-13 call John proposed an alternate approach where discovery/registration would include a FQDN or URL base for X509 (which effectually establishes some rooting of trust) and then individual JWx messages would indicate the key via x5u header (some matching of the x5u and the prior established FQDN would be required). A similar approach could be used for JWK using the jku header. But I don't know if he was suggesting taking it that far or just suggesting the approach for certificates.

  2. Brian Campbell reporter

    In thinking about this (esp. with respect to key rolling) in the context of encryption, I'm not sure John's idea or the kid parametrized x509_url are viable approaches. I don't see how the encrypting party could know the url or url paramter to use.

  3. Brian Campbell reporter

    Fixed #703 (in disco and reg) - Added the PKIX JWK key type for X.509 certificates and consolidated the x509_uri, x509_encryption_uri, and jwk_encryption_uri parameters into a combined jwk_uri parameter.

    → <<cset 6d045c41d45e>>

  4. Log in to comment