On Sat, Sep 03, 2022 at 11:42:46PM +0900, AJITOMI Daisuke wrote:
> Hi Hannes and folks
>
> > The challenge is that the COSE WG has already defined formats for certain
> public keys and, at least at the last IETF meeting, was in favor of using
> those existing key formats.
>
> Thanks for your information, I've watched the recorded IETF114 meeting.
> Regarding Ilari's proposal, I agreed with his attempt to treat ”enc"
> (encapsulated sender's public key) as an octet string, but I did not agree
> with his attempt to force the use of the COSE_Key structure, and I thought
> the current specification format was relatively better.
>
> Please allow me to suggest a solution to the above problems. It is just an
> idea that is not very refined yet though:
> 1. Define 'HPKE'(COSE_ALG_HPKE) as a new 'alg' value for a COSE Header
> Parameter. Unlike the current draft, AEAD information is not included in
> the alg value.
> 2. Introduce a new 'HPKE sender information' structure including enc as a
> parameter of 'HPKE' alg, instead of using the COSE_Key structured
> ’ephemeral key'. The structure also includes the HPKE cipher suite
> information(at least KDF ID and AEAD ID are required) negotiated with the
> recipient. An example is as follows:
>
> ```
> 96(
> [
> / algorithm id TBD1 for COSE_ALG_HPKE /
> << {1: TBD1} >>,
> {
> / HPKE sender information structure /
> -4 (TBD2): << {
> / KEM identifier, 2bytes (optional because (the
> recipient's)kid can be mapped to a KEM id.) /
> -1: 0x0010,
> / HPKE symmetric cipher suite (KDF id + AEAD id), 4bytes
> (required) /
> 1: 0x00010001,
> / HPKE encapsulated key (required) /
> 2: h'xxxxxxxxxxxxxxxxxxxxxxxxxxx',
> } >>,
> / the recipient's public key identifier (required) /
> 4: 'kid-2'
> },
> / encrypted plaintext /
> h'4123E7C3CD992723F0FA1CD3A903A58842B1161E02D8E7FD842C4DA3B984B9CF'
> ]
> )
> ```
Here is how I would do full-registry-offload (all new HPKE algorithms
immediately usable) design:
- Define new kty HPKE. Fields: kem (uint), kdf (uint),
priv (bstr; optional), pub (bstr), aead (uint; optional).
- Define new alg HPKE.
- Define new header field ek (bstr) [Encapsulated Key]
- For HPKE, ek is concatenation of big-endian 2 byte encoding of AEAD
and the HPKE encapsulated key.
- If there are no compact NIST curves in HPKE, for NIST curves,
compressed forms of pub and ek are decompressed.
Notes:
- This is fire-and-forget. CFRG defined a new PQC KEM? It is usable
already.
- hpke:priv is used to encode private keys.
- hpke:aead can be used to hint AEAD to use when encrypting.
- This is designed to be space-efficient:
* For long-term keys, disaggregation of kem/kdf is probably space-
optimal.
* For encapsulated keys, aggregation is space-optimal.
* Yes, the way of making NIST curves be space-efficient is a nasty
hack.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
