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

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 18:32:59 +0000

http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Dec 2013 10:41:20 -0800

> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html

The text isn't a draft charter.  It's a very generic statement of an 
idea.  Formulating that into the detail an actual charter will be helpful.

The text needs to give some explanation of what is being proposed, 
beyond a highly cryptic label like "Cryptographically verifiable logs". 
  A term like that could mean many things and from the message, I can't 
tell what is meant.

The text needs to explain what sort of usage scenario is expected, with 
enough detail to make the scenario substantive.  That permits the reader 
to get a sense of basic/likely relevance to operational environments.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 18:52:56 +0000

On 11 December 2013 18:41, Dave Crocker <[email-masked]> wrote:
> The text isn't a draft charter.  It's a very generic statement of an idea.
> Formulating that into the detail an actual charter will be helpful.
>
> The text needs to give some explanation of what is being proposed, beyond a
> highly cryptic label like "Cryptographically verifiable logs".  A term like
> that could mean many things and from the message, I can't tell what is
> meant.
>
> enough detail to make the scenario substantive.  That permits the reader to
> get a sense of basic/likely relevance to operational environments.

Am I allowed to refer to RFC 6962 for background?

Reiterating what's in there doesn't seem useful.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2013 16:50:08 -0500

On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie <[email-masked]> wrote:

> idea.
> beyond a
> to

Well how far do we want the group to be allowed to stray from RFC 6962?

One approach would be to divide the problem up into two parts:

* An append only log that provides a cryptographic assurance of integrity
that is independent of the trustworthiness of the log maintainer from the
time of the last checkpoint.

* Application of the above to the specific use cases

Initial use cases that the WG agreed to deliver might be

* PKIX certificate signing certificates
* PKIX TLS end entity certificates

Use cases that are in scope but without a delivery undertaking might be
OpenPGP, S/MIME, etc.

-- 
Website: http://hallambaker.com/

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 21:56:55 +0000

> Use cases that are in scope but without a delivery undertaking might be

Agree, I just want to be able to refer to 6962 for what
"cryptographically verifiable log" means.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Dec 2013 14:02:17 -0800

> "cryptographically verifiable log" means.

Being able to cite a doc that defines the term is always nice; so yes, 
please do cite freely.

My own view is that charters need to have some pedagogy, since one goal 
of a charter is to explain the work to folk who might get involved 
(eventually).  While a citation is formally sufficient, it's not the 
best pedagogy.  So I tend to prefer to have a charter be somewhat 
self-explanatory about its basic constructs, unless they are already 
very well established in industry.

In this case, I think what you mean is /not/ obvious to a reader who is 
not already immersed in the topic.  So some sort of superficial 
explanation would help, with the citation pointing the reader to the 
deeper discussion.

d/

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Dec 2013 15:48:31 -0800

> "cryptographically verifiable log" means.

Dear Ben,

There was an eXtensible Access Method, XAM, developed by SNIA.  This permitted vendors a means to implement strategies for handling massive amounts of data in a manner called Content Addressable Storage, such as EMC^2's Centera product. The data blobs create multiple secure hashes that act within a standardized label. The blobs are combined with timestamps and XML MIME tags. This removes a need for difficult to manage file hierarchy.  One of the benefits of this scheme is data can not change without detection.

SNIA now seems focused on identifying individuals.  Perhaps this is an outgrowth of their data-deduplication?
http://www.snia.org/tech_activities/standards/curr_standards/xam

Regards,
Douglas Otis

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 10:59:55 +0000

[please include therightkey on replies]

On 11 December 2013 22:02, Dave Crocker <[email-masked]> wrote:
> My own view is that charters need to have some pedagogy, since one goal of a
> charter is to explain the work to folk who might get involved (eventually).
> While a citation is formally sufficient, it's not the best pedagogy.  So I
> tend to prefer to have a charter be somewhat self-explanatory about its
> basic constructs, unless they are already very well established in industry.
>
> In this case, I think what you mean is /not/ obvious to a reader who is not
> already immersed in the topic.  So some sort of superficial explanation
> would help, with the citation pointing the reader to the deeper discussion.

How about this footnote?

"A cryptographically verifiable log is an append-only log of hashes of
more-or-less anything that can prove its own correctness
cryptographically. See RFC 6962,
http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf and
http://www.links.org/files/RevocationTransparency.pdf for background."

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 11:06:25 +0000

On 11 December 2013 23:48, Douglas Otis <[email-masked]> wrote:
> There was an eXtensible Access Method, XAM, developed by SNIA.  This
> permitted vendors a means to implement strategies for handling massive
> amounts of data in a manner called Content Addressable Storage, such as
> EMC^2's Centera product. The data blobs create multiple secure hashes that
> act within a standardized label. The blobs are combined with timestamps and
> XML MIME tags. This removes a need for difficult to manage file hierarchy.
> One of the benefits of this scheme is data can not change without detection.

A brief romp through the spec suggests that XUIDs could be hashes, but
don't have to be. In particular, identical XSets do not have to have
identical XUIDs.

In the case where they are hashes (or are otherwise one-to-one linked
to XSets), then a transparent log might well be usefully applied to
them.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Dec 2013 08:58:31 -0500

> to XSets), then a transparent log might well be usefully applied to

If we get into that area I have to point out that I am currently engaged by
a client who is defending a case in which a relevant patent is being
asserted.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Dec 2013 11:36:44 -0500

Ben

> cryptographically. See RFC 6962,
I'd like something a bit more technical, since the phrase "prove its
own correctness" is pretty general. Hopefully there is text in 6962
that you can use.

Steve

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Dec 2013 08:40:30 -0800

> own correctness" is pretty general. Hopefully there is text in 6962

Ben,

The other piece of information I'm suggesting is some text that explains 
how this mechanism will be used for the purpose that's claimed.  Enough 
text to make clear why this is useful work.

Although the utility might seem intuitively obvious (to some folk), 
having the charter make this explicit will help other readers who are 
less immersed in the topic.

d/

---

From: Paul Lambert <[email-masked]>
Date: Thu, 12 Dec 2013 08:48:26 -0800

On Dec 11, 2013, at 1:56 PM, Ben Laurie <[email-masked]<mailto:[email-masked]>> wrote:

Dear Ben,

Interesting … in IEEE we’re  defining ‘services’ as a hash/UUID-like identifier https://mentor.ieee.org/802.11/dcn/12/11-12-0706-00-0isd-service-discovery-proposal.pptx ).  UPnP and Bonjour are both mapped to a hash.  We’re truncating them to 6 octets … but that’s a different discussion.

In looking at Transparency for “X”, I’d suggest that the X can be an arbitrary service identified as a hash.

Paul

Regards,
Douglas Otis

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 18:51:50 +0000

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.

On 12 December 2013 16:36, Stephen Kent <[email-masked]> wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Dec 2013 09:08:30 -0500

> own correctness" is pretty general. Hopefully there is text in 6962

How about just call it a catenate certificate append-only notary log which
is the technical term of are that Harber and Stornetta introduced in their
paper and patents?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Dec 2013 09:17:05 -0500

> efficiently detected and proved to the world at large.”

I disagree. The Merkle tree part is only relevant to verification
efficiency. And I would want to look into it a lot further before
committing to that particular approach due to the Micali patents and other
patents applying Merkle to catenate certs.

The property that is important is the chaining of one hash to the next and
that is the property that is definitively out of patent.

For email security I am not planning to use trees at all or at least not in
that way. Chains are simpler to debug and the additional overhead largely
irrelevant as all the certificate validation and evaluation can be done
offline.

Latency is not a concern as this is a store and forward protocol or a
messaging protocol. The time it takes someone to pick up the phone is
always going to be much longer than any key evaluation process.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 13 Dec 2013 14:25:24 +0000

On 13 December 2013 14:17, Phillip Hallam-Baker <[email-masked]> wrote:
> efficiency. And I would want to look into it a lot further before committing
> to that particular approach due to the Micali patents and other patents
> applying Merkle to catenate certs.

You disagree that RFC 6962 provides an example? I'm not sure what
you're disagreeing with...

> that is the property that is definitively out of patent.

The property that is important is the ability to prove correctness, by
whatever means.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Dec 2013 10:36:32 -0500

Ben,
> and http://www.links.org/files/RevocationTransparency.pdf for
Sorry to be so late in responding; holidays ...

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.

Steve