[Cfrg] Citing specs in specs

[Paul Hoffman <[e-mail]>]

[[ Subject line changed to be relevant to the discussion ]]

On Mar 1, 2014, at 4:16 AM, Robert Ransom <[e-mail]> wrote:

> On 2/28/14, David McGrew <[e-mail]> wrote:
>> I am wary of relying on the curve25519 paper as a normative reference.
>> Perhaps your goal here is to provide an informational document (the
>> draft that you mention above) that offers implementation guidance,
>> instead of a normative reference?
> 
> RFC 4492 (ECC ciphersuites for TLS) cites ANSI X9.62, IEEE 1363, and a
> few documents labeled as ‘standards’ by the corporations which
> authored them as normative references.  It cannot be implemented
> without the information in ANSI X9.62 and IEEE 1363.  ANSI X9.62 is
> available from ANSI for 100 USD; IEEE 1363 is available from ANSI for
> 168 USD.

I have been told by implementers that you can implement RFC 4492 just fine without those references, only with [SECG]. What information in the ANSI and IEEE spec do you feel is needed to implement 4492?

> It is true that the author of the Curve25519 paper is neither a large
> corporation nor an organization with “Standards” in its name, and did
> not label Curve25519 as a ‘standard’ in the paper's title.  However,
> the Curve25519 scalar multiplication function specified in the paper
> became a ‘standard’, in the sense which IETF claims to use the word,
> when software developers came to the rough consensus that it was a
> good cryptographic primitive to use, and wrote and deployed running
> code which implements it.  

That is not the sense which the IETF claims to use the word.

> The Curve25519 paper is available for free
> from the URL <http://cr.yp.to/ecdh/curve25519-20060209.pdf>.
> 
> What is your objection to using the Curve25519 paper as a normative
> reference for the standard Curve25519 scalar multiplication function?

The paper is at a URL; the contents of that URL can change any time. RFCs can sometimes make normative reference to URLs that seem very stable, and Dan's might or might not be. Dan has a history of poking at the IETF (sometimes for good reason), so it is quite believable that he might change the contents of that URL just to make a point. Having a more stable reference would clearly be better.

--Paul Hoffman