Ben tells me he reckons this is ready to do. I plan to give it a read and all being well start IETF LC in the next few days. (Probably for 5 weeks given the holidays.)
So now's a very good time to read this and comment if you care. S. On 12/19/2012 09:16 PM, Ben Laurie wrote: > ---------- Forwarded message ---------- > From: <[email protected]> > Date: 19 December 2012 21:16 > Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt > To: [email protected] > Cc: [email protected], [email protected] > > > > A new version of I-D, draft-laurie-pki-sunlight-04.txt > has been successfully submitted by Ben Laurie and posted to the > IETF repository. > > Filename: draft-laurie-pki-sunlight > Revision: 04 > Title: Certificate Transparency > Creation date: 2012-12-19 > WG ID: Individual Submission > Number of pages: 28 > URL: > http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-04.txt > Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight > Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-04 > Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-04 > > Abstract: > The aim of Certificate Transparency is to have every public end- > entity (for example, web servers) and intermediate TLS certificate > issued by a known Certificate Authority recorded in one or more > certificate logs. In order to detect misissuance of certificates, > all logs are publicly auditable. In particular, domain owners or > their agents will be able to monitor logs for certificates issued on > their own domain. > > To protect clients from unlogged misissued certificates, each log > signs all certificates it records, and clients can choose not to > trust certificates that are not accompanied by an appropriate log > signature. For privacy and performance reasons log signatures are > embedded in the TLS handshake via the TLS authorization extension, in > a stapled OCSP extension, or in the certificate itself via an X.509v3 > certificate extension. > > To ensure a globally consistent view of any particular log, each log > also provides a global signature over the entire log. Any > inconsistency of logs can be detected through cross-checks on the > global signature. Consistency between any pair of global signatures, > corresponding to snapshots of a particular log at different times, > can be efficiently shown. > > Logs are only expected to certify that they have seen a certificate, > and thus we do not specify any revocation mechanism for log > signatures in this document. Logs are append-only, and log > signatures do not expire. > > > > > > The IETF Secretariat > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey > > _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
