Hi all,

IETF last call on this is done. There were a bunch of
comments and I believe Ben is preparing an update to
handle those and some discussion is still ongoing.
Once that's done and we have a version that addresses
the comments received (*) then my plan is to put this
on an IESG telechat agenda.

Cheers,
S.

(*) Note "addressed" != "accepted as-is" its just
fine if the authors argue convincingly to not accept
a comment.

On 12/20/2012 09:34 PM, Stephen Farrell wrote:
> 
> FYI. Slightly longer than normal IETF LC give the holidays.
> 
> S
> 
> 
> -------- Original Message --------
> Subject: Last Call: <draft-laurie-pki-sunlight-05.txt> (Certificate
> Transparency) to Experimental RFC
> Date: Thu, 20 Dec 2012 11:33:58 -0800
> From: The IESG <iesg-secret...@ietf.org>
> Reply-To: i...@ietf.org
> To: IETF-Announce <ietf-annou...@ietf.org>
> 
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Certificate Transparency'
>   <draft-laurie-pki-sunlight-05.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> i...@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be
> sent to i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> 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 file can be obtained via
> http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> _______________________________________________
> 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

Reply via email to