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

[Colin Bendell <[e-mail]>]

On Fri, 9 Jun 2023 at 23:15, Tommy Pauly <[e-mail]> wrote:

> 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


Yes. thanks for finding the correct link.


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

The one thing that strikes me is if you look at even the cloudflare
implementation, they have had to add all the standard kinds of things like
'version' and 'not-before'. While I agree that there are specific nuances
that are unique for privacy-pass, it feels like all the other standard
mechanics of key rotation would benefit from aligning to a common standard.
There are many additional features I assume implementers will eventually
also require (including: not-after, not-before, version, priority,
revocation uri, cache policy, etc).

I proposed JWK because it has browser support in webcrypto. I wonder
if there are other standards that have flushed these nuances out more
completely?

At the very least Privacy Pass should define some of these common fields
because as it stands the 'not-before' field is currently implementation
specific. Is it in epoch seconds? milliseconds? Is it like PST and measured
in microseconds? (madness!)


> A couple comments inline below:
>
> 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
>>
>
> 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.
>

This is a good point. Right now EC/P384 and RSA/PS384 are convenient short
hands for type 1 and type 2, As you say, it might not always be the case -
particularly if the Type's are used as a stand-in for rfc versions where
type=4 is the vNext of what is type=2 today. (I'm assuming that type won't
include minor versions)


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

To be fair, it's not a burden today only because there are only 2 issuers
that are in use in production environments. And the issuer directory isn't
available for one of them.

If PST aligns with this spec, we should expect multiple orders of magnitude
increase in the number of valid issuers and origins+clients that are
consuming them.

/colin


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