Re: [Trans] RFC6962 BIS Log file encodings.

Erwann Abalea <eabalea@gmail.com> Fri, 28 March 2014 18:48 UTC

Return-Path: <eabalea@gmail.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 948161A0941 for <trans@ietfa.amsl.com>; Fri, 28 Mar 2014 11:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_52=1, SPF_PASS=-0.001] 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 wc0IBpII7CPx for <trans@ietfa.amsl.com>; Fri, 28 Mar 2014 11:47:58 -0700 (PDT)
Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0785E1A01DB for <trans@ietf.org>; Fri, 28 Mar 2014 11:47:57 -0700 (PDT)
Received: by mail-ve0-f176.google.com with SMTP id db11so2976812veb.35 for <trans@ietf.org>; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rNZ6Pf0uzNfYUyoELOqUFsg+bF102zdwyg6RjPUF5Qc=; b=ZVDAOACjb7JQ6ty425VdF/zLLhA9iF69sgppMOWPgGxaM1MZn6hh83PCrjS7x8s4bM WOLAIHjHsB9H4XKPMCmaaAkD1ZbiOODcUu/cCylCXIF5HboaFRa6JuOI3buYLVKtBDiq TSY7bWjIht3KQPYsMqbzPLE567fWCflngmU/7JfyM1Dw9pxfynbGrZUb6tttJi1dFn36 Oc8eg/sdChpotTXV6TDe+p2XOHo9bEQCB7Np/w5gqKyV6b/UNseiPFR9FX/9CkhRy8qy aGZLHr+/ERFoP2RufBYv8Ym9pNy0bCtojElvbELdxmc6AcYmq8HJoW4r4rrtR6QPWueS YUVw==
MIME-Version: 1.0
X-Received: by 10.58.201.5 with SMTP id jw5mr8226724vec.6.1396032475567; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
Received: by 10.52.142.103 with HTTP; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
Received: by 10.52.142.103 with HTTP; Fri, 28 Mar 2014 11:47:55 -0700 (PDT)
In-Reply-To: <CAMm+LwjriXwEYZZX03y=w-gC_O5uczuXKnAcJpUFnZ-m6JS4Pw@mail.gmail.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>
Date: Fri, 28 Mar 2014 19:47:55 +0100
Message-ID: <CA+i=0E7FecAG_Dq2VAtyqrrsiHzkt9jgPfAL_BJ9mm4-G58n2w@mail.gmail.com>
From: Erwann Abalea <eabalea@gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bd6aea2cd1ef204f5af237f
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ppz-74KB68yLvbupMMcDpWITwGY
Cc: Rob Stradling <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>, Rick Andrews <Rick_Andrews@symantec.com>, Eran Messeri <eranm@google.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: Fri, 28 Mar 2014 18:48:00 -0000

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" <hallam@gmail.com> a écrit :

> 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;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 <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<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 <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
>
>