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

[Christopher Wood <[e-mail]>]

To hopefully close the loop in this, I put together this PR that conceptually lifts the concept of key commitments from PSTs into the current Privacy Pass issuer directory:

https://github.com/ietf-wg-privacypass/base-drafts/pull/381" dir="ltr" width="300">

https://github.com/ietf-wg-privacypass/base-drafts/pull/381">Add "not-before" field by chris-wood · Pull Request #381 · ietf-wg-privacypass/base-drafts https://github.com/ietf-wg-privacypass/base-drafts/pull/381">github.com

I think we can pursue alternative representations separately.

This is the last open issue against the base documents before we advance to IESG, so please review! We will aim to resolve this and cut a new version next week.

Best,

Chris 

On Jun 13, 2023, at 12:14 PM, Christopher Wood <[e-mail]> wrote:



On Jun 12, 2023, at 3:43 PM, Tommy Pauly <[e-mail]> wrote:

On Jun 11, 2023, at 7:30 PM, Colin Bendell <[e-mail]> wrote:

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!)

The document suggests that lifetime be controlled with the standard cache-control headers from HTTP.

I’m not entirely sure on why the cloudflare dictionary includes the extra keys, or who is parsing them out — Chris can you comment on why those are there?

They’re specific to our deployment. Specifically, our origin uses them for key rotation purposes. These could be standardized, but since these are intentionally extensible objects they can be extended as needed for specific use cases. We might consider normalizing these types of parameters as part of the consistency work, since key rotation is highly relevant to key consistency mechanisms. In other words, I continue to think we should stick with what we have now and then either extend the existing format as needed for consistency or related purposes, or propose different representations (JWKS or whatever) for the directory as needed or desired for implementations. Would that work?

Best,
Chris

That said, I’d prefer to define more standard keys there than switch to a format that doesn’t have items like the token type.

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.

That’s not quite true — there were two highlighted when iOS first added support last year, but several others are running now in large scale.

Tommy

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