Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

See my review comments in the thread “[OAUTH-WG] Comments on 
draft-chadwick-oauth-jwk-uri-00”.

   -- Mike

From: David Chadwick 
Sent: Friday, February 18, 2022 3:52 AM
To: Mike Jones ; Kristina Yasuda 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi Mike

The additional mechanism was published as an I-D last week.


draft-chadwick-oauth-jwk-uri-00.txt

I thought this list had been notified, but my-bad, I see it was not.  So I have 
just sent out the notification now.

So can we get some feedback from this group as well as the OIDC one, before 
progressing either?

Kind regards

David

On 17/02/2022 22:23, Mike Jones wrote:
Hi David,

Rifaat reminded me that yours is the only WGLC comment that has not been 
resolved by publication of -01.  As noted earlier, the substantive differences 
between this draft and the JWK URI draft that you’re proposing are being 
primarily discussed in the OpenID Connect working group, where the JWK 
Thumbprint URI mechanism is used.

In that discussion, you made this issue comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:

“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly 
JWK Thumbprint URIs should not exclude JWK URIs.”

That seems to me to indicate that you’re OK with this specification being 
published, while also wanting both working groups to consider your additional 
mechanism when a draft is submitted?  Am I hearing you correctly on that?

At least in my mind, the fact that you might publish another not-equivalent 
mechanism shouldn’t hold up publication of this mechanism.

   Thanks again,
   -- Mike

From: David Chadwick 
<mailto:d.w.chadw...@verifiablecredentials.info>
Sent: Monday, February 7, 2022 12:54 PM
To: Kristina Yasuda 
<mailto:kristina.yas...@microsoft.com>; Mike 
Jones <mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 07/02/2022 20:42, Kristina Yasuda wrote:
Hi David,

I think your comments below apply to the choices made in another specification 
(SIOP v2 in OIDF), rather than this IETF draft we are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a matter for 
this list, and should answer this question, "what is the best way (or ways) of 
creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way of specifying a 
public key as a URI and therefore needs some other standard or standards to 
refer to.
I’ve seen you opened an issue in the OpenID Connect WG Bitbucket. Let’s discuss 
there whether SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,
Kristina

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones 
<mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 
7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D=0>]
 computation used by this specification, and not the operation defined by this 
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK 
Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it 
leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 
transfers the public key and the public key thumbprint. My I-D suggests that we 
simply transfer the public key as a URI then no thumbprint computation is 
necessary by the SIOPv2. The recipient can compute its own thumbprint if it 
needs to by utilising the JWK Thumprint RFC and in this case no hashing 
algorithm needs to be jointly agreed upon.

Kind regards

David

This 
specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[David Chadwick]

  
  
Hi Mike


The additional mechanism was published
  as an I-D last week.




  draft-chadwick-oauth-jwk-uri-00.txt



I thought this list had been notified,
  but my-bad, I see it was not.  So I have just sent out the
  notification now.


So can we get some feedback from this
  group as well as the OIDC one, before progressing either?


Kind regards


David


On 17/02/2022 22:23, Mike Jones wrote:


  
  
  
  
Hi David,
 
Rifaat reminded me that yours is the only
  WGLC comment that has not been resolved by publication of
  -01.  As noted earlier, the substantive differences between
  this draft and the JWK URI draft that you’re proposing are
  being primarily discussed in the OpenID Connect working group,
  where the JWK Thumbprint URI mechanism is used.
 
In that discussion, you made this issue
  comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:
 
“I
agree that adding JWK URI should not exclude JWK Thumbprint
URIs. Similarly JWK Thumbprint URIs should not exclude JWK
URIs.”
 
That seems to me to indicate that you’re OK
  with this specification being published, while also wanting
  both working groups to consider your additional mechanism when
  a draft is submitted?  Am I hearing you correctly on that?
 
At least in my mind, the fact that you
  might publish another not-equivalent mechanism shouldn’t hold
  up publication of this mechanism.
 
  
  Thanks again,
  
  -- Mike
 

  
From: David Chadwick
  
  
  Sent: Monday, February 7, 2022 12:54 PM
  To: Kristina Yasuda
  ; Mike Jones
  ; oauth@ietf.org
  Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI
  document
  

 

  On 07/02/2022 20:42, Kristina Yasuda
wrote:


  Hi David,
   
  I think your comments below apply to the
choices made in another specification (SIOP v2 in OIDF),
rather than this IETF draft we are discussing.

Hi Kristina
Yes and no. 
No, in that the registration of either of the I-Ds as an RFC
  is a matter for this list, and should answer this question,
  "what is the best way (or ways) of creating a URI from a
  public key."
Yes, in that the SIOPv2 specification requires at least one
  way of specifying a public key as a URI and therefore needs
  some other standard or standards to refer to.

  I’ve seen you opened an issue in the
OpenID Connect WG Bitbucket. Let’s discuss there whether
SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF
Kind regards
David

   
  Best,
  Kristina
   
  

  From: OAuth 
On Behalf Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones ;
oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint
        URI document

  
   
  
On 05/02/2022 17:46, Mike Jones wrote:
  
  
David, I believe your objections below
  are actually about the JWK Thumbprint [RFC 7638] computation used by
  this specification, and not the operation defined by this
  specification.  JWK Thumbprint became an RFC in 2015.
  
  Hi Mike
  no, my objection is to the JWK Thumbprint URI document. I
accept that the JWK Thumbprint RFC already exists.
  The aim of the SIOPv2 group is to transfer a public key as
a URI, so it leverages the JWK Thumbprint RFC to do this. As
I point out in my I-D, SIOPv2 transfers the public key and
the public key thumbprint. My I-D suggests that we simply
transfer the public key as a URI then no thumbprint
computation is necessary by the SIOPv2. The recipient can
compute its own thumbprint if it needs to by utilising the
JWK Thumprint RFC and in this case no hashing algorithm
needs to be jointly agreed upon.
  Kind regards
 

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

Hi David,

Rifaat reminded me that yours is the only WGLC comment that has not been 
resolved by publication of -01.  As noted earlier, the substantive differences 
between this draft and the JWK URI draft that you’re proposing are being 
primarily discussed in the OpenID Connect working group, where the JWK 
Thumbprint URI mechanism is used.

In that discussion, you made this issue comment 
https://bitbucket.org/openid/connect/issues/1429/replace-jwk-thumbprint-uri-with-jwk-uri#comment-61838115:

“I agree that adding JWK URI should not exclude JWK Thumbprint URIs. Similarly 
JWK Thumbprint URIs should not exclude JWK URIs.”

That seems to me to indicate that you’re OK with this specification being 
published, while also wanting both working groups to consider your additional 
mechanism when a draft is submitted?  Am I hearing you correctly on that?

At least in my mind, the fact that you might publish another not-equivalent 
mechanism shouldn’t hold up publication of this mechanism.

   Thanks again,
   -- Mike

From: David Chadwick 
Sent: Monday, February 7, 2022 12:54 PM
To: Kristina Yasuda ; Mike Jones 
; oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 07/02/2022 20:42, Kristina Yasuda wrote:
Hi David,

I think your comments below apply to the choices made in another specification 
(SIOP v2 in OIDF), rather than this IETF draft we are discussing.

Hi Kristina

Yes and no.

No, in that the registration of either of the I-Ds as an RFC is a matter for 
this list, and should answer this question, "what is the best way (or ways) of 
creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way of specifying a 
public key as a URI and therefore needs some other standard or standards to 
refer to.
I’ve seen you opened an issue in the OpenID Connect WG Bitbucket. Let’s discuss 
there whether SIOP v2 should use JWK Thumbprint URI.

Yes we can certainly discuss the latter issue in OIDF

Kind regards

David

Best,
Kristina

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones 
<mailto:michael.jo...@microsoft.com>; 
oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 
7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D=0>]
 computation used by this specification, and not the operation defined by this 
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK 
Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it 
leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 
transfers the public key and the public key thumbprint. My I-D suggests that we 
simply transfer the public key as a URI then no thumbprint computation is 
necessary by the SIOPv2. The recipient can compute its own thumbprint if it 
needs to by utilising the JWK Thumprint RFC and in this case no hashing 
algorithm needs to be jointly agreed upon.

