Re: [Trans] redacted names and my proposal

Rob Stradling <> Fri, 12 September 2014 10:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 02F1D1A06AF for <>; Fri, 12 Sep 2014 03:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id weEme317kC3g for <>; Fri, 12 Sep 2014 03:04:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF0901A06EE for <>; Fri, 12 Sep 2014 03:03:26 -0700 (PDT)
Received: (qmail 25333 invoked by uid 1000); 12 Sep 2014 10:03:23 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 12 Sep 2014 11:03:23 +0100
Message-ID: <>
Date: Fri, 12 Sep 2014 11:03:23 +0100
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Stephen Kent <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Trans] redacted names and my proposal
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: Fri, 12 Sep 2014 10:04:03 -0000

Steve, my point is that the name redaction mechanism I proposed is, 
necessarily, a one-phase protocol.  The Precertificate must be logged 
(hence phase 1), and the final certificate must not be required to be 
logged (hence the lack of a phase 2).

If the final certificate is logged, then the redacted names become 
public.  If the final certificate is not logged, then we need to at 
least know its serial number so that it is revocable.

I don't think we can avoid requiring the serial number of the final 
certificate to be seen by the log before the final certificate is 
actually issued, because the embedded SCT(s) in the final certificate 
need to prove that the log(s) have seen that serial number.

And if we can't avoid that requirement, I don't see how a two-phase 
approach would offer any benefit.

On 11/09/14 19:37, Stephen Kent wrote:
> 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

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online