I think one point of confusion may be that in JOSE, ephemeral public keys
are JWKs... for example:
"jwe": {
"protected": "eyJlbmMiOiJYQzIwUCJ9",
"recipients": [
{
"header": {
"kid": "did:example:123#key-0",
"alg": "ECDH-ES+A256KW",
"epk": {
"kty": "OKP",
"crv": "X25519",
"x": "17sQFStg7ORPTq20OtU_MOzdzOU9iJAbqMP4cYVmUR0"
},
"apu": "17sQFStg7ORPTq20OtU_MOzdzOU9iJAbqMP4cYVmUR0",
"apv":
"ZGlkOmtleTp6Nk1rdENpMjlpQXdVaVZEYWV3U1N0SFZXNXFoQnhaVEdYQkZYTTlZRDlSaXNiRm4jejZMU240V3E1WEU0RmdKOGp5S3NzMWtMNUdxd3NuN2dWZ3NLcE5FUEdITWVDeFFx"
},
"encrypted_key":
"mtKsC05glLghX4s6LGva3Nr9A_l9SYVdQviB81HJRoiAfi0HfhkvnQ"
}
],
"iv": "IpYeFb6utO2J_Ii8R50d-O9ppiEOQZN2",
"ciphertext": "ewKbg3EJ6Pm4dH1tGdXGkJO5rTiMbn-tnfDGSvyvdQHD7HeE9g",
"tag": "QYakakAfhHJ0KRXM47_uRQ"
}
Whereas in this case, the proposal seems to be to make them another key
type that is not a COSE_Key, and that is specific to HPKE.
The gist of the argument that Ajitomi and Ilari are making seems to be:
The epk in HPKE does not need to be a standard format, because the standard
format uses too many bytes, and includes extraneous information.
If I got the argument wrong, please correct me.
Regards,
OS
On Mon, Sep 5, 2022 at 6:35 AM AJITOMI Daisuke <[email protected]> wrote:
> Hi Michael,
>
>
>> Now what I understand is that HPKE (some HPKEs?) do not produce a series
>> of
>> octets that can just be called a key. Is that correct?
>
>
> No, it isn't. The HPKE encryption process produces an encapsulated key (an
> ephemeral public key) as a series of octets.
>
> Regards,
> Daisuke
>
> 2022年9月4日(日) 17:33 Michael Richardson <[email protected]>:
>
>>
>> Hi, permit me to ask some really dumb questions, which may reveal
>> where the understanding gap is :-)
>>
>> Orie Steele <[email protected]> wrote:
>> > Thanks for this email, responses inline:
>>
>> > On Sat, Sep 3, 2022 at 9:43 AM AJITOMI Daisuke <[email protected]>
>>
>> >> 1) There is no guarantee that enc can be mapped to COSE_Key in the
>> >> future, so if a new HPKE cipher suite is specified, it cannot be
>> used
>> >> on COSE immediately. Whenever a new cipher suite is added to HPKE,
>> it
>> >> is necessary to develop a mapping specification for COSE_Key
>> >> (including alg/crv value registration to IANA) and implement an
>> >> additional enc->COSE_Key conversion process in existing many COSE
>> >> libraries. As a library implementer (I'm also a COSE/CWT
>> implementer
>> >> https://github.com/dajiaji/python-cwt ...), I cannot overlook
>> this...
>> >>
>>
>> os> I agree, this is a major problem.. but it's not limited to COSE,
>> it's
>> os> also a concern for JOSE... and PGP.... and SSH...
>>
>> I've been watching from the sidelines. I haven't really understood the
>> problem.
>> HPKE is a organ grinder with a handle that I turn, and I haven't really
>> had time/interest to look inside.
>>
>> Now what I understand is that HPKE (some HPKEs?) do not produce a series
>> of
>> octets that can just be called a key. Is that correct?
>>
>> Why isn't this a CFRG problem to go and define a clear mapping, so that
>> everyone can just use the same thing? Is it the case that one part of
>> the
>> IRTF/IETF is producing metric bolts, whole the other part is requiring
>> imperial gauge ones?
>>
>> > 1. Keys should be used for one purpose, and under one algorithm.
>>
>> > implicit 4. From 3, don't attempt to "infer" `alg`... require it...
>> for
>> > example, P-256 can be used for signatures and encryptions, when
>> `alg`
>> > and `use` are absent, inference is ambiguous without sufficient
>> > context.
>>
>> I guess I would say that the COSE Protocol designer must
>>
>> > There are 2 registries that will need to be updated in order for
>> your
>> > new "alg" to be understood.
>>
>> > - https://www.iana.org/assignments/jose/jose.xhtml -
>> > https://www.iana.org/assignments/cose/cose.xhtml
>>
>> > I interpret this as an answer to your question... There __is__ a
>> > guarantee that `enc` can be mapped to `COSE_Key` in the future, but
>> > only for `enc` and `COSE_Key` that have been properly registered,
>> and
>> > not before that, can they be safely used with COSE.
>>
>> Reasonable to me.
>>
>> I have found that some young academics think that every algorithm in an
>> IANA
>> Registry must be acceptable as valid, because ... IANA... in the same way
>> that some people think a CA signing a certificate authorizes the
>> possessor of the
>> key to do stuff.
>>
>> > I'm struggling to visualize how this would actually work based on
>> the
>> > text in this email, and your example.
>>
>> > As a developer, I'm expecting something like this:
>>
>> > standard_ciphertext = encrypt ( standard_msg, standard_public_key,
>> ?alg
>> > ) ... where either standard_public_key contains `alg` or it is
>> required
>>
>> Me too.
>>
>>
>> --
>> Michael Richardson <[email protected]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________
>> COSE mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
--
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries
<https://www.transmute.industries>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
