Subject: Re: [saag] [perpass] Draft charter for a Transparency Working Group

From: Ben Laurie <[email-masked]>
Date: Mon, 6 Jan 2014 17:02:14 +0000

On 30 December 2013 15:36, Stephen Kent <[email-masked]> wrote:
> Ben,
>
>> How's this?
>>
>> [1] A cryptographically verifiable log is an append-only log of hashes
>> of more-or-less anything that can prove its own correctness
>> cryptographically.
>>
>> For example, from RFC 6962: “The append-only property of each log is
>> technically achieved using Merkle Trees, which can be used to show
>> that any particular version of the log is a superset of any particular
>> previous version. Likewise, Merkle Trees avoid the need to blindly
>> trust logs: if a log attempts to show different things to different
>> people, this can be efficiently detected by comparing tree roots and
>> consistency proofs. Similarly, other misbehaviours of any log (e.g.,
>> issuing signed timestamps for certificates they then don't log) can be
>> efficiently detected and proved to the world at large.”
>>
>> See RFC 6962,
>> http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
>> and http://www.links.org/files/RevocationTransparency.pdf for
>> background.
>>
> Sorry to be so late in responding; holidays ...

Likewise.

> The text describing how 6962 uses Merkle trees is good. I think the
> phrase "prove its own correctness" is way too broad. The example
> you cite shows how to demonstrate internal consistency for a log,
> and to enable third parties to verify certain lob properties. That
> is much narrower than what the term "correctness" implies.

How about, instead of "can prove its own correctness
cryptographically", we say "allows efficient verification of
behaviour"?

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 16:10:50 +0000

On 6 January 2014 17:20, Robin Wilton <[email-masked]> wrote:
> Hi all -
>
> A further suggestion inline. One motivation for my suggesting a change is
> that I am instinctively uneasy when the word "proof" crops up in this kind
> of context. I think what we're doing is providing the means to accrue
> evidence, on the basis of which someone can make an inference as to whether
> correct log behaviour has been recorded.

My suggestion already eliminated the word "proof". But I quite like
your suggestion, too. Note, however, we are on the wrong lists. I will
post a revised draft charter to therightkey shortly.

>
> R
>
>
> On 6 Jan 2014, at 17:02, Ben Laurie wrote:
>
> "A cryptographically verifiable log is an append-only log of hashes,
> structured in such a way as to provide efficiently-accessible,
> cryptographically-supported evidence of correct [log] behaviour".
>
> That way, you capture the following:
>
> - use of hashing/cryptographic mechanisms to maintain the integrity of the
> evidence trail
> - reference to the relevance of structure (Merkle trees)
> - de-coupling of the evidence (signed records) from what it is that the
> evidence is intended to show (correct behaviour)
>
> Hope this helps -
>
> Robin
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Jan 2014 13:19:38 -0500

Ben,

> cryptographically", we say "allows efficient verification of
I still find that phase vague. What sort of behavior is being
verified? Isn't the behavior amenable to verification a function
of the context details? For example, a self-signed cert is
an example of a crypto construct that allows an RP to verify a few
aspect of its "behavior"
      - the public key contained within the cert is matched to the
        private key used to sign it.
     - the cert content was not modified after it was signed

But most of the other semantics of CA-issued certs are not
verified by this construct.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 18:28:45 +0000

> verified by this construct.

As Stephen Farrell has pointed out, therightkey is the correct list
for discussion. I have posted a revised charter there which phrases
this in yet another way. See if you prefer that version.

---

From: Robin Wilton <[email-masked]>
Date: Mon, 6 Jan 2014 17:20:53 +0000

Hi all -

A further suggestion inline. One motivation for my suggesting a change is that I am instinctively uneasy when the word "proof" crops up in this kind of context. I think what we're doing is providing the means to accrue evidence, on the basis of which someone can make an inference as to whether correct log behaviour has been recorded. 

R

> cryptographically", we say "allows efficient verification of

"A cryptographically verifiable log is an append-only log of hashes, structured in such a way as to provide efficiently-accessible, cryptographically-supported evidence of correct [log] behaviour". 

- use of hashing/cryptographic mechanisms to maintain the integrity of the evidence trail
- reference to the relevance of structure (Merkle trees)
- de-coupling of the evidence (signed records) from what it is that the evidence is intended to show (correct behaviour)

Hope this helps - 

Robin

---

From: Mouse <[email-masked]>
Date: Fri, 10 Jan 2014 11:53:31 -0500 (EST)

> [...] I am instinctively uneasy when the word "proof" crops up in
> this kind of context.  [...]

As a mathematician I get similar twitches.  But, in cryptography,
`proof' usually means something more like `the chance of this happening
any way other than the intended one is negligbly small', where
`negligbly small' typically means one chance in 2^128 or thereabouts.
(Obviously, if a cryptosystem is involved, this works only if it is not
breakable by any putative attacker.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B