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/ On 01/22/2014 12:16 AM, Paul Lambert wrote: > > > OHiya, >>> >>> 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:-) >> >> NEW is the first three paragraphs mostly a restructure for readability. > > Ooops - new is the first 4 paragraphs ending at the ³These logs can Š² > >> >> 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. >> >> >> >> >> >> >> >>> >>> 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/ >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
