[COSE] Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose

[Kyle Den Hartog <[e-mail]>]

First off thanks Mike Jones for jumping in and PowerPoint jockeying through the slides for me. Sorry for missing the meeting I had a time zone mix up. I was able to rewatch the portion of the recording afterwards and wanted to weigh in on a few questions I heard and had prompted on the slides.

  1.  Should we use EC2 vs OKP?
     *   This is where I was going with this question. It was asked to me if SEC1 encoding was commonly in use today. I realize now that the draft doesn't accurately convey that when I referenced SEC1 that I was implying the usage of SEC1 point compression which would then use OKP. I'll need to update that. As far as I've seen it's mainly gone towards OKP (with a single compressed point and a sign) so my take was that we follow that pattern as well. However, the latest pairing-friendly-curves draft[1] references draft-ietf-lwig-curve-representations[2] (note it's draft 08 while the latest draft it's now in Appendix I.5). In this case, my questions was trying to figure out if the draft should use the SEC1 compression serialization of the keys which seems more common in JOSE and COSE or if it would be better to continue in the serialization method described in section 2.5. In this case, I didn't fully understand what was being described in the lwig-curve draft, so I opted to go with SEC1 compressions in the initial draft. I'd like to get others to weigh in on if this is even possible first, and then for us to consider what is the better direction.
  2.  Whether Bn256G1/G2 should be registered and prohibited?
     *   The discussion hit the nail on the head here. Thank you, Jonathan Hammell, for jumping in and explaining the background on the security issue. My concern was that because the security has been reduced to 100 bits rather than 128 bits does this warrant the draft defining it and marking it as prohibited. My take was "yes" hence the original question.
  3.  Regarding the G1/G2 question:
     *   This was largely heading in the direction of trying to figure out if it makes sense to recogonize these separate finite fields as independent "curves" or would it make more sense to use a different way to differentiate them. One suggestion on the github repo has been to use multicodec as an alternative serialization to SEC1 and lwigs-curve and then use that as a way to represent the sub groups. My general take is that this didn't align well with the traditional approach COSE/JOSE have used and so it's going to introduce some new dependencies in many implementations I'd suspect. For this reason I would prefer to not go this route, but am not necessarily certain if my "crv" route is the right way either.
  4.  Regarding defining these with signatures:
     *   My general take would be that I'd prefer to not have to do this. Since we haven't implemented any of the signatures schemes that utilize these curves in JOSE or COSE, it would be a bit of a yak shaving exercise for us and our primary goals at this point to have to also define those. I know of some related proposals that are looking to define these signatures (BBS+) in JOSE in the very introductory stages which may pair well with this, but for now I'm of the opinion we could just as easily separate the works. If there is a desire to define at least one signature scheme with this, the IRTF does have the BLS signatures[3] being worked on which would pair well with this work if there's a desire to add threshold signatures to JOSE/COSE.

Hopefully with this additional context to the slides, people may have a better understanding and some further opinions on the various questions to date.

[1]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-10#section-2.5
[2]: https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-08#appendix-J.4
[3]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04/

Thanks,
Kyle Den Hartog