tplooker/draft-ietf-cose-bls-key-representations

Internet Draft defining the key representation format for the barreto lynn scott elliptic curve

Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE

This is the working area for the individual Internet-Draft, "Barreto-Lynn-Scott Elliptic Curve Key Representations for JOSE and COSE".

• Editor's Copy
• Datatracker Page
• Individual Draft
• Compare Editor's Copy to Individual Draft

Contributing

See the guidelines for contributions.

Contributions can be made by creating pull requests. The GitHub interface supports creating pull requests using the Edit (✏) button.

Command Line Usage

Formatted text and HTML versions of the draft can be built using make.

$ make

Command line usage requires that you have the necessary software installed. See the instructions.

draft-ietf-cose-bls-key-representations's Issues

Bls should be BLS

All of the letters b l s should be capitalized, since they are initials for people's names. @dwaite pointed this out to me during a JWP call.

Rename draft to conform to IETF naming conventions

To submit to the COSE working group, the draft name must be of the form draft-<lastname>-cose-<draftname>. I'd suggest the identifier draft-looker-cose-bls-curves-representations or something similar.

Note that both the filename and the draft name in the markdown (which is currently draft-looker-bls-jose-cose-00) need to be changed.

Key identifier?

I'm posing this as a question and not a direct suggestion.

The key identifiers are specifically for only one subgroup (the G1 on Bls48581G1 for example) on the defined pairing curve, and in practice an implementation will use that single group identifier to first identify the pairing curve itself, caring only about the Bls48581 prefix. Would it make sense to add a separator character such as _, -, or + like in other JOSE/COSE identifiers?

In fact, one could argue that Bls48581 is technically the curve name and the group could be identified via a separate element, but that's being rather pedantic :)

Are the JOSE registrations missing "Key Type: OKP"?

It's in each of the COSE registrations, should it be in the JOSE ones too?

Add example COSE and JOSE key representations

Relation to existing draft?

I'm assuming this is a successor to https://datatracker.ietf.org/doc/html/draft-denhartog-pairing-curves-jose-cose-00#section-3.1 but only specifically for the BLS curve?

Add some additional non-normative commentary on the applications of BLS12-381

Add examples of what cryptographic schemes are likely to be used in the near term e.g BBS Signatures and BLS Signatures

References needed for some cited related work

The draft includes "Further work on a similar scheme has also been progressed at the FIDO Alliance and W3C. Similarly Intel released (EPID) which provides a solution to remote hardware attestation for Intel Software Guard Extension (SGX) enabled environments." IETF style guidelines say that if we're citing work, we should provide references to it.

Private key representation

Supply definition under the OKP key type for how the private key should be encoded

Add code point for 48 bytes BLS12-381 signatures

As discussed at IETF 116 there are several reasons to also register a signature algorithm. BLS signatures do not have to be used with aggregations. They can also be used as a replacement for ordinary ECDSA signatures. The benefit with a BLS12-381 signatures are that they are 48 bytes instead of the 64 bytes for ECDSA and EdDSA. This would be a nice addition to COSE.

Other people agreed and stated that registering a signature should be done just to make the document complete and useful in it self.

One use case for 48 bytes BLS12-381 signatures is Group OSCORE. With 48 bytes signatures you could in quite many cases get away with sending one frame less which is a big win.