Re: [Trans] RFC6962 BIS Log file encodings.

Ben Laurie <> Mon, 31 March 2014 15:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 56E951A6EF0 for <>; Mon, 31 Mar 2014 08:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mIlLPSO2sx2f for <>; Mon, 31 Mar 2014 08:35:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::231]) by (Postfix) with ESMTP id A3C4B1A6EDC for <>; Mon, 31 Mar 2014 08:35:04 -0700 (PDT)
Received: by with SMTP id if17so8184713vcb.8 for <>; Mon, 31 Mar 2014 08:35:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jewWlSO9AMH+zcTD7tboKkTZgaHisI/twDpIrEB4DCg=; b=iSwxIZpNRA2kh/UrfmXelzm09/d++1+cZwZsYxbTLqwbmStCIq0LLdUb1ZbbzDMTIN 43R+XXlRn1vE15kG907ZjNFh/IfNDEssDHiONQUANt83kqXdU/QlsMEmOOVPtjA1D7z9 OfRr922jZjx4gg3czTrVoDeMy3FViYD45WorsVcAKAwWsTjjoDza93hgqQn9nsUJINY2 IXodXA1M0H/Fc+I9lgcU+U7qkBMPpOWLE3K+pJBcrLSqamu1qs8iqksePAzDj+tA4s6W pqJm6Ay5GvZxlBj/QCNxJ8rZFyXwqt9IkIExvMKTIV9VMvu6QaJBce53+WIoW9TmrmdG F5qA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jewWlSO9AMH+zcTD7tboKkTZgaHisI/twDpIrEB4DCg=; b=hwYj3zaP8WTl6vwIczx7sUvSCnGQ/lr+5BkDnUcf/f0QuoW8v7kW840sXM734ayeGt DKiKdBXzQITahsErb9MA8xRSwcnAgY2dYLPFagkfIKaDsULnvBhLSj2HGiZU2xhe1mHn sqhYmsqcfrJJVI8OTrN0MeAcr6UG9sm6/c+gxV++TktLKgs3nenQPgUdei2C6X1AqFzX Aofbb/y6irzlNKYd9S1HyPD4CmCWyTRr4Fyaqs0PeerAJ1VMuh5zpWMG3iahTK0a9GVg Tbw7KwwyiDUdZO2Le2xDUdml0CUumRZtk5zvupU0pn+ywSj3pubHvCLk/YKMJC1zX8no vjPQ==
X-Gm-Message-State: ALoCoQk6jJ/Sj9EZn3vjwVma/q5HzCK9OLPqht86Z2SGIuFX7Q1VJwOsKxRnpm+jd0UKlBSVV34RF4uzrMbzzsf+FJooc7xyfm0ygebpK94OEKDt0FHrucSMwcGAiEmyVctPp4eqR7ioYGwNCODMZwH/IpyBxFuCMfuZCJKeusZzByqexVGHMGetO8UuPxIm6iAZJWBx+rpL
MIME-Version: 1.0
X-Received: by with SMTP id bc4mr187380vec.45.1396280101200; Mon, 31 Mar 2014 08:35:01 -0700 (PDT)
Received: by with HTTP; Mon, 31 Mar 2014 08:35:01 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 31 Mar 2014 16:35:01 +0100
Message-ID: <>
From: Ben Laurie <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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: Mon, 31 Mar 2014 15:35:06 -0000

And to answer the original question...

On 13 March 2014 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.

RFC 5246 seems pretty clear already, from 4.7:

"A digitally-signed element is encoded as a struct DigitallySigned:

      struct {
         SignatureAndHashAlgorithm algorithm;
         opaque signature<0..2^16-1>;
      } DigitallySigned;

   The algorithm field specifies the algorithm used (see Section for the definition of this field).  Note that the
   introduction of the algorithm field is a change from previous
   versions.  The signature is a digital signature using those
   algorithms over the contents of the element.  The contents themselves
   do not appear on the wire but are simply calculated.  The length of
   the signature is specified by the signing algorithm and key."

I'm not sure how to state it more clearly than that.

> 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

Certificate Transparency is hiring! Let me know if you're interested.