Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes <[e-mail]>]

Hi Watson,

I appreciate the concerns with regard to re-using Web PKI certs for cases
such as these.  Care is required, but I think there is a path here.

1. Clearly there are cross-protocol concerns.  I expect that most usage
here in reality would be based on ECDSA / EdDSA, not RSA, which helps.  I
would be comfortable with security considerations recommending that a key
pair / certificate used for signing these things be used for no other
purpose.

2. Validity times are definitely a challenge for the container signing use
case, but from the conversations I've had with that community, they are
taking an orthogonal approach.  As I tried to sketch in the document, they
are establishing authorities that will vouch that a signed thing existed at
a given time, so that a relying party can safely rewind their clock and
validate as if it were that time.  See, e.g., SigStore <
https://www.sigstore.dev/>, which has roughly this shape if you squint
right.

3. I don't think there's actually any disconnect between HTTPS
authentication and proof of authority.  The Web PKI is about authenticating
domain names, which is what both use cases require.

Best,
--Richard

On Mon, Mar 18, 2024 at 10:23 AM Watson Ladd <[e-mail]> wrote:

> On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes <[e-mail]> wrote:
> >
> > Hi all,
> >
> > A few of us have been considering use cases for JWTs related to
> Verifiable Credentials and container signing, which require better "proof
> of authority" for JWT signing keys.  Sharon Goldberg and I wrote up a quick
> specification for how to sign a JWK set, and how you might extend discovery
> mechanisms to present such a signed JWK set:
> >
> >
> https://github.com/bifurcation/redistributable-jwks/blob/main/draft-barnes-oauth-redistributable-jwks.md
> >
> > (Just in GitHub for now; will publish as an I-D when the window reopens
> tomorrow.)
> >
> > If we could get this functionality added to OAuth / OIDC, it would make
> these use cases work a lot better.  As a prelude toward proposing working
> group adoption, it would be great to know if this design seems helpful to
> other folks as well.  Obviously, happy to answer any questions / comments.
>
> I have concerns about this proposal. First we need to ban any use of
> RSA-1.5 encryption (aka TLS 1.2) with the certificates used here. This
> is not really possible in TLS as commonly implemented for reasons, and
> can't be determined from the certificate alone (unless it's RSA-PSS
> certificate with special stuff that hopefully is honored or ECDSA).
> Then there's a philosphical issue to reusing keys for different
> purposes that requires domain separation ala TLS 1.3, and likely some
> X509 extensions as well to really nail it.
>
> Secondly there are a bunch of layer 8 question with the Web PKI this
> raises. The web PKI is moving to short term issuance and possibly
> removal of revocation entirely if certificates can be sufficiently
> short term. For signatures on containers this is inappropriate: a
> verification that a container is the correct container needs to be
> possible long after 90 days or a week, and this means the keying
> material that was used to make that signature must be held secure
> afterwards. This runs straight up into what we're trying to do to
> improve the Web PKI, and using the Web PKI for other things often
> leads to pain.
>
> Thirdly the web PKI issuance methods make sense from a web
> perspective, but not necessarily from a codesigning perspective. What
> we want to validate is different. Organizationally websites and
> codesigning often belong in different places. At the same time there's
> a barrier to alternatives, especially the ones that don't exist (see
> also Roughtime for my personal experience with this). These issues get
> real thorny real fast.
>
> Sincerely,
> Watson Ladd
>
>
> --
> Astra mortemque praestare gradatim
>