On Mon, Jul 17, 2023 at 10:29:10AM +0300, Ilari Liusvaara wrote:
> On Thu, Jul 13, 2023 at 11:41:49AM +0200, Hannes Tschofenig wrote:
> > Hi all,
> >
> > The following people expressed their preference for a single algorithm
> > to express the HPKE combination of KEM/KDF/AEAD*:
>
> ...
>
> > *: Various ways for registering this combination have been mentioned
> > and discussed. I leave those details for later.
>
> Has there been a proposal for a way that is none of the following?
>
>
> 1) Systematic embedding of the ciphersuite (internal HPKE term)
> identifiers into alg.
>
>
> 2) Creating some sort of special procedure to allow registering new
> algorithms for ciphersuites just specifying the HPKE identifer values.
>
>
> 3) Not allowing adding new ciphersuites. Any new ciphersuites would
> require a new version of COSE-HPKE.
Well, another way entirely (which is at least not pareto-worse than
current):
- Move the existing codepoints to larger range (e.g., three byte range).
- Define new header parameter encapsulated key (bstr) in 1 byte range.
- Define shortcut notation algorithm codepoints. Something like:
Shortcut notation:
------------------
When using shortcut notation algorithms, the following differences
SHALL apply:
- Value of alg is the shortcut algorithm, instead of HPKE-v1-BASE.
- The value of enc is placed in encapsulated key header parameter,
instead of HPKE_sender_info.enc.
- The values of kem_id, kdf_id and aead_id are fixed per algorithm,
instead of being placed in eponymous fields of HPKE_sender_Info.
If used in two-layer structure, both layers SHOULD use the same
encryption algorithm.
- The terminology should be distinctive, so that other RFCs can
refer to it in order to specify needed shortcuts.
- It might be feasible to define just 4 shortcut algs:
* CP-256 + SHA-256 + AES128 (?-1-1), 1 byte alg id.
* CP-384 + SHA-384 + AES256 (?-2-2), 2 bytes alg id.
* X25519 + SHA-256 + Chacha20 (32-1-3), 1 byte alg id.
* X448 + SHA-512 + Chacha20 (33-3-3), 2 bytes alg id.
Note: The CP-256 and CP-384 are not registered into HPKE yet, but
there is a draft.
The two 1 byte algs (and use of CP-256 instead of P-256) are to golf
the thing to the last byte.
Those should cover most of the needs. If that is not sufficent (e.g.,
for post-quantum) HPKE-v1-BASE can be used. Anyone being able to
afford the post-quantum KEM should be able to afford ~dozen extra
bytes from less compact encodings, plus the extra code size.
... Shortcut notations are not unheard of in COSE. E.g., anything
in "Key Agreement with Key Wrap" category, since that could be
decomposed into Direct Key Agreement and Key Wrap (however, that is
_not_ true in JOSE!).
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
