Subject: [Trans] RFC6962 BIS Log file encodings.

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Mar 2014 13:29:14 -0400

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: http://hallambaker.com/

---

From: Rob Stradling <[email-masked]>
Date: Thu, 13 Mar 2014 20:20:42 +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.
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

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

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Mar 2014 18:50:07 -0400

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

I think we definitely need that for Proposed. But right now I am trying to
see how complete the description is.

---

From: Eran Messeri <[email-masked]>
Date: Fri, 14 Mar 2014 10:00:50 +0000

I strongly support clarifying the description of the file format. When I
started implementing aspects of RFC6962 (with no background in TLS encoding
or ASN.1) it was very unclear.
>From other posts<https://groups.google.com/forum/#!topic/certificate-transparency/T9CDwnsercQ>on
the list it seems this was unclear to others as well.

---

From: Rick Andrews <[email-masked]>
Date: Fri, 28 Mar 2014 10:31:18 -0700

In addition, our ASN.1 experts have asked for the syntax to be described in “ASN.1-like” syntax, as is used in RFCs 3280 and 5280.

For example, 3280/5280 defines an Extension like this:

Extension  ::=  SEQUENCE  {
     extnID      OBJECT IDENTIFIER,
     critical    BOOLEAN DEFAULT FALSE,
     extnValue   OCTET STRING  }

so the extnValue is defined as an OCTET STRING, yet 6962 says “…encoding the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and inserting the resulting data in the TBSCertificate as an X.509v3 certificate extension…”. The ASN.1 folks say it’s not clear if that means that the Extension contains the OCTET STRING data type (for extnValue) and length followed by another OCTET STRING data type identifier and length of the SCT. Or is the second OCTET STRING identifier redundant?

Those updating existing cert generation code will probably be dealing with ASN.1 compilers, so a precise definition of structures in ASN.1-like syntax will go a long way. In addition, defining OIDs as arc plus extension (like this: id-kp-serverAuth  OBJECT IDENTIFIER ::= { id-kp 1 }) would help.

-Rick

From: Trans [mailto:[email-masked]] On Behalf Of Eran Messeri
Sent: Friday, March 14, 2014 3:01 AM
To: Phillip Hallam-Baker
Cc: Rob Stradling; [email-masked]<mailto:[email-masked]>
Subject: Re: [Trans] RFC6962 BIS Log file encodings.

I strongly support clarifying the description of the file format. When I started implementing aspects of RFC6962 (with no background in TLS encoding or ASN.1) it was very unclear.
From other posts<https://groups.google.com/forum/#!topic/certificate-transparency/T9CDwnsercQ> on the list it seems this was unclear to others as well.

On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <[email-masked]<mailto:[email-masked]>> wrote:
(Inspired by RFC5280 Appendix C)

I think we definitely need that for Proposed. But right now I am trying to see how complete the description is.

_______________________________________________
Trans mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/trans

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 28 Mar 2014 13:54:52 -0400

Rick,

I haven't read RFC 6962 in detail, but the ASN.1 experts you spoke
with may not be familiar with the definition of Extension in
certificates. X.509 defines it as:

Extension ::= SEQUENCE {

extnId EXTENSION.&id ({ExtensionSet}),

extnValue OCTET STRING

(CONTAINING
EXTENSION.&ExtnType({ExtensionSet}{@extnId})

ENCODED
BY der)}

der OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1)
ber-derived(2) distinguished-encoding(1)}

In RFC 5280 it is:

Extension  ::=  SEQUENCE  {

extnValue   OCTET STRING

-- contains the DER encoding of an
ASN.1 value

-- corresponding to the extension type
identified

-- by extnID

}

It is my understanding that the two definitions are based on
different versions of ASN.1, but are considered to be equivalent.
The important point is that both indicate that the extension value
must contain the DER encoding of some ASN.1 value. So, the only
way to interpret the RFC 6962 text in a manner that is consistent
with X.509 is that the extnValue contains the tag for OCTET STRING
followed by a length then a second OCTET STRING tag and a second
length and then the (non-ASN.1) encoded
SignedCertificateTimestampList structure. Given that the
SignedCertificateTimestampList structure is not ASN.1, and so it
cannot be DER encoded, this seems the only reasonable way to
include it in a certificate.

