> 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.
In theory we could do advert without restriction, but that seems off to me it
could not use the “alg” parameter. It would to be some new algorithm advert
parameters.
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.
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
2) Define some new advert parameters
What we can’t do is exclusively repurpose the alg parameter for advert because
that would be in conflict with RFC 9052 section 7.1
My opinion is that we should do the work for restriction. It seems like
COSE-HPKE would be incomplete without it.
I’m mostly neutral on what’s done for advert. Seems OK to say the alg parameter
can also be used for advert. Also seems like that is only a partial solution
because there’s lots of COSE-HPKE use cases that won’t use COSE_key. I’ve
pasted in the RFC 9052 text from section 10 for advert below.
LL
• Applications may need to provide some type of negotiation or
discovery method if multiple algorithms or message structures are permitted.
The method can range from something as simple as requiring preconfiguration of
the set of algorithms to providing a discovery method built into the protocol.
S/MIME provided a number of different ways to approach the problem that
applications could follow:
• Advertising in the message (S/MIME capabilities) [RFC8551].
• Advertising in the certificate (capabilities extension)
[RFC4262].
• Minimum requirements for the S/MIME, which have been updated
over time [RFC2633] [RFC3851][RFC5751] [RFC8551]. (Note that [RFC2633] was
obsoleted by [RFC3851], which was obsoleted by [RFC5751], which was obsoleted
by [RFC8551].)
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
