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