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