Re: Integrity protection for RFCs (was Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of) draft-ietf-json-text-sequence-09)

[manning bill <[e-mail]>]

this seems silly.  one reason the rocs were widely distributed in both electronic and hardcopy forms was to enable running diffs to check.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 8December2014Monday, at 20:52, Nico Williams <[e-mail]> wrote:

> 
> On Sat, Dec 06, 2014 at 11:37:45PM +0000, Dave Cridland wrote:
>> On 6 December 2014 at 22:49, <[e-mail]> wrote:
>>> Security pedants might wonder why there is no easy way to authenticate
>>> electronic copies of RFCs, given the vast array of security-related
>>> protocols that the IETF has defined. How can I check the integrity of an
>>> RFC document and that it hasn't been tampered with? I imagine an MD5sum
>>> just won't do.
>> 
>> All the copies I'm reading are properly signed, according to RFC 4637. If
>> yours aren't, maybe they *have* been tampered with.
> 
> Maybe each RFC should be like a commit in any modern version control
> system, complete with a commit hash binding all past RFCs into each new
> RFC.
> 
> Of course, that would really bind us to having canonical RFC
> representations, and/or new renderings by the RFC-Editor added as
> "commits".
> 
> Then we could reference RFCs as RFC-af551e0 (short-form) and
> RFC-af551e089ca623216a312e475a6837de0aa7995b (long-form) and so on :) in
> mailing list discussion, verbally, in RFCs as rendered, in other
> documents, ..., and by doing so we'd be embedding the commit hashes of
> the entire RFC series deeply into the Internet, in a way that would be
> quite difficult to tamper with.
> 
> No digital signatures needed, just a decent hash function.
> 
> Or at least that's what I think Lloyd was suggesting.
> 
> I leave it to others to make a serious proposal along these lines.
> 
> (We can't quite adopt a VCS for this: we'd have to standardize it.)
> 
> Nico
> -- 
>