search

cfrg / draft-irtf-cfrg-bls-signature

32 stars 16 forks source link

broken links #32

Open kwantam opened 4 years ago

kwantam commented 4 years ago

reported via email:

The first one is in the bibliography of ZCash                                                                                  
(https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-04#ref-ZCash) which                                                 
points to                                                                                                                      

https://github.com/zkcrypto/pairing/blob/master/src/bls12_381/README.md#serialization.                                         

However, the link returns a 404 error. I suppose that the last version of the                                                  
file is this one                                                                                                               

https://github.com/zkcrypto/pairing/blob/bac16ab134ccebf85e58db2ca82ef56dba73ae56/src/bls12_381/README.md#serialization        

The second is about a reference in the Section 4.2. It is written                                                              

> These ciphersuites use the hash-to-curve suites BLS12381G1_XMD:SHA-                                                          
> 256_SSWU_RO_ and BLS12381G2_XMD:SHA-256_SSWU_RO_ defined in                                                                  
> [I-D.irtf-cfrg-hash-to-curve], Section 8.7.                                                                                  

However, Section 8.7 is about "Suites for secp256k1". I suppose that the                                                       
section you targeted is Section 8.8 about "Suites for BLS12-381".
lgremy commented 4 years ago

Hi, another possibility for the first link is to refer to Appendix C of Pairing-Friendly Curves. If I correctly understand #18, it was one of the point of this issue. Thanks for your work.

dot-asm commented 3 years ago

another possibility for the first link is to refer to Appendix C of Pairing-Friendly Curves.

One should wonder what is the most appropriate place for specification of the serialization procedure. Arguably the referred draft is probably the least appropriate place. Because draft's subject matter is not actually dependent on serialization format, and appendix can even be omitted from the draft without loosing the overall meaning.

The same line of reasoning can be applied even to this draft. Indeed, can the suggested schemes be implemented with arbitrary serialization format? Unequivocally yes. However, this draft gets pretty "close" to real-life applications, and one can argue that a concrete example of serialization procedure would be appropriate.

In other words, if anything, it would be appropriate to move the serialization specification from draft-irtf-cfrg-pairing-friendly-curves to this draft. As "a concrete example" and not necessarily as absolute requirement.

dot-asm commented 3 years ago

As "a concrete example"

In which case, it would be arguably appropriate to eliminate ambiguity by spelling the following natural constraint in deserialization. Outputs from OS2IP calls should be checked for being less than curve modulus.

dot-asm commented 3 years ago

it would be arguably appropriate to eliminate ambiguity...

To recap. Formally speaking serialization is ultimately an application matter, hence serialization specification doesn't really belong is this draft (let alone "pairing-friendly curves" draft). However, it would be only appropriate to formulate minimum requirements for for serialization format to fulfill. And the quoted line is such minimum requirement. This is irregardless of what happens to reference to Zcash format, moved, omitted, whatever.