Re: [OAUTH-WG] Signed JWK Sets

[Michael Jones]

Signed JWK Sets are part of the OpenID Federation specification and are in 
production use.  For instance, see 
https://openid.net/specs/openid-federation-1_0.html#name-metadata-extensions-for-jwk
 and the "keys" registration at 
https://openid.net/specs/openid-federation-1_0.html#name-registry-contents-7.  
I believe that should already do what you need.  If you believe it doesn't, I'd 
be curious to discuss why not with you here in Brisbane.

Best wishes,
-- Mike

From: OAuth  On Behalf Of Richard Barnes
Sent: Sunday, March 17, 2024 3:55 PM
To: oauth@ietf.org WG 
Cc: Sharon Goldberg 
Subject: [OAUTH-WG] Signed JWK Sets

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.

Thanks,
--Richard
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Michael Jones]

Also, see the additional key parameter registrations 
https://openid.net/specs/openid-federation-1_0.html#section-16.8, which can be 
used to indicate key expiration time, etc.

From: Michael Jones
Sent: Sunday, March 17, 2024 7:00 PM
To: Richard Barnes ; oauth@ietf.org WG 
Cc: Sharon Goldberg 
Subject: RE: [OAUTH-WG] Signed JWK Sets

Signed JWK Sets are part of the OpenID Federation specification and are in 
production use.  For instance, see 
https://openid.net/specs/openid-federation-1_0.html#name-metadata-extensions-for-jwk
 and the "keys" registration at 
https://openid.net/specs/openid-federation-1_0.html#name-registry-contents-7.  
I believe that should already do what you need.  If you believe it doesn't, I'd 
be curious to discuss why not with you here in Brisbane.

Best wishes,
-- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Richard Barnes
Sent: Sunday, March 17, 2024 3:55 PM
To: oauth@ietf.org<mailto:oauth@ietf.org> WG 
mailto:oauth@ietf.org>>
Cc: Sharon Goldberg mailto:gol...@bastionzero.com>>
Subject: [OAUTH-WG] Signed JWK Sets

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.

Thanks,
--Richard
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Watson Ladd]

On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes  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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes]

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  wrote:

> On Sat, Mar 16, 2024 at 10:56 PM Richard Barnes  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
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes]

Hi Mike,

Thanks for these links.  These do indeed cover a bunch of piece parts, but
they're still missing a key point for the use cases, namely: A mechanism
for a Relying Party to verify that a signer is authoritative for a given
issuer ID.

The OpenID Federation spec assumes that relying parties are configured with
a Trust Anchor that represents the federation.  (It effectively makes a PKI
encoded in JWTs.)  OpenID Connect and SD-JWT-VC rely on a domain name PKI
(e.g., the Web PKI) instead of a special federation hierarchy.  In other
words, the "x5c" field in this document is the moral equivalent of the
"trust chain" header parameter in OpenID Federation [1].

So there is still a gap here from the perspective of the use cases
described in the document.  Given the overlap here, maybe it would be
useful to pull the Signed JWK Set bits out of OpenID Federation into an
OAuth document to facilitate their re-use elsewhere.

Best,
--Richard

[1]
https://openid.net/specs/openid-federation-1_0.html#name-trust-chain-header-paramete

On Mon, Mar 18, 2024 at 9:28 AM Michael Jones 
wrote:

> Also, see the additional key parameter registrations
> https://openid.net/specs/openid-federation-1_0.html#section-16.8, which
> can be used to indicate key expiration time, etc.
>
>
>
> *From:* Michael Jones
> *Sent:* Sunday, March 17, 2024 7:00 PM
> *To:* Richard Barnes ; oauth@ietf.org WG 
> *Cc:* Sharon Goldberg 
> *Subject:* RE: [OAUTH-WG] Signed JWK Sets
>
>
>
> Signed JWK Sets are part of the OpenID Federation specification and are in
> production use.  For instance, see
> https://openid.net/specs/openid-federation-1_0.html#name-metadata-extensions-for-jwk
> and the “keys” registration at
> https://openid.net/specs/openid-federation-1_0.html#name-registry-contents-7.
> I believe that should already do what you need.  If you believe it doesn’t,
> I’d be curious to discuss why not with you here in Brisbane.
>
>
>
> Best
> wishes,
>
> -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Richard Barnes
> *Sent:* Sunday, March 17, 2024 3:55 PM
> *To:* oauth@ietf.org WG 
> *Cc:* Sharon Goldberg 
> *Subject:* [OAUTH-WG] Signed JWK Sets
>
>
>
> 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.
>
>
>
> Thanks,
>
> --Richard
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Watson Ladd]

