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

[Tommy Pauly <[e-mail]>]

> On Jun 9, 2023, at 1:14 PM, Colin Bendell <[e-mail]> wrote:
> 
> 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

I believe this link should be this, right?

https://github.com/colinbendell/private-access-token/blob/main/demo-pat.issuer.cloudflare.com.jwks.json

Overall, while I’m not opposed to JWK being defined at some point, I don’t think it simplifies things for privacy pass, and this proposal is missing key pieces of information like the token type, and isn’t consistent with the formats clients would commonly see in HTTP auth challenges. Defining JWK formats in a new document where the details of how they should work and what clients might benefit from them — sure! Removing definitions for the simple JSON format — not so much.

A couple comments inline below:

> 
> You can find others in the repo as well.
> 
> On Fri, 9 Jun 2023 at 16:13, Colin Bendell <[e-mail] <mailto:[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

Having JWK for the issuer dictionary would not mean we don’t need token type — token type is not just a cryptographic algorithm, it defines the issuance protocol. Type 2 and type 3 have the same format for the resulting token, but different properties throughout issuance.

Thus, a JWK format would need to also be paired with token types.

>> 
>> 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.

I think that aligning with Privacy Pass standards should be a goal of proposals like private state tokens. But clients already can directly consume public keys with existing deployments of privacy pass, and that doesn’t seem to be a burden. Also, privacy pass communicates keys in HTTP challenges, which are in the format that’s in the issuer dictionary, not a JWK.

Tommy

>> 
>> 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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>> -- 
>>> Privacy-pass mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
> -- 
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass