Subject: [therightkey] Another suggested change

From: Paul Lambert <[email-masked]>
Date: Thu, 29 Nov 2012 07:55:08 -0800

>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;
>
>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 30 Nov 2012 14:17:59 +0000

>>           TreeHeadSignature tree_head_signature;  <--- contains timestamp

Not sure why you think the timestamp is not needed?

---

From: Emilia Kasper <[email-masked]>
Date: Fri, 30 Nov 2012 15:28:30 +0100

> Not sure why you think the timestamp is not needed?

I'm glad to see people verifying the sanity of the structures!

I think I know where the confusion is - in TLS notation,
digitally-signed struct  { } is a signature on the data in the struct;
it does not include the data itself. So TreeHeadSignature is a
signature over timestamp and other bits, but you need to include all
bits needed for verification separately.

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

---

From: Paul Lambert <[email-masked]>
Date: Fri, 30 Nov 2012 09:27:35 -0800

>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.

However Š 03 no longer has the MerkelAuditProof structure

The SignedCertificateTimestamp is similar and has two timestamps. Clarity
on the need and utilization of two time values would be useful.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Fri, 30 Nov 2012 17:39:29 -0800

>bits needed for verification separately.

Thanks! Yes, I was confused by the struct usage as a definition of "input"
to the signature Š just need to read the text an not just the code :-)

Paul

PS - seems like we should have better ways to define protocols Š
PPS - still don't see that the audit path algorithm is correct, should be:

k = k1 + largestPower2(k2-k1)

  PATH(m, D[n]) = PATH(m, D[k1:k]) : MTH(D[k:k2]) for m < k; and

  PATH(m, D[n]) = PATH(m, D[k:k2]) : MTH(D[k1:k]) for m >= k,