Re: [Trans] path validation

David Leon Gil <coruus@gmail.com> Wed, 01 October 2014 14:48 UTC

Return-Path: <coruus@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1355F1ACE20 for <trans@ietfa.amsl.com>; Wed, 1 Oct 2014 07:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWOqK6pC-Iw0 for <trans@ietfa.amsl.com>; Wed, 1 Oct 2014 07:48:04 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910D41ACE24 for <trans@ietf.org>; Wed, 1 Oct 2014 07:48:04 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id l4so464925lbv.26 for <trans@ietf.org>; Wed, 01 Oct 2014 07:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tsZMUOvi0RX83tBJLBCsVQuHTC29fKbQ8vFEwaQKCs4=; b=falTyLc3sPuOfE3DWNHAKlKmyORKkXAM6CgCZo0AOg1arpQxsue/jW/7M7kTBxVkZd BxJrXyn00ZHQlFCkUWMypKqMdMK8CeasCWcAxco6zDPwjWJqVn+3bcSfnPVEfpsIwXmE L6FyhOjJxP/EHrE/caBYDfauS/qXDf5VkidCk0ciPLfxtyIb1BOYgcdwKhaE4HOQTc8u AF3LdNaN1BKteu6Kqdmn3qnNM6mG7VM8q1biV9QelEXiXQo+l018QEfQisV13bSX/YDm SYpf/bCgvbhogIE/16DAzfe1ODckGwhTX71Z5lwH6R5lJK8dDexg382NwGc+c9aHc9K1 MLMw==
X-Received: by 10.112.78.38 with SMTP id y6mr18787873lbw.94.1412174882843; Wed, 01 Oct 2014 07:48:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.218.145 with HTTP; Wed, 1 Oct 2014 07:47:42 -0700 (PDT)
In-Reply-To: <542C0FCB.7010906@bbn.com>
References: <54296FB2.1060109@bbn.com> <4262AC0DB9856847A2D00EF817E81139233695@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D1629838@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <4262AC0DB9856847A2D00EF817E8113923370C@scygexch10.cygnacom.com> <544B0DD62A64C1448B2DA253C011414607D162989C@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAA7UWsWr2p7t2uTrhiF9meU8htT=aWQT7qiBV6Xxg2E-GAwUBQ@mail.gmail.com> <542C0FCB.7010906@bbn.com>
From: David Leon Gil <coruus@gmail.com>
Date: Wed, 01 Oct 2014 10:47:42 -0400
Message-ID: <CAA7UWsW8qM8jdOOjdEznmyW6iEcnQ58izuMCbZbRtHWSQmBp5Q@mail.gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/g8TmPH6DnTYzdEKjEOzRInf47JA
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] path validation
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Oct 2014 14:48:07 -0000

On Wed, Oct 1, 2014 at 10:29 AM, Stephen Kent <kent@bbn.com> wrote:
> I disagree. Once Ben said that he meant mis-issuance to be interpreted in a
> much broader context,
> and cited EV cert requirements as an example, I pursued documenting what
> that would mean. If
> the WG wants to say that mis-issuance is more than issuing a cert to the
> wrong Subject, then
> we need to say just what it is, not hand wave.

You are missing the point of certificate transparency.

We have no idea all the forms that misissuance -- particularly
malicious misissuance -- might take. If it were trivial to detect
"misissuance", browsers would validate certs for "misissuance" and the
problem would be solved.

The point of having a log that includes everything signed with a CA's
key is that analysis of issued certificates can be conducted post-hoc.

Proposals to limit the scope of what logs can log kneecap CT. They
should not be considered.