On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes  wrote:
>
> 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 
> , which has roughly this shape if you squint right.

That should work out: might want a security considerations saying this.

>
> 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.

Only with certain validation methods. Others like agreed upon change
to site content have a narrower scope and the BRs reflect this
subtlety. To be honest you're probably safe and I am not the expert
here.

Sincerely,
Watson

--
Astra mortemque praestare gradatim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Joseph Salowey]

I think Signed JWK sets are useful and would like to see them used in more
use cases so separating out the specifications seems like a good idea.  We
will have to be careful specify what security and deployment properties you
are trying to achieve in different use cases.

On Tue, Mar 19, 2024 at 11:36 AM Watson Ladd  wrote:

> On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes  wrote:
> >
> > 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.
> >
>

[Joe] I think there may also be a consideration in some environments that
problems could arise if keys not intended for signing JWK sets could be
used to sign JWK sets.


> > 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.
>
> That should work out: might want a security considerations saying this.
>
> >
> > 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.
>
> Only with certain validation methods. Others like agreed upon change
> to site content have a narrower scope and the BRs reflect this
> subtlety. To be honest you're probably safe and I am not the expert
> here.
>

[Joe] I think this can work and be useful in many cases, but there may be
some subtleties here that should be considered.  All the more reason to
document this.


> Sincerely,
> Watson
>
> --
> Astra mortemque praestare gradatim
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Orie Steele]

In SPICE and SCITT, we have discussed similar proposals for "identity
documents", which are essentially a signed collection of keys and
attributes.

I think a generic building block that works for JOSE and COSE would be
great.

I don't think OAuth is the right place to develop general purpose identity
credentials, but it is a great place to develop profiles of identity
credentials that are specific to authorization.

Tldr, I'm supportive of the work, and I'd like to see a COSE format that we
could use in SCITT.

OS

On Wed, Mar 20, 2024, 9:24 AM Joseph Salowey  wrote:

> I think Signed JWK sets are useful and would like to see them used in more
> use cases so separating out the specifications seems like a good idea.  We
> will have to be careful specify what security and deployment properties you
> are trying to achieve in different use cases.
>
> On Tue, Mar 19, 2024 at 11:36 AM Watson Ladd 
> wrote:
>
>> On Sun, Mar 17, 2024 at 5:32 PM Richard Barnes  wrote:
>> >
>> > 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.
>> >
>>
>
> [Joe] I think there may also be a consideration in some environments that
> problems could arise if keys not intended for signing JWK sets could be
> used to sign JWK sets.
>
>
>> > 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.
>>
>> That should work out: might want a security considerations saying this.
>>
>> >
>> > 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.
>>
>> Only with certain validation methods. Others like agreed upon change
>> to site content have a narrower scope and the BRs reflect this
>> subtlety. To be honest you're probably safe and I am not the expert
>> here.
>>
>
> [Joe] I think this can work and be useful in many cases, but there may be
> some subtleties here that should be considered.  All the more reason to
> document this.
>
>
>> Sincerely,
>> Watson
>>
>> --
>> Astra mortemque praestare gradatim
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Richard Barnes]

Hi all,

Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a
second pass at this idea and actually made an Internet-Draft this time:

https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/

The new draft is focused on "Proofs of Issuer Key Authority".  This new
framing is based on a couple of important bits of feedback from Mike Jones,
(1) that OpenID Federation had already defined most of what we need, and
(2) that it would help to be clear that the real focus here was on
replacing HTTPS with JWT as the proof that a key is authoritative for a
given issuer.  Given that, we reuse the "historical JWK set" format from
OpenID Federation, and of course, focus on the "key authority" issue.

Obviously, more feedback is welcome, but especially on whether this would
be a good thing for the OAuth WG to work on.

Thanks,
--Richard


On Sun, Mar 17, 2024 at 1:55 AM Richard Barnes  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.
>
> Thanks,
> --Richard
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Ethan Heilman]

