Re: [Trans] RFC6962 BIS Log file encodings.
Ben Laurie <benl@google.com> Mon, 31 March 2014 15:26 UTC
Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35BC1A0A6F for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 08:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMhG29wJGwdo for <trans@ietfa.amsl.com>; Mon, 31 Mar 2014 08:26:50 -0700 (PDT)
Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 171901A0884 for <trans@ietf.org>; Mon, 31 Mar 2014 08:26:50 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id sa20so8201288veb.36 for <trans@ietf.org>; Mon, 31 Mar 2014 08:26:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x+ClOsGh0FqX+fGkYhRq3+FjMt9OEoTi6fxVsaQ5N+w=; b=oZ49EdPNrVZEpocuIT3Wnqp2S61qIlBkh8+pJXXdlnoztVNgfAX+L/4t7j4htavdIK EV0rPgX0pfJCU+Dh31JmoEyJajnPvJfrBlYLMQs46LkrCugHfNs4Rrpdi5BD7UE17wGU H57RPLYdAI9SSO2qQn/75Qd6c5HV+OCNL3S8mihY5r97mqgBEIgcNv3HGjwoww/awSum d2GgE3iRX96pmQyi9wphKsKUoTSoPJJe+C9IxRpRa0yPvZWl1i1LfQWhzz5W1JhZvoXp VQnDpugOQb1IDjjp6NyR6sf9dGoIFgAU3DDgnczPjr33OrkkKAGpSu9e8h/CONy2Ijw4 pB/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x+ClOsGh0FqX+fGkYhRq3+FjMt9OEoTi6fxVsaQ5N+w=; b=b4tUVE4ktInV+wfqkKMjZdFgXzzGh9SP7Pgtwfiu/i8oJ78yKIKRtHGwh7IIldxV4v Rly33voVUEu/XJMZig4Ue3qcbPCaMQMAhIU/IL5X5PmxrWQFAbmXAlaHgHceQmmMJoWh Yb8hDUvVfHaVrfyfvZs4JU1lY/MTThimJBLCJG6tpFuSGlqsHuW5Rf6AYmfBksjLM8Hr TZ7QxEnnclrNdq++yorwTfxehwET1RVAHqQ2HVnkA21mupBbOeB8FaY5fvfItlb70tEP ypidft9qd7/k7gNWH6HzVE2GgpsCDr3wSc8Pl7OYyKZgydXLBQZPkEZO0bTNq0z6vzej 3OWA==
X-Gm-Message-State: ALoCoQnsysd9wKanX66eAR7Nk+W9RzEgzB5C80ENriLyiCjeKndTr05ny/9xiOOje1+umMwJ7BG+oTeuPUvmRl/IL7jZMc8lBuhvH4NezPOHcIuurBqcD2siuKK9/7hW98pN0hGG4vUUcndRbrOMFmbkMJW1ns23Z8FIo5qc37YpWh0fELm2qTYb0+el6boSYgp54ouAD/Bp
MIME-Version: 1.0
X-Received: by 10.221.26.10 with SMTP id rk10mr23875961vcb.0.1396279606622; Mon, 31 Mar 2014 08:26:46 -0700 (PDT)
Received: by 10.52.119.179 with HTTP; Mon, 31 Mar 2014 08:26:46 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <CAMm+Lwjy7gMphsfByROYP2WDTvP4nVkCQPj=oHkVFr=AQv=qjw@mail.gmail.com> <5322131A.2080507@comodo.com> <CAMm+Lwhz7KM44kMgn8mdFtR6Ow=aMik-5GD-Wge+JZUKz751mA@mail.gmail.com> <CALzYgEdSs0+SJrL9uzem1NnWv=jPAFr_dxrqvLkSqyd_nX+yGg@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607C85F39F4@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <CAMm+LwjriXwEYZZX03y=w-gC_O5uczuXKnAcJpUFnZ-m6JS4Pw@mail.gmail.com> <544B0DD62A64C1448B2DA253C011414607C85F3B2D@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Mon, 31 Mar 2014 16:26:46 +0100
Message-ID: <CABrd9SSZ=h_V-vn_jMO0D-NcqDg0KbkqfUHMa3XMo_eqM1J23Q@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Rick Andrews <Rick_Andrews@symantec.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/62JijDez3tl45AC6Z9wiShCrKfE
Cc: "trans@ietf.org" <trans@ietf.org>, Eran Messeri <eranm@google.com>, Phillip Hallam-Baker <hallam@gmail.com>, Rob Stradling <rob.stradling@comodo.com>
Subject: Re: [Trans] RFC6962 BIS Log file encodings.
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 15:26:51 -0000
On 28 March 2014 18:27, Rick Andrews <Rick_Andrews@symantec.com> 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. > > > > If the encoding were ASN.1, it might make adoption more straightforward. 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. > > > > -Rick > > > > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Friday, March 28, 2014 11:14 AM > To: Rick Andrews > Cc: Eran Messeri; Rob Stradling; trans@ietf.org > > > 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 <Rick_Andrews@symantec.com> > 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 { > > 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:trans-bounces@ietf.org] On Behalf Of Eran Messeri > Sent: Friday, March 14, 2014 3:01 AM > To: Phillip Hallam-Baker > Cc: Rob Stradling; trans@ietf.org > 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 on the list it seems this was unclear to others as well. > > > > On Thu, Mar 13, 2014 at 10:50 PM, Phillip Hallam-Baker <hallam@gmail.com> > wrote: > > On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <rob.stradling@comodo.com> > 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. > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > > > > > -- > 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.
- [Trans] RFC6962 BIS Log file encodings. Phillip Hallam-Baker
- Re: [Trans] RFC6962 BIS Log file encodings. Rob Stradling
- Re: [Trans] RFC6962 BIS Log file encodings. Phillip Hallam-Baker
- Re: [Trans] RFC6962 BIS Log file encodings. Eran Messeri
- Re: [Trans] RFC6962 BIS Log file encodings. Rick Andrews
- Re: [Trans] RFC6962 BIS Log file encodings. David A. Cooper
- Re: [Trans] RFC6962 BIS Log file encodings. Rick Andrews
- Re: [Trans] RFC6962 BIS Log file encodings. Phillip Hallam-Baker
- Re: [Trans] RFC6962 BIS Log file encodings. Rick Andrews
- Re: [Trans] RFC6962 BIS Log file encodings. Salz, Rich
- Re: [Trans] RFC6962 BIS Log file encodings. Erwann Abalea
- Re: [Trans] RFC6962 BIS Log file encodings. Bill Frantz
- Re: [Trans] RFC6962 BIS Log file encodings. Erwann Abalea
- Re: [Trans] RFC6962 BIS Log file encodings. Bill Frantz
- Re: [Trans] RFC6962 BIS Log file encodings. Rob Stradling
- Re: [Trans] RFC6962 BIS Log file encodings. Rob Stradling
- Re: [Trans] RFC6962 BIS Log file encodings. Stephen Kent
- Re: [Trans] RFC6962 BIS Log file encodings. Stephen Kent
- Re: [Trans] RFC6962 BIS Log file encodings. Salz, Rich
- Re: [Trans] RFC6962 BIS Log file encodings. Ben Laurie
- Re: [Trans] RFC6962 BIS Log file encodings. Ben Laurie
- Re: [Trans] RFC6962 BIS Log file encodings. Ben Laurie
- Re: [Trans] RFC6962 BIS Log file encodings. Stephen Kent
- Re: [Trans] RFC6962 BIS Log file encodings. Bill Frantz
- Re: [Trans] RFC6962 BIS Log file encodings. Gervase Markham
- Re: [Trans] RFC6962 BIS Log file encodings. Gervase Markham
- Re: [Trans] RFC6962 BIS Log file encodings. Ben Laurie
- Re: [Trans] RFC6962 BIS Log file encodings. Eran Messeri