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
