Internet-Draft | Barreto-Lynn-Scott Elliptic Curve Key Re | October 2022 |
Looker & Jones | Expires 27 April 2023 | [Page] |
This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott (BLS), for use with the key representation formats of JSON Web Key (JWK) and COSE (COSE_Key).¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/tplooker/draft-ietf-cose-bls-key-representations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 27 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This specification defines how to represent cryptographic keys for the pairing-friendly elliptic curves known as Barreto-Lynn-Scott [BLS], for use with the key representation formats of JSON Web Key (JWK) and COSE_Key. This specification registers the elliptic curves in appropriate IANA JOSE and COSE registries.¶
There are a variety of applications for pairing based cryptography including schemes already published as RFCs, such as Identity-Based Cryptography [RFC5091] Sakai-Kasahara Key Encryption (SAKKE) [RFC6508], and Identity-Based Authenticated Key Exchange (IBAKE) [RFC6539]. SAKKE is applied to Multimedia Internet KEYing (MIKEY) [RFC6509].¶
This branch of cryptography has also been used to develop privacy-preserving cryptographic hardware attestations schemes, including the Elliptic Curve Direct Anonymous Attestation (ECDAA) in the Trusted Platform Modules [TPM] specified by the Trusted Computing Group. Further work on similar schemes has also occurred at the FIDO Alliance [ECDAA]. Similarly, Intel released [EPID] which provides a solution to remote hardware attestation for Intel Software Guard Extension (SGX) enabled environments.¶
More recently, applications of pairing based cryptography using the Barreto-Lynn-Scott curves include the standardization effort for BLS Signatures [id.draft.bls-signature-04], which are used extensively in multiple blockchain projects due to their unique signature aggregation properties, including [Ethereum] [DFINITY] [Algorand]. Additionally, efforts are under way to standardize the general purpose short group signature scheme of BBS Signatures [BBS], which features novel properties such as multi-message signing and selective disclosure alongside zero knowledge proving. It is intended that this draft will help with these efforts by standardizing the associated cryptographic key representation in the popular formats of JWK and COSE_Key.¶
Other relevant work to this draft includes [JWP] which is extending the JOSE family of specifications to provide support for representing a variety of new proof based cryptographic schemes such as [BBS] which as referred to above uses the Barreto-Lynn-Scott curves.¶
There are multiple different pairing-friendly curves in active use; however, this draft focuses on a definition for the Barreto-Lynn-Scott curves due to them being the most "widely used" and "efficient" whilst achieving 128-bit and 256-bit security (BLS12-381 and BLS48-581 respectively).¶
More extensive discussion on the broader application of pairing based cryptography and the assessment of various elliptic curves (including the BLS family) can be found in [id.draft.pairing-friendly-curves-10].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following definitions apply to the pairing-friendly elliptic curves known as the Barreto-Lynn-Scott (BLS) curves.¶
When expressing a cryptographic key for these curves in JSON Web Key (JWK) form, the following rules apply:¶
When expressing a cryptographic key for these curves in COSE_Key form, the following rules apply:¶
JWK "crv" value | COSE_Key "crv" value | Description |
---|---|---|
Bls12381G1 | TBD (13 requested) | A cryptographic key on the Barreto-Lynn-Scott (BLS) curve featuring an embedding degree 12 with 381-bit p in the subgroup of G1 defined as E(GF(p)) of order r |
Bls12381G2 | TBD (14 requested) | A cryptographic key on the Barreto-Lynn-Scott (BLS) curve featuring an embedding degree 12 with 381-bit p in the subgroup of G1 defined as E(GF(p^2)) of order r |
Bls48581G1 | TBD (15 requested) | A cryptographic key on the Barreto-Lynn-Scott (BLS) curve featuring an embedding degree 48 with 581-bit p in the subgroup of G1 defined as E(GF(p)) of order r |
Bls48581G2 | TBD (16 requested) | A cryptographic key on the Barreto-Lynn-Scott (BLS) curve featuring an embedding degree 48 with 581-bit p in the subgroup of G1 defined as E(GF(p^8)) of order r |
See [id.draft.pairing-friendly-curves-10] for additional details on security considerations for the curves used. Implementers should also consider the general guidance provided in Section 9 of [RFC7517] and Section 17 of [RFC8152] when using this specification.¶
Furthermore, because this specification only defines the cryptographic key representations and not the usage of these keys with specific algorithms, implementers should be aware to follow any guidance that may be provided around appropriate usage of the keys and or additional steps that may be required to validate the keys within the context of particular algorithms.¶
This section registers the following values in the IANA "JSON Web Key Elliptic Curve" registry [IANA.JOSE.Curves].¶
Bls12381G1¶
Bls12381G2¶
Bls48581G1¶
Bls48581G2¶
This section registers the following value in the IANA "COSE Elliptic Curves" registry [IANA.COSE.Curves].¶
Bls12381G1¶
Bls12381G2¶
Bls48581G1¶
Bls48581G2¶
The following examples showcase JWKs for both the G1 and G2 subgroups of the Bls12381 curve. Note, the examples also include the corresponding private key, expressed through the inclusion of the "d" parameter.¶
An example JWK for the Bls12381 curve where the public key is in the G1 subgroup.¶
{ "kty": "OKP", "crv": "Bls12381G1", "d": "Mt_OyD9IAsYvobHJ9NCipm6-G7zAu28FCc-saRnXhjQ", "x": "iXmOmxttBniHSpyoq-vBr82BexrqG7WDTsxCY4ngUOERVxwpwUT7yKqSKqJeIr7J" }¶
Another example of a different JWK for the Bls12381 curve where the public key is in the G1 subgroup.¶
{ "kty": "OKP", "crv": "Bls12381G1", "d": "PV21Ysd3RNtDBzx94WOkIItSdMkMx0xdjtVFWen9xy8", "x": "jQb7AerHCU1Zf7oUCMYioqAkK_Q35-hDmg9cKhIJzGyZmQgb4saO376vjmGkvaLC" }¶
An example JWK for the Bls12381 curve where the public key is in the G2 subgroup.¶
{ "kty": "OKP", "crv": "Bls12381G2", "d": "CUrC9Xp5pEonbFaykalWlbNYYwueJlcuoOexhEhpu0k", "x": "rvdKcdkxwlj0Y-XZsFpz1hDPJGjnLN27IJipbmaLlaKdYfICGG6dzakG6EkdcvW0AtVV6hXBSKtdFnKQKmmD759tMYYuvKYf5o2cZnROLN5iWQ2H6vp6FlLi71a_AE5I" }¶
Another example of a different JWK for the Bls12381 curve where the public key is in the G2 subgroup.¶
{ "kty": "OKP", "crv": "Bls12381G2", "d": "oF2xFR6Iu3aWQARjHFdmNjeZBKuSO6q1DA1t2ucNHyc", "x": "pHufIAzbxDG-oaD0Kb1BcRsDpjw0JX3h6FHRJQpuYSpqQr_sZigCD3UOTrDO2YEvAxiC6GZXZvlwkqSIOVHRWAwRt2loaqAu6jFiL0L0r8LuXhBxX0tvfPX1UhYgcl3_" }¶
The authors would like to acknowledge the work of Kyle Den Hartog, which was used as the foundation for this draft.¶
-00¶