Proposal 162: Publish the consensus in multiple flavors

[Sebastian Hahn]

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