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 =-
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