Kind regards

David

This 
specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D=0>
 defines how to create a JWK Thumbprint URI by concatenating the URI prefix 
“urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.  That’s 
all it does.  That’s why Rifaat’s statement “The JWK Thumbprint URI document is 
a simple and straightforward specification” is indeed correct.

   Best wishes,
   -- Mike

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
All,

The JWK Thumbprint URI document is a simple and straightforward specification.

Actually this

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

My traditional blog post describing the updated draft is at 
https://self-issued.info/?p=2251.  I also tweeted about it at 
https://twitter.com/selfissued/status/1493778351919489037.

   -- Mike

From: OAuth  On Behalf Of Kristina Yasuda
Sent: Monday, February 14, 2022 4:34 PM
To: oauth 
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

Hi All,

Thank you very much for the constructive feedback.
We have tried to address the WGLC comments received to date with the latest 
draft published at 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01.

Following are updates made to the document:
- Added security considerations about multiple public keys coresponding to the 
same private key.
- Added hash algorithm identifier after the JWK thumbprint URI prefix to make 
it explicit in a URI which hash algorithm is used.
- Added reference to a registry for hash algorithm identifiers.
- Added SHA-256 as a mandatory to implement hash algorithm to promote 
interoperability.

Kindest Regards,
Kristina

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth mailto:oauth@ietf.org>>
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D=0>

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Warren Parad]

This is a great improvement.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Tue, Feb 15, 2022 at 2:37 PM Neil Madden 
wrote:

> Thanks, these changes address my comments. I am happy with the new draft
> text.
>
> Cheers,
>
> Neil
>
> On 15 Feb 2022, at 00:33, Kristina Yasuda <
> Kristina.Yasuda=40microsoft@dmarc.ietf.org> wrote:
>
> Hi All,
>
> Thank you very much for the constructive feedback.
> We have tried to address the WGLC comments received to date with the
> latest draft published at
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01
> .
>
> Following are updates made to the document:
> - Added security considerations about multiple public keys coresponding to
> the same private key.
> - Added hash algorithm identifier after the JWK thumbprint URI prefix to
> make it explicit in a URI which hash algorithm is used.
> - Added reference to a registry for hash algorithm identifiers.
> - Added SHA-256 as a mandatory to implement hash algorithm to promote
> interoperability.
>
> Kindest Regards,
> Kristina
>
> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
> *Sent:* Wednesday, February 2, 2022 4:19 AM
> *To:* oauth 
> *Subject:* [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
> All,
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D=0>
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
> Regards,
>  Rifaat & Hannes
>
>
> ___
> 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] WGLC for JWK Thumbprint URI document

[Neil Madden]

Thanks, these changes address my comments. I am happy with the new draft text.

Cheers,

Neil

> On 15 Feb 2022, at 00:33, Kristina Yasuda 
>  wrote:
> 
> Hi All,
>  
> Thank you very much for the constructive feedback.
> We have tried to address the WGLC comments received to date with the latest 
> draft published 
> athttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01
>  
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01>.
>  
> Following are updates made to the document:
> - Added security considerations about multiple public keys coresponding to 
> the same private key. 
> - Added hash algorithm identifier after the JWK thumbprint URI prefix to make 
> it explicit in a URI which hash algorithm is used.
> - Added reference to a registry for hash algorithm identifiers. 
> - Added SHA-256 as a mandatory to implement hash algorithm to promote 
> interoperability.
>  
> Kindest Regards,
> Kristina 
>  
> From: OAuth  On Behalf Of Rifaat Shekh-Yusef
> Sent: Wednesday, February 2, 2022 4:19 AM
> To: oauth 
> Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>  
> All,
>  
> The JWK Thumbprint URI document is a simple and straightforward specification.
>  
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D=0>
>  
> Please, provide your feedback on the mailing list by Feb 16th.
>  
> Regards,
>  Rifaat & Hannes
>  
>  
> ___
> 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] WGLC for JWK Thumbprint URI document

[Kristina Yasuda]

Hi All,

Thank you very much for the constructive feedback.
We have tried to address the WGLC comments received to date with the latest 
draft published at 
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwk-thumbprint-uri-01.

Following are updates made to the document:
- Added security considerations about multiple public keys coresponding to the 
same private key.
- Added hash algorithm identifier after the JWK thumbprint URI prefix to make 
it explicit in a URI which hash algorithm is used.
- Added reference to a registry for hash algorithm identifiers.
- Added SHA-256 as a mandatory to implement hash algorithm to promote 
interoperability.

Kindest Regards,
Kristina

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth 
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7C798aea1808b74133e90308d9e64643b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794012195931100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=UDG%2F77OaaA%2BaTPiBiDzKYbyXUvJ2YY5m%2F7wO7OhW%2FNI%3D=0>

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

Thanks for the useful information, Neil!  I learned things I didn't know from 
reading your remarks, which is always good. :-)

The good news is that in the application that motivated writing this 
specification (OpenID Connect Self-Issued OpenID Provider v2) the mitigation 
you described is already in place; the key is used to sign a JWT that includes 
both the key thumbprint and the key itself.  But it will be great to describe 
these attacks and how they relate to using key thumbprints as identifiers 
generally, so others are aware of them.

We also look forward to any additional Security Considerations text you may 
choose to supply.

   Thanks again,
   -- Mike

From: Neil Madden 
Sent: Saturday, February 5, 2022 1:00 AM
To: Mike Jones 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document

Hi Mike,


On 4 Feb 2022, at 15:30, Mike Jones 
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>>
 wrote:

Neil, thanks for your review.  First, you wrote:

> Using a (hash of a) public key as an identifier is an idea that has 
> historically been subject to various attacks such as unknown key share 
> attacks, as well as issues due to malleable signature schemes or key exchange 
> schemes - where the same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

I’ll have a look and see if there is a concise write up somewhere. To give you 
an idea, here are some potential attacks:

Firstly, in ECDSA for example each signature is typically valid for at least 
two public keys, and these keys can be easily recovered from the signature 
itself [1]. So if Alice is using an ECDSA signature as proof of her identity, 
and her identity is a (hash of a) public key, then it is also a valid proof of 
identity for a different identity (different JWK thumbprint). This makes an 
authentication scheme based on this ambiguous, which is not usually a good 
thing.

A similar thing can happen with ECDH-based key exchanges or authenticated 
encryption schemes (like my own ECDH-1PU) with certain elliptic curves. In this 
case you can add “points of small order” to a public key to derive a new public 
key that will produce the same ECDH shared secrets (or even simpler change the 
PK point (x,y) to (x,-y)). The attacker in this case can’t decrypt or tamper 
with a message but they can claim that it came from their public key instead of 
the real originator. Again, this can make the same proof of identity valid for 
two or more identities if you use public keys as identities.

In both cases these “attacks” can be avoided by including the identities/public 
keys in the input to the signature (or KDF for ECDH). For example, EdDSA 
already does this, and this is a recommended best practice for ECDH (sadly 
missing from JWE). An alternative is to define a canonical public key for each 
given signature and reject non-canonical keys.

Whether these “attacks” actually lead to a vulnerability or not depends on 
exactly what you are doing. But it is a surprising property that can lead to 
subtle issues as the security considerations of RFC 7748 note [2]:

“ Designers using these curves should be aware that for each public

   key, there are several publicly computable public keys that are

   equivalent to it, i.e., they produce the same shared secrets.  Thus

   using a public key as an identifier and knowledge of a shared secret

   as proof of ownership (without including the public keys in the key

   derivation) might lead to subtle vulnerabilities.”


Adding wording along those lines (generalised to mention signatures too) would 
be good. I’ll come up with some wording.

