On 22 January 2014 13:17, Stephen Farrell <[email protected]> wrote: > > 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.)
I like that version. > > 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/therightkey >>> >>> _______________________________________________ >>> therightkey mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/therightkey >> >> _______________________________________________ >> therightkey mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/therightkey >> >> > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
