Key objects / JWK equivalent

[nrktkt]

For paseto to become a viable JOSE alternative, it probably needs to cover more of the JOSE suite including JWK.

At DC26 CiPHPerCoder talked about how key objects in library implementations should be typed and not just byte arrays. To this end, paseto should have a JSON object format for keys to a) guide implementations of key classes and b) provide simple standard ways of serializing/deserializing keys.

[paragonie-scott]

For the purpose of keeping things parallel but still domain-separated, I think we should do as follows:

• Symmetric keys
  • v1.local. -> k1.local.
  • v2.local. -> k2.local.
• Asymmetric keys
  • v1.public. ->
    • k1.public. for the public key component of a keypair
    • k1.secret. for the secret key component of a keypair
  • v2.public. ->
    • k2.public. for the public key component of a keypair
    • k2.secret. for the secret key component of a keypair

Does this sound reasonable enough?

[ghost]

Does it need key ID (kid)?

[nrktkt]

@fkooman I think that's a good idea, I suppose that could go in a body object.

@paragonie-scott so what would that look like? Two different strings if the complete key pair needed to be communicated somewhere? I suppose it should also include some of what JWA specifies for the actual key parameters. eg

so such a thing might look like k2.local.{ "id": "123abc", "k": "some base46" } where the body would be base64url encoded

[paragonie-scott]

Hmm, I'm probably going to make a separate standard proposal for a JWK alternative.

Bonus: We can do fun stuff like ECDH-ES over Curve25519, key wrap, etc. without adding a lot of machinery to PASETO.

Would anyone object to PASERK? (Platform-Agnostic Serialized Keys, would rhyme with "berserk").

[nrktkt]

Separate standard would probably be good.

Another thing to consider with the key ID, there's nowhere to put it in the PASETO header. Knowing which key was used for signing/encryption is essential for systems to support smooth key rotation.

[paragonie-scott]

Another thing to consider with the key ID, there's nowhere to put it in the PASETO header.

That is the entire reason the footer exists.

[paragonie-scott]

In related news, we (being cryptography nerds, not PIE) are going to be proposing a separate XChaCha RFC: https://github.com/bikeshedders/xchacha-rfc

This cuts down on the amount of documentation needed inside PASETO's next RFC draft.

[nrktkt]

That is the entire reason the footer exists.

Ah alright, should the footer then be modified to have some standard fields (like key ID) rather than freeform data?

[ghost]

Regarding kid, maybe this could actually be part of the signature/ciphertext itself, like e.g. minisign does. It would be very nice not to need to parse JSON before figuring out the kid.

[paragonie-security]

PASERK (currently a draft) aims to solve the problems raised in this issue and provide additional benefit.

[paragonie-security]

https://github.com/paragonie/paserk-php implements the current PASERK draft. Please continue this discussion in either the specification repository (our previous comment links to it) or the PHP implementation.