Re: [Trans] RFC6962 BIS Log file encodings.

Rick Andrews <> Fri, 28 March 2014 18:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B6BF61A0941 for <>; Fri, 28 Mar 2014 11:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pk9RVgtpsbVn for <>; Fri, 28 Mar 2014 11:27:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CFD6B1A094E for <>; Fri, 28 Mar 2014 11:27:20 -0700 (PDT)
X-AuditID: d80ac3f3-b7f258e000006064-6c-5335bf06e73e
Received: from ( []) by (Symantec Brightmail Gateway out) with SMTP id 0F.D0.24676.60FB5335; Fri, 28 Mar 2014 18:27:18 +0000 (GMT)
Received: from [] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by with esmtp (Exim 4.76) (envelope-from <>) id 1WTbUr-0008A6-UW; Fri, 28 Mar 2014 14:27:18 -0400
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([]) with mapi; Fri, 28 Mar 2014 11:27:06 -0700
From: Rick Andrews <>
To: Phillip Hallam-Baker <>
Date: Fri, 28 Mar 2014 11:27:04 -0700
Thread-Topic: [Trans] RFC6962 BIS Log file encodings.
Thread-Index: Ac9KsXj0MD4tIBGmRdufjav8x8zLiAAAU+fQ
Message-ID: <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <> <> <> <> <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607C85F3B2DTUS1XCHEVSPIN_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsXCZeB6Spdtv2mwwfmF+hafv29ns7i6/DiT xaLGxawWax9fZHFg8bi0ZDajx85Zd9k9Fmwq9Viy5CdTAEsUl01Kak5mWWqRvl0CV8b+o31s Bas6GSue9x1gaWBcUd3FyMkhIWAi0Xn8OhuELSZx4d56IJuLQ0jgHaPExz1/WEASQgKvGCV6 FqpAJFYxShw6fIkVJMEmoCex5fEVdhBbREBb4ui+LWBxZoEiidkT7zCB2CwCqhLXVqwE2yAM tO3GjI9ANgdQvanEtU2cEK1GEkvPPwMr5xWIkuj+3A91xDRmiVcH34PVcwoESpydAraKEejQ 76fWMEGsEpe49WQ+E8QDAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEfb7E7qeHmSF2CUqcnPmE ZQKj2Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYpQpKS02LM4tyS8t KUitMDDWK67MTQRGbrJecn7uJkZg9N7gOvx5B+PvPY6HGAU4GJV4eB23mgYLsSaWAVUeYpTg YFYS4b28FyjEm5JYWZValB9fVJqTWnyIUZqDRUmcN+SjYbCQQHpiSWp2ampBahFMlomDU6qB ceHeRxuDL/2Y+tNmUs1CZsZlc7ZyNPAEvbbIuJT+btWq1p2u3LO+S5X9/MCjYC9R+0rnAKck a4xsKO/q5iemDUGVVgcfCqiaf3wzQyeeofOj+8oyxiy3pG7tczPZBLhcNy/uqzj/tumKze6t TFm7t/gs9GSq9Sm6ePtmX8dRy72vf372WpgcrsRSnJFoqMVcVJwIADcHMgvaAgAA
Cc: Eran Messeri <>, "" <>, Rob Stradling <>
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: Fri, 28 Mar 2014 18:27:25 -0000

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.


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

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 <<>> 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  {
     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.


From: Trans [] On Behalf Of Eran Messeri
Sent: Friday, March 14, 2014 3:01 AM
To: Phillip Hallam-Baker
Cc: Rob Stradling;<>
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<!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 <<>> wrote:
On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <<>> 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<>