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

From: Mike Jones <[email-masked]>
Date: Sat, 5 Feb 2022 01:32:55 +0000

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 <[email-masked]> On Behalf Of Mike Jones
Sent: Friday, February 4, 2022 7:30 AM
To: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Vladimir Dzhuvinov
Sent: Thursday, February 3, 2022 11:00 PM
To: [email-masked]<mailto:[email-masked]>
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 <[email-masked]><mailto:[email-masked]> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 4 Feb 2022 17:48:24 -0800

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 <Michael.Jones=
[email-masked]> 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
>
>
> 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 <[email-masked]> *On Behalf Of * Mike Jones
> *Sent:* Friday, February 4, 2022 7:30 AM
> *To:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Re: WGLC for JWK Thumbprint URI document
>
>
>
> > 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 <[email-masked]> *On Behalf Of *Vladimir Dzhuvinov
> *Sent:* Thursday, February 3, 2022 11:00 PM
> *To:* [email-masked]
> *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.
>
> 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.
>
> 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 <[email-masked]>
> <[email-masked]> wrote:
>
> 
>
> All,
>
>
>
> The *JWK Thumbprint URI *document is a simple and
> straightforward specification.
>
>
>
> Please, provide your feedback on the mailing list by *Feb 16th*.
>
>
>
> Regards,
>
>  Rifaat & Hannes
>
>
>
>
>
> [email-masked]
> [email-masked]
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Feb 2022 19:01:29 -0700

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

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 4 Feb 2022 18:03:17 -0800

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

On Fri, Feb 4, 2022 at 6:02 PM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> 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
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: David Waite <[email-masked]>
Date: Fri, 4 Feb 2022 19:16:52 -0700

> On Feb 4, 2022, at 6:32 PM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 

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

---

From: Kristina Yasuda <[email-masked]>
Date: Mon, 7 Feb 2022 20:54:27 +0000

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 <[email-masked]> On Behalf Of David Waite
Sent: Friday, February 4, 2022 6:17 PM
To: Mike Jones <Michael.Jones=[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] WGLC for JWK Thumbprint URI document

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

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcose%2Fcose.xhtml%23algorithms&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C6efedfb5f6f745813e5f08d9e84da05d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637796242424613801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=S7XBsB8pokg2Vd2aDRsvdu8MwqW1CLCy8WR31IwBrsY%3D&amp;reserved=0

-DW
_______________________________________________
OAuth mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=04%7C01%7CKristina.Yasuda%40microsoft.com%7C6efedfb5f6f745813e5f08d9e84da05d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637796242424613801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DSwK90M9dF2dtVnALFI7jTwzP%2BCCXS7WEH3FrENqK4Y%3D&amp;reserved=0