Other security issues can arise when a public key hash is informally associated 
with some other kind of identifier without a strong binding between the two. 
For example, the unknown key share attacks described in RFC 8844 [3].

[1]: https://crypto.stackexchange.com/a/60219
[2]: https://datatracker.ietf.org/doc/html/rfc7748#section-7
[3]: https://www.rfc-editor.org/rfc/rfc8844.html

— Neil



Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth mailto:oauth-b

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Kristina Yasuda]

Thank you, Brian, DW and Aaron for the references.

Mike and I discussed this and we would like to

- Make SHA-256 the mandatory to implement algorithm, to guarantee 
interoperability (as suggested by DW).
- Use the "Named Information Hash Algorithm Registry" as the source of a string 
hash algorithm identifiers when including hash function explicitly in the URI 
prefix.

This means that an example of using the SHA-256 hash function
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
would become
> urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs

Best,
Kristina
.

-Original Message-
From: OAuth  On Behalf Of David Waite
Sent: Friday, February 4, 2022 6:17 PM
To: Mike Jones 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

> On Feb 4, 2022, at 6:32 PM, Mike Jones 
>  wrote:
> 
> Kristina and I spoke about it today and we agreed that it makes sense 
> to make the hash algorithm explicit.  So for instance, we'd propose 
> that the example 
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfH
> kxZsRGC9Xs
> become
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWX
> FZAfHkxZsRGC9Xs
> when using the SHA-256 hash function.
>  
> Similarly, we'd propose to also define S384, S512, and possibly also S3-256, 
> S3-384, and S3-512 (for the SHA-3 hash functions).

My ideal would be making the algorithm explicit in the name, while deferring 
establishing a registry of other algorithms until a technical need is 
established.

While it is not necessary that a URN namespace define a unique name for a 
resource, it is a useful property that would be lost with multiple hashing 
schemes. Use of a hashing scheme not supported by a piece of software would 
also mean that there is no way to verify the name corresponds to a given 
resource.

For this reason, if we do support multiple algorithms I would expect a mandate 
in dependent specs and systems that mandate a specific one or a specific set. 
For example, they may exclude the Kekkak variants (SHA3, SHAKE) as there are no 
other algorithms registered for JOSE which depend upon them.

>  
> For extra credit, if there's already an IANA registry with string names for 
> these hash functions, we'd consider using it.  I looked for one and 
> surprisingly didn't find it.  Or we could create one.
>  

The COSE algorithms are declared with both numbers and names, and include 
hashes as algorithms.

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcose%2Fcose.xhtml%23algorithmsdata=04%7C01%7CKristina.Yasuda%40microsoft.com%7C6efedfb5f6f745813e5f08d9e84da05d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637796242424613801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=S7XBsB8pokg2Vd2aDRsvdu8MwqW1CLCy8WR31IwBrsY%3Dreserved=0

-DW
___
OAuth mailing list
OAuth@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauthdata=04%7C01%7CKristina.Yasuda%40microsoft.com%7C6efedfb5f6f745813e5f08d9e84da05d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637796242424613801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=DSwK90M9dF2dtVnALFI7jTwzP%2BCCXS7WEH3FrENqK4Y%3Dreserved=0

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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[David Chadwick]

  
  
On 07/02/2022 20:42, Kristina Yasuda
  wrote:


  
  
  
  
Hi David,
 
I think your comments below apply to the
  choices made in another specification (SIOP v2 in OIDF),
  rather than this IETF draft we are discussing.
  

Hi Kristina
Yes and no. 

No, in that the registration of either of the I-Ds as an RFC is a
  matter for this list, and should answer this question, "what is
  the best way (or ways) of creating a URI from a public key."

Yes, in that the SIOPv2 specification requires at least one way
  of specifying a public key as a URI and therefore needs some other
  standard or standards to refer to.


  

I’ve seen you opened an issue in the OpenID
  Connect WG Bitbucket. Let’s discuss there whether SIOP v2
  should use JWK Thumbprint URI.
  

Yes we can certainly discuss the latter issue in OIDF
Kind regards
David


  

 
Best,
Kristina
 

  
From: OAuth
   On Behalf Of 
  David Chadwick
  Sent: Sunday, February 6, 2022 2:40 AM
  To: Mike Jones ;
  oauth@ietf.org
  Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI
  document
  

 

  On 05/02/2022 17:46, Mike Jones wrote:


  David, I believe your objections below
are actually about the JWK Thumbprint [RFC 7638] computation used by
this specification, and not the operation defined by this
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike
no, my objection is to the JWK Thumbprint URI document. I
  accept that the JWK Thumbprint RFC already exists.
The aim of the SIOPv2 group is to transfer a public key as a
  URI, so it leverages the JWK Thumbprint RFC to do this. As I
  point out in my I-D, SIOPv2 transfers the public key and the
  public key thumbprint. My I-D suggests that we simply transfer
  the public key as a URI then no thumbprint computation is
  necessary by the SIOPv2. The recipient can compute its own
  thumbprint if it needs to by utilising the JWK Thumprint RFC
  and in this case no hashing algorithm needs to be jointly
  agreed upon.
Kind regards
David

   
  This specification defines how
to create a JWK Thumbprint URI by concatenating the URI
prefix “urn:ietf:params:oauth:jwk-thumbprint”
to an RFC 7638 JWK Thumbprint.  That’s all it does.  That’s
why Rifaat’s statement “The JWK Thumbprint URI document
  is a simple and straightforward specification” is
indeed correct.
   
    
Best wishes,
    
-- Mike
   
  

  From: OAuth 
On Behalf Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint
        URI document

  
   
  
On 02/02/2022 12:18, Rifaat Shekh-Yusef
  wrote:
  
  

  All, 
  
 
  
  
The JWK Thumbprint URI document
  is a simple and straightforward specification.
  

  
  Actually this is a complex and inefficient specification
compared to other possibilities.
  I have written an Internet-Draft outlining an alternative
scheme, the JWK URI, which provides OIDC SIOPv2 with all the
requirements that it needs with much less effort than
implementing JWK Thumbprint URIs. I am currently formatting
this I-D correctly to submit to the IETF. The rationale for
this new Internet Draft is as follows.
  
To produce or validate a JWK
  Thumbprint, both the sender and the receiver have to have
  the JWK available to them. Then they have to canonicalise
  the JWK as described in [RFC7638], and finally hash the
  octets of the UTF-8 representation of this JSON
  object with a pre-agreed algorithm in order to both obtain
  the same hash value. The way that the JWK Thumbprint URI
  is used in SIOPv2 [SIOPv2] is as follows:
  

  the SIOP creates an asymmetric
key pair and encodes 

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Kristina Yasuda]

Hi David,

I think your comments below apply to the choices made in another specification 
(SIOP v2 in OIDF), rather than this IETF draft we are discussing.
I've seen you opened an issue in the OpenID Connect WG Bitbucket. Let's discuss 
there whether SIOP v2 should use JWK Thumbprint URI.

Best,
Kristina

From: OAuth  On Behalf Of David Chadwick
Sent: Sunday, February 6, 2022 2:40 AM
To: Mike Jones ; oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 05/02/2022 17:46, Mike Jones wrote:
David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 
7638<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7638.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=YsMfndDhygG7AkSPK9NeYrKhDwFkd5P%2FSAgZsrXH%2F6Q%3D=0>]
 computation used by this specification, and not the operation defined by this 
specification.  JWK Thumbprint became an RFC in 2015.

Hi Mike

no, my objection is to the JWK Thumbprint URI document. I accept that the JWK 
Thumbprint RFC already exists.

The aim of the SIOPv2 group is to transfer a public key as a URI, so it 
leverages the JWK Thumbprint RFC to do this. As I point out in my I-D, SIOPv2 
transfers the public key and the public key thumbprint. My I-D suggests that we 
simply transfer the public key as a URI then no thumbprint computation is 
necessary by the SIOPv2. The recipient can compute its own thumbprint if it 
needs to by utilising the JWK Thumprint RFC and in this case no hashing 
algorithm needs to be jointly agreed upon.

