Re: [Cfrg] normative references

[Paul Hoffman <[e-mail]>]

In general: RFCs are used by different people for wildly different reasons. If you make a statement in an RFC that could use some deeper explanation and you leave that explanation out, you can rest assured that someone will implement (or try to correct a working implementation) and not understand what you left out. We have 40 years of experience with this problem.

It is fine for you to create an RFC that just lists curves and does not show how to implement them interoperably. However, if you do, you need to say that is what you are doing right up front *and* resist the temptation to help on implementation at all. Also, you then need to deal with the fact that there will be five other RFCs afterwards that will show how to implement for TLS / IPsec / S/MIME / PGP ..., and they may or may not all line up. Again, there are plenty of people here with tooth marks on our asses from this.

And: this is a volunteer effort on everyone's part. We all want everything so that we don't have to deal with the inevitable problems later. But none of us did this before you, even though the data has been there. So: thank you and we have more requests. :-) :-(

> Do you really think everyone implementing P256 does it themselves? Or do they
> take example code from the Internet?

"Or" is unfortunately the wrong conjunction. Plenty of people take sample code from the Internet *and* then tweak it because they think they're smart. If you don't warn about things that they can do wrong but still be interoperable, someone is likely to do it. A fair amount of practical cryptography is hand-holding (and trying to move the most dangerous choices further out of reach...).

>> Hex fits better in an RFC ...  decimal would be fine also.
> 
> Six of one, half-dozen of the other.

You would think, until you see a "10" and don't get that is in hex. If you use hex anywhere (and you will), you should try to use it everywhere except for one-digit values less than 0xa.

> What do you propose for the name scheme? E,M with prime in the expc
> format is my best proposal, but this might not be unique all the time.

With respect to naming: given enough elapsed time, your name system will *always* fail. Pick something that fill all of your needs now and has a hopefully-reasonable extension mechanism and hope for the best.

--Paul Hoffman