Re: [Cfrg] normative references

Paul Hoffman <> Wed, 15 January 2014 21:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 44FB51AE246 for <>; Wed, 15 Jan 2014 13:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vgcHYHiLiT0V for <>; Wed, 15 Jan 2014 13:51:21 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 1A7291AE41C for <>; Wed, 15 Jan 2014 13:51:21 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id s0FLV0t1085906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jan 2014 14:31:02 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Wed, 15 Jan 2014 13:51:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Watson Ladd <>
X-Mailer: Apple Mail (2.1827)
Cc: "" <>
Subject: Re: [Cfrg] normative references
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jan 2014 21:51:22 -0000

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