Re: [Trans] RFC6962 BIS Log file encodings.

Rick Andrews <Rick_Andrews@symantec.com> Fri, 28 March 2014 18:00 UTC

Return-Path: <Rick_Andrews@symantec.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 833B71A032F for <trans@ietfa.amsl.com>; Fri, 28 Mar 2014 11:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODLm8tKPnwFi for <trans@ietfa.amsl.com>; Fri, 28 Mar 2014 11:00:27 -0700 (PDT)
Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id 895961A0950 for <trans@ietf.org>; Fri, 28 Mar 2014 11:00:27 -0700 (PDT)
X-AuditID: d80ac3f3-b7f258e000006064-1d-5335b8b8be97
Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 1A.BF.24676.8B8B5335; Fri, 28 Mar 2014 18:00:25 +0000 (GMT)
Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from <Rick_Andrews@symantec.com>) id 1WTb4q-0000YR-BD; Fri, 28 Mar 2014 18:00:24 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Fri, 28 Mar 2014 11:00:08 -0700
From: Rick Andrews <Rick_Andrews@symantec.com>
To: "David A. Cooper" <david.cooper@nist.gov>
Date: Fri, 28 Mar 2014 11:00:06 -0700
Thread-Topic: [Trans] RFC6962 BIS Log file encodings.
Thread-Index: Ac9Krt0JwDR97MZjQzu6ht0+bZsBowAAIlTw
Message-ID: <544B0DD62A64C1448B2DA253C011414607C85F3A8F@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> <5335B76C.4050303@nist.gov>
In-Reply-To: <5335B76C.4050303@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607C85F3A8FTUS1XCHEVSPIN_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsXCZeB6UnfnDtNgg/+/BC2OLLrKaLH28UUW ByaPJUt+MnlcO/mXNYApissmJTUnsyy1SN8ugStjxYbTTAXz1zBWbG/qZGpgnDCNsYuRk0NC wESif/8DVghbTOLCvfVsXYxcHEIC7xglOq5eZYJwXjFK9HzqAqsSEljFKHFqphqIzSagJ7Hl 8RV2EFtEQFdi0YNFYDXMAqoS244+BYuzANlfX2wAs4WBtt2Y8RFoAwdQvanEtU2cEK1GEucv H2MCsXkFoiReNG+A2vuWSeLQ2vdgvZwCGhKXn79iA7EZgS79fmoNE8QucYlbT+YzQXwgILFk z3lmCFtU4uXjf6wQ9aISd9rXM4LsZRbIlzjbzwGxS1Di5MwnLBMYxWYhmTQLoWoWkiqIEh2J Bbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNMSWmxYXFuSX5pSUFqhYGxXnFlbiIwJpP1kvNz NzEC4/IG1+HPOxh/73E8xCjAwajEw+u41TRYiDWxDKjyEKMEB7OSCG/WRKAQb0piZVVqUX58 UWlOavEhRmkOFiVx3pCPhsFCAumJJanZqakFqUUwWSYOTqkGxrWFvSw1D6xWySpF2UTw799m cr9bSZ7NN7Woal9Z1sndm5eEzv95+MgB8batxes5QjrtlbanVf+ZclPirWVWmMRlPsdoH9mo jVnT975V3Pp6r+KuC7fOZM06wTlTx3qauNovh/Z83aQrJlxN03Vkg7SW1TXM7V82MX6p8rRP coWvUi5Zsbx2VmIpzkg01GIuKk4EAEUQewTHAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/x_SxKdtXZOQjzK_IRPrq2BV703k
Cc: "trans@ietf.org" <trans@ietf.org>
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:00:33 -0000

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:david.cooper@nist.gov]
Sent: Friday, March 28, 2014 10:55 AM
To: Rick Andrews
Cc: trans@ietf.org
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:

     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  {
     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<mailto: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/#%21topic/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<mailto:hallam@gmail.com>> wrote:
On Thu, Mar 13, 2014 at 4:20 PM, Rob Stradling <rob.stradling@comodo.com<mailto: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<mailto:Trans@ietf.org>
https://www.ietf.org/mailman/listinfo/trans





_______________________________________________

Trans mailing list

Trans@ietf.org<mailto:Trans@ietf.org>

https://www.ietf.org/mailman/listinfo/trans