‹‹‹‹
On 1/21/14, 2:46 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote:
>
>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:-)
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.
>
>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
