[Openid-specs-ab] [openid/connect] Key publication needs to be reworked (x509_url and jwk_url) (issue #703)

[Brian Campbell]

--- you can reply above this line ---

New issue 703: Key publication needs to be reworked (x509_url and jwk_url)
https://bitbucket.org/openid/connect/issue/703/key-publication-needs-to-be-reworked

Brian Campbell:

See http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121224/002749.html for some initial points of confusion and concern.

Based on some subsequent discussion (kinda captured at http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20121231/002773.html) 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 https://www.googleapis.com/oauth2/v1/certs 

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.










 


--

This is an issue notification from bitbucket.org. You are receiving
this either because you are the owner of the issue, or you are
following the issue.