Kind regards

David

This 
specification<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7Ca3ed141a4e8d44a502ac08d9e95d13c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637797408920851038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=8Vt%2BwrhXuAC3CjvGzaQtmYv4%2BIV3ElozbVGED4FLUvQ%3D=0>
 defines how to create a JWK Thumbprint URI by concatenating the URI prefix 
"urn:ietf:params:oauth:jwk-thumbprint" to an RFC 7638 JWK Thumbprint.  That's 
all it does.  That's why Rifaat's statement "The JWK Thumbprint URI document is 
a simple and straightforward specification" is indeed correct.

   Best wishes,
   -- Mike

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
All,

The JWK Thumbprint URI document is a simple and straightforward specification.

Actually this is a complex and inefficient specification compared to other 
possibilities.

I have written an Internet-Draft outlining an alternative scheme, the JWK URI, 
which provides OIDC SIOPv2 with all the requirements that it needs with much 
less effort than implementing JWK Thumbprint URIs. I am currently formatting 
this I-D correctly to submit to the IETF. The rationale for this new Internet 
Draft is as follows.

To produce or validate a JWK Thumbprint, both the sender and the receiver have 
to have the JWK available to them. Then they have to canonicalise the JWK as 
described in [RFC7638], and finally hash the octets of the UTF-8 representation 
of this JSON object with a pre-agreed algorithm in order to both obtain the 
same hash value. The way that the JWK Thumbprint URI is used in SIOPv2 [SIOPv2] 
is as follows:

  1.  the SIOP creates an asymmetric key pair and encodes the public key as a 
JWK
  2.  the SIOP creates the JWK Thumbprint as described in [RFC7638] and 
converts it to a URI as described in [JONES],
  3.  the SIOP passes both the JWK and JWK Thumbprint URI to the RP in the JWT,
  4.  the RP extracts the JWK and JWK Thumbprint from the JWT
  5.  the RP re-computes the JWK Thumbprint from the JWK
  6.  the RP compares the computed JWK Thumbprint with the received JWK 
Thumbprint to confirm that they are equal.

One can see that the use of JWK Thumbprint URIs is both inefficient (in all 
cases) and a significant disadvantage (in some cases). If the JWK URI is 
transferred instead of the JWK and JWK Thumbprint URI then:

a) The SIOP will never need to create the JWK Thumbprint URI. The RP may only 
need to create the JWK Thumbprint if it needs this, for example, as a unique 
subject identifier. Even in this case, there is still an advantage to the RP in 
receiving the JWK URI instead of the JWK Thumprint URI, in that the RP no 
longer needs to pre-agree a hash

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[David Chadwick]

  
  
On 05/02/2022 17:46, Mike Jones wrote:


  
  
  
  
David, I believe your objections below are
  actually about the JWK Thumbprint [RFC 7638] computation used by
  this specification, and not the operation defined by this
  specification.  JWK Thumbprint became an RFC in 2015.
  

Hi Mike
no, my objection is to the JWK Thumbprint URI document. I accept
  that the JWK Thumbprint RFC already exists.
The aim of the SIOPv2 group is to transfer a public key as a URI,
  so it leverages the JWK Thumbprint RFC to do this. As I point out
  in my I-D, SIOPv2 transfers the public key and the public key
  thumbprint. My I-D suggests that we simply transfer the public key
  as a URI then no thumbprint computation is necessary by the
  SIOPv2. The recipient can compute its own thumbprint if it needs
  to by utilising the JWK Thumprint RFC and in this case no hashing
  algorithm needs to be jointly agreed upon.

Kind regards
David


  

 
This specification defines how to
  create a JWK Thumbprint URI by concatenating the URI prefix “urn:ietf:params:oauth:jwk-thumbprint”
  to an RFC 7638 JWK Thumbprint.  That’s all it does.  That’s
  why Rifaat’s statement “The JWK Thumbprint URI document is
a simple and straightforward specification” is indeed
  correct.
 
  
  Best wishes,
  
  -- Mike
 

  
From: OAuth
   On Behalf Of 
  David Chadwick
  Sent: Friday, February 4, 2022 9:55 AM
  To: oauth@ietf.org
  Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI
  document
  

 

  On 02/02/2022 12:18, Rifaat Shekh-Yusef
wrote:


  
All, 

   


  The JWK Thumbprint URI document
is a simple and straightforward specification.

  

Actually this is a complex and inefficient specification
  compared to other possibilities.
I have written an Internet-Draft outlining an alternative
  scheme, the JWK URI, which provides OIDC SIOPv2 with all the
  requirements that it needs with much less effort than
  implementing JWK Thumbprint URIs. I am currently formatting
  this I-D correctly to submit to the IETF. The rationale for
  this new Internet Draft is as follows.

  To produce or validate a
JWK Thumbprint, both the sender and the receiver have to
have the JWK available to them. Then they have to
canonicalise the JWK as described in [RFC7638], and finally
hash the octets of the UTF-8 representation of this JSON
object with a pre-agreed algorithm in order to both obtain
the same hash value. The way that the JWK Thumbprint URI is
used in SIOPv2 [SIOPv2] is as follows:

  
the SIOP creates an asymmetric key
  pair and encodes the public key as a JWK
  the SIOP creates the JWK Thumbprint
  as described in [RFC7638] and converts it to a URI as
  described in [JONES],
  the SIOP passes both the JWK and JWK
  Thumbprint URI to the RP in the JWT,
  the RP extracts the JWK and JWK
  Thumbprint from the JWT
  the RP re-computes the JWK Thumbprint
  from the JWK
  the RP compares the computed JWK
  Thumbprint with the received JWK Thumbprint to confirm
  that they are equal. 


  One can see that the use
of JWK Thumbprint URIs is both inefficient (in all cases)
and a significant disadvantage (in some cases). If the JWK
URI is transferred instead of the JWK and JWK Thumbprint URI
then:

  a) The SIOP will never
need to create the JWK Thumbprint URI. The RP may only need
to create the JWK Thumbprint if it needs this, for example,
as a unique subject identifier. Even in this case, there is
still an advantage to the RP in receiving the JWK URI
instead of the JWK Thumprint URI, in that the RP no longer
needs to pre-agree a hashing algorithm with the SIOP. Thus
the RP can independently determine which hashing algorithm
to use when creating its own JWK Thumbprint. (Note. If the
SIOP were able to canonicalise the same public key in a JWK
in different ways and produce different thumbprints

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Warren Parad]

Then perhaps what is in order is to replace 7638, before moving forward
with this one, that way we don't end up in state where implementations are
based on unnecessary complexity which isn't backwards compatible.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress <https://authress.io/>.


On Sat, Feb 5, 2022 at 6:47 PM Mike Jones  wrote:

