Re: [therightkey] IESG eval of charter

[Paul Lambert <[e-mail]>]

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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/therightkey
>
>_______________________________________________
>therightkey mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/therightkey