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 protected]> > wrote: > > 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: > > 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? > 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 > > <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 > Sent: Monday, August 2, 2021 6:08 PM > To: [email protected] <[email protected]> > Subject: Response to IETF 111 Agenda questions for > draft-denhartog-pairing-curves-jose-cose > > 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. > 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. > 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 > > <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 protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
