Re: [Trans] Threat model outline, attack model

Stephen Kent <> Wed, 01 October 2014 14:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 024081ACDD8 for <>; Wed, 1 Oct 2014 07:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pgutExzoh-dv for <>; Wed, 1 Oct 2014 07:32:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9437A1ACDCF for <>; Wed, 1 Oct 2014 07:32:06 -0700 (PDT)
Received: from ([]:43503 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XZKx2-0005OM-1H; Wed, 01 Oct 2014 10:32:20 -0400
Message-ID: <>
Date: Wed, 01 Oct 2014 10:32:03 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Laurie <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 01 Oct 2014 14:32:11 -0000


> ...
>> 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.
I'm may get in trouble for saying this, but it seems as though the 
to which you allude are just the result of taking the terms that have 
been used
to motivate development of CT and making them concrete, rather than 

If a "broader scope" means using more ambiguous terms, I can't see why that
would be an improvement.
> 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.

I'm very bothered by your suggested change of focus. For me, this 
characterization of
CT is way too vague for an IETF security standard (vs. an experimental RFC).

It leads a reader to imagine that we don't have a simple, sound, 
defensible argument
for why we're pursuing this technology. It has the flavor of "CT is 
obviously good,
so let's just do it."  (pardon me for putting words into anyone's mouth.)