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

From: Kyle Den Hartog <[email-masked]>
Date: Mon, 2 Aug 2021 06:08:16 +0000

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

---

From: Kyle Den Hartog <[email-masked]>
Date: Mon, 9 Aug 2021 03:38:55 +0000

Regarding question 2: "Whether Bn256G1/G2 should be registered and prohibited?"

I was just reading the TPM2.0 profile[1] and it looks like Bn256G1/G2 are used by default for ECDAA signatures and are by default included in the TPM2.0 profile. There's an additional BN638 Curve that's optionally supported as well. It looks like there were algorithms under "ED256" which has registration entries included in the FIDO ECDAA Algorithm specification[2] (see section 5.7). This raises 2 questions for me:

  1.  Do these algorithms still need to be registered in the COSE/JOSE registries? Given I'm still quite new to the COSE WG I'm not sure about the back history. I'll do some digging in the mailing list to see if I can find some discussion about the topic.
  2.  Interestingly, they didn't define and attempt to register how the keys would be formatted in a JWK/CWK format. Is anyone aware of why that was?

Given the case that Bn256 is actively in use within FIDO with ECDAA, I'm leaning against prohibiting usage of this even though there's been attacks that have reduce the security entropy to be ~100 bits. From a practical perspective this is just to prevent confusion for implementors of FIDO. Are there any experts on this list who want to weigh in on this given the new (to me) information?

[1]: https://web.archive.org/web/20161031085411/https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf
[2]: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#iana-considerations

-Kyle
________________________________
From: Kyle Den Hartog
Sent: Monday, August 2, 2021 6:08 PM
To: [email-masked] <[email-masked]>
Subject: Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose

Thanks,
Kyle Den Hartog

---

From: David Waite <[email-masked]>
Date: Sun, 8 Aug 2021 22:23:19 -0600

AFAIK BN curves are not actively in use with FIDO, and there are no production authenticators producing ECDAA attestations.

-DW

> On Aug 8, 2021, at 9:38 PM, Kyle Den Hartog <[email-masked]> wrote:
> 
> Do these algorithms still need to be registered in the COSE/JOSE registries? Given I'm still quite new to the COSE WG I'm not sure about the back history. I'll do some digging in the mailing list to see if I can find some discussion about the topic.
> Interestingly, they didn't define and attempt to register how the keys would be formatted in a JWK/CWK format. Is anyone aware of why that was?
> [1]: https://web.archive.org/web/20161031085411/https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf <https://web.archive.org/web/20161031085411/https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.22.pdf>
> [2]: https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#iana-considerations <https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm-v2.0-id-20180227.html#iana-considerations>
> 
> -Kyle
> From: Kyle Den Hartog
> 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.
> 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.
> 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.
> 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.
> [1]: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-10#section-2.5 <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 <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/ <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04/>
> 
> Thanks,
> Kyle Den Hartog
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Kyle Den Hartog <[email-masked]>
Date: Fri, 13 Aug 2021 00:16:54 +0000

Thanks for the update on that. In that case, it's probably worth sticking with the original plan to prohibit it if it's not overly common to implementations that are already using these things in JOSE and COSE implementations.

-Kyle
________________________________
From: David Waite <[email-masked]>
Sent: Monday, August 9, 2021 4:23 PM
To: Kyle Den Hartog <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: EXTERNAL: Re: [COSE] Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose

-DW

On Aug 8, 2021, at 9:38 PM, Kyle Den Hartog <[email-masked]<mailto:[email-masked]>> wrote:

-Kyle
________________________________
From: Kyle Den Hartog
Sent: Monday, August 2, 2021 6:08 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Response to IETF 111 Agenda questions for draft-denhartog-pairing-curves-jose-cose

Thanks,
Kyle Den Hartog
_______________________________________________
COSE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cose