On Thu, Jul 06, 2023 at 08:29:11AM -0500, Orie Steele wrote:
> [image: Screen Shot 2023-07-06 at 7.41.14 AM.png]
> https://datatracker.ietf.org/doc/html/rfc9052#section-3.1
>
> Given that the ability exists, it seems `alg` is required.
>
> It matters what information alg conveys, for example, does alg convey the
> "mode" only, or [mode, kem, kdf, aead].
>
> However, I think `alg` is the only requirement in the protected header.
>
> Encapsulated key and sender info can both be communicated out of band.
>
> In the case that "alg" includes sender info, only the encapsulated key
> needs to be communicated out of band.
>
> Encapsulated key could be conveyed by reference (by kid in unprotected
> header).
That does not work, because encapsulated key is only ever used once.
This is the same reason why one can't encode "eph" by reference!
> sender info serves the same purpose as sender ephemeral key.... but lacks
> its extensibility.
The reason for new header is that HPKE ciphertexts are not keys, but
eph requires a key. And there is no known useful extension to sender
info, so it was not made extensible, simplifying things.
> In the case of DHKems enc is literally a public key.
Even if it is a DHKem, the key might not be expressible by COSE.
There is actually I-D that proposes such DHKems. And moreover those
DHKems are very much attractive for COSE.
And not all KEMs are DHKems.
> In another thread Ilari proposed a new key type for HPKE.
Right, to carry the long-term keys that are something else than the five
curves. This includes post-quantum. Which happens to currently be the
only genuinely new thing.
> HPKE is an algorithm family, it supports many existing keys that are
> already expressible in JWK and COSE Key.
Right, the idea is to allow using existing long-term five curves keys
with HPKE.
> Today when you call HPKE lower layer apis, you get:
>
> [aead, enc, ciphertext]... [A128GCM, encoded public key, cipher text]
>
> You can see this entire thing can be simplified if you use the standard key
> representations to build things that require keys...
>
> [ cose-key: { alg: TBD_0, ... encoded public key}, ciphertext ]
No, that does not work.
- There is no guarantee it is possible.
- It is definitely not simpler than using bstr for byte string.
> or... using the ability to add arbitrary data to a cose key... (or a JWK)
>
> cose-key: { alg: TBD_0, ciphertext, ... encoded public key }
>
> The tag for cose key is already supported in unprotected headers.
This fundementially violates RFC 9052 (any such extension obviously
has to be critical, but RFC 9052 does not allow critical key
extensions)..
> It would be nice if there were an unprotected header tag for *cose-key-set*
> then you could replace the traditional recipient structure for a
> standard cose key set.
>
> If the objection is that kyber's enc value is not a public key...
> good news, you can represent any data you want in cose key...
> including whatever kyber's kem operation outputs.
That would require a very nasty hack (there was actually version of
my code that did this).
> There should be no "new key type" for HPKE...
The only alternative I see is the bit nasty hack my code currently
does.
> but there should be new "alg" values that will work for keys that exist
> today,
> and ones that will be encoded in cose key in the future (like kyber keys).
Currently, there is one alg that works for everything. Present and
future.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
