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

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2013 18:02:11 -0500

---------- Forwarded message ----------
From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, Dec 11, 2013 at 4:50 PM
Subject: Re: [perpass] Draft charter for a Transparency Working Group
To: Ben Laurie <[email-masked]>
Cc: Dave Crocker <[email-masked]>, perpass <[email-masked]>, "
[email-masked]" <[email-masked]>

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

> On 11 December 2013 18:41, Dave Crocker <[email-masked]> wrote:
> > On 12/11/2013 10:32 AM, Ben Laurie wrote:
> >>
> >> 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.
>
> Am I allowed to refer to RFC 6962 for background?
>
> Reiterating what's in there doesn't seem useful.

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/

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

---

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:
> On 12/11/2013 1:56 PM, Ben Laurie wrote:
>>
>> Agree, I just want to be able to refer to 6962 for what
>> "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.

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