Re: [Trans] Parsing existing logs entries.
Rob Stradling <rob.stradling@comodo.com> Thu, 29 May 2014 20:18 UTC
Return-Path: <rob.stradling@comodo.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 A4D4E1A09ED for <trans@ietfa.amsl.com>; Thu, 29 May 2014 13:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 ANc2fgtWOzXw for <trans@ietfa.amsl.com>; Thu, 29 May 2014 13:18:45 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160291A06A4 for <trans@ietf.org>; Thu, 29 May 2014 13:18:44 -0700 (PDT)
Received: (qmail 16935 invoked by uid 1000); 29 May 2014 20:18:38 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 29 May 2014 21:18:38 +0100
Message-ID: <5387961D.1010503@comodo.com>
Date: Thu, 29 May 2014 21:18:37 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Kurt Roeckx <kurt@roeckx.be>, trans@ietf.org
References: <20140529175912.GB15165@roeckx.be>
In-Reply-To: <20140529175912.GB15165@roeckx.be>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/40j6PhAr7PkAdakTjb8P1sQfX0I
Subject: Re: [Trans] Parsing existing logs entries.
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: Thu, 29 May 2014 20:18:47 -0000
Kurt, RFC6962 says... "1.2. Data Structures Data structures are defined according to the conventions laid out in Section 4 of [RFC5246]." So you shouldn't have to guess. Just read RFC5246 Section 4. On 29/05/14 18:59, Kurt Roeckx wrote: > Hi, > > I've been tryint to parse the existing log file based on the > description in RFC 6962. I'm using Google's pilot log as example. > > The RFC says that GET will give you: > leaf_input: The base64-encoded MerkleTreeLeaf structure. > > extra_data: The base64-encoded unsigned data pertaining to the > log entry. In the case of an X509ChainEntry, this is the > "certificate_chain". In the case of a PrecertChainEntry, > this is the whole "PrecertChainEntry". > > With MerkleTreeLeaf: > struct { > Version version; > MerkleLeafType leaf_type; > select (leaf_type) { > case timestamped_entry: TimestampedEntry; > } > } MerkleTreeLeaf; > > Which uses the following types: > enum { v1(0), (255) } > Version; > > enum { timestamped_entry(0), (255) } > MerkleLeafType; > > struct { > uint64 timestamp; > LogEntryType entry_type; > select(entry_type) { > case x509_entry: ASN.1Cert; > case precert_entry: PreCert; > } signed_entry; > CtExtensions extensions; > } TimestampedEntry; > > enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; > > opaque ASN.1Cert<1..2^24-1>; > > opaque CtExtensions<0..2^16-1>; > > So after base64 decoding things, and turning it to hex, I see: > 0000000 00 00 00 00 01 3d a4 07 ab d0 00 00 00 05 09 30 > 0000020 82 05 05 30 82 03 ed a0 03 02 01 02 02 11 00 91 > > So my guess of parsing it is: > MerkleTreeLeaf { > version = 00 (v1) > leaf_type = 00 (timestamped_entry) > TimestampedEntry { > timestamp = 00 00 01 3d a4 07 ab d0 (1364256598992, 2013-03-26 00:09:58.992) > entry_type = 00 00 (x509_entry) > ASN.1Cert = 00 05 09 30 82 05 05 30 [...] > > And I seem to have been gotton lost somewhere. That doesn't look > like a valid X509 certificate, nor do I have any idea how long it > is. > > If I had to guess "00 05 09" would be a length, and that might > work since it's limited to 2^24-1 bytes, so let's just assume > that's the case for now. > > > Now let's try to look at the extra_data. That is: > struct { > ASN.1Cert leaf_certificate; > ASN.1Cert certificate_chain<0..2^24-1>; > } X509ChainEntry; > > And we have this hex data: > 0000000 00 09 29 00 04 e9 30 82 04 e5 30 82 03 cd a0 03 > 0000020 02 01 02 02 10 07 6f 12 46 81 45 9c 28 d5 48 d6 > > So with what we learned from the previous attempt, it looks like > we need to parse it like: > certificate_chain { > length = 00 09 29 (2345) > ASN.1Cert { > length = 00 04 e9 (1257) > data = 30 82 04 e5 30 82 03 cd a0 03 [...] } > ASN.1Cert { [...] > > I think the RFC needs some clarifications on how to parse things, > so that I don't have to guess. > > This definition is also confusing: > extra_data: The base64-encoded unsigned data pertaining to the > log entry. In the case of an X509ChainEntry, this is the > "certificate_chain". In the case of a PrecertChainEntry, > this is the whole "PrecertChainEntry". > > So the X509ChainEntry is not used, you need to directly go to it's > member certificate_chain. The LogEntry also isn't used anywhere. > > > > Kurt > > _______________________________________________ > Trans mailing list > Trans@ietf.org > 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.
- [Trans] Parsing existing logs entries. Kurt Roeckx
- Re: [Trans] Parsing existing logs entries. Rob Stradling
- Re: [Trans] Parsing existing logs entries. Kurt Roeckx
- Re: [Trans] Parsing existing logs entries. Rob Stradling
- Re: [Trans] Parsing existing logs entries. Ben Laurie