On Fri, Jun 30, 2023 at 05:29:32PM +0000, lgl island-resort.com wrote:
> 
> 
> On Jun 29, 2023, at 1:41 PM, Ilari Liusvaara 
> <[email protected]<mailto:[email protected]>> wrote:
> 
> On Thu, Jun 29, 2023 at 04:00:09PM +0000, Jeremy O'Donoghue wrote:
> 
> COSE_Sign1 and COSE_Sign+COSE_Recipient
> Single integer — The integer specifies the hash, signing algorithm and
> the curve

It does not specify the curve (it does in JOSE, but not in COSE).

 
> COSE_Encrypt+COSE_Recipient or COSE_Mac+COSE_Recpient
> This is the one of interest. It has at least two algorithm identifiers:
> 
>   *   The COSE_Encrypt bulk content encryption algorithm, typically AES-GCM
>   *   The COSE_Recipient algorithm
> 
> In the case of ECDH, the curve comes from the key, not from the algorithm ID, 
> so for RFC 9053 6.3 and 6.4 encryption there are 3 identifiers:
> 
>   *   COSE_Encrypt bulk alg, e.g. AES-GCM
>   *   COSE_Recipient alg, e,g, ECDH-ES + A128KW
>   *   Curve which comes from the key, e.g. NIST P-256
>
> There is also the case of nested COSE_Recipients, in which case there is an 
> algorithm identifier per nesting level.

Yes, one can also do ECDH as follows:

* COSE_Encrypt bulk alg, e.g. AES-GCM
* COSE_Recipient alg, e,g, A128KW
* ECDH alg, e.g., ECDH-ES + SHA256
* Curve which comes from the key, e.g. NIST P-256

3 algs, plus key subtype...

Then COSE is not limited to 3 layers, even if nobody has yet invented
use for that yet.


> COSE_Key
> A single algorithm identifier from the same space used by
> COSE_Sign1…COSE_Recipient plus a curve identifier for EC keys.

The alg there is optional. Not a good idea with symmetric algorithms,
but asymmetric algorithms are much less troublesome without alg in key.


> While a COSE_Encrypt may have more than one algorithm identifier, that
> algorithm identifier is never a tuple, vector, array or map like
> “hkc". It is alway a single integer (or string).

The point is that there is no single ciphersuite, but the information is
disaggregated.

The real information is in HPKE sender structure. HKC is just interop
mechanism. If your application does not need it, then don't use it.


> Also, I looked through the COSE message archive going back to 2015 to
> see if this was discussed. I found almost no discussion. It looks to
> me like the single specifier was inherited from JOSE. JOSE also has
> no tuple, vector, array or map for specifying anything like “hkc”.

The strategies used by COSE-HPKE just do not work in JOSE. JOSE-HPKE has
to be very different from COSE-HPKE.




-Ilari

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to