Re: [Cfrg] BLS standard draft

John Mattsson <john.mattsson@ericsson.com> Tue, 05 March 2019 13:48 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC73131268 for <cfrg@ietfa.amsl.com>; Tue, 5 Mar 2019 05:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=X22OV2LM; dkim=pass (1024-bit key) header.d=ericsson.com header.b=e8FhVuo6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RbxF_Vxe02M for <cfrg@ietfa.amsl.com>; Tue, 5 Mar 2019 05:48:06 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925EB131140 for <cfrg@irtf.org>; Tue, 5 Mar 2019 05:48:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551793681; x=1554385681; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2ck+xYizIx2diVUSrue0T3WKegsXSeCJwg9s0guL6Z4=; b=X22OV2LMDvBVuqpUGDA+WNCe3ACyBgUatE7iT6ZQEfudbhlRT2/8VwHuky1csmF4 mbHOoB9mK4ONFhgnIZrlAOR2NeYw0jFxLjsL/V7Jwx6npvoKg8GKVl7//NY0iZAC OjoRJOvthWMWiaPphy9byforkVKm1Vu2TCdbmZhAf7A=;
X-AuditID: c1b4fb2d-d9dff7000000062f-d2-5c7e7e1107cb
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.CC.01583.11E7E7C5; Tue, 5 Mar 2019 14:48:01 +0100 (CET)
Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB503.ericsson.se (153.88.183.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 14:48:01 +0100
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 14:48:01 +0100
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 14:48:01 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2ck+xYizIx2diVUSrue0T3WKegsXSeCJwg9s0guL6Z4=; b=e8FhVuo6UOtCI8Pqay2Zom9GPO4GvBrZWQZPhc+josh4Bmfjvy+rq7a2JtJnAhJvkP6gB0N/CS3cMgxdODpbNFkBNaw5dLDTsVoxma40BwrjVJzEcngMxlMG+qq6CLjwvi8XmD3ijCPD76Bl0QMMmJBg1k3/TJFP5PYRf0y2VFA=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3321.eurprd07.prod.outlook.com (10.170.246.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.14; Tue, 5 Mar 2019 13:47:59 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 13:47:59 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Sergey Gorbunov <sgorbunov@uwaterloo.ca>, "cfrg@irtf.org" <cfrg@irtf.org>, David Wong <davidwong.crypto@gmail.com>, "ylzhao@fudan.edu.cn" <ylzhao@fudan.edu.cn>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [Cfrg] BLS standard draft
Thread-Index: AQHUy62bRHjJzlw8PUajG5tI8LwjdqX9LX0A
Date: Tue, 5 Mar 2019 13:47:59 +0000
Message-ID: <1F407B07-E1FE-40F5-8C3A-D4FF76577083@ericsson.com>
References: <CACnav0oDeJ14LphESnrsD8C1C+4iFByPqp4tfqxGT4hwbe1ucg@mail.gmail.com>
In-Reply-To: <CACnav0oDeJ14LphESnrsD8C1C+4iFByPqp4tfqxGT4hwbe1ucg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 65f6967c-daf7-46df-37c3-08d6a1712e3a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3321;
x-ms-traffictypediagnostic: HE1PR07MB3321:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzMzIxOzIzOlVYY2FGZmNHdERYRE1YQXVCanJKc290QzhS?= =?utf-8?B?bFZocUlSa1Q4TmRMSFUvQ2F2WUNJNTRmelFTaFMwVUxRd3dVcWxDS0Y2Z1pT?= =?utf-8?B?QytlK2JIaGpVNTBFMEU5eWVNZ29vai9nZ0ZHWk4wUGc2ZDE1NEJrL3MvaURG?= =?utf-8?B?TlY4Z2NGYmJOcEZLd0xrODBpTStUdWNseWN3bnl6M0ErenBwV2VueTNodHpa?= =?utf-8?B?anhvS1FUWkZvdHhwZGhRWlUvSHBzdk5VVUJZK0tWVEZOdWFLYVlQU1YwVnh1?= =?utf-8?B?YVlTZTFSSVlMaGt6QTJmNXpCc1JNeG02a0t3Tm9mTXlQaEJCQzEzVC9PcE9K?= =?utf-8?B?bVpVVmxJTjVTTWQwRmd0ZkZ6QmRINTNaS0dmZlNKTVZkSERWL0Z0NENENW5o?= =?utf-8?B?c3ZYQUJ6WU96WlB3NjQybWZaMW1nUXc2amprQXJOSWlnMkZ4Q3h0YXl3SkpZ?= =?utf-8?B?ZEMzQllkQjhjam05dEdDeTV0bmdveXhueDNUNU41endVb3JKSWt6UmVDaVl6?= =?utf-8?B?NDZubUJiY3ZYMWNnVFM0b2Ftb2hrSzJNVEljOFBpMm5GUmpNQ2s3SWMwSGlq?= =?utf-8?B?cEdVY0l4bHZQcTg0MnFudERjdXBJTWw4SXFMbFZNU01obkxEblFnUHZmV1Rv?= =?utf-8?B?ZDdQd1E4V0ZvWjdTR213bUthRmhYSXNUSGQ3YllsS0wwTTUrd2wraUFPdHJx?= =?utf-8?B?QVRiY1FFclNvVnRaZmM2WVoreGpPSUtLdXE5WDFiOGh4aEV0YmFzcVBFWXpK?= =?utf-8?B?NitydW9taU9IMUoxWG1GWnVtTzd0UTFoVFhaeG5xWDVRQ2VlbXZPNUNzUTJh?= =?utf-8?B?WUwzOXp1M0ZlYS9HUHlhdVBFTi95SHE0M0V2elF6WmYrdGpMbWRJd0hEc2hz?= =?utf-8?B?eVNHaUJRYktXZ2NsMndZNWY2VGxRU2VOVmxlMVVpUWVYdGZKbldLWlNVOEJ1?= =?utf-8?B?SzZGK1BDR2JiSDZlUSthaVFJbDJNR215N2NkWGJnSVRaQndRazEzR2kwSjhJ?= =?utf-8?B?V3dDdjVLSTcvUTR5L1E0NTk1M3l0S21ZRkE2VXdqL1lVQkp4VlFpTHM1dWFM?= =?utf-8?B?UUJoVHNzblFJdmJMclNWdkZFYTN0ckpaOWhyQzFiVXR2RzkwSWNaVm5KdHdE?= =?utf-8?B?YUpWYkZ1Zmwrd1ExOVdPWlhSdUFKYWc0RzhPeGxEOHJ6blBWRVJuNjNCdkRJ?= =?utf-8?B?cllBVFNpakM0SEpsditGWVI5Smg5SnAvMGRTSm1sTmhNWk1CR0ROcE84UnRV?= =?utf-8?B?S014TERnNWVIS29qN3IvQ1VTekZ5cm53SUh4dzNXQUdUbC9aYnZqZjF4M1h6?= =?utf-8?B?cTM3V3FYd1hVdE1zVWtsRDc3ODYwVnFqOGVJMFcwdnBCUkpYSm5wdVltWlZu?= =?utf-8?B?SStZOXN5RlZBZTNocnNPU0ptRERTckZIbno0bit2a1diSlNDTlVGajRGbE5V?= =?utf-8?B?bnJhR3JKQWJnNHNtRTRNckFUdlp1VUJsVDZ0aGQxZy9HN1g4Q2htbHpteG9H?= =?utf-8?B?RHNmaFZIbnJibUo2V0JvZkNZYnlkRnhweXJ6eFFMVjV0SEJzcE9PYUJEbjdI?= =?utf-8?B?R01UQUZnZUN4VUg2R3Z1MHBwak04UXR3RTJvWjlzTisyZkJWRlRUUTNWejE1?= =?utf-8?B?ZUpkZjF3dTdQUWFubjdTbHJnUFdJRkQ3UjNHTDBjUWlTNElIbHJOTWZtTVl3?= =?utf-8?B?K2ZNQ2h1bXJQVHFIdFNZQ0VGQ2RLd0tBOFIyYjJRdzlvL1pRMmNUZlVIUWQv?= =?utf-8?B?ekR3N3lIYngwUk1LZStMTUVFQXBTMmJhREh3SzYzV0VuYjdBd0VSbXpvOUZL?= =?utf-8?B?Q0dzdWkzaVBUbm1yRlhFU1hWUW9WMi9qdHhzOWczOVhhSUp6RDNvb3V2YXdy?= =?utf-8?B?d3FvZjhjZkhQaTlIRVJSY0JrcTNTK3dXbzZtTzdRdyt1NUVrdXM3eVZRem9q?= =?utf-8?Q?9BYf57DwHklndgp/r1Qi/G+inPyF6I=3D?=
x-microsoft-antispam-prvs: <HE1PR07MB3321E5F91423DB0ED09C807F89720@HE1PR07MB3321.eurprd07.prod.outlook.com>
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(136003)(376002)(366004)(55674003)(199004)(189003)(6436002)(36756003)(110136005)(316002)(58126008)(606006)(2171002)(229853002)(53936002)(6486002)(236005)(102836004)(54896002)(6512007)(6306002)(82746002)(6506007)(53546011)(14454004)(478600001)(26005)(2906002)(76176011)(33656002)(6246003)(99286004)(105586002)(68736007)(66574012)(8936002)(486006)(186003)(2616005)(81166006)(106356001)(476003)(14444005)(6116002)(86362001)(7736002)(446003)(2501003)(66066001)(44832011)(790700001)(3846002)(71190400001)(25786009)(256004)(8676002)(81156014)(5660300002)(97736004)(71200400001)(83716004)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3321; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: cqLBq1AQwFYGRX7Hv7Bz+fyK9SrEE1VPsV4gLJqXPt+quzzlAw/SsJ8NFaFkyLxTimX6IYoW58qk57TKTsHrlVZddmQTQblJgqZeVaUJP0k1RVMqkrrxCRomV69MkmOD/GlEgOwphaLG1oqkmakuSKJMcIbwEqHOip0EbBkOJYvFXjDd5KY74WGpGQsAk3GBeFVMhCu/lG/da+pgqiNbObSjXX75cgpgBU5xCyPsHCxF+wa5ICVn6+e3pICL3cdnrbWxFWqiEJOBZvDazK8s5HJikJEgPD0sQHexMw6fJhCH960D1Z7rLnYa4CETEtS/O8zec2d6wa8tT4QG8bPmuoWi+P5dix1f6r7m9Qeg0SiQYOyMbjDDbAF14tggydaFSLbeSP9hfnDk+0z4mLFrE0LeF2FT3DFHY4IetM/pMAA=
Content-Type: multipart/alternative; boundary="_000_1F407B07E1FE40F58C3AD4FF76577083ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 65f6967c-daf7-46df-37c3-08d6a1712e3a
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 13:47:59.6496 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3321
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfO2Y6jweu8PVhRji4q6LxETNSyoFxQpGIkotjS491pOyqZ JKZpXsgsy8tULDUyNcwUpiaUU/OuJX5IwUtqmQoZYpg5JLezwm+/5/n/n/e58NKEeJyypqOU iYxKqYiV8IVkWYAm0cE0LS3I6WGhqyz/dxdPVlLxiC+rWx0VyNL7omWamX6eFyV/NWQnb1dP C+RFzd18edFCNiG/1/aN50MFCj3CmNioZEYlPXVNGPk9MwsldGyimxndmUQ62vyJ8pAJDfgE rK/NkXlISItxD4K35T18LviFQD1STP4P7mznGJUaHug2pwh9QOJCApZfFBkeE+MiHmy9DOdc swierH0W6AU+doLKznRDuTnuRTA60MfTC2b4GMz0aAzV5vg4fJytEXDsAiuluXw9k/gI6D6M GViET0NV8TCVh+jdDj6QW31FnzbBvjBYl03qGWFL2BxsNDxPYCuYWqzicZtiqO0cIzi2gOWF HUrPFlgKrQVzxtpgyMoqoTjPYdCNz/M5PgjjVfnGi12Cdc1rw10ATyJofF5ubGAPXbWrRraG /k+9FGdqMoPGjS1SPzTgGKjOVnB4ANY2BIXIUb1nVI5DobmghVIbNjaFgbJFUr1bQWA7aOqQ chYbeJz/RcCxLWRVVBpZDt3tfYK9nqeIrkcWLMOycREuro6MKiqUZeOVjkom8Q3a/WldrdsO bahh9YwWYRpJ9olaYtKCxJQimU2J0yKgCYm5KPXGbkoUpki5xajiQ1RJsQyrRftpUmIl0olN g8Q4QpHIxDBMAqP6p/JoE+t0dHem4KKOjRga9fDUEBNDncMubsU5tr3nVlv9L6stAyVs8AW3 kQfqCLzSZBN+XTlZMtog9tAeGp/wbfW8L/VcOj/v+ye2VBbzFfv5TKQlCUPeP1vyOhpQnOP/ Y8VDmG3hPe1kdXvdPXAnxHnH/WhGavDJ+mqrq+/O+lHe0SFe7rSEZCMVzvaEilX8BZcWfuZl AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/e4LlrccQbWr_jtz7EJkdQkymXtk>
Subject: Re: [Cfrg] BLS standard draft
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2019 13:48:11 -0000

Hi Sergey,

I think this is interesting and likely something worth spending time on. I agree with the opinion that quantum computers is not a reason to stop looking at this, at least not yet.

Some very quick high level comments:

- It is stated the BLS12-381 yield signature sizes of 48 bytes when signatures are in G1. I think the draft should also state what the public keys sizes are in this case. I assume the "minimizing public key size" option just swap the sizes.

- It would be good if the draft gave some hint to potential implementors regarding the amount of processing required. While short signatures would be good in many IoT applications, I assume that the pairing operations are relatively expensive.

- The curve is called both BLS12-381 and BLS-381, I assume they are the same curve.

My memory of BLS (backed up by a book section by K.G.Paterson that I had in my book shelf) is that BLS signatures where close to half the size of ECDSA (170 vs. 320 bits for 80 bit security), I assume some new attacks have changed this?

/John

From: Cfrg <cfrg-bounces@irtf.org> on behalf of Sergey Gorbunov <sgorbunov@uwaterloo.ca>
Date: Saturday, 23 February 2019 at 20:26
To: "cfrg@irtf.org" <cfrg@irtf.org>rg>, David Wong <davidwong.crypto@gmail.com>om>, "ylzhao@fudan.edu.cn" <ylzhao@fudan.edu.cn>cn>, Eric Rescorla <ekr@rtfm.com>
Subject: Re: [Cfrg] BLS standard draft

Thanks, David and everyone else for the feedback!
We will create a github repository where anyone will be able to view and comment on the latest draft and share the link.

In the meantime, please continue sending us feedback by email.

Regards,
Sergey
web<https://cs.uwaterloo.ca/~sgorbuno/>


On Sun, Feb 17, 2019 at 3:00 PM <cfrg-request@irtf.org<mailto:cfrg-request@irtf.org>> wrote:
Message: 1
Date: Sun, 17 Feb 2019 08:54:36 -0800
From: David Wong <davidwong.crypto@gmail.com<mailto:davidwong.crypto@gmail.com>>
To: ??? <ylzhao@fudan.edu.cn<mailto:ylzhao@fudan.edu.cn>>
Cc: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>, CFRG <cfrg@irtf.org<mailto:cfrg@irtf.org>>,  Sergey
        Gorbunov <sgorbunov@uwaterloo.ca<mailto:sgorbunov@uwaterloo.ca>>
Subject: Re: [Cfrg] BLS standard draft
Message-ID:
        <CAK3aN2r9J9ToH6OZPNqUv4vNPx_DqJM+KQC=X=rfHFEkM5hkdg@mail.gmail.com<mailto:rfHFEkM5hkdg@mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

Hi again,

I am not sure what the process is. If you have a github repo where we
can participate or if you want us to give you feedback here. So here
is some feedback from a first read. Feel free to ignore the bits you
don't agree with of course. Some common themes were:

* Keep in mind that this is for implementations, so remove information
that belongs in a whitepaper
* Make the RFC timeless (we should be able to read it in 5 years and
understand it)
* Set things in stone so that the RFC is actionable, don't make it
vague. If people want to add to it, extensions and updates are
possible later.

And here is the more detailed feedback:

- abstract: re-write with "what is it?" in mind first, history bits
can wait until the introduction. I suggest using developer-friendly
terms like "compression" and define aggregation later if the term is
needed. Example:

    BLS is a digital signature scheme with compression properties.
With a given set of signatures (sig_1, ..., sig_n) anyone can produce
a compressed signature sig_compressed. The same is true for a set of
private keys or public keys, while keeping the connection between sets
(a compressed public key is associated to its compressed public key).
Furthermore, the BLS signature scheme is deterministic, non-malleable,
and efficient. Its simplicity and cryptographic properties allows it
to be useful in a variety of use-cases, specifically when minimal
storage space or bandwidth are required.

- intro:
    - "A signature scheme is a fundamental cryptographic primitive
used on the Internet that is used to protect integrity of
communication" -> not necessarily used on the internet, and not
necessarily for integrity of communications.
    - "2.  Verification requires 2 pairing operations." -> at this
point pairing is not defined, and what does that mean for the
developer? how does it compare to other signature schemes that do not
use pairing?
    - "we believe the scheme will find very interesting applications"
-> too temporal. At some point, it is possible that the scheme will be
popular and this sentence will seem out of place.
    - "the BLS signature scheme is already integrated" -> maybe out of
place (as too temporal as well). If not, sort the list by alphabetical
order, I think no one will mind that.
    - "BLS signatures are used for authenticating transactions as well
as votes during the consensus protocol" -> I suggest we itemize the
different use-cases of BLS (from PKI to blockchain).
- section "1.1.  Terminology"
    - "msg" -> I suggest we change that to "message"
    - "sigma" -> "signature"
    - "signer/verifier/aggregator" do we need roles for these? Can't
we do with just an API ("sign/verify/compress")
    - "P1" is defined but never seem to be used. Am I missing something?
    - I suggest we spell "e()" as "pairing()" in the algorithms, and
define it here
- section "1.2.  Signature Scheme Algorithms and Properties"
    - "A signature scheme comes with" -> "Like most signature schemes,
BLS comes with the following API", this way we can leverage the
reader's knowledge of other signature scheme.
    - "The signing algorithm may be deterministic or randomized,
depending on the scheme" -> as this is a spec, we need to make a
decision here. I think it makes more sense to make it deterministic.
- section "1..2.2.  Security" -> do we need these security properties
in the RFC? It sounds to me like they would belong in a whitepaper
instead..
- section "2."
    - "BLS signatures require pairing-friendly curves" -> I suggest
standardizing BLS with a set of curves. Extensions or updates can
later add more curves if needed.
    - "There are two variants of the scheme" -> It'd be nice if the
two variants were specified in this document, as they both have
use-cases.
    - "Put ... in G1" -> not clear, rephrase
- section "2.1.  Preliminaries". I recommend renaming "suite_string"
to "domain_separator" and having specific values for it instead of
potential values.. (We're standardizing something after all, ideally it
should be self-contained)
- section "2.4.  Verify: Signature Verification"
    - "4.  If r*Gamma != 0, output "INVALID" and stop" -> I had heard
a while ago that this membership check was patented for ECDH. Anyone
remembers something like this?
- section "2.5.  Aggregate"
    - it should be "sigma = E1_to_string(string_to_E1(sigma_1) + ... +
string_to_E1(sigma_n))"
    - you specify verifying aggregates of SAME msg and of DIFFERENT
msgs, but only have the aggregate algorithm for SAME msg specified.
- section "2.5.3.  Implementation optimizations". Two things:
    - this should be towards the end of the documentation as these are
optional recommendations. Perhaps after "security recommendations" or
as an appendix
    - is it really wise to have the standard contain this? Available
optimizations may change over time. I've also never seen an RFC
talking about optimizations.
- section "2.7.  Security analysis" -> I don't think this is necessary
to have that in the RFC.
- section "3.1. Verifying public keys"
    - define "G2 membership test"
    - "to prevent rogue key attacks" -> needs a reference
- section "3.4. Randomness considerations" needs a citation, for
example on ECDSA issues when the nonce is repeated
- section "4.  Implementation Status". Standards usually don't refer
to implementations AFAIK. I imagine this is because their state can
change, and new good implementations can arise after the RFC is set in
stone. I think this is good to have in the draft though, so perhaps
add an indication somewhere that this will be deleted in the final
document.
- section "6.  IANA Considerations". Do we need this?
- section "2.6.1.  Preliminaries", "In fact, we will pad each
substring with 0s so that the length of each substring is a multiple
of 8." specify that this is in bits.

Cheers,
David