Re: [Trans] RFC6962 BIS Log file encodings.

And to answer the original question...

On 13 March 2014 17:29, Phillip Hallam-Baker <hallam@gmail.com> 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.

Exactly.

> 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
   7.4.1.4.1 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: http://hallambaker.com/
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

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