On May 11, 2022, at 6:45 AM, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com> wrote:
> On Wed, May 11, 2022 at 4:53 AM David Waite <da...@alkaline-solutions.com
> <mailto:da...@alkaline-solutions.com>> wrote:
> The information dropping of the canonicalization in JWK thumbprints results
> in a few important properties - in particular, a local JWK document
> representing a private key and the shared JWK document representing the
> corresponding public key will have the same thumbprint.
>
> Can you elaborate on this? how would two different documents produce the same
> hash?
Sure. In terms of named information, we could refer to an instance of a JWK
that has had the thumbprint canonicalization rules partially applied to it,
such that it would refer to a valid JWK with the identical hash of the JWK
thumbprint.
However, a named information is meant to refer to a specific resource with a
specific series of bytes. This ni-scheme URI would refer only to the resource
that is that specific canonicalized JWK, with certain information stripped.
In the semantics of a JWK thumbprint however, the hash refers to an infinite
set of documents that might have different JSON serialization order,
whitespace, and/or additional optional JWK fields (including potentially the
private key information.) The JWK thumbprint is meant to serve as a common
identifying value by all parties to a particular logical key. JWK Thumbprint
URI simply provide a common scheme for expressing that identifier as a URI.
So, the resolving a named information URI is defined to give you a particular
binary entity representation, while resolving a thumbprint will give you one of
possibly many object representations that share certain cryptographic
properties. Thus I don’t feel it is appropriate to use the same URI scheme to
represent both, even though they are potentially isomorphic data forms - we
would be using ni-scheme URI as a hash value container rather than for the
defined named information semantics.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
