Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-04.txt

From: Ben Laurie <[email-masked]>
Date: Wed, 19 Dec 2012 21:16:37 +0000

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 19 December 2012 21:16
Subject: New Version Notification for draft-laurie-pki-sunlight-04.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Dec 2012 22:21:32 +0000

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:
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>

---

From: Tom Ritter <[email-masked]>
Date: Wed, 19 Dec 2012 22:37:56 -0500

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 09:47:02 +0000

> Spelling / Grammar: "Authorizationn" on page 22

Thanks.

> but that'd require defining new APIs and structures, and that's too

I kinda like this suggestion, but it doesn't seem like it would
actually be much of a barrier to spam. Of course, if we make it a MAY
it would be no skin off my nose - but I doubt Google will implement
the MAY.

---

From: Tom Ritter <[email-masked]>
Date: Thu, 20 Dec 2012 08:46:23 -0500

> it would be no skin off my nose - but I doubt Google will implement

Poop, since Google's the only person committed to running a log so far...

I figured requiring a spammer to generate a valid key & certificate,
and deploy it on a reachable DNS name would be enough of a cost offset
from the log; and on the DANE side requiring them to deploy to a
signed DNSSEC record would be likewise.  And the subdomain
restrictions mean you could go so far as to require a new domain name
for each entry, plus rate limiting at no resubmissions for a domain
per hour/day.

-tom

---

From: Ben Laurie <[email-masked]>
Date: Thu, 20 Dec 2012 14:46:53 +0000

> for each entry, plus rate limiting at no resubmissions for a domain

Well, I'm certainly prepared to consider solutions - particularly for
DANE backed records. So far, however, the DNSSEC people haven't shown
much interest.

However, rather than log DANE-based certificates, it makes more sense,
as previously discussed, to log DNSSEC key records.

I did have an idea for anti-spam there, which I'll write up properly
some time soon - but in short, each domain from the root down has its
own log for delegations. If it wishes it can also log subdelegations,
or it can instead subdelegate the log. So, anyone wanting to create
large numbers of subdomains could be required by their parent's log to
run their own log, but small users could be serviced directly by the
parent's log.