[sidr] Certificate Transparency WG

Ben Laurie <benl@google.com> Fri, 07 September 2012 13:20 UTC

Return-Path: <benl@google.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754FA21E805D for <sidr@ietfa.amsl.com>; Fri, 7 Sep 2012 06:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8COS0Ayo3pUL for <sidr@ietfa.amsl.com>; Fri, 7 Sep 2012 06:20:02 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C58D621E804D for <sidr@ietf.org>; Fri, 7 Sep 2012 06:20:02 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so4998113obb.31 for <sidr@ietf.org>; Fri, 07 Sep 2012 06:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=Fl82Cpc+gYAyEfw19G8HCUsP6qaIRKN70MNXvBHsrWE=; b=auFJQfgFV8H8CxYBX3UJXGskU0RqllD2pWY/QGm8+t7ofqI/fDnjZnG9XPiS2zwWxA gjv5o0VvpaAyw9fpZyXEz/PQ7FOChK7kx69iP9leX33DdTvEUltWAQHA+yQ/Rh/gjloi 4YZNoZKITlbgZpJD+60Kio+nZLdzKIDJctHugywohYzAVgj3+gIh/4WJoqe9MfSoWDPb Hz7LYX1QPvRHnZ3zWHxauwNyRK0TpmeUGrFxGvofD3R9N+0o1q/2LZwccaaZ4CVYI5aY mZUolyXPe/k7+bsEb4Y4Ms1+J65S4RtNWJQz8cBsS37xMkWTSCEgQQFoTwZ2Lajyjeqa 1psA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=Fl82Cpc+gYAyEfw19G8HCUsP6qaIRKN70MNXvBHsrWE=; b=AawLI8B4PEGMXWVLSHiBdAmQwNw2w0WklSfVd888u6tC0MdFUEM9jXB3urfD6U6hdd ZzB+ex+7YPbhN00+NTuH6o1CUGDVvdbe/+O8oV0xCi6s1C2X11HLMm5N5x6PtOuI9fZ7 EczTNM9Vtok2/aX47qawETRqMYCU9ojunaZEFuzHJV5fkPyhwQDBT1iprprhbddhIA9U +Jp25sP8i8RXzBUn+/062fjKTyP/OGX03Yb2blTZOMNkeOGqKDW962nxLmOvUmexUo0W At+3g726LkVZnXU8G3nPWn6SazuI2+Y+GUk1o47C+oL0I5FZTMvLGcsoSH8wbr4Vfc+t DTqA==
Received: by 10.60.11.104 with SMTP id p8mr6002780oeb.133.1347024002394; Fri, 07 Sep 2012 06:20:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.11.104 with SMTP id p8mr6002768oeb.133.1347024002281; Fri, 07 Sep 2012 06:20:02 -0700 (PDT)
Received: by 10.60.5.72 with HTTP; Fri, 7 Sep 2012 06:20:02 -0700 (PDT)
Date: Fri, 07 Sep 2012 14:20:02 +0100
Message-ID: <CABrd9STFwbngU9MFN8_uRcZ4ngpmbDynHo8ACgYC+4VyhX97Xg@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: sidr@ietf.org, therightkey@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkZYiYwZZNWOE/tI6Cx6vg09qQFmnsXY8nvfI/V4e4Pax0745PEuaj29ge6gATJZrRaFk/ykud7ZRRZIgeGCNTWzg+RSCNBOmc6+lUlSkCgGeQAIMtfw2nPfGV3LTWQc/WGQlaRtsS6ECKQ1bdZPt7TqbAyaq3HR5uEjxmHtTCCQb3R6Ojf3QkUJz0Y7Wsel7FbWH4w
Subject: [sidr] Certificate Transparency WG
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Sep 2012 13:20:05 -0000

It has been suggested to me that the SIDR WG might be interested in
Certificate Transparency and a possible BoF in Atlanta. Please send
followup discussion to therightkey@ietf.org.

Here's an (updated) draft charter.

CT IETF WG Draft Charter

version 2

Objective

Specify mechanisms and techniques that allow Internet applications to
monitor and verify the issuance of public X.509 certificates such that
all issued certificates are available to applications, and each
certificate seen by an application can be efficiently shown to be in
the log of issued certificates. Furthermore, it should be possible to
cryptographically verify the correct operation of the log.


Optionally, do the same for certificate revocations.

Problem Statement

Currently it is possible for any CA to issue a certificate for any
purpose without any oversight. This has led to some high profile
mis-issuance of web certificates, such as by DigiNotar, a subsidiary
of VASCO Data Security International, in July 2011
(http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx).


The aim is to make it possible to detect such mis-issuance promptly
through the use of a public log of all public issued certificates.
Domain owners can then monitor this log and, upon detecting
mis-issuance, take appropriate action.


This public log must also be able to efficiently demonstrate its own
correct operation, rather than introducing yet another party that must
be trusted into the equation.


Clients should also be able to efficiently verify that certificates
they receive have indeed been entered into the public log.


For revocations, the aim would be similar: ensure that revocations are
as expected, that clients can efficiently obtain the revocation status
of a certificate and that the log is operating correctly.


Also, in both cases, the solution must be usable by browsers - this
means that it cannot add any round trips to page fetches, and that any
data transfers that are mandatory are of a reasonable size.

Existing Work

Certificate Transparency v2.1a
(http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf)


Spec and working code:
http://code.google.com/p/certificate-transparency/source/browse/