Re: [Trans] RFC6962 BIS Log file encodings.

Rob Stradling <> Thu, 13 March 2014 20:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 668701A0763 for <>; Thu, 13 Mar 2014 13:20:55 -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 AFGoxn7tNu2f for <>; Thu, 13 Mar 2014 13:20:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1EE171A0A10 for <>; Thu, 13 Mar 2014 13:20:51 -0700 (PDT)
Received: (qmail 24838 invoked by uid 1000); 13 Mar 2014 20:20:42 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 13 Mar 2014 20:20:42 +0000
Message-ID: <>
Date: Thu, 13 Mar 2014 20:20:42 +0000
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
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, 13 Mar 2014 20:20:55 -0000

(Inspired by RFC5280 Appendix C)

Would it help to include one or more example SCTs in the text?

On 13/03/14 17:29, Phillip Hallam-Baker wrote:
> I am trying to make sense of the log file encoding (section 3). this
> does not seem to me to be properly or clearly specified.
> RFC6962 punts the encoding question to RFC5246 but this only helps
> somewhat because the description there is atrocious.
> In particular it is implicit in the text that digitaly-signed is
> equivalent to the ASN.1 macro. But this isn't actually explained
> anywhere in section 4 of 5246. So as a result there is no information on
> where the signature appears in the data stream, does it precede or
> follow the signed data?
> This is quite problematic because in the TLS use the signed data does
> not appear on the wire at all, the construct is used in client auth when
> the prior handshake is signed so there is no need to retransmit the data.
> It looks to me like the idea here is that the SCT does not need to
> include the certificate or precertificate data because the corresponding
> signed data will always be implicit from the mode of use. But that needs
> to be clearly stated.
> At the moment the specification is assuming that the reader has a high
> degree of familiarity with PKIX and TLS encodings and can switch gear
> between them.
> --
> Website:
> _______________________________________________
> 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.