A novice question, would you explain conditions under which one should use paserk?

[iambumblehead]

Hello,

Would you explain the conditions under which one should or must use a paserk/jwk-like endpoint?

I'm currently using PASETO tokens verified with a static public key file I control and can easily update. Thank you for any response you may give.

---

Though I'm not sure if I need web keys, openid-configurations served from google and facebook define jwks_uris,

• https://accounts.google.com/.well-known/openid-configuration
• https://www.facebook.com/.well-known/openid-configuration/
• https://login.salesforce.com/.well-known/openid-configuration

And according to this stackoverflow user, JWKs was/is required by a public JWT library for haskell

• https://stackoverflow.com/questions/52478096/usage-of-jwk-in-a-jws

These things make me wonder if I should be using a paserk/jwk endpoint.

[paragonie-security]

No, we're not doing key discovery in PASERK.

We're going to explore key discovery in a subsequent PASETO extension which will use Gossamer. Obviously, we're not ready to specify that yet. :)

[dajiaji]

We're going to explore key discovery in a subsequent PASETO extension which will use Gossamer. Obviously, we're not ready to specify that yet. :)

I'm looking forward to your output on the key discovery, but I think a simple .well-known/paserk endpoint as follows would be a good place to start:

GET .well-known/paserk

{
    "keys": [
        "k3.public.AnBxcnN0dXZ3eHl6e3x9fn-AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2enw",
        "k4.public.cHFyc3R1dnd4eXp7fH1-f4CBgoOEhYaHiImKi4yNjpA"
    ] 
}

Is there any concern with this? I would appreciate it if you could tell me.

[paragonie-security]

Is there any concern with this? I would appreciate it if you could tell me.

Yes: https://docs.google.com/document/u/1/d/e/2PACX-1vQQ-FhNjW0ZhZVTnK1VG_87IBNZKBaJmweYZb1VBRdQCMAWXekqKfxdNl8wL6FWFDJ9pxXxpr66-GZp/pub

[dajiaji]

OK. I knew it.

I just wanted to get a clear picture of your motivation.

Thanks.

[iambumblehead]

@dajiaji @paragonie-security thanks to you for the additional interesting and useful comments.

[DylanYoung]

@paragonie-security Does it make sense to support something like a public-signed mode in PASERK for that use-case? Then the IdP would have one or more long-lived key-pairs (private key kept offline) which they would use to sign new public keys (either for adding them as new trusted keys or to revoke old keys, which could be accomplished via dedicated keywords in the PASETO footer, though the former might be accomplished by piggy-backing on wpk).

Just a thought.

e.g. if the footer contains

{
    "wpk":"k4.public-signed.jLhVAJYWaOcKiFvnKv6kFEQxSGV9BQuW1Qt4jRwr6yHiNeQf2h1GQ0czBJZpveX5T0R0YZv2OEenf8uyLqwamDJUbtS-GdYp_TXT1OJCwGJb2UpEHvcSOciH2PVCEiTrLM9n_mAI4SWXDfw4xYenmINDhi8EiPaPKvsOU64YBvY",
    "kid": "k4.pid.9ShR3xc8-qVJ_di0tc9nx0IDIqbatdeM2mqLFBJsKRHs"
}

This would indicate that the current PASETO is signed with wpk and wpk should be added as a trusted key iff wpk is signed by the key corresponding to kid and that key is a "root" trusted key (has the ability to add new trusted keys).

I believe this correponds to the Fixed Key Exchange idea in the paper you linked.

NOTE: Hmmmm.... Maybe a PASETO containing the public PASERK as claim could be used for this, then other claims would also be signed (e.g. revoke versus add to trust store).

Could also have well-known endpoint to fetch the currently trusted and revoked keys (signed by a root key of course) so that it doesn't have to be sent on every exchange. I think this removes the dependency on TLS.

[paragonie-security]

Why would a public-signed mode need to exist when that's vX.public in PASETO?

[DylanYoung]

Just adds secure key rotation without a lot of overhead. Not super familiar with the spec though, so perhaps it doesn't need a new type, just an embedded PASETO....

[paragonie-security]

What are the threats you're trying to protect against?

[paragonie-security]

The reason we ask is, the existing tools might be sufficient, but the only way for us to be certain is to understand your threat model.

• If you want key rotation, you just need a way to distinguish key IDs. PASERK gives you lid for symmetric keys, sid for signing keys (secret keys), and pid for verification keys (public keys). Stick them in a footer, use PASETO vX.public.
• If you need some sort of certificate chain, what you can do is have the issuer vend a vX.public PASETO which includes the pid for the given leaf public key.

If there's some other use-case we're not envisioning, happy to explain further once we know the parameters.

[DylanYoung]

Key compromise. An IdP needs to be able to rotate/revoke its keys. Much like the Gossamer protocol you linked, but doesn't require any out-of-band communication in daily operation (just for updating the master key) and doesn't provide the third-party attestation. Gossamer seems interesting though.

[DylanYoung]

I agree that your current tooling probably provides the primitives necessary, but without a higher level protocol, you'll end up with fragmented (and potentially broken) implementations.

[paragonie-security]

Key compromise is a thorny problem to deal with.

Gossamer is the kind of tooling you want, since it makes revocation actually work and makes MitM attacks from compromised CA certificates useless to the attacker.

The current plan is to get PASETO standardized with PASERK, then focus on Gossamer + {WordPress, Composer} before focusing on an automated Key Discovery mechanism for the PASETO suite. That specification doesn't exist yet, but it would basically make key rotation automatic at the scale of the entire Internet.

[DylanYoung]

I look forward to seeing what you come up with. I like what you've done so far :)