On Sun, Apr 16, 2023 at 09:05:54PM +0900, AJITOMI Daisuke wrote:
>
> I think there are several topics mixed in this thread, but first, I'd like
> to comment on whether this draft should be merged into the existing
> COSE-HPKE spec.
>
> The reasons why I proposed this draft as an independent specification
> separate from COSE-HPKE are as follows:
>
> a) I wanted to define not only COSE_Key but also JWK representation
> together for HPKE. This is the biggest reason.
>
> b) Key representation is essentially independent of the COSE message format
> and can be used for various applications unrelated to COSE or JOSE. As I
> mentioned in the slides for IETF116, I thought it would be beneficial for
> applications using HPKE for end-to-end encryption over HTTP if the HPKE
> recipient's public key could be published at the .well-known/jwks endpoint.
> COSE_Key representation may also be useful for CoAP-based end-to-end
> encryption apps in the same way.
a) and b) seems to be essentially the same thing? But yes, I agree
this should be something to work on.
> c) I wanted to consolidate the definitions of all expected alg values
> (HPKE-v1-{Base, Auth, PSK, AuthPSK}) into one document. Although I had
> agreed with the opinion that the COSE-HPKE should focus only on the Base
> mode, I thought it would be better to have all alg values for HPKE modes
> consolidated into one document. If this draft is adopted as a working group
> document, I was thinking of proposing to move the definition of alg values
> from the COSE-HPKE spec to this draft.
I think c) is a really bad idea. Defining alg value requires specifying
how it would work. Which would imply extending scope into specifying
the other three modes of HPKE. Just the security considerations in
doing so are highly nontrivial.
And doing this with JWK is even worse idea, because now you need full
definition of JOSE-HPKE, which is considerably harder task than the
entiere COSE-HPKE spec.
> If it is concluded that JWK should not be defined together, and that the
> definition of key representation should be limited to the HPKE Base mode,
> and that other HPKE modes should not be defined at this point, then it may
> indeed be better to merge this draft into the COSE-HPKE spec. On the other
> hand, if there is room for discussion on these issues, I think it would be
> appropriate to consider it as an independent draft currently. We can merge
> it into the COSE-HPKE spec at any time. What do you think?
I think the work should be split into two sub-tasks, both to be handled
in one document (if applicable):
1) Definition of minimal kty for generic HPKE keys in COSE_Key and JWK.
E.g. (for JWK, the COSE_key version just replaces JOSEisms with
COSEisms):
{
"kty":"HPKE",
"kem":48,
"priv":"ge...t5",
"pub":"cd...7i",
}
2) If desired by the WG (since this is unprecedented), a negotiation
mechanism for HPKE algorithms.
E.g. (again can replace JOSEisms with COSEisms for COSE_Key version):
{
<other key fields>
"hpkeadv":[[],[1],[2,3]],
"cose-bulk":[2,3,24],
}
The order in hpkeadv is supported KEMs, KDFs, AEADs. Every field allows
one or more values (if in kty=HPKE, then kem value is implicitly added
to the KEM list).
"cose-bulk" is list of COSE algorithm IDs supported for bulk encryption
at layer 0 (integer or string, so fits JSON datamodel).
I wrote the examples for JWK because it is consderably easier to sketch
JSON than CBOR diagnostic notation, and the mapping to COSE_Key is
pretty much trivial.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
