> On Feb 4, 2022, at 6:32 PM, Mike Jones > <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
