Thanks. Makes sense to me now.  Appreciate the info.

Paul



On 12/3/12 2:53 AM, "Ben Laurie" <[email protected]> wrote:

>On 30 November 2012 17:27, Paul Lambert <[email protected]> wrote:
>>
>>
>> On 11/30/12 6:17 AM, "Ben Laurie" <[email protected]> wrote:
>>
>>>On 29 November 2012 15:55, Paul Lambert <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>>Structure of the Merkle audit proof:
>>>>>
>>>>>       struct {
>>>>>           opaque sha256_hash[32];
>>>>>       } MerkleNode;
>>>>>
>>>>>       struct {
>>>>>           Version version;
>>>>>           LogID id;
>>>>>           uint64 tree_size;
>>>>>           uint64 timestamp;   <------------------------------ not
>>>>>necessary
>>>>>           uint64 leaf_index;
>>>>>           MerkleNode audit_path<0..2^16-1>;
>>>>>           TreeHeadSignature tree_head_signature;  <--- contains
>>>>>timestamp
>>>>>       } MerkleAuditProof;
>>>
>>>Not sure why you think the timestamp is not needed?
>>
>> There are two timestamps Š  one in the tree_head_signature and one on
>>the
>> Audit Proof.
>> The timestamp within tree_head_signature is very useful.
>> Not sure the intent of the usage and benefit of the additional timestamp
>> on MerkleAuditProof.
>> Seems that the timestamp with the tree_head_signature would always be
>>the
>> definitive creation time.
>
>I trust this is explained by Emilia's post? In case it isn't: the
>TreeHeadSignature is just a signature, the timestamp in the audit
>proof _is_ the timestamp the THS signs.
>
>> However Š 03 no longer has the MerkelAuditProof structure
>
>That's because we now define the log API in terms of JSON.
>
>> The SignedCertificateTimestamp is similar and has two timestamps.
>>Clarity
>> on the need and utilization of two time values would be useful.
>
>Same thing.
>
>>
>>
>> Paul
>>>
>>>>>
>>>>>
>>>>
>>

_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey

Reply via email to