Hi Ilari,
Thanks for your comment.
> 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.
>
I think your approach is very good. At least, from my point of view, it is
much better than the current draft.
I was thinking of a similar approach for the 'recipient public key' sharing
format.
For example, I thought the response of jwks_uri would be as follows:
```
keys: [
{
"kty": "HPKE",
"kid": "x25519-01",
"kem": 0x0020, // DHKEM(X25519, HKDF-SHA256)
"kdfs": [0x0001, 0x0002, 0x0003], // All of the currently defined KDFs
are acceptable.
"aeads": [0x0001, 0x0002, 0x0003], // All of the currently defined
AEADs are acceptable.
"pub": "2E6dX83gqD_D0eAmqnaHe1TC1xuld6iAKXfw2OVATr0", //
base64-encoded X25519 public key.
}
]
```
The difference between my approach and yours is that my approach allows
multiple acceptable KDFs and AEADs to be specified. The reason is that pub
(recipient's public key) is only for KEM and does not depend on KDF or AEAD.
In my previous discussions, I have clearly distinguished between recipient
public keys and ephemeral sender public keys, and have only talked about
the latter.
I believe that the former requires a specification for its representation
in COSE_Key. However, I believe this should be discussed more broadly,
including an extended specification for JWK. As you know, JWK is very
widespread so careful discussion is needed. In fact, this perspective is
also one of the reasons I am opposed to the current draft.
On the other hand, the latter ephemeral sender public key can be considered
independently of the recipient public key. Since it is based on the
recipient public key, it does not necessarily need the attributes as in the
JWK example above. And also It is handled internally in the library, and
there is no need to force it into the COSE_Key structure.
Regards,
Daisuke
2022年9月4日(日) 3:53 Ilari Liusvaara <[email protected]>:
> 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
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
