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