This is similar to the subjectKeyIdentifier extension. The
subjectKeyIdentifier just contains a string of bits, such as the
SHA-1 hash of the subject public key. It is defined in RFC 5280 as
follows:

KeyIdentifier ::= OCTET STRING

-- subject key identifier OID and syntax

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  {
id-ce 14 }

SubjectKeyIdentifier ::= KeyIdentifier

and here is an example of an encoded subjectKeyIdentifier
extension:

SEQUENCE {

SEQUENCE {

OBJECT IDENTIFIER
subjectKeyIdentifier (2 5 29 14)

OCTET STRING, encapsulates {

OCTET STRING

08 68 AF 85 33 C8 39 4A 7A F8 82
93 8E 70 6A 4A

20 84 2C 32

}

}

RFC 5912 shows the extensions in the newer ASN.1 syntax.

Dave

On 03/28/2014 01:31 PM, Rick Andrews wrote:

In
addition, our ASN.1 experts have asked for the syntax to be
described in “ASN.1-like” syntax, as is used in RFCs 3280
and 5280.

For
example, 3280/5280 defines an Extension like this:

Extension
::=  SEQUENCE  {

extnValue   OCTET STRING  }

so
the extnValue is defined as an OCTET STRING, yet 6962 says
“…encoding the SignedCertificateTimestampList structure as
an ASN.1 OCTET STRING and inserting the resulting data in
the TBSCertificate as an X.509v3 certificate extension…”.
The ASN.1 folks say it’s not clear if that means that the
Extension contains the OCTET STRING data type (for
extnValue) and length followed by another OCTET STRING data
type identifier and length of the SCT. Or is the second
OCTET STRING identifier redundant?

Those
updating existing cert generation code will probably be
dealing with ASN.1 compilers, so a precise definition of
structures in ASN.1-like syntax will go a long way. In
addition, defining OIDs as arc plus extension (like this:
id-kp-serverAuth  OBJECT IDENTIFIER ::= { id-kp 1 }) would
help.

-Rick

From:
Trans [mailto:[email-masked]]
On Behalf Of Eran Messeri

To: Phillip Hallam-Baker

Cc: Rob Stradling; [email-masked]

I strongly
support clarifying the description of the file format. When
I started implementing aspects of RFC6962 (with no
background in TLS encoding or ASN.1) it was very unclear.

From other posts
on the list it seems this was unclear to others as well.

On Thu, Mar
13, 2014 at 10:50 PM, Phillip Hallam-Baker <[email-masked]> wrote:

On
Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <[email-masked]>
wrote:

(Inspired
by RFC5280 Appendix C)

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

I
think we definitely need that for Proposed. But
right now I am trying to see how complete the
description is.

--

Trans mailing list

[email-masked]

---

From: Rick Andrews <[email-masked]>
Date: Fri, 28 Mar 2014 11:00:06 -0700

Thanks, Dave, I'll forward this on. But are you saying that the descriptions in 6962 are precise enough? Would you have any objections to defining structures in 6962 using the same syntax as 5280?

-Rick

From: David A. Cooper [mailto:[email-masked]]
Sent: Friday, March 28, 2014 10:55 AM
To: Rick Andrews
Cc: [email-masked]
Subject: Re: [Trans] RFC6962 BIS Log file encodings.

Rick,

I haven't read RFC 6962 in detail, but the ASN.1 experts you spoke with may not be familiar with the definition of Extension in certificates. X.509 defines it as:

   Extension ::= SEQUENCE {
            extnId EXTENSION.&id ({ExtensionSet}),
            critical BOOLEAN DEFAULT FALSE,
            extnValue OCTET STRING
   (CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
                                                    ENCODED BY der)}

   der OBJECT IDENTIFIER ::= {joint-iso-itu-t asn1(1) ber-derived(2) distinguished-encoding(1)}

In RFC 5280 it is:
   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

It is my understanding that the two definitions are based on different versions of ASN.1, but are considered to be equivalent. The important point is that both indicate that the extension value must contain the DER encoding of some ASN.1 value. So, the only way to interpret the RFC 6962 text in a manner that is consistent with X.509 is that the extnValue contains the tag for OCTET STRING followed by a length then a second OCTET STRING tag and a second length and then the (non-ASN.1) encoded SignedCertificateTimestampList structure. Given that the SignedCertificateTimestampList structure is not ASN.1, and so it cannot be DER encoded, this seems the only reasonable way to include it in a certificate.

This is similar to the subjectKeyIdentifier extension. The subjectKeyIdentifier just contains a string of bits, such as the SHA-1 hash of the subject public key. It is defined in RFC 5280 as follows:

     id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }

