> On May 14, 2023, at 11:57 AM, Ilari Liusvaara <[email protected]>
> wrote:
>
> On Sun, May 14, 2023 at 11:39:47AM -0700, Laurence Lundblade wrote:
>>
>>> On May 8, 2023, at 1:20 AM, Ilari Liusvaara <[email protected]>
>>> wrote:
>>>
>>> On Sun, May 07, 2023 at 11:10:25AM -0700, Laurence Lundblade wrote:
>>> ...
>>>
>>>> if the “alg” field is present and set to HPKE-v1-Base and the “hkc”
>>>> field is present, the kem, kdf and aead used must be listed in the
>>>> “hkc” field (see definition of “hkc” below”).
>>>
>>> I think this should be SHOULD and be independent of alg. I think
>>> "hkc" is advertisment, not restriction.
>>
>> I’m not opposed to defining parameters for advert/negotiation/
>> agreement, but want to be clear what is what.
>
> Yup. The draft is not clear if "hkc" is supposed to be restriction or
> advert.
>
>
>> RFC 9052 section 7.1 is very clear: “alg: This parameter is used to
>> restrict the algorithm that is used with the key”. That doesn’t
>> preclude it from being used for advert, but it has to be used for
>> restriction first.
>
> Yup, according to RFC 9052, "alg" is restriction (along with some
> others). However, it is not clear if it is possible to define any
> new restrictions (COSE has hardcoded list of critical key parameters).
>
>
>> If we want to work on advert that’s fine. I think the choices are:
>>
>> 1) Fully and properly define use of the alg parameter for restriction
>> and then say it can be also used for advert
>
> Just leave "alg" alone. No need to say anything about its semantics,
> RFC 9052 specifies that.
As is, it is not possible for someone to restrict use of a COSE_Key to a
particular KEM, KDF or AEAD. The only restriction would be to any algorithms in
the IANA HPKE registry. \\
Your statement would be true if COSE HPKE used cipher suites.
>> 2) Define some new advert parameters
>
> I proposed defining "hkc" and "cbc" as new advert parameters.
Have you thought about defining some general CBOR/COSE HPKE algorithm
identification system for advert in scenarios that don’t use COSE_Key? Tie it
in to some of the scenarios in section 10 of RFC 9052. Could also be for
COSE_Key.
Again, there would be nothing to do here if COSE HPKE used cipher suites.
>> My opinion is that we should do the work for restriction. It seems
>> like COSE-HPKE would be incomplete without it.
>
> I don't think it would be incomplete, because HPKE is cryptographically
> sound without restrictions.
This doesn’t seem right because:
1) There are several choices in the registry for a reason. Some will want to
exclude the smaller key sizes
2) I don’t believe the IANA HPKE registry will stay pristine and perfect with
no bad choices
3) There are political and regulatory reasons for selecting algorithms
4) COSE_Key is a mechanism for individual systems that want to use restriction.
We should provide it is a full and general way so they don’t have to rely on
the IANA HPKE registry.
There would be no work here if COSE HPKE used cipher suites.
LL
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
