Re: [Trans] Threat model outline, attack model

Stephen Kent <> Mon, 29 September 2014 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CBFF1A88B8 for <>; Mon, 29 Sep 2014 12:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.966
X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 mP_WMVgTT6fB for <>; Mon, 29 Sep 2014 12:16:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A6311A9248 for <>; Mon, 29 Sep 2014 12:16:17 -0700 (PDT)
Received: from ([]:33149 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XYgQi-0007FZ-FA for; Mon, 29 Sep 2014 15:16:16 -0400
Message-ID: <>
Date: Mon, 29 Sep 2014 15:16:15 -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
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 29 Sep 2014 19:16:19 -0000


I'm impressed by your web site graphics.

Unfortunately, for RFCs, we have to stick with ASCII art, which is 
painful and
only black and white.  So, although I agree that diagrams are very helpful
when trying to understand the CT context, I won't be able to incorporate 
into my text.

I have not visited the Google CT web site because I focus on what we do 
WGs, and for that only material published in that context counts. In 
fact, I have
complained about referring to the CT web site to gain a better understanding
of what 6962-bis is supposed to mean; discussion and explanations of CT 
need to
be part of the IETF archival data, not on an independent web site. But, 
that's another

I'm continuing to revise the attack analysis, based on my analysis of the
CABF guidelines, more thought, and helpful feedback from folks like Rick 
and Santosh.
I'll post an updated version of the attack analysis later this week,