Re: [therightkey] Barely-capable CAs

Rob Stradling <rob.stradling@comodo.com> Thu, 01 November 2012 21:55 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC7021F974B for <therightkey@ietfa.amsl.com>; Thu, 1 Nov 2012 14:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Yaopy3P6X2Tp for <therightkey@ietfa.amsl.com>; Thu, 1 Nov 2012 14:55:59 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id EAFCE21F9627 for <therightkey@ietf.org>; Thu, 1 Nov 2012 14:55:58 -0700 (PDT)
Received: (qmail 25952 invoked from network); 1 Nov 2012 21:55:57 -0000
Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 1 Nov 2012 21:55:57 -0000
Received: (qmail 19948 invoked by uid 1000); 1 Nov 2012 21:55:55 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 01 Nov 2012 21:55:55 +0000
Message-ID: <5092EFEA.90202@comodo.com>
Date: Thu, 01 Nov 2012 21:55:54 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <CAOuvq22PMSq2sAmUBfJcWu6LhEdCA3jKteu38m4UuHbykp7xZw@mail.gmail.com> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD! 62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CABrd9STHtw__Wm30Z5T27mx8PMb-mScCSa-EZVDdeQvy_Rru1Q@mail.gmail.com> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CABrd9SSJWm_8BY9uN4D6=LmogwkNeLMZtJaOX2MQU1QuCHJwyg@mail.gmail.com> <80A8F0DC-C894-4299-AEC7-12B84A803E84@vpnc.org> <CAMm+Lwh2Qhv8eHtmy=KisShdJiLYe=ziyfezQELqqfu8y9H5qg@mail.gmail.com> <59E2ABDF-EF90-4BBF-BC45-048BF4C2B848@vpnc.org> <5092C4F7.106! 0908@comodo.com> <B02347BF-059C-40B1-AD2E-572EBFFD3869@vpnc.org> <5! 092D4C1.2000701@comodo.com> <A9902D0A-F450-4A16-90FC-9161945489D2@vpnc.org>
In-Reply-To: <A9902D0A-F450-4A16-90FC-9161945489D2@vpnc.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] Barely-capable CAs
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2012 21:55:59 -0000

On 01/11/12 20:33, Paul Hoffman wrote:
> On Nov 1, 2012, at 1:00 PM, Rob Stradling <rob.stradling@comodo.com> wrote:
>
>> If by "actively participating" you mean that the CA has embedded the CT proof in the cert, then yes, there is no requirement on the bank.
>
> That's one definition of "actively participating", but there are others, such as publishing a list that the auditors pick up.

What sort of list did you have in mind?

Would this list be "transparent"?
(i.e. if the CA were to publish an inaccurate or incomplete list, would 
the auditor definitely notice?)

>> If the CA instead embeds the CT proof in OCSP Responses relating to the cert, then there is no requirement on the bank apart from to use OCSP Stapling.
>
> This confuses me. If the CA is putting the CT proof in its OCSP responses, why does the bank have to do anything?

Because not all clients do online OCSP checks.
Because far too many online OCSP checks fail due to the Responder being 
unreachable.
Because OCSP Stapling is not currently enabled by default in (at least) 
Apache and nginx.

>> If the CA is not participating in either of these 2 ways, then there is a requirement on the bank (aka the "server operator"), which may or may not be rocket science, depending on your opinion.
>
> If the CA is not participating, why should that CA be in the trust pile of software that relies on CT?

AFAIK, this is the first time it's been suggested that CT should require 
CA participation.  I think it's an idea we should consider seriously.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online