couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <j...@mooseyard.com>
Subject Re: Proposal for digital signatures of documents
Date Mon, 09 Mar 2009 16:27:54 GMT

On Mar 8, 2009, at 2:25 PM, Noah Slater wrote:

> SSL client/server certificates can be used to verify identity.

Right, and the P2P message-passing code I've written in the past makes  
use of that. But knowing the identity of the peer you're connected to  
is not the same thing as knowing the identity of the author of a piece  
of content sent to you by that peer ... at least not if your topology  
consists of more than two nodes :)

> Unless the community is willing to standardise a JSON canonicalisation
> specification through a standards body like the IETF, I'm going to  
> loose
> interest, and I rather suspect others will do so too.

*blink* Um, sure. Maybe we could add it as an appendix to the CouchDB  
RFC — what was its number again?

Seriously: This is a tangential digression at this point —  
canonicalization is merely a detail, albeit a messy one. At this early  
stage of "throwing things against the wall and seeing what sticks",  
I'm more interested in comments about the big picture. The IETF itself  
calls for "rough consensus and running code" (to quote David Clark.)  
It's premature to talk about standardization until we have more to  
discuss.

But yes, I've written formal specs before, and I'd be glad to file an  
Internet-Draft on signing JSON ... once there's something there to  
document.


Dirk-Willem.van.Gulik@bbc.co.uk wrote:
> The IETF has just about the lowest barrier to entry of any standards
> organisation and is very efficient at supporting community efforts  
> which
> are backed by running code.

It's not always that smooth. The standardization process of Atom  
(syndication and publishing) looked pretty torturous from my  
observers' perspective. (Although ultimately worth it, in comparison  
with the horrible example of RSS.)

—Jens
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message