I want to voice my support for this draft: Proof of Issuer Key Authority
(PIKA). The ability to reason about the past validity of JWKS is extremely
useful for using OIDC in signing CI artifacts and e2e encrypted
messaging.This includes what we are building at OpenPubkey (
github.com/openpubkey/openpubkey) and also proposed security improvements
to software supply chain systems like SigStore (
https://arxiv.org/pdf/2307.08201.pdf).

I want to underscore the value of PIKA to increase the security of JWKS
URIs and OpenID Connect. Currently if an attacker compromises an OpenID
Provider's JWKS URI the attackers can substitute their own public keys and
impersonate any user to any relying parties who depend that OpenID
Provider. The effects of Google, Microsoft or Okta's JWKS URI being
controlled by a malicious party for even a few minutes could be
devastating. The widespread deployment of PIKA would remove this risk and
require that attackers compromise not only the JWKS URI but also the PIKA
signing keys.

As part of the OpenPubkey project, we are planning to write an
implementation of PIKA and looking with excitement toward this draft.


On Tue, Apr 9, 2024 at 3:33 PM Richard Barnes  wrote:

> Hi all,
>
> Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a
> second pass at this idea and actually made an Internet-Draft this time:
>
> https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/
>
> The new draft is focused on "Proofs of Issuer Key Authority".  This new
> framing is based on a couple of important bits of feedback from Mike Jones,
> (1) that OpenID Federation had already defined most of what we need, and
> (2) that it would help to be clear that the real focus here was on
> replacing HTTPS with JWT as the proof that a key is authoritative for a
> given issuer.  Given that, we reuse the "historical JWK set" format from
> OpenID Federation, and of course, focus on the "key authority" issue.
>
> Obviously, more feedback is welcome, but especially on whether this would
> be a good thing for the OAuth WG to work on.
>
> Thanks,
> --Richard
>
>
> On Sun, Mar 17, 2024 at 1:55 AM Richard Barnes  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.
>>
>> Thanks,
>> --Richard
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden]

On 11 Apr 2024, at 01:12, Ethan Heilman  wrote:
> 
> I want to voice my support for this draft: Proof of Issuer Key Authority 
> (PIKA). The ability to reason about the past validity of JWKS is extremely 
> useful for using OIDC in signing CI artifacts and e2e encrypted 
> messaging.This includes what we are building at OpenPubkey 
> (github.com/openpubkey/openpubkey ) 
> and also proposed security improvements to software supply chain systems like 
> SigStore (https://arxiv.org/pdf/2307.08201.pdf 
> ).
> 
> I want to underscore the value of PIKA to increase the security of JWKS URIs 
> and OpenID Connect. Currently if an attacker compromises an OpenID Provider's 
> JWKS URI the attackers can substitute their own public keys and impersonate 
> any user to any relying parties who depend that OpenID Provider. The effects 
> of Google, Microsoft or Okta's JWKS URI being controlled by a malicious party 
> for even a few minutes could be devastating. The widespread deployment of 
> PIKA would remove this risk and require that attackers compromise not only 
> the JWKS URI but also the PIKA signing keys.

I'm still digesting this draft, and generally supportive of it. However, I 
don't think it stops the attack you mention here, which sounds similar to 
threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the 
current OIDC model, an attacker that briefly compromises the jwks_uri of an OP 
(e.g. through a mis-issued TLS cert) can serve a JWK Set containing public keys 
under their own control with a long Cache-Control header. Clients then might 
blindly cache that key set even beyond the time when the certificate is revoked 
and the rightful owner restored.

But I think this attack is basically the same even with PIKA. The attacker in 
this case just uses their mis-issued cert to sign the PIKA and serve that 
instead, perhaps putting a really long "exp" claim in it so that clients cache 
it for a really long time. The only thing that would stop that is if the draft 
insisted that clients regularly perform an OCSP or CRL lookup on the cert in 
the x5c chain to make sure it hasn't been revoked. But that would completely 
negate the benefits of avoiding clients all hitting the OP jwks_uri: we've just 
shifted the burden from the OP to the CA.

Perhaps I'm missing something?

[1]: 
https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email
 

 

-- Neil___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Ethan Heilman]

Hi Neil,

I agree that PIKA would not protect against an attacker compromising a JWKS
URI via a mis-issued TLS cert.

I was thinking of a simpler attack where the attacker compromises the
server where a JWKS URI is hosted or the JWKS is stored. For instance
consider an JWKS which is read from a database. An attacker could use a SQL
injection to add their own key to the JWKS. Because such an attacker does
not compromise any TLS certificates PIKA would defeat this attack (assuming
the verifier required PIKA for that JWT issuer).

Today, write access to a JWKS is sufficient to comprise the signing
authority of a JWT issuer. With PIKA write access to a JWKS may not be
sufficient to compromise the signing authority of a JWT issuer.

