Just from a quick scan of the RFC: this seems to generate the encrypted session key directly from the public key of the recipient somehow. This also seems to be an attempt to standardize generating the public/secret keypair from something like a passphrase.
Traditionally you generate a random session key and then encrypt it using the public key of the recipient. The public/secret keypair is generated standalone where you optionally encrypt the secret bit of the keypair separately with a passphrase.
Not yet sure how this scheme would work in practice and what the advantage is...
IIUC, the two main goals/advantages over the traditional two-step approach is efficiency in the store-and-forward/block case and patching holes that lead to data leakage in the online/stream case, correct?
If so, it would be good in both TFA and the RFC to state this up front. Otherwise, one might wonder if it ain’t broke, why are we fixing it?
If not, all corrections/explications hatefully received!
HPKE allows you to use private/public keypairs that are signed by a trusted authority, therefore enabling two parties that have never met prior to securely communicate. That is, as long as they trust the same authority.
Another major benefit of HPKE is a shared key schedule. Two parties can generate as many symmetric keys as they would like over a persistent conversation. This kind of provides ‘sub keys’, but within the context of a conversation, as they are not long lived.
GPG’s web of trust model is powerful but is limited in contexts where you have no prior trust. The world’s existing PKI structure, with a handful of root CAs, is already well established and trusted by nearly every device on the planet.
>GPG’s web of trust model is powerful but is limited in contexts where you have no prior trust.
With the WOT you can choose who you trust. In particular you have the choice not to trust every single one of the several thousand second level CAs that currently exist.
None of this explains what HPKE is and why anyone would be interested in it.
It doesn't look like this would even work for the offline stuff that PGP targets. The session key seems to be linked to the public key. So really only good for things where you throw away the keys after the session has closed. Forward secret TLS for example. Unless I am missing something, the reference to OpenPGP and S/MIME is gratuitous.
The fact that it's being RFCed?