Re: [Trans] Precertificate format

Rob Stradling <> Thu, 11 September 2014 12:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AC3681A895F for <>; Thu, 11 Sep 2014 05:52:14 -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 KcilM0ulOj41 for <>; Thu, 11 Sep 2014 05:52:11 -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 0E4A01A6FA8 for <>; Thu, 11 Sep 2014 05:52:10 -0700 (PDT)
Received: (qmail 31714 invoked by uid 1000); 11 Sep 2014 12:52:08 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 11 Sep 2014 13:52:08 +0100
Message-ID: <>
Date: Thu, 11 Sep 2014 13:52:07 +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: <><><><544B0DD62A64C1448B2DA253C011414607D07DC251@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM><><><> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Trans] Precertificate format
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: Thu, 11 Sep 2014 12:52:14 -0000

On 10/09/14 17:08, Stephen Kent wrote:
> Rob,
>> Hi Stephen.  That's an interesting idea, but I see a few issues.
>> Step 4 requires the final cert to be logged, so it's incompatible with
>> the name redaction mechanism.
> Oops, an oversimplified description on my part. In step 4 I think one
> can apply the whatever redaction mechanisms that we adopt.

Steve, can you suggest a name redaction mechanism that would be 
compatible with your idea?

>> Monitors want to detect misissuance (i.e. certs that have been issued
>> incorrectly).  I'm not sure that it's reasonable to expect Monitors to
>> also take responsibility for detecting non-issuance of certs that
>> should have been issued.
> The current I-D says
>      Monitors watch logs and check that they behave correctly.They also
>      watch for certificates of interest.
> The non-issuance of an SCT after issuance of an SCT* for a "certificate
> of interest"
> would seem to be within scope, given the somewhat vague description in
> the I-D.

OK, let's explore this avenue and see whether or not we hit any 
roadblocks.  :-)

> Steve
> _______________________________________________
> Trans mailing list

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.