> On Apr 15, 2023, at 10:12 PM, Ilari Liusvaara <[email protected]> 
> wrote:
> 
>> On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <[email protected] 
>> <mailto:[email protected]>>
>> wrote:
>> 
>> When we say "public key" in a CRFG document, I think it is reasonable to
>> assume no specific representation (JWK, COSE Key, PGP, etc...)
>> 
>> As a side note, HPKE requires more than just having a recipient public key,
>> it also requires knowledge of the recipient supported algorithms... (this
>> is extremely obvious per the security considerations).
>> It is natural to assume this will be solved differently in COSE, PGP,
>> etc...
>> Maybe it is in the key representation, maybe it is via negotiation, as you
>> mentioned earlier...
>> 
>> But it has to actually be solved for, or the sender is just guessing that
>> the recipient will be able to process their messages.
> 
> Well, in store-and-forward system like COSE or JOSE, there are really
> only two ways:
> 
> - negotiation.
> - assume based on application.
> 
> And when it comes to COSE and JOSE, there are no usable negotation
> capabilties, so it is the latter: assuming based on application.

Hi Ilari,

Want to clarify your point here.

I think you mean that we can’t design and standardize a negotation protocol 
that COSE use case will use (if we did it would be a bad TLS). Instead, each 
COSE use case, each COSE application, will come up with its own way of 
determining the algorithm(s) used. Right? I think this is right.

When I used the word “negotiation” in framing I was using it in a very broad 
general sense to cover every means that sender and receiver come to know what 
algorithm to use. I think you used the word negotiation the narrow sense of a 
round trip protocol.

I am little unsure about your wording “assume based on application”.  We could 
rip out CMS and replace it with COSE for S/MIME and still use X.509 and the 
sender could know that the recipients algorithm from the X.509 cert. That 
doesn’t seem like “assuming” to me.

Modern web protocols can be pretty complex and powerful and do a lot with a lot 
of round trips. One of those round trips  might allow algorithm agreement for 
some use of COSE in another part of the protocol.

When you use the word “assume” I think of more of a simple thing like 
minimum-to-implement, a general specification that a use case uses only one 
algorithm, or allowing the sender to pick one of three and requiring the 
receiver to support all three.  These are fine, but there’s also a proprietary 
round-trip agreement, certificate-based agreement and probably a lot more.

It might be good to see what JWT and CWT do. They certainly have this problem 
and have real world deployments.

LL








_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to