Hi Carsten, # Initial COSE algorithm identifiers for HPKE
Your idea is interesting but I can't agree with it for the following reasons: - It cannot represent ExportOnly. There is no reasonable justification to exclude ExportOnly at the current stage. - There is a need for continuous standardization effort to ensure that HPKE algorithm IDs are assigned within the applicable scope of this ID conversion rule. - Starting the IDs from 1024 would result in larger ID sizes. - Compared to the current specification, unnecessary conversion implementations would be required at the COSE library layer. Best, Daisuke 2023年6月1日(木) 17:31 Carsten Bormann <[email protected]>: > On 31. May 2023, at 21:02, Hannes Tschofenig <[email protected]> > wrote: > > > > When it comes to the algorithm registry there are only two choices: > > > > • A la carte, or > > • Ciphersuites > > The HPKE registry has opted for a la carte, and combinations (cipher > suites) are the COSE way. > > So let’s have the cake and eat it, too. > > (If you think the below is complicated, maybe read it again — it is just a > trivial way to get a number for a cipher suite from a triple of choices out > of the HPKE registry. For developer use, we could even regularly generate > a table so people who just want to use a cipher suite can just read through > the table.) > > The alternative to only register an alg value for today’s favorite cipher > suite is just a signal towards people who want other combinations to go > elsewhere. Why did the other entries in the HPKE registry get in there? > > Grüße, Carsten > > > # Initial COSE algorithm identifiers for HPKE > > We register a range of algorithm identifiers, assigning the alg > numbers 1024 to 2047. > > These 1024 alg identifiers stand for certain combinations of RFC 9180 > KEM Identifiers, KDF Identifiers, and AEAD Identifiers. > Only certain values of the RFC 9180 identifiers are covered; if values > outside the ranges covered now for each of the HPKE identifiers are > eventually assigned in the HPKE registry, additional registrations may > become necessary on the COSE side as well. > > These assigned numbers are used as follows: > > alg = 1024 + AEAD-Value + 8 * KDF-Value + 64 * KEM-Value > > AEAD-Value is a number from 0 to 7, each of these standing for the > value 1 to 8 from the HPKE AEAD Identifier registry, i.e.: > > AEAD-Identifier = AEAD-Value + 1 > > KDF-Value is a number from 0 to 7, each of these standing for the > value 1 to 8 from the HPKE KDF Identifier registry, i.e., > > KDF-Identifier = KDF-Value + 1 > > KEM-Value is a number from 0 to 15, each of which stands for a value > from the HPKE KEM Identifier registry computed as follows: > > (KEM-Value % 4) + (16 * ((KEM-Value / 4) + 1)) > > For all current HPKE registry entries, a corresponding value exists: > > HPKE KEM Value to Identifier > 0 0x0010 DHKEM(P-256, HKDF-SHA256) > 1 0x0011 DHKEM(P-384, HKDF-SHA384) > 2 0x0012 DHKEM(P-521, HKDF-SHA512) > 4 0x0020 DHKEM(X25519, HKDF-SHA256) > 5 0x0021 DHKEM(X448, HKDF-SHA512) > > HPKE KDF Value to Identifier > 0 0x0001 HKDF-SHA256 > 1 0x0002 HKDF-SHA384 > 2 0x0003 HKDF-SHA512 > > HPKE AEAD Identifier > 0 0x0001 AES-128-GCM > 1 0x0002 AES-256-GCM > 2 0x0003 ChaCha20Poly1305 > > As an example, the now popular combination > > DHKEM(P-256,HKDF-SHA256)/HKDF-SHA256/AES-128-GCM > > would use algorithm identifier > > alg = 1024 + 0 + 0 * 8 + 0 * 64 > = 1024. > > > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