> David, I believe your objections below are actually about the JWK
> Thumbprint [RFC 7638 <https://www.rfc-editor.org/rfc/rfc7638.html>]
> computation used by this specification, and not the operation defined by
> this specification.  JWK Thumbprint became an RFC in 2015.
>
>
>
> This specification
> <https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html>
> defines how to create a JWK Thumbprint URI by concatenating the URI prefix “
> urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.
> That’s all it does.  That’s why Rifaat’s statement “*The JWK Thumbprint
> URI document is a simple and straightforward specification*” is indeed
> correct.
>
>
>
>Best wishes,
>
>-- Mike
>
>
>
> *From:* OAuth  *On Behalf Of * David Chadwick
> *Sent:* Friday, February 4, 2022 9:55 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> Actually this is a complex and inefficient specification compared to other
> possibilities.
>
> I have written an Internet-Draft outlining an alternative scheme, the JWK
> URI, which provides OIDC SIOPv2 with all the requirements that it needs
> with much less effort than implementing JWK Thumbprint URIs. I am currently
> formatting this I-D correctly to submit to the IETF. The rationale for this
> new Internet Draft is as follows.
>
> To produce or validate a JWK Thumbprint, both the sender and the receiver
> have to have the JWK available to them. Then they have to canonicalise the
> JWK as described in [RFC7638], and finally hash the octets of the UTF-8
> representation of this JSON object with a pre-agreed algorithm in order to
> both obtain the same hash value. The way that the JWK Thumbprint URI is
> used in SIOPv2 [SIOPv2] is as follows:
>
>1. the SIOP creates an asymmetric key pair and encodes the public key
>as a JWK
>2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and
>converts it to a URI as described in [JONES],
>3. the SIOP passes both the JWK and JWK Thumbprint URI to the RP in
>the JWT,
>4. the RP extracts the JWK and JWK Thumbprint from the JWT
>5. the RP re-computes the JWK Thumbprint from the JWK
>6. the RP compares the computed JWK Thumbprint with the received JWK
>Thumbprint to confirm that they are equal.
>
> One can see that the use of JWK Thumbprint URIs is both inefficient (in
> all cases) and a significant disadvantage (in some cases). If the JWK URI
> is transferred instead of the JWK and JWK Thumbprint URI then:
>
> a) The SIOP will never need to create the JWK Thumbprint URI. The RP may
> only need to create the JWK Thumbprint if it needs this, for example, as a
> unique subject identifier. Even in this case, there is still an advantage
> to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in
> that the RP no longer needs to pre-agree a hashing algorithm with the SIOP.
> Thus the RP can independently determine which hashing algorithm to use when
> creating its own JWK Thumbprint. (Note. If the SIOP were able to
> canonicalise the same public key in a JWK in different ways and produce
> different thumbprints from the same public key, then the canonicalisation
> algorithm is broken, and the RP would never to able to deterministically
> produce the same thumbprints each time.)
>
> b) In those cases where the SIOP uses ephemeral key pairs and a different
> public key each time it communicates with an RP, then neither party needs
> to produce the JWK Thumbprint as it will never be seen again. It is a
> significant disadvantage to have to use JWK Thumbprints in this case.
>
> I therefore kindly request that the JWK Thumbprint URI document does not
> progress until the WG has had chance to compare and contrast the two
> methods.
>
> Kind regards
>
> David
>
>
>
>
>
> This is a WG Last Call for this document:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
>
>
> Please, provide your feedback on the mailin

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

David, I believe your objections below are actually about the JWK Thumbprint 
[RFC 7638<https://www.rfc-editor.org/rfc/rfc7638.html>] computation used by 
this specification, and not the operation defined by this specification.  JWK 
Thumbprint became an RFC in 2015.

This 
specification<https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html>
 defines how to create a JWK Thumbprint URI by concatenating the URI prefix 
“urn:ietf:params:oauth:jwk-thumbprint” to an RFC 7638 JWK Thumbprint.  That’s 
all it does.  That’s why Rifaat’s statement “The JWK Thumbprint URI document is 
a simple and straightforward specification” is indeed correct.

   Best wishes,
   -- Mike

From: OAuth  On Behalf Of David Chadwick
Sent: Friday, February 4, 2022 9:55 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
All,

The JWK Thumbprint URI document is a simple and straightforward specification.

Actually this is a complex and inefficient specification compared to other 
possibilities.

I have written an Internet-Draft outlining an alternative scheme, the JWK URI, 
which provides OIDC SIOPv2 with all the requirements that it needs with much 
less effort than implementing JWK Thumbprint URIs. I am currently formatting 
this I-D correctly to submit to the IETF. The rationale for this new Internet 
Draft is as follows.

To produce or validate a JWK Thumbprint, both the sender and the receiver have 
to have the JWK available to them. Then they have to canonicalise the JWK as 
described in [RFC7638], and finally hash the octets of the UTF-8 representation 
of this JSON object with a pre-agreed algorithm in order to both obtain the 
same hash value. The way that the JWK Thumbprint URI is used in SIOPv2 [SIOPv2] 
is as follows:

  1.  the SIOP creates an asymmetric key pair and encodes the public key as a 
JWK
  2.  the SIOP creates the JWK Thumbprint as described in [RFC7638] and 
converts it to a URI as described in [JONES],
  3.  the SIOP passes both the JWK and JWK Thumbprint URI to the RP in the JWT,
  4.  the RP extracts the JWK and JWK Thumbprint from the JWT
  5.  the RP re-computes the JWK Thumbprint from the JWK
  6.  the RP compares the computed JWK Thumbprint with the received JWK 
Thumbprint to confirm that they are equal.

One can see that the use of JWK Thumbprint URIs is both inefficient (in all 
cases) and a significant disadvantage (in some cases). If the JWK URI is 
transferred instead of the JWK and JWK Thumbprint URI then:

a) The SIOP will never need to create the JWK Thumbprint URI. The RP may only 
need to create the JWK Thumbprint if it needs this, for example, as a unique 
subject identifier. Even in this case, there is still an advantage to the RP in 
receiving the JWK URI instead of the JWK Thumprint URI, in that the RP no 
longer needs to pre-agree a hashing algorithm with the SIOP. Thus the RP can 
independently determine which hashing algorithm to use when creating its own 
JWK Thumbprint. (Note. If the SIOP were able to canonicalise the same public 
key in a JWK in different ways and produce different thumbprints from the same 
public key, then the canonicalisation algorithm is broken, and the RP would 
never to able to deterministically produce the same thumbprints each time.)

b) In those cases where the SIOP uses ephemeral key pairs and a different 
public key each time it communicates with an RP, then neither party needs to 
produce the JWK Thumbprint as it will never be seen again. It is a significant 
disadvantage to have to use JWK Thumbprints in this case.

I therefore kindly request that the JWK Thumbprint URI document does not 
progress until the WG has had chance to compare and contrast the two methods.

Kind regards

David



This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes





___

OAuth mailing list

OAuth@ietf.org<mailto: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] WGLC for JWK Thumbprint URI document

[David Waite]

> On Feb 4, 2022, at 6:32 PM, Mike Jones 
>  wrote:
> 
> Kristina and I spoke about it today and we agreed that it makes sense to make 
> the hash algorithm explicit.  So for instance, we’d propose that the example
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
> become
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
> when using the SHA-256 hash function.
>  
> Similarly, we’d propose to also define S384, S512, and possibly also S3-256, 
> S3-384, and S3-512 (for the SHA-3 hash functions).

My ideal would be making the algorithm explicit in the name, while deferring 
establishing a registry of other algorithms until a technical need is 
established.

While it is not necessary that a URN namespace define a unique name for a 
resource, it is a useful property that would be lost with multiple hashing 
schemes. Use of a hashing scheme not supported by a piece of software would 
also mean that there is no way to verify the name corresponds to a given 
resource.

For this reason, if we do support multiple algorithms I would expect a mandate 
in dependent specs and systems that mandate a specific one or a specific set. 
For example, they may exclude the Kekkak variants (SHA3, SHAKE) as there are no 
other algorithms registered for JOSE which depend upon them.

>  
> For extra credit, if there’s already an IANA registry with string names for 
> these hash functions, we’d consider using it.  I looked for one and 
> surprisingly didn’t find it.  Or we could create one.
>  

The COSE algorithms are declared with both numbers and names, and include 
hashes as algorithms.

https://www.iana.org/assignments/cose/cose.xhtml#algorithms

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

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Aaron Parecki]

That doesn't have the literal string "S256", only the full name.


On Fri, Feb 4, 2022 at 6:02 PM Brian Campbell  wrote:

