[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Proposal 162: Publish the consensus in multiple flavors



I like the proposal, it's a big step towards getting new features into the users' hands faster. I have just one question that popped up:

On May 15, 2009, at 7:05 PM, Nick Mathewson wrote:

   Each Document line describes the length of the signed portion of
   a consensus (the signatures themselves are not included), along
   with one or more digests of that signed portion.  Digests are
   given in hex.  The algorithm "sha256" MUST be included; others
   are allowed.

   The algname part of a signature describes what algorithm was
   used to hash the identity and signing keys, and to compute the
   signature.  The algorithm "sha256" MUST be recognized;
   signatures with unrecognized algorithms MUST be ignored.
   (See below).

[snip]

   4.1. The "sha256" signature format.

   The 'SHA256' signature format for directory objects is defined as
   the RSA signature of the OAEP+-padded SHA256 digest of the SHA256
   digest of the the item to be signed.  When checking signatures,
   the signature MUST be treated as valid if the signed material
   begins with SHA256(SHA256(document)); this allows us to add other
   data later.

Somehow, this sections seems to create a dependency on sha256, as I don't see how we could quickly migrate away from that, if we needed to. Maybe I'm understanding this wrong, but I have the impression that clients could assume that if the sha256 signature is correct, they don't need to verify any other signatures that they recognize. Imo, they should verify those, as well, and only treat the document as valid if all signatures match?


Sebastian