Thanks,
Ethan


On Thu, Apr 11, 2024 at 5:15 PM Neil Madden  wrote:

> On 11 Apr 2024, at 01:12, Ethan Heilman  wrote:
>
>
> I want to voice my support for this draft: Proof of Issuer Key Authority
> (PIKA). The ability to reason about the past validity of JWKS is extremely
> useful for using OIDC in signing CI artifacts and e2e encrypted
> messaging.This includes what we are building at OpenPubkey (
> github.com/openpubkey/openpubkey) and also proposed security improvements
> to software supply chain systems like SigStore (
> https://arxiv.org/pdf/2307.08201.pdf).
>
> I want to underscore the value of PIKA to increase the security of JWKS
> URIs and OpenID Connect. Currently if an attacker compromises an OpenID
> Provider's JWKS URI the attackers can substitute their own public keys and
> impersonate any user to any relying parties who depend that OpenID
> Provider. The effects of Google, Microsoft or Okta's JWKS URI being
> controlled by a malicious party for even a few minutes could be
> devastating. The widespread deployment of PIKA would remove this risk and
> require that attackers compromise not only the JWKS URI but also the PIKA
> signing keys.
>
>
> I'm still digesting this draft, and generally supportive of it. However, I
> don't think it stops the attack you mention here, which sounds similar to
> threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the
> current OIDC model, an attacker that briefly compromises the jwks_uri of an
> OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing
> public keys under their own control with a long Cache-Control header.
> Clients then might blindly cache that key set even beyond the time when the
> certificate is revoked and the rightful owner restored.
>
> But I think this attack is basically the same even with PIKA. The attacker
> in this case just uses their mis-issued cert to sign the PIKA and serve
> that instead, perhaps putting a really long "exp" claim in it so that
> clients cache it for a really long time. The only thing that would stop
> that is if the draft insisted that clients regularly perform an OCSP or CRL
> lookup on the cert in the x5c chain to make sure it hasn't been revoked.
> But that would completely negate the benefits of avoiding clients all
> hitting the OP jwks_uri: we've just shifted the burden from the OP to the
> CA.
>
> Perhaps I'm missing something?
>
> [1]:
> https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email
>
>
> -- Neil
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Joseph Salowey]

The mechanism in the draft provides some separation between the trust
establishment and distribution which is useful.  This is definitely
applicable to the use cases described in the draft and I agree with Ethan
that it can help in other areas as well depending upon how things are
deployed.  I support this draft.

Joe

On Thu, Apr 11, 2024 at 7:16 PM Ethan Heilman  wrote:

> Hi Neil,
>
> I agree that PIKA would not protect against an attacker compromising a
> JWKS URI via a mis-issued TLS cert.
>
> I was thinking of a simpler attack where the attacker compromises the
> server where a JWKS URI is hosted or the JWKS is stored. For instance
> consider an JWKS which is read from a database. An attacker could use a SQL
> injection to add their own key to the JWKS. Because such an attacker does
> not compromise any TLS certificates PIKA would defeat this attack (assuming
> the verifier required PIKA for that JWT issuer).
>
> Today, write access to a JWKS is sufficient to comprise the signing
> authority of a JWT issuer. With PIKA write access to a JWKS may not be
> sufficient to compromise the signing authority of a JWT issuer.
>
> Thanks,
> Ethan
>
>
> On Thu, Apr 11, 2024 at 5:15 PM Neil Madden 
> wrote:
>
>> On 11 Apr 2024, at 01:12, Ethan Heilman  wrote:
>>
>>
>> I want to voice my support for this draft: Proof of Issuer Key Authority
>> (PIKA). The ability to reason about the past validity of JWKS is extremely
>> useful for using OIDC in signing CI artifacts and e2e encrypted
>> messaging.This includes what we are building at OpenPubkey (
>> github.com/openpubkey/openpubkey) and also proposed security
>> improvements to software supply chain systems like SigStore (
>> https://arxiv.org/pdf/2307.08201.pdf).
>>
>> I want to underscore the value of PIKA to increase the security of JWKS
>> URIs and OpenID Connect. Currently if an attacker compromises an OpenID
>> Provider's JWKS URI the attackers can substitute their own public keys and
>> impersonate any user to any relying parties who depend that OpenID
>> Provider. The effects of Google, Microsoft or Okta's JWKS URI being
>> controlled by a malicious party for even a few minutes could be
>> devastating. The widespread deployment of PIKA would remove this risk and
>> require that attackers compromise not only the JWKS URI but also the PIKA
>> signing keys.
>>
>>
>> I'm still digesting this draft, and generally supportive of it. However,
>> I don't think it stops the attack you mention here, which sounds similar to
>> threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the
>> current OIDC model, an attacker that briefly compromises the jwks_uri of an
>> OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing
>> public keys under their own control with a long Cache-Control header.
>> Clients then might blindly cache that key set even beyond the time when the
>> certificate is revoked and the rightful owner restored.
>>
>> But I think this attack is basically the same even with PIKA. The
>> attacker in this case just uses their mis-issued cert to sign the PIKA and
>> serve that instead, perhaps putting a really long "exp" claim in it so that
>> clients cache it for a really long time. The only thing that would stop
>> that is if the draft insisted that clients regularly perform an OCSP or CRL
>> lookup on the cert in the x5c chain to make sure it hasn't been revoked.
>> But that would completely negate the benefits of avoiding clients all
>> hitting the OP jwks_uri: we've just shifted the burden from the OP to the
>> CA.
>>
>> Perhaps I'm missing something?
>>
>> [1]:
>> https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub?utm_source=illuminatedsecurity&utm_medium=email
>>
>>
>> -- Neil
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden]