> I think
> https://www.iana.org/assignments/named-information/named-information.xhtml
> maybe has what you're looking for.
>
> On Fri, Feb 4, 2022, 6:33 PM Mike Jones  40microsoft@dmarc.ietf.org> wrote:
>
>> Kristina and I spoke about it today and we agreed that it makes sense to
>> make the hash algorithm explicit.  So for instance, we’d propose that the
>> example
>>
>>
>> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> become
>>
>>
>> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>>
>> when using the SHA-256 hash function.
>>
>>
>>
>> Similarly, we’d propose to also define S384, S512, and possibly also
>> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>>
>>
>>
>> For extra credit, if there’s already an IANA registry with string names
>> for these hash functions, we’d consider using it.  I looked for one and
>> surprisingly didn’t find it.  Or we could create one.
>>
>>
>>
>>Thanks all,
>>
>>                    -- Mike & Kristina
>>
>>
>>
>> *From:* OAuth  *On Behalf Of * Mike Jones
>> *Sent:* Friday, February 4, 2022 7:30 AM
>> *To:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>>
>>
>>
>> Neil, thanks for your review.  First, you wrote:
>>
>>
>>
>> > Using a (hash of a) public key as an identifier is an idea that has
>> historically been subject to various attacks such as unknown key share
>> attacks, as well as issues due to malleable signature schemes or key
>> exchange schemes - where the same proof of identity is valid under many
>> public keys. The security considerations should mention these issues, and
>> potential suggest countermeasures (eg including the full public key JWK in
>> the input to be signed etc).
>>
>>
>>
>> I’m not all that familiar with the attacks you’re referencing.  Is there
>> I write-up on them that you could refer me and the other working group
>> members to so we can better understand them?  And ideally, could you write
>> up a paragraph or two on them that you’d like us to include in the Security
>> Considerations?
>>
>>
>>
>> Second, you asked that the hash algorithm be made explicit, as did
>> Vladimir.  I’ll consult with Kristina on that today and respond to that
>> suggestion in a subsequent message.
>>
>>
>>
>>Thanks again,
>>
>>-- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
>> *Sent:* Thursday, February 3, 2022 11:00 PM
>> *To:* oauth@ietf.org
>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>>
>>
>>
>> The original JWK thumbprint RFC 7638 essentially describes the method for
>> composing the hash input from a JWK and that the output is base64url
>> encoded. SHA-256 is mentioned, but there is no default implied hash
>> function. This leaves it to applications / other specs to determine.
>>
>> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>>
>> The URN gives us now a natural possibility to encode the hash function
>> alongside the fact that it's a JWK thumbprint, so let's include it. This
>> will make things more explicit and self-contained.
>>
>> What do the authors think about this possibility?
>>
>> ~Vladimir
>>
>> Vladimir Dzhuvinov
>>
>> On 04/02/2022 01:47, Neil Madden wrote:
>>
>> The draft doesn’t specify which hash function is being used. I assume it
>> is SHA-256, but it should either say that is the only algorithm allowed or
>> perhaps encode the hash algorithm into the URI. Otherwise the value is
>> ambiguous.
>>
>>
>>
>> Using a (hash of a) public key as an identifier is an idea that has
>> historically been subject to various attacks such as unknown key share
>> attacks, as well as issues due to malleable signature schemes or key
>> exchange schemes - where the same proof of identity is valid under many
>> public keys. The security considerations should mention these issues, and
>> poten

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Brian Campbell]

I think
https://www.iana.org/assignments/named-information/named-information.xhtml
maybe has what you're looking for.

On Fri, Feb 4, 2022, 6:33 PM Mike Jones  wrote:

> Kristina and I spoke about it today and we agreed that it makes sense to
> make the hash algorithm explicit.  So for instance, we’d propose that the
> example
>
>
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> become
>
>
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> when using the SHA-256 hash function.
>
>
>
> Similarly, we’d propose to also define S384, S512, and possibly also
> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>
>
>
> For extra credit, if there’s already an IANA registry with string names
> for these hash functions, we’d consider using it.  I looked for one and
> surprisingly didn’t find it.  Or we could create one.
>
>
>
>Thanks all,
>
>-- Mike & Kristina
>
>
>
> *From:* OAuth  *On Behalf Of * Mike Jones
> *Sent:* Friday, February 4, 2022 7:30 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>
>
>
> Neil, thanks for your review.  First, you wrote:
>
>
>
> > Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> I’m not all that familiar with the attacks you’re referencing.  Is there I
> write-up on them that you could refer me and the other working group
> members to so we can better understand them?  And ideally, could you write
> up a paragraph or two on them that you’d like us to include in the Security
> Considerations?
>
>
>
> Second, you asked that the hash algorithm be made explicit, as did
> Vladimir.  I’ll consult with Kristina on that today and respond to that
> suggestion in a subsequent message.
>
>
>
>Thanks again,
>
>                    -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
> *Sent:* Thursday, February 3, 2022 11:00 PM
> *To:* oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> The original JWK thumbprint RFC 7638 essentially describes the method for
> composing the hash input from a JWK and that the output is base64url
> encoded. SHA-256 is mentioned, but there is no default implied hash
> function. This leaves it to applications / other specs to determine.
>
> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>
> The URN gives us now a natural possibility to encode the hash function
> alongside the fact that it's a JWK thumbprint, so let's include it. This
> will make things more explicit and self-contained.
>
> What do the authors think about this possibility?
>
> ~Vladimir
>
> Vladimir Dzhuvinov
>
> On 04/02/2022 01:47, Neil Madden wrote:
>
> The draft doesn’t specify which hash function is being used. I assume it
> is SHA-256, but it should either say that is the only algorithm allowed or
> perhaps encode the hash algorithm into the URI. Otherwise the value is
> ambiguous.
>
>
>
> Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> — Neil
>
>
>
> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
>  wrote:
>
> 
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
>
>
> This is a WG Last Call for this document:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
>
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
>
>
> _

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Aaron Parecki]

I don't think this is actually the best place to reference, but S256
already exists in the registry established by RFC7636 (PKCE):

https://datatracker.ietf.org/doc/html/rfc7636#section-6.2
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#pkce-code-challenge-method

The other place these similar strings appear are FIDO, which also
references PKCE for the naming convention:

https://fidoalliance.org/specs/fido-v2.0-ps-20150904/fido-signature-format-v2.0-ps-20150904.html#iana-considerations

I thought I had remembered these strings being defined somewhere in NIST,
but I can't find that reference anymore.

Maybe it does make sense to establish this registry in the OAuth WG that
could be referenced by any related spec that needs them? OAuth 2.1 could
reference it as well.

Aaron



On Fri, Feb 4, 2022 at 5:33 PM Mike Jones  wrote:

> Kristina and I spoke about it today and we agreed that it makes sense to
> make the hash algorithm explicit.  So for instance, we’d propose that the
> example
>
>
> urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> become
>
>
> urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
>
> when using the SHA-256 hash function.
>
>
>
> Similarly, we’d propose to also define S384, S512, and possibly also
> S3-256, S3-384, and S3-512 (for the SHA-3 hash functions).
>
>
>
> For extra credit, if there’s already an IANA registry with string names
> for these hash functions, we’d consider using it.  I looked for one and
> surprisingly didn’t find it.  Or we could create one.
>
>
>
>Thanks all,
>
>-- Mike & Kristina
>
>
>
> *From:* OAuth  *On Behalf Of * Mike Jones
> *Sent:* Friday, February 4, 2022 7:30 AM
> *To:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>
>
>
> Neil, thanks for your review.  First, you wrote:
>
>
>
> > Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> potential suggest countermeasures (eg including the full public key JWK in
> the input to be signed etc).
>
>
>
> I’m not all that familiar with the attacks you’re referencing.  Is there I
> write-up on them that you could refer me and the other working group
> members to so we can better understand them?  And ideally, could you write
> up a paragraph or two on them that you’d like us to include in the Security
> Considerations?
>
>
>
> Second, you asked that the hash algorithm be made explicit, as did
> Vladimir.  I’ll consult with Kristina on that today and respond to that
> suggestion in a subsequent message.
>
>
>
>Thanks again,
>
>                    -- Mike
>
>
>
> *From:* OAuth  *On Behalf Of *Vladimir Dzhuvinov
> *Sent:* Thursday, February 3, 2022 11:00 PM
> *To:* oauth@ietf.org
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
>
>
>
> The original JWK thumbprint RFC 7638 essentially describes the method for
> composing the hash input from a JWK and that the output is base64url
> encoded. SHA-256 is mentioned, but there is no default implied hash
> function. This leaves it to applications / other specs to determine.
>
> https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4
>
> The URN gives us now a natural possibility to encode the hash function
> alongside the fact that it's a JWK thumbprint, so let's include it. This
> will make things more explicit and self-contained.
>
> What do the authors think about this possibility?
>
> ~Vladimir
>
> Vladimir Dzhuvinov
>
> On 04/02/2022 01:47, Neil Madden wrote:
>
> The draft doesn’t specify which hash function is being used. I assume it
> is SHA-256, but it should either say that is the only algorithm allowed or
> perhaps encode the hash algorithm into the URI. Otherwise the value is
> ambiguous.
>
>
>
> Using a (hash of a) public key as an identifier is an idea that has
> historically been subject to various attacks such as unknown key share
> attacks, as well as issues due to malleable signature schemes or key
> exchange schemes - where the same proof of identity is valid under many
> public keys. The security considerations should mention these issues, and
> pot

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