and here is an example of an encoded subjectKeyIdentifier extension:
       SEQUENCE {
         SEQUENCE {
           OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
           OCTET STRING, encapsulates {
             OCTET STRING
               08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A
               20 84 2C 32
             }
           }

Dave

On 03/28/2014 01:31 PM, Rick Andrews wrote:
In addition, our ASN.1 experts have asked for the syntax to be described in "ASN.1-like" syntax, as is used in RFCs 3280 and 5280.

Extension  ::=  SEQUENCE  {

so the extnValue is defined as an OCTET STRING, yet 6962 says "...encoding the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and inserting the resulting data in the TBSCertificate as an X.509v3 certificate extension...". The ASN.1 folks say it's not clear if that means that the Extension contains the OCTET STRING data type (for extnValue) and length followed by another OCTET STRING data type identifier and length of the SCT. Or is the second OCTET STRING identifier redundant?

-Rick

>From other posts<https://groups.google.com/forum/#%21topic/certificate-transparency/T9CDwnsercQ> on the list it seems this was unclear to others as well.

Trans mailing list

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 28 Mar 2014 14:13:44 -0400

The encoding isn't ASN.1 so using ASN.1 schema is a terrible idea.

Putting data in certificates does unfortunately lead to the risk of ASN.1.

One of the reasons I developed JSON-BCD was I could see this going to
happen and I would much prefer the JSON style approach over any further
investment in ASN.1.

On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews <[email-masked]>wrote:

> In addition, our ASN.1 experts have asked for the syntax to be described
> in "ASN.1-like" syntax, as is used in RFCs 3280 and 5280.
>
>
>
> so the extnValue is defined as an OCTET STRING, yet 6962 says "...encoding
> the SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and
> inserting the resulting data in the TBSCertificate as an X.509v3
> certificate extension...". The ASN.1 folks say it's not clear if that means
> that the Extension contains the OCTET STRING data type (for extnValue) and
> length followed by another OCTET STRING data type identifier and length of
> the SCT. Or is the second OCTET STRING identifier redundant?
>
>
>
> Those updating existing cert generation code will probably be dealing with
> ASN.1 compilers, so a precise definition of structures in ASN.1-like syntax
> will go a long way. In addition, defining OIDs as arc plus extension (like
> this: id-kp-serverAuth  OBJECT IDENTIFIER ::= { id-kp 1 }) would help.
>
>
>
> -Rick
>
>
>
> *From:* Trans [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Eran Messeri
> *Sent:* Friday, March 14, 2014 3:01 AM
> *To:* Phillip Hallam-Baker
> *Cc:* Rob Stradling; [email-masked]
> *Subject:* Re: [Trans] RFC6962 BIS Log file encodings.
>
>
>
> From other posts<https://groups.google.com/forum/#!topic/certificate-transparency/T9CDwnsercQ>on the list it seems this was unclear to others as well.
>
>
>

---

From: Rick Andrews <[email-masked]>
Date: Fri, 28 Mar 2014 11:27:04 -0700

I understand that there are problems with ASN.1 and many people don't like it, but if we're talking about X.509 certificates we have to use ASN.1. All of our code for putting blobs into a cert work by defining the structure using ASN.1. Yes, we can add a blob that has some other encoding, but it's more difficult.

If the encoding were ASN.1, it might make adoption more straightforward.

-Rick

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Friday, March 28, 2014 11:14 AM
To: Rick Andrews
Cc: Eran Messeri; Rob Stradling; [email-masked]
Subject: Re: [Trans] RFC6962 BIS Log file encodings.

One of the reasons I developed JSON-BCD was I could see this going to happen and I would much prefer the JSON style approach over any further investment in ASN.1.

On Fri, Mar 28, 2014 at 1:31 PM, Rick Andrews <[email-masked]<mailto:[email-masked]>> wrote:
In addition, our ASN.1 experts have asked for the syntax to be described in "ASN.1-like" syntax, as is used in RFCs 3280 and 5280.

Extension  ::=  SEQUENCE  {

-Rick

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Mar 2014 14:32:18 -0400

Ø  I understand that there are problems with ASN.1 and many people don't like it, but if we're talking about X.509 certificates we have to use ASN.1. All of our code for putting blobs into a cert work by defining the structure using ASN.1. Yes, we can add a blob that has some other encoding, but it's more difficult.

Ø  If the encoding were ASN.1, it might make adoption more straightforward.

+1

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 28 Mar 2014 19:47:55 +0100

I don't see the problem with ASN.1.
Can't you propose a JSON Encoding Rule standard?
Le 28 mars 2014 19:13, "Phillip Hallam-Baker" <[email-masked]> a écrit :

>> in “ASN.1-like” syntax, as is used in RFCs 3280 and 5280.
>>
>>
>>
>> so the extnValue is defined as an OCTET STRING, yet 6962 says “…encoding
>> certificate extension…”. The ASN.1 folks say it’s not clear if that means
>> Those updating existing cert generation code will probably be dealing
>> with ASN.1 compilers, so a precise definition of structures in ASN.1-like
>> syntax will go a long way. In addition, defining OIDs as arc plus extension
>> (like this: id-kp-serverAuth  OBJECT IDENTIFIER ::= { id-kp 1 }) would help.
>>
>>
>>
>> -Rick
>>
>>
>>

---

From: Bill Frantz <[email-masked]>
Date: Sat, 29 Mar 2014 15:49:10 -0700

>I don't see the problem with ASN.1.

IMHO, the problem with ASN.1 is that it is too complex. There 
exists a history of attacks on computer security by sending 
malformed ASN.1 irritating bugs in ASN.1 encoders. In addition, 
the ability to specify "infinite" length data has caused buffer overruns.

ASN.1 fans my say that these bugs have all been fixed, and they 
may be right if no new ASN.1 interpreters are written.

However, complexity is always a bad thing in a security 
protocol. Make it only as complex as necessary, and no more complex.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said 
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier

---

From: Erwann Abalea <[email-masked]>
Date: Sun, 30 Mar 2014 00:21:18 +0100

2014-03-29 23:49 GMT+01:00 Bill Frantz <[email-masked]>:

> IMHO, the problem with ASN.1 is that it is too complex. There exists a
> history of attacks on computer security by sending malformed ASN.1
> irritating bugs in ASN.1 encoders. In addition, the ability to specify
> "infinite" length data has caused buffer overruns.
>

ASN.1 isn't a stream of bytes. It's only a language used to describe a
structure, and it needs some encoding rule to serialize data transmitted on
the wire. Use another encoding rule, and you'll have a different bit/byte
representation.
The mentioned bugs (infinite length) are to be found on some BER/DER
encoders, and similar ones can be found on XML parsers, MS Word files
loaders, and many others.
If a certificate is encoded using XER and an XML parser is hit by a bug,
can the fault be attributed to ASN.1, the language used to describe a
certificate? If the same format is described with another language while
keeping the same binary representation, will it make the bug disappear?

Data structures defined in RFC6962 can be described in ASN.1 as well, and
encoded using PER (that's not common), and it will be binary compatible
with what is proposed. Will it introduce new bugs because of ASN.1?

-- 
Erwann.

---

From: Bill Frantz <[email-masked]>
Date: Sat, 29 Mar 2014 18:55:13 -0700

>keeping the same binary representation, will it make the bug disappear?

Yes, part of the problem is at the description level. The 
description language is too general. If I describe a data 
structure as: a 16 bit length field followed by the bytes of the 
data, then I can't have any data longer than 64K bytes. It is 
easy to allocate a buffer that is long enough.

The disadvantage of this form of description is that we may need 
to expand to data longer than 64K, needing a new description.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 10:32:17 +0100

Hi Rick.  Dave's analysis is correct.  6962, interpreted in the light of 
X.509/5280, is unambiguous.  That said, I think we could make life 
easier for implementers by improving the text in RFC6962-bis.

We should certainly add at least one example of an encoded SCTList 
extension.

On 28/03/14 18:00, Rick Andrews wrote:
> Thanks, Dave, I’ll forward this on. But are you saying that the
> descriptions in 6962 are precise enough? Would you have any objections
> to defining structures in 6962 using the same syntax as 5280?
>
> -Rick
>
> *From:*David A. Cooper [mailto:[email-masked]]
> *Sent:* Friday, March 28, 2014 10:55 AM
> *To:* Rick Andrews
> *Cc:* [email-masked]
> I haven't read RFC 6962 in detail, but the ASN.1 experts you spoke with
> may not be familiar with the definition of Extension in certificates.
> X.509 defines it as:
>
> *   Extension ::= SEQUENCE {
> *
> *   Extension  ::=  SEQUENCE  {
>          }*
> It is my understanding that the two definitions are based on different
> versions of ASN.1, but are considered to be equivalent. The important
> point is that both indicate that the extension value must contain the
> DER encoding of some ASN.1 value. So, the only way to interpret the RFC
> 6962 text in a manner that is consistent with X.509 is that the
> extnValue contains the tag for OCTET STRING followed by a length then a
> second OCTET STRING tag and a second length and then the (non-ASN.1)
> encoded SignedCertificateTimestampList structure. Given that the
> SignedCertificateTimestampList structure is not ASN.1, and so it cannot
> be DER encoded, this seems the only reasonable way to include it in a
> certificate.
>
> subjectKeyIdentifier just contains a string of bits, such as the SHA-1
> hash of the subject public key. It is defined in RFC 5280 as follows:
>
> *     KeyIdentifier ::= OCTET STRING
>
>       SubjectKeyIdentifier ::= KeyIdentifier*
>
> *SEQUENCE {**
>             }*
>     In addition, our ASN.1 experts have asked for the syntax to be
>     described in “ASN.1-like” syntax, as is used in RFCs 3280 and 5280.
>
>     so the extnValue is defined as an OCTET STRING, yet 6962 says
>     “…encoding the SignedCertificateTimestampList structure as an ASN.1
>     OCTET STRING and inserting the resulting data in the TBSCertificate
>     as an X.509v3 certificate extension…”. The ASN.1 folks say it’s not
>     clear if that means that the Extension contains the OCTET STRING
>     data type (for extnValue) and length followed by another OCTET
>     STRING data type identifier and length of the SCT. Or is the second
>     Those updating existing cert generation code will probably be
>     dealing with ASN.1 compilers, so a precise definition of structures
>     in ASN.1-like syntax will go a long way. In addition, defining OIDs
>     as arc plus extension (like this: id-kp-serverAuth  OBJECT
>     IDENTIFIER ::= { id-kp 1 }) would help.
>
>     -Rick
>
>     *From:*Trans [mailto:[email-masked]] *On Behalf Of *Eran Messeri
>     *Cc:* Rob Stradling; [email-masked] <mailto:[email-masked]>
>     I strongly support clarifying the description of the file format.
>     When I started implementing aspects of RFC6962 (with no background
>     in TLS encoding or ASN.1) it was very unclear.
>
>      From other posts
>     <https://groups.google.com/forum/#%21topic/certificate-transparency/T9CDwnsercQ>
>     On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I think we definitely need that for Proposed. But right now I am
>     trying to see how complete the description is.
>
>     --
>     [email-masked] <mailto:[email-masked]>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 31 Mar 2014 10:53:55 +0100

> We should certainly add at least one example of an encoded SCTList

http://trac.tools.ietf.org/wg/trans/trac/ticket/14

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Mar 2014 11:05:09 -0400

> I understand that there are problems with ASN.1 and many people don't 
> like it, but if we're talking about X.509 certificates we have to use 
> ASN.1. All of our code for putting blobs into a cert work by defining 
> the structure using ASN.1. Yes, we can add a blob that has some other 
> encoding, but it's more difficult.
>
*+1 though, as former PKIX, I may be biased :-).*

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Mar 2014 11:16:56 -0400

Bill,

> ASN.1 fans my say that these bugs have all been fixed, and they may be 
> right if no new ASN.1 interpreters are written.
>
> However, complexity is always a bad thing in a security protocol. Make 
> it only as complex as necessary, and no more complex.
>
> Cheers - Bill
I agree that ASN.1 is complex, and if this were a new protocol, not tied 
to any existing
ASN.1-based data structures, I would not select ASN.1 as a starting 
point. But since we're
talking about data from a TBS cert,since the generators of the data are 
CAs (who should
know how to process ASN.1), and since the consumers of the data are 
browsers who already
process certs, it seems reasonable to stick with ASN.1.

Steve

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Mar 2014 11:19:03 -0400

>  But since we're talking about data from a TBS cert,since the generators of the data are CAs (who should know how to process ASN.1), and since the consumers of the data are browsers who already process certs, it seems reasonable to stick with ASN.1.

Adding another encoding makes things more complex.  Therefore, the simplest thing to do is use ASN.1

It's like when you're editing someone else's source code: the best thing to do is preserve the existing style.

	/r$

---

From: Ben Laurie <[email-masked]>
Date: Mon, 31 Mar 2014 16:26:46 +0100

On 28 March 2014 18:27, Rick Andrews <[email-masked]> wrote:
> I understand that there are problems with ASN.1 and many people don’t like
> it, but if we’re talking about X.509 certificates we have to use ASN.1. All
> of our code for putting blobs into a cert work by defining the structure
> using ASN.1. Yes, we can add a blob that has some other encoding, but it’s
> more difficult.
>
>
>

The problem is, there's no right answer here: strictly, the "most
correct" way of including an SCT is as a TLS extension - and that's
why we chose TLS encoding for SCTs. Whatever we do, it seems someone
will be unhappy. And at least TLS encoding is less complicated than
DER.

> One of the reasons I developed JSON-BCD was I could see this going to happen
> and I would much prefer the JSON style approach over any further investment
> in ASN.1.
>
>
>
>
>
>
>
> In addition, our ASN.1 experts have asked for the syntax to be described in
> “ASN.1-like” syntax, as is used in RFCs 3280 and 5280.
>
>
>
> so the extnValue is defined as an OCTET STRING, yet 6962 says “…encoding the
> SignedCertificateTimestampList structure as an ASN.1 OCTET STRING and
> inserting the resulting data in the TBSCertificate as an X.509v3 certificate
> extension…”. The ASN.1 folks say it’s not clear if that means that the
> Extension contains the OCTET STRING data type (for extnValue) and length
> followed by another OCTET STRING data type identifier and length of the SCT.
> Or is the second OCTET STRING identifier redundant?
>
>
>
> From other posts on the list it seems this was unclear to others as well.
>
>
>

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

---

From: Ben Laurie <[email-masked]>
Date: Mon, 31 Mar 2014 16:28:11 +0100

> It's like when you're editing someone else's source code: the best thing to do is preserve the existing style.

As I just mention, its not actually another encoding - the data
structure can also (ideally should also) be sent as a TLS extension,
in which case ASN.1 is not the simplest thing to do.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 31 Mar 2014 16:35:01 +0100

And to answer the original question...

On 13 March 2014 17:29, Phillip Hallam-Baker <[email-masked]> wrote:
> 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.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 31 Mar 2014 16:00:15 -0400

Ben,

> in which case ASN.1 is not the simplest thing to do.
Sorry if I misinterpreted the context. We need definitive statements 
about how each major
data element is transmitted, against what it is compared, and how it is 
generated.
Only then does it make sense to debate which encoding(s) make sense.

Steve

---

From: Bill Frantz <[email-masked]>
Date: Mon, 31 Mar 2014 22:59:49 -0700

On 3/31/14 at 8:16 AM, [email-masked] (Stephen Kent) wrote:

>I agree that ASN.1 is complex, and if this were a new protocol, not tied to any existing
>ASN.1-based data structures, I would not select ASN.1 as a starting point. But since we're
>talking about data from a TBS cert,since the generators of the data are CAs (who should
>know how to process ASN.1), and since the consumers of the data are browsers who already

On 3/31/14 at 8:19 AM, [email-masked] (Salz, Rich) wrote:

>It's like when you're editing someone else's source code: the 
>best thing to do is preserve the existing style.

>in which case ASN.1 is not the simplest thing to do.

Stephen, Rich and Ben make good points. It's too bad the 
conclusions differ.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | There are now so many exceptions to the
408-356-8506       | Fourth Amendment that it operates only by
www.pwpconsult.com | accident.  -  William Hugh Murray