> On 12 Apr 2024, at 03:16, Ethan Heilman  wrote:
> 
> 
> Hi Neil,
> 
> I agree that PIKA would not protect against an attacker compromising a JWKS 
> URI via a mis-issued TLS cert.
> 
> I was thinking of a simpler attack where the attacker compromises the server 
> where a JWKS URI is hosted or the JWKS is stored. For instance consider an 
> JWKS which is read from a database. An attacker could use a SQL injection to 
> add their own key to the JWKS. Because such an attacker does not compromise 
> any TLS certificates PIKA would defeat this attack (assuming the verifier 
> required PIKA for that JWT issuer).

It depends how the PIKA is created. If you mean that the database stores the 
signed PIKA, then yes that would prevent the attack. But if the database just 
stores the keys and another process periodically extracts them and signs them 
to create the PIKA (which seems more likely to me), then the attack still 
succeeds. 

> 
> Today, write access to a JWKS is sufficient to comprise the signing authority 
> of a JWT issuer. With PIKA write access to a JWKS may not be sufficient to 
> compromise the signing authority of a JWT issuer.

I’m not sure this is true in many cases. Doesn’t PIKA essentially assume that 
the TLS cert signing key is accessible to whatever process creates the JWK Set? 
So if you have write access to the JWK Set, you often will also have access to 
that private key - either directly, or via some API/HSM call. Not always, but I 
think in many scenarios. 

— Neil

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Neil Madden]

I’m not sure this is an official call for adoption, but I support this draft. Regardless of the discussion in the other thread, I think this draft has clear value and is well designed. A couple of thoughts:Presumably it is infeasible for a client to construct a TLS transcript that looks like a valid JWK Set? Ie because we are reusing the TLS cert signing key, I want to check that this doesn’t open up an issue where an attacker interacting with TLS can trick the server into signing a PIKA of their choosing. I’d like to see a security analysis of that. Are there privacy advantages to using PIKA? It seems like clients not all calling back to the OP to retrieve verification keys would also prevent some tracking? If so, that seems like a good positive to add to the draft. Best wishes,NeilOn 9 Apr 2024, at 20:33, Richard Barnes  wrote:Hi all,Thanks for all the feedback on-list and at IETF 119.  Sharon and I took a second pass at this idea and actually made an Internet-Draft this time:https://datatracker.ietf.org/doc/draft-barnes-oauth-pika/The new draft is focused on "Proofs of Issuer Key Authority".  This new framing is based on a couple of important bits of feedback from Mike Jones, (1) that OpenID Federation had already defined most of what we need, and (2) that it would help to be clear that the real focus here was on replacing HTTPS with JWT as the proof that a key is authoritative for a given issuer.  Given that, we reuse the "historical JWK set" format from OpenID Federation, and of course, focus on the "key authority" issue.Obviously, more feedback is welcome, but especially on whether this would be a good thing for the OAuth WG to work on.Thanks,--RichardOn Sun, Mar 17, 2024 at 1:55 AM Richard Barnes  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.Thanks,--Richard

___OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[John Zila]

On 11 Apr 2024, at 21:15, Neil Madden  wrote:

> I'm still digesting this draft, and generally supportive of it. However,
I don't think it stops the attack you mention here, which sounds similar to
threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the
current OIDC model, an attacker that briefly compromises the jwks_uri of an
OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing
public keys under their own control with a long Cache-Control header.
Clients then might blindly cache that key set even beyond the time when the
certificate is revoked and the rightful owner restored.
>
> But I think this attack is basically the same even with PIKA. The
attacker in this case just uses their mis-issued cert to sign the PIKA and
serve that instead, perhaps putting a really long "exp" claim in it so that
clients cache it for a really long time. The only thing that would stop
that is if the draft insisted that clients regularly perform an OCSP or CRL
lookup on the cert in the x5c chain to make sure it hasn't been revoked.
But that would completely negate the benefits of avoiding clients all
hitting the OP jwks_uri: we've just shifted the burden from the OP to the
CA.

I am also supportive of this draft. Chain of Trust is a real problem in JWT
issuance, and it's nice to see a simple solution that addresses it.
Regarding Neil's attack above, rather than requiring clients to separately
do OCSP or CRL, you could envision an OCSP stapling-like approach that
could include a signature over a timestamped PIKA as a "staple" in a JWT,
which moves up the proof of issuer validity to the time of issuance of the
JWT, rather than just the last time you retrieved the PIKA. If you see a
new PIKA staple, you know you need to fetch again. If you see a staple for
a PIKA you've already cached, then you know it hasn't been revoked.

You could additionally layer this approach by stapling the PIKAs
themselves, where the PIKA staples are periodically updated to assert
continued validity of the signing certificate. With such a system, you can
provide guarantees regarding validity latency down the entire signature
chain.

- John
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[Rifaat Shekh-Yusef]

Just to be clear, this is *not* a call for adoption at this time.

So, please focus on discussing the concept described in this individual
draft.

Regards,
 Rifaat



On Wed, Apr 17, 2024 at 1:43 PM John Zila  wrote:

> On 11 Apr 2024, at 21:15, Neil Madden  wrote:
>
> > I'm still digesting this draft, and generally supportive of it. However,
> I don't think it stops the attack you mention here, which sounds similar to
> threats that Ryan Sleevi discussed for FastFed in [1]. Essentially, in the
> current OIDC model, an attacker that briefly compromises the jwks_uri of an
> OP (e.g. through a mis-issued TLS cert) can serve a JWK Set containing
> public keys under their own control with a long Cache-Control header.
> Clients then might blindly cache that key set even beyond the time when the
> certificate is revoked and the rightful owner restored.
> >
> > But I think this attack is basically the same even with PIKA. The
> attacker in this case just uses their mis-issued cert to sign the PIKA and
> serve that instead, perhaps putting a really long "exp" claim in it so that
> clients cache it for a really long time. The only thing that would stop
> that is if the draft insisted that clients regularly perform an OCSP or CRL
> lookup on the cert in the x5c chain to make sure it hasn't been revoked.
> But that would completely negate the benefits of avoiding clients all
> hitting the OP jwks_uri: we've just shifted the burden from the OP to the
> CA.
>
> I am also supportive of this draft. Chain of Trust is a real problem in
> JWT issuance, and it's nice to see a simple solution that addresses it.
> Regarding Neil's attack above, rather than requiring clients to separately
> do OCSP or CRL, you could envision an OCSP stapling-like approach that
> could include a signature over a timestamped PIKA as a "staple" in a JWT,
> which moves up the proof of issuer validity to the time of issuance of the
> JWT, rather than just the last time you retrieved the PIKA. If you see a
> new PIKA staple, you know you need to fetch again. If you see a staple for
> a PIKA you've already cached, then you know it hasn't been revoked.
>
> You could additionally layer this approach by stapling the PIKAs
> themselves, where the PIKA staples are periodically updated to assert
> continued validity of the signing certificate. With such a system, you can
> provide guarantees regarding validity latency down the entire signature
> chain.
>
> - John
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signed JWK Sets

[James Carnegie]

Hi there,

FWIW, this is a really interesting proposal, and I recognise the use case
in 1.2. Use Case: Verifying Stored Signature.

>From a Docker perspective, being able to sign attestations on container
images using workload identity (i.g. GitHub) using something like
OpenPubkey (https://github.com/openpubkey/openpubkey) would be great, and
this proposal would help us to verify signatures created under previous
(expired) OIDC public keys.

Thanks,

James Carnegie (supply chain engineer at Docker)
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth