couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "SignedDocuments" by ChrisAnderson
Date Tue, 31 Mar 2009 03:11:19 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by ChrisAnderson:
http://wiki.apache.org/couchdb/SignedDocuments

The comment on the change is:
note about signing artifacts

------------------------------------------------------------------------------
  
  Note that the key does not directly sign the document. This is so that the signature can
also encompass metadata like the creation and expiration dates. Also, it would be feasible
to separate the signature from the document entirely, and store it elsewhere, since its `digest`
field uniquely identifies the document it signs.
  
- === Canonicalizing JSON ===
+ === Processing JSON for Signing ===
  
  A single object can be represented by multiple different JSON strings, with different sequences
of bytes, since key/value pairs may be rearranged, whitespace added or removed, and different
Unicode encodings used. It's possible for the byte representation to change in transit, if
the document is parsed into a data structure and then re-serialized. This would prevent the
recipient from being able to verify the signature.
  
+ The signature has to be generated from a ''repeatable representation'' of the JSON. The
important aspect is that the algorithm which generates the signing artifact can be generated
reliably and repeatedly from the transferred text. It may be best to link to the algorithm
which generates the signing artifact, or otherwise include the algorithm in the signature
itself, so that the signature can be verified across time and space.
+ 
- So the signature has to be generated from a ''canonical representation'' of the JSON. There
is no standard for this yet, but [http://www.unicode.org/reports/tr15/ the OLPC group has
documented one] that's pretty reasonable:
+ There is no standard for this yet, but [http://www.unicode.org/reports/tr15/ the OLPC group
has documented one] that's pretty reasonable:
  
   * No whitespace.
   * No escape sequences in strings other than `\"` and `\\`. All other characters must be
represented literally, including control characters.

Mime
View raw message