Re: [saag] [pkix] Fwd: [therightkey] Certificate Transparency Working Group?

Santosh Chokhani <SChokhani@cygnacom.com> Thu, 06 September 2012 21:19 UTC

Return-Path: <SChokhani@cygnacom.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779CA21F86B5; Thu, 6 Sep 2012 14:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 rYI3SZWf5mR8; Thu, 6 Sep 2012 14:19:35 -0700 (PDT)
Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCF621F867C; Thu, 6 Sep 2012 14:19:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,381,1344225600"; d="scan'208,217";a="1880458"
Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 06 Sep 2012 17:19:31 -0400
Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Thu, 6 Sep 2012 17:19:31 -0400
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: "denis.pinkas@bull.net" <denis.pinkas@bull.net>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>
Date: Thu, 06 Sep 2012 17:19:30 -0400
Thread-Topic: [pkix] Fwd: [therightkey] Certificate Transparency Working Group?
Thread-Index: Ac2MP7aNNCOrJRfXREq4TcOezgbyVAANRC1w
Message-ID: <B83745DA469B7847811819C5005244AF362EC770@scygexch7.cygnacom.com>
References: <5048B653.3080902@cs.tcd.ie>, <CABrd9ST=8iRB6+d=Oka6nnM+xaZfPcR+NMx_QAF-8+_dq1XTig@mail.gmail.com> <OF7814676F.9D502DDE-ONC1257A71.00520289-C1257A71.0052028F@bull.net>
In-Reply-To: <OF7814676F.9D502DDE-ONC1257A71.00520289-C1257A71.0052028F@bull.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF362EC770scygexch7cygnac_"
MIME-Version: 1.0
Cc: "pkix@ietf.org" <pkix@ietf.org>, "wpkops@ietf.org" <wpkops@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] [pkix] Fwd: [therightkey] Certificate Transparency Working Group?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 21:19:38 -0000

Denis,

As you may have seen my comment on this I-D and additions for security consideration, this extension does not provide the requisite transparency since anyone who has compromised the CA can put in their own OCSP pointer.

That is the reason I want you to add the text in the "Security Considerations" section.

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of denis.pinkas@bull.net
Sent: Thursday, September 06, 2012 10:56 AM
To: stephen.farrell@cs.tcd.ie
Cc: pkix@ietf.org; wpkops@ietf.org; saag@ietf.org
Subject: Re: [pkix] Fwd: [therightkey] Certificate Transparency Working Group?

Part of the stated objective (i.e. verify the issuance of public X.509 certificates)
is currently addressed, within the context of OCSP, in :

https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/

This draft is being considered within the PKIX WG.

The second part of the objective (i.e. making all public issued certificates available to applications)
may be dangerous in many situations.

Denis

-----pkix-bounces@ietf.org<mailto:-----pkix-bounces@ietf.org> a écrit : -----
A : "saag@ietf.org<mailto:saag@ietf.org>" <saag@ietf.org<mailto:saag@ietf.org>>, "'wpkops@ietf.org'" <wpkops@ietf.org<mailto:wpkops@ietf.org>>, pkix <pkix@ietf.org<mailto:pkix@ietf.org>>
De : Stephen Farrell
Envoyé par : pkix-bounces@ietf.org<mailto:pkix-bounces@ietf.org>
Date : 06/09/2012 16:42
Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group?

Hi all,

Please see below. Ben Laurie's looking to see if folks are
interested in a BoF on Certificate Transparency for the
IETF meeting in Altanta.

Sean and I would be fine with that, if there's sufficient
interest etc.

Please follow up on therightkey@ietf.org<mailto:therightkey@ietf.org> if this is a
topic that's of interest to you.

Thanks,
Stephen.


-------- Original Message --------
Subject: [therightkey] Certificate Transparency Working Group?
Date: Thu, 6 Sep 2012 15:32:05 +0100
From: Ben Laurie <benl@google.com<mailto:benl@google.com>>
To: therightkey@ietf.org<mailto:therightkey@ietf.org>

Would people be interested in starting a WG on Certificate
Transparency? If so, how about a BoF in Atlanta?

Here's a draft charter...


CT IETF WG Draft Charter

Objective

Specify mechanisms and techniques that allow Internet applications to
monitor and verify the issuance of public X.509 certificates such that
all public 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
site without any oversight. This has led to some high profile
mis-issuance of 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.
_______________________________________________
therightkey mailing list
therightkey@ietf.org<mailto:therightkey@ietf.org>
https://www.ietf.org/mailman/listinfo/therightkey




_______________________________________________
pkix mailing list
pkix@ietf.org<mailto:pkix@ietf.org>
https://www.ietf.org/mailman/listinfo/pkix