Re: [Trans] Threat model outline, attack model

Ben Laurie <> Tue, 30 September 2014 12:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 745D71A06FD for <>; Tue, 30 Sep 2014 05:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UK31udkOjWeE for <>; Tue, 30 Sep 2014 05:18:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C90411A06E9 for <>; Tue, 30 Sep 2014 05:18:45 -0700 (PDT)
Received: by with SMTP id x3so3287531qcv.25 for <>; Tue, 30 Sep 2014 05:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MEHXUpV2D5qav2j+yv3GJt7UsEB8WY3ypFCPj866sqk=; b=mk0bhd9OaATm3fX6J4StFOqR3/MTaGbE9Wf4M8PxzQF/4XXLaO2MrFOIhzSMXhnO9K OArG2zfO0G7A8j+PXpF/KjbAFWrU/1H1sEJ2RyjezTohKwVYglVZ0GVJOiw7aQYxCP/Q 0EMAaaLceKXwkvEse2GFUIJQ/3crrrq8EFvenK8syAZacRBoC1Egxdcghy69Tj1QUJ35 RfKEpvUsd8yMisbolAMD3uwm70w2gxf4pinFKEnAANvhCyJubXZM+NNv99uGOx/w+/LS qewNX5I6HmyOm6/212Cv6QNKLnjDV2jGUxOvLz/QvnkUAxOTNHHCmqWZOMUqDIl7kdzm 0S+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MEHXUpV2D5qav2j+yv3GJt7UsEB8WY3ypFCPj866sqk=; b=NaLOUvNqmS/dGVRK3x3N/9HGDH2XwUQPCMwqrrz82SdLdGWldo5bOARhxes7xATmsS 8egGTiKOXU0n833cdWyPR29rcN7WO2fdRKdgLIFDMApcJUbf1QxHtdHzYb7lXDOjhzDo 12401OJD+nN1C+5j2YyQrXv+podW+xYJxT1qFKx8m1mtpbBKo6w93SvYR56UF3Afh502 AlpYZdK6Cd/PDakERPc301dZ/mX45HmeIIvXOVeUxyNKh6WPfTUQm46wdgmLO3RFPU4/ v+cI8ijLfdl3eUt7D8xeOOqaT+iBWpcKRRoruAjPQ6cCRJLDzDhok/ULVqITFjE/Obxi fm0w==
X-Gm-Message-State: ALoCoQmOHbYRoRPhVeWKkVtc5dMnnnMGaRMwDEmZOI6ZORYT2X1yuWzdalRk+Nyqavq21ovsHYst
MIME-Version: 1.0
X-Received: by with SMTP id u3mr18541280qat.82.1412079521944; Tue, 30 Sep 2014 05:18:41 -0700 (PDT)
Received: by with HTTP; Tue, 30 Sep 2014 05:18:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Tue, 30 Sep 2014 13:18:41 +0100
Message-ID: <>
From: Ben Laurie <>
To: Stephen Kent <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Trans] Threat model outline, attack model
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Sep 2014 12:18:47 -0000

On 29 September 2014 15:52, Stephen Kent <> wrote:
>>> At a minimum we need a set of universally-applicable issuance standards
>>> to
>>> apply, based on two things:
>>> - the syntax of the cert, which everyone can examine
>>> - comparison of logged certs against reference certs, i.e., valid
>>> certs already issued to (legitimate) Subjects. A Monitor can
>>> perform this comparison if provided with a reference cert. if the
>>> Monitor wants to perform additional checks, that may be fine
>>> if we're going to create a standard that purports to detect mis-issuance,
>>> but we can't define mis-issuance in a well-articulated, testable fashion,
>>> I
>>> question the utility of this effort.
>> I didn't intend to suggest there was no point in defining mis-issuance
>> to the extent that its possible, just that I don't think its likely
>> we'll manage to completely define it, so we should not attempt to do
>> so. i.e. I would not like to see the RFC say "this is mis-issuance,
>> and nothing else is".
> Again, I disagree. We should define what we can and make design decisions
> based on that definition. Anything else that might be considered
> mis-issuanve,
> is out of scope for purposes of this work. This is the sort of delineation
> that
> we often impose on RFCs; we define a scope for a standard and declare that
> other
> stuff is out of scope, relative to the standard.

Then perhaps we should have a broader scope. Focusing on mis-issuance
seems to lead to all sorts of, IMO, unnecessary complications.

It might be simpler to define CT as a mechanism for allowing the
public examination of the contents of all issued certificates, without
getting into exactly what might be done as a result of that
examination. Detecting mis-issuance is, of course, an obvious example.