Kristina and I spoke about it today and we agreed that it makes sense to make 
the hash algorithm explicit.  So for instance, we’d propose that the example
urn:ietf:params:oauth:jwk-thumbprint:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
become
urn:ietf:params:oauth:jwk-thumbprint:S256:NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
when using the SHA-256 hash function.

Similarly, we’d propose to also define S384, S512, and possibly also S3-256, 
S3-384, and S3-512 (for the SHA-3 hash functions).

For extra credit, if there’s already an IANA registry with string names for 
these hash functions, we’d consider using it.  I looked for one and 
surprisingly didn’t find it.  Or we could create one.

   Thanks all,
   -- Mike & Kristina

From: OAuth  On Behalf Of Mike Jones
Sent: Friday, February 4, 2022 7:30 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document

Neil, thanks for your review.  First, you wrote:

> Using a (hash of a) public key as an identifier is an idea that has 
> historically been subject to various attacks such as unknown key share 
> attacks, as well as issues due to malleable signature schemes or key exchange 
> schemes - where the same proof of identity is valid under many public keys. 
> The security considerations should mention these issues, and potential 
> suggest countermeasures (eg including the full public key JWK in the input to 
> be signed etc).

I’m not all that familiar with the attacks you’re referencing.  Is there I 
write-up on them that you could refer me and the other working group members to 
so we can better understand them?  And ideally, could you write up a paragraph 
or two on them that you’d like us to include in the Security Considerations?

Second, you asked that the hash algorithm be made explicit, as did Vladimir.  
I’ll consult with Kristina on that today and respond to that suggestion in a 
subsequent message.

   Thanks again,
   -- Mike

From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf 
Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: oauth@ietf.org<mailto:oauth@ietf.org>
Subject: [EXTERNAL] Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


The original JWK thumbprint RFC 7638 essentially describes the method for 
composing the hash input from a JWK and that the output is base64url encoded. 
SHA-256 is mentioned, but there is no default implied hash function. This 
leaves it to applications / other specs to determine.

https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This will 
make things more explicit and self-contained.

What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov
On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous.

Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share attacks, 
as well as issues due to malleable signature schemes or key exchange schemes - 
where the same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc).

— Neil

On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef 
<mailto:rifaat.s.i...@gmail.com> wrote:

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


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


___

OAuth mailing list

OAuth@ietf.org<mailto: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] WGLC for JWK Thumbprint URI document

[Warren Parad]

I also agree that there hasn't been sufficient review of this document to
warrant progressing it.

Warren Parad

Founder, CTO
Secure your user data with IAM authorization as a service. Implement
Authress .


On Fri, Feb 4, 2022 at 6:56 PM David Chadwick <
d.w.chadw...@verifiablecredentials.info> wrote:

> On 02/02/2022 12:18, Rifaat Shekh-Yusef wrote:
>
> All,
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
> Actually this is a complex and inefficient specification compared to other
> possibilities.
>
> I have written an Internet-Draft outlining an alternative scheme, the JWK
> URI, which provides OIDC SIOPv2 with all the requirements that it needs
> with much less effort than implementing JWK Thumbprint URIs. I am currently
> formatting this I-D correctly to submit to the IETF. The rationale for this
> new Internet Draft is as follows.
>
> To produce or validate a JWK Thumbprint, both the sender and the receiver
> have to have the JWK available to them. Then they have to canonicalise the
> JWK as described in [RFC7638], and finally hash the octets of the UTF-8
> representation of this JSON object with a pre-agreed algorithm in order to
> both obtain the same hash value. The way that the JWK Thumbprint URI is
> used in SIOPv2 [SIOPv2] is as follows:
>
>1. the SIOP creates an asymmetric key pair and encodes the public key
>as a JWK
>2. the SIOP creates the JWK Thumbprint as described in [RFC7638] and
>converts it to a URI as described in [JONES],
>3. the SIOP passes both the JWK and JWK Thumbprint URI to the RP in
>the JWT,
>4. the RP extracts the JWK and JWK Thumbprint from the JWT
>5. the RP re-computes the JWK Thumbprint from the JWK
>6. the RP compares the computed JWK Thumbprint with the received JWK
>Thumbprint to confirm that they are equal.
>
> One can see that the use of JWK Thumbprint URIs is both inefficient (in
> all cases) and a significant disadvantage (in some cases). If the JWK URI
> is transferred instead of the JWK and JWK Thumbprint URI then:
>
> a) The SIOP will never need to create the JWK Thumbprint URI. The RP may
> only need to create the JWK Thumbprint if it needs this, for example, as a
> unique subject identifier. Even in this case, there is still an advantage
> to the RP in receiving the JWK URI instead of the JWK Thumprint URI, in
> that the RP no longer needs to pre-agree a hashing algorithm with the SIOP.
> Thus the RP can independently determine which hashing algorithm to use when
> creating its own JWK Thumbprint. (Note. If the SIOP were able to
> canonicalise the same public key in a JWK in different ways and produce
> different thumbprints from the same public key, then the canonicalisation
> algorithm is broken, and the RP would never to able to deterministically
> produce the same thumbprints each time.)
>
> b) In those cases where the SIOP uses ephemeral key pairs and a different
> public key each time it communicates with an RP, then neither party needs
> to produce the JWK Thumbprint as it will never be seen again. It is a
> significant disadvantage to have to use JWK Thumbprints in this case.
>
> I therefore kindly request that the JWK Thumbprint URI document does not
> progress until the WG has had chance to compare and contrast the two
> methods.
>
> Kind regards
>
> David
>
>
>
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
> Regards,
>  Rifaat & Hannes
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://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] WGLC for JWK Thumbprint URI document

[David Chadwick]

  
  
On 02/02/2022 12:18, Rifaat Shekh-Yusef
  wrote:


  
  All,


The JWK Thumbprint URI document is a simple and
  straightforward specification.
  

Actually this is a complex and inefficient specification compared
  to other possibilities.
I have written an Internet-Draft outlining an alternative scheme,
  the JWK URI, which provides OIDC SIOPv2 with all the requirements
  that it needs with much less effort than implementing JWK
  Thumbprint URIs. I am currently formatting this I-D correctly to
  submit to the IETF. The rationale for this new Internet Draft is
  as follows.

To produce
  or validate a JWK Thumbprint, both the sender and the receiver
  have to have the JWK available to them. Then they have to
  canonicalise the JWK as described in [RFC7638], and finally
  hash the octets of the UTF-8 representation of this JSON
  object with a pre-agreed algorithm in order to both obtain the
  same hash value. The way that the JWK Thumbprint URI is used in
  SIOPv2 [SIOPv2] is as follows:

  the SIOP creates an asymmetric
key pair and encodes the public key as a JWK
  the SIOP creates
the JWK Thumbprint as described in [RFC7638] and converts it to
a URI as described in [JONES],
  the SIOP passes
both the JWK and JWK Thumbprint URI to the RP in the JWT,
  the RP extracts
the JWK and JWK Thumbprint from the JWT
  the RP re-computes
the JWK Thumbprint from the JWK
  the RP compares
the computed JWK Thumbprint with the received JWK Thumbprint to
confirm that they are equal. 

One can
  see that the use of JWK Thumbprint URIs is both inefficient (in
  all cases) and a significant disadvantage (in some cases). If the
  JWK URI is transferred instead of the JWK and JWK Thumbprint URI
  then:
a) The
  SIOP will never need to create the JWK Thumbprint URI. The RP may
  only need to create the JWK Thumbprint if it needs this, for
  example, as a unique subject identifier. Even in this case, there
  is still an advantage to the RP in receiving the JWK URI instead
  of the JWK Thumprint URI, in that the RP no longer needs to
  pre-agree a hashing algorithm with the SIOP. Thus the RP can
  independently determine which hashing algorithm to use when
  creating its own JWK Thumbprint. (Note. If the SIOP were able to
  canonicalise the same public key in a JWK in different ways and
  produce different thumbprints from the same public key, then the
  canonicalisation algorithm is broken, and the RP would never to
  able to deterministically produce the same thumbprints each time.)
b) In
  those cases where the SIOP uses ephemeral key pairs and a
  different public key each time it communicates with an RP, then
  neither party needs to produce the JWK Thumbprint as it will never
  be seen again. It is a significant disadvantage to have to use JWK
  Thumbprints in this case.
I therefore kindly request that the JWK Thumbprint URI document
  does not progress until the WG has had chance to compare and
  contrast the two methods.
Kind regards
David



  


This is a WG Last Call for this document:

https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html



Please, provide your feedback on the mailing list by Feb
16th.


Regards,
 Rifaat & Hannes




  
  
  
  ___
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] WGLC for JWK Thumbprint URI document

[Vladimir Dzhuvinov]

The original JWK thumbprint RFC 7638 essentially describes the method 
for composing the hash input from a JWK and that the output is base64url 
encoded. SHA-256 is mentioned, but there is no default implied hash 
function. This leaves it to applications / other specs to determine.


https://www.rfc-editor.org/rfc/rfc7638.html#section-3.4

The URN gives us now a natural possibility to encode the hash function 
alongside the fact that it's a JWK thumbprint, so let's include it. This 
will make things more explicit and self-contained.


What do the authors think about this possibility?

~Vladimir

Vladimir Dzhuvinov

On 04/02/2022 01:47, Neil Madden wrote:
The draft doesn’t specify which hash function is being used. I assume 
it is SHA-256, but it should either say that is the only algorithm 
allowed or perhaps encode the hash algorithm into the URI. Otherwise 
the value is ambiguous.


Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share 
attacks, as well as issues due to malleable signature schemes or key 
exchange schemes - where the same proof of identity is valid under 
many public keys. The security considerations should mention these 
issues, and potential suggest countermeasures (eg including the full 
public key JWK in the input to be signed etc).


— Neil

On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef  
wrote:



All,

The *JWK Thumbprint URI *document is a simple and 
straightforward specification.


This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by *Feb 16th*.

Regards,
 Rifaat & Hannes


___
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] WGLC for JWK Thumbprint URI document

[Neil Madden]

The draft doesn’t specify which hash function is being used. I assume it is 
SHA-256, but it should either say that is the only algorithm allowed or perhaps 
encode the hash algorithm into the URI. Otherwise the value is ambiguous. 

Using a (hash of a) public key as an identifier is an idea that has 
historically been subject to various attacks such as unknown key share attacks, 
as well as issues due to malleable signature schemes or key exchange schemes - 
where the same proof of identity is valid under many public keys. The security 
considerations should mention these issues, and potential suggest 
countermeasures (eg including the full public key JWK in the input to be signed 
etc). 

— Neil

> On 2 Feb 2022, at 12:19, Rifaat Shekh-Yusef  wrote:
> 
> 
> All,
> 
> The JWK Thumbprint URI document is a simple and straightforward specification.
> 
> This is a WG Last Call for this document:
> https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html
> 
> Please, provide your feedback on the mailing list by Feb 16th.
> 
> Regards,
>  Rifaat & Hannes
> 
> 
> ___
> 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] WGLC for JWK Thumbprint URI document

[Tim Cappalli]

I support publication of JWK Thumbprint URI specification.

Tim

From: OAuth  on behalf of Kristina Yasuda 

Date: Thursday, February 3, 2022 at 17:48
To: Vladimir Dzhuvinov , oauth@ietf.org 

Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document
I support publication of JWK Thumbprint URI specification.
Kristina


From: OAuth  On Behalf Of Vladimir Dzhuvinov
Sent: Wednesday, February 2, 2022 7:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


+1 in support for a jkt URI RFC

Vladimir Dzhuvinov
On 02/02/2022 16:50, Mike Jones wrote:
Thanks Rifaat,

I support publication of the specification.

   -- Mike

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth <mailto:oauth@ietf.org>
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7Ctim.cappalli%40microsoft.com%7C4241e68c33e3497d951908d9e7672b2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637795253052338639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Ju7SN44Rcu9Uzhk%2BQMHfbhX97rtbjUQfLhq09YufUgU%3D=0>

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes






___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=04%7C01%7Ctim.cappalli%40microsoft.com%7C4241e68c33e3497d951908d9e7672b2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637795253052338639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=hnnW%2FwYy3E2oHRKe%2BfLWlgiBXeWBUbHUwXH8LSjrCN4%3D=0>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Kristina Yasuda]

I support publication of JWK Thumbprint URI specification.
Kristina


From: OAuth  On Behalf Of Vladimir Dzhuvinov
Sent: Wednesday, February 2, 2022 7:20 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document


+1 in support for a jkt URI RFC

Vladimir Dzhuvinov
On 02/02/2022 16:50, Mike Jones wrote:
Thanks Rifaat,

I support publication of the specification.

   -- Mike

From: OAuth <mailto:oauth-boun...@ietf.org> On Behalf 
Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth <mailto:oauth@ietf.org>
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-jwk-thumbprint-uri-00.html=04%7C01%7CKristina.Yasuda%40microsoft.com%7C00c30138b2a644eeb38808d9e65f9f96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794121813619547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=byFDOBUW44tcb5ZC9b4oqn7lpFrL9dFSDEdvWNP4%2FyY%3D=0>

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes





___

OAuth mailing list

OAuth@ietf.org<mailto:OAuth@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=04%7C01%7CKristina.Yasuda%40microsoft.com%7C00c30138b2a644eeb38808d9e65f9f96%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637794121813619547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=JK%2BeAf6bm0OzDNrdOkFQDvJbV8hVHSqH%2BLpGCjsN2Wc%3D=0>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Vladimir Dzhuvinov]

+1 in support for a jkt URI RFC

Vladimir Dzhuvinov

On 02/02/2022 16:50, Mike Jones wrote:


Thanks Rifaat,

I support publication of the specification.

-- Mike

*From:* OAuth  *On Behalf Of * Rifaat Shekh-Yusef
*Sent:* Wednesday, February 2, 2022 4:19 AM
*To:* oauth 
*Subject:* [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The *JWK Thumbprint URI *document is a simple and 
straightforward specification.


This is a WG Last Call for this document:

https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by *Feb 16th*.

Regards,

 Rifaat & Hannes


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

smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

[Mike Jones]

Thanks Rifaat,

I support publication of the specification.

   -- Mike

From: OAuth  On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, February 2, 2022 4:19 AM
To: oauth 
Subject: [OAUTH-WG] WGLC for JWK Thumbprint URI document

All,

The JWK Thumbprint URI document is a simple and straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by Feb 16th.

Regards,
 Rifaat & Hannes


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

[OAUTH-WG] WGLC for JWK Thumbprint URI document

[Rifaat Shekh-Yusef]

All,

The *JWK Thumbprint URI *document is a simple and
straightforward specification.

This is a WG Last Call for this document:
https://www.ietf.org/archive/id/draft-ietf-oauth-jwk-thumbprint-uri-00.html

Please, provide your feedback on the mailing list by *Feb 16th*.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth