[Trans] redacted names and my proposal

Stephen Kent <kent@bbn.com> Thu, 11 September 2014 18:37 UTC

Return-Path: <kent@bbn.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 600BC1A7018 for <trans@ietfa.amsl.com>; Thu, 11 Sep 2014 11:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level:
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 kKNBT2fz7CwT for <trans@ietfa.amsl.com>; Thu, 11 Sep 2014 11:37:10 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407CB1A701D for <trans@ietf.org>; Thu, 11 Sep 2014 11:37:09 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:50049 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XS9FC-0002pZ-KN for trans@ietf.org; Thu, 11 Sep 2014 14:37:22 -0400
Message-ID: <5411EBD2.6010703@bbn.com>
Date: Thu, 11 Sep 2014 14:37:06 -0400
From: Stephen Kent <kent@bbn.com>
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: "trans@ietf.org" <trans@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mp2Cisq9V0KDwAiGv6kAk5ykm04
Subject: [Trans] redacted names and my proposal
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: Thu, 11 Sep 2014 18:37:12 -0000

Rob,

My intent, perhaps not well articulated, was that the SCT* submission 
would use
the same name redaction mechanism you proposed, if they prove to be viable.

The step 4 submission would include that same data, the serial number, 
and the
previously-issued SCT*. This would enable a log (doing more work) to 
ensure that
the SCT it issues is consistent between the two submissions. It also 
ensures that
the serial number is available for revocation when needed (which arises 
in only
some of the attack scenarios).

Thus, whatever name redaction mechanism the WG ultimately deems suitable 
should
work in my suggested two-phase protocol.

As Ben noted, there is a residual vulnerability with my proposal since 
the SCT*
is not tied to the serial number. But, in the context of the attack 
analysis I just
submitted,  I'm not sure how serious this vulnerability is, relative to 
the other
ones that I identified in the current CT design. We should discuss that 
later,
once we have agreement on an attack analysis.

Steve