diff options
Diffstat (limited to 'proposals/162-consensus-flavors.txt')
| -rw-r--r-- | proposals/162-consensus-flavors.txt | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/proposals/162-consensus-flavors.txt b/proposals/162-consensus-flavors.txt index da14057..caff96c 100644 --- a/proposals/162-consensus-flavors.txt +++ b/proposals/162-consensus-flavors.txt @@ -5,7 +5,6 @@ Created: 14-May-2009 Target: 0.2.2 Status: Open - Overview: This proposal describes a way to publish each consensus in @@ -67,8 +66,8 @@ Spec modifications: The supported consensus flavors are defined as part of the authorities' consensus method. - For each supported flavors, every authority calculates another - consensus document of as-yet-unspecified format, and exchange + For each supported flavor, every authority calculates another + consensus document of as-yet-unspecified format, and exchanges detached signatures for these documents as in the current consensus design. @@ -112,7 +111,7 @@ Spec modifications: Documents = Document* Document = "document" SP flavor SP SignedLength 1*(SP AlgorithmName "=" Digest) NL - Signatures = Signature * + Signatures = Signature* Signature = "directory-signature" SP algname SP identity SP signing-key-digest NL signature @@ -141,15 +140,15 @@ Spec modifications: 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 + digest of the item to be signed. When checking signatures, + the signature MUST be treated as valid if the signature material begins with SHA256(SHA256(document)); this allows us to add other data later. Considerations: - We should not create a new flavor of consensus when adding a - field wouldn't be too onerous. + field instead wouldn't be too onerous. - We should not proliferate flavors lightly: clients will be distinguishable based on which flavor they download. @@ -159,7 +158,7 @@ Migration: - Stage one: authorities begin generating and serving consensus-index files. - - Stage two: Caches begin downloading consenusus-index files, + - Stage two: Caches begin downloading consensus-index files, validating them, and using them to decide what flavors of consensus documents to cache. They download all listed documents, and compare them to the digests given in the @@ -176,3 +175,4 @@ Acknowledgements: Aspects of this design and its applications to hash migration were heavily influenced by IRC conversations with Marian. + |