Subject: [therightkey] IESG eval of charter

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jan 2014 22:46:35 +0000

Hiya,

Getting a number of comments [1] from IESG folks that
the charter's not so easy to grasp for non CT-aware
folks.

My current try at fixing that at [2]. Please suggest
any *necessary* changes by tomorrow if you can. (And
in OLD/NEW format please, just to be nice to me:-)

Bear in mind that we're developing the charter text
that will go to IETF review, so this need not be the
final final thing, e.g. the final wordsmithing polish
can be done later.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-trans/ballot/
[2] https://datatracker.ietf.org/doc/charter-ietf-trans/

---

From: Paul Lambert <[email-masked]>
Date: Tue, 21 Jan 2014 15:38:34 -0800

‹‹‹‹

>in OLD/NEW format please, just to be nice to me:-)

NEW is the first three paragraphs Š mostly a restructure for readability.

Paul

- - - - -

Cryptographic logs provide a mechanism to publish a list of events that
can be verified for correct ordering and content.  The logs are
append-only and can be efficiently verified by the world at large for
correct log behavior.  Certificate Transparency (CT, RFC6962) logs the
issuance of X.509 certificates.  The CT log enables the detection of
mis-issued certificates providing validation of correct CA operation.  The
working group will produce a standards-track version of the experimental
CT RFC 6962 reflecting implementation and deployment experience since that
specification was completed.

Many other Internet protocols besides X.509 map public keys to some kind
of identifier and would benefit from a verifiable log These possible
application of a cryptographic log include: SMTPS, IPSec, DNSSEC and
OpenPGP. 

These protocols rely on either ad-hoc mappings, (as in a web of trust), or
on authorities (such as CAs) that attest to the mappings. History shows
that neither of these mechanisms is entirely satisfactory.  Ad-hoc
mappings are difficult to discover and maintain, and authorities make
mistakes or are subverted.  Cryptographically verifiable logs can be used
to support these and other protocols to maintain consistent and correct
mappings.  Errors or subversion of the mappings can be detected and
corrected to minimize any adverse impact.
 
A cryptographically verifiable log is an append-only log of hashes.  The
hashes can represent more-or-less anything and serve as a unique identify
for any information object.  The log is structured to provide efficient
access and cryptographic evidence of correct log operation. The individual
hashes are linked together using Merkle Trees, which can be used to show
that any particular version of the log is a superset of any particular
previous version. 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 misbehaviors 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.

These logs can potentially also assist with other interesting problems,
such as how to assure end users that software they are running is, indeed,
the software they intend to run.

Work items:  

- Publish an update to RFC 6962 as a standards-track mechanism to apply
verifiable logs to HTTP over TLS.  As DANE (RFC6698) provides an
alternative keying infrastructure to that used in the current web PKI, the
working group should consider appropriate client behavior in the presence
of both DANE-based keying and current web PKI when standardising CT.

- Discuss mechanisms and techniques that allow cryptographically
verifiable logs to be deployed to improve the security of protocols and
software distribution. Where such mechanisms appear sufficiently useful,
the WG will re-charter to add relevant new work items.  Should no such
items be chartered the WG will close when documents associated with the
first work item are complete.

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

---

From: Paul Lambert <[email-masked]>
Date: Tue, 21 Jan 2014 16:16:59 -0800

OHiya,
>NEW is the first three paragraphs mostly a restructure for readability.

Ooops - new is the first 4 paragraphs ending at the ³These logs can Š²

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Jan 2014 13:17:13 +0000

Thanks Paul,

I'll hold off on these changes for now as the IESG
are reading this for tomorrow's telechat but we can
look at them again after that. Be good to know if
folks on the list like the changes though. (But
let's not get into wordsmithing.)

Also - I added the following in response to another
comment:

"While the privacy issues related to use of RFC6962 for public
web sites are minimal, the working group will consider privacy
as it might impact on uses of CT e.g. within enterprises or
for other uses of logs."

That's at [1] now.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-trans/

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Jan 2014 03:44:58 +0000

> let's not get into wordsmithing.)

I like that version.