Re: [Privacy-pass] Issuer directory representation (#369)

[Colin Bendell <[e-mail]>]

For reference, I have a few examples using the publicly available keys.

Here is cloudflare's demo issuery directory:
*
https://github.com/colinbendell/private-access-token/blob/main/demo-pat.issuer.cloudflare.com.json

And the same in jwks format (nb: I've set "kid" to the
"truncated_token_key_id" value instead of preserving "version")
*
https://github.com/colinbendell/private-access-token/blob/main/demo-pat.issuer.cloudflare.com.json

You can find others in the repo as well.

On Fri, 9 Jun 2023 at 16:13, Colin Bendell <[e-mail]> wrote:

> The argument for JWK is that it reduces the sprawl of directory syntaxes
> and allows the devs to lean on pre-existing tooling and documentation. JWKS
> does have extensibility built into the RFC to be adapted for this purpose.
>
> The main advantages for using JWKS are:
> 1. we don't need to introduce a new iana for algorithm types.
> issuer-type=2 is the same as alg="PS384". This will further allow for
> future expansion and key selection
>
> 2. adopting a consistent standard leverages existing dev and infra tools
> around the jwk and jwks ecosystem. Particularly for key store loading,
> rotating and management. This is particularly important if aligning
> Private-State-Tokens is a goal of Privacy Pass. With PST, the UA is
> expected to consume these public key stores.
>
> 3. Since it uses the expanded form, and not DER encoded, it sidesteps some
> of the awkwardness of the dev ecosystem for RSASSA-PSS. Most of the
> RSASSA-PSS implementations are spotty which is why WebCrypto has dropped
> support [1]. Converting between RSASSA-PSS and RSA is a bit messy [2] in
> the DER encoded form, it's much more straightforward with the JWK since the
> modulus and exponent are already expanded.
>
> 4. The syntax for JWK already has extensions to pre-calculate the
> token-key-id (see: "x5t#S256" [3]). This is an optimization that can be
> done server side or on origin startup, having it available in a
> materialized form has some convenience advantages.
>
> There are disadvantages as well, which are worth expanding:
> 1. The syntax is terse. it does take a special decoder ring to decipher
> the fields. Likewise, the fields are in expanded form instead of
> encapsulating in DER format. (This is done so that you can very quickly
> sanitize a JWK and remove the secret key fields without having to
> re-encode.)
>
> 2. We would still need to define the iana values to expand JWKS for fields
> like 'issuer-request-uri" or "issuer-name" (for PST), etc. Other fields
> that are already common in the public issuer identifiers [4], like
> 'not-before' and 'version' do have corrolories in JWKS.
>
> 3. While convenient to have the components of the key in expanded form, we
> still need to convert it to the DER encoded form for the purposes of
> Privacy-Pass - specifically for token-key and token-key-id fields.
>
> [1] https://github.com/w3c/webcrypto/pull/325
> [2]
> https://github.com/colinbendell/private-access-token/blob/main/src/utils.js#L382-L395
> [3] https://datatracker.ietf.org/doc/html/rfc7517#section-4.9
> [4]
> https://demo-pat.issuer.cloudflare.com/.well-known/token-issuer-directory
>
> On Fri, 9 Jun 2023 at 06:28, Eli-Shaoul Khedouri <eli=
> [e-mail]> wrote:
>
>> I do not see a benefit to adopting JWKs at this stage. As you say, they
>> are somewhat complex for the PP use case.
>>
>> Eli
>>
>> On Thu, Jun 8, 2023 at 5:30 PM Christopher Wood <[e-mail]>
>> wrote:
>>
>>> Colin filed #369 [1] to discuss the current representation we are
>>> currently using for issuer directories. Basically, Privacy Pass chose to
>>> introduce a new representation that bears resemblance to that which is used
>>> in Private State Tokens [2] and is already specified in JSON Web Key Sets
>>> [3]. We should sort out what to do with this discrepancy.
>>>
>>> Speaking for myself, neither a JWK or JWT expert, I think we should
>>> stick with what's currently in the draft because (1) all formats seem
>>> mostly isomorphic and (2) JWKS are, to my knowledge, meant primarily for
>>> JWTs. Moreover, the way that keys are represented seems unnecessarily
>>> complex. Why do we need to specify any of the "kty", "alg", or "kid"
>>> parameters when they can be inferred from the token type and public key?
>>>
>>> Note that this is primarily relevant for origins that consume the
>>> directory and use it for the purposes of challenging clients, but it may in
>>> the future become relevant for clients that want to consume this resource
>>> for consistency checking purposes.
>>>
>>> What do others think?
>>>
>>> Best,
>>> Chris
>>>
>>> [1] https://github.com/ietf-wg-privacypass/base-drafts/issues/369
>>> [2] https://github.com/WICG/trust-token-api/blob/main/ISSUER_PROTOCOL.md
>>> [3] https://datatracker.ietf.org/doc/html/rfc7517
>>>
>>> --
>>> Privacy-pass mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>
>> --
>> Privacy-pass mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>
>