On Mon, May 7, 2012 at 5:13 PM, Karsten Loesing
<karsten@xxxxxxxxxxxxxx> wrote:
On 5/6/12 3:36 AM, Damian Johnson wrote:
> First I'd like to make sure that I'm clear on what we're trying to do.
> The javadocs for VerifyDescriptors [1] says that it...
>
>> Verify server descriptors using the contained signing key. Verify that
>> 1) a contained fingerprint is actually a hash of the signing key and
>> 2) a router signature was created using the signing key.
>>
>> Verify consensuses using the separate certs. Verify that
>> 1) the fingerprint in a cert is actually a hash of the identity key,
>> 2) a cert was signed using the identity key,
>> 3) a consensus was signed using the signing key from the cert.
>
> Honestly I'm not yet sure what most of this means. The first #2 is
> simply checking that the descriptor content can be verified using the
> router-signature and signing-key, right?
Yup. But you also need the first #1, or metrics-db could modify server
descriptors at will, put in its own key, and re-sign the descriptor with
that key, and stem would think everything's valid.
Then is it possible that metrics-db modifies the fingerprint at the same time
so that the first #1 would pass? Any why would metrics-db try to do this at
all?
Cheers,
Beck