Spelling / Grammar: "Authorizationn" on page 22

RE: DANE/Self-Signed Certs

    [Note: this effectively excludes self-signed and DANE-based
    certificates until some mechanism to control spam for those
    certificates is found - the authors welcome suggestions].


Suggestion:

  Logs MAY accept certificates without a complete chain if querying
  the Common Name in the certificate indicates the certificate is
  deployed on a webserver or included in DNS records. Logs MAY
  set policies around subdomains and paths to maintain availability.

If what you're trying to avoid is bloating the Merkle Tree, then
reaching out for a TLS handshake or DNS records could work.  Even if
they were spoofed/middled/whatever - the log isn't certifying they're
valid, only that they're public.  In the future, someone could submit
a DNS signature chain and bypass the need for the log to reach out,
but that'd require defining new APIs and structures, and that's too
much.

-tom



On 19 December 2012 17:21, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
>
>
> 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:  <internet-dra...@ietf.org>
> > Date: 19 December 2012 21:16
> > Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt
> > To: b...@google.com
> > Cc: ekas...@google.com, a...@google.com
> >
> >
> >
> > 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
> > therightkey@ietf.org
> > https://www.ietf.org/mailman/listinfo/therightkey
> >
> >
> _______________________________________________
> 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