---------- 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

Reply via email to