That doesn't have the literal string "S256", only the full name.
On Fri, Feb 4, 2022 at 6:02 PM Brian Campbell <bcampbell= 40pingidentity....@dmarc.ietf.org> 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 <Michael.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 <oauth-boun...@ietf.org> *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 <oauth-boun...@ietf.org> *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 <rifaat.s.i...@gmail.com> >> <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 >> 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 >> > > *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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
