IETF Logo Mail Archive

Re: [Trans] add-chain return value

Adam Eijdenberg <eijdenberg@google.com> Mon, 09 November 2015 19:45 UTC

Return-Path: <eijdenberg@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 EFA941B8284 for <trans@ietfa.amsl.com>; Mon, 9 Nov 2015 11:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, 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 RHi8AAR3LVfu for <trans@ietfa.amsl.com>; Mon, 9 Nov 2015 11:45:19 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C461B8282 for <trans@ietf.org>; Mon, 9 Nov 2015 11:45:19 -0800 (PST)
Received: by iofh3 with SMTP id h3so29880565iof.3 for <trans@ietf.org>; Mon, 09 Nov 2015 11:45:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=KvZxXfx6p830DbpHuzpe7VTGGDkQufr0YivNQIgQUuo=; b=Tdr8QrJO9JEBOpwOalQJ4DpCYFsX/RkcJIRSSUdSkQyY5n8VZ435+bFaxV78h2Sz8/ elr4x3vfFNC9r5BlTeqfmHsvMcIsZholNjpT+otIzsN9xU4Wo3VAK4mReyDH0zczYRpt mNOB4iyhxadKKk/k621sQqk0RszGnoouK840Vhu1aKuhKzHqJ2zOhoVEebGcRmHVpy9M Xr0DFb4SiPbOEfhalGubZU/xHzkotVknUabuj2h9fOZWc+g70kFsGiC2/I3BTFqBdpjA blpqv0vsLzPaknnaR7C3+u5fMMlP5k+lKHY9qg/lx+lnHmIfD5QKpd+FMghyH2gBZhQ3 fzqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=KvZxXfx6p830DbpHuzpe7VTGGDkQufr0YivNQIgQUuo=; b=ZOsYxPYO83oIW3j4b6eeo/dvlXdNOBqO/3OsMNK4/fMyvFPnCn1vAsu/qxdkkqIFjI yxh2/xtdzTftzNd3EYc4pZP4JtlJrUqUbNStA64exIk19OiPMrvthHHpeVlH7mi9VbuC 688VepdnTQlp8eQo+58Y7jMpWU6mMiQ2t+CoHfRDhu/Y6mfrqisQH4bXGc5vnEqpnQnD JQpNEs63Hje0Va77Ib8kVFXJRxj2J7Evs6EDiYKfKuXUiYSLfp9WUI9yGXqDqz6ZKIRu P8gdm+6q8BZIzIzVx5/9DItz4imK9a3P7uS2eOWnsLxwP0SmLVBZrPG6v5vexsM/zKCt ltAQ==
X-Gm-Message-State: ALoCoQlr4bS5YtI+k3N8z33CuthYWYcNzuvtyrxfzJTceSURvY70RbxmuPryjuwc9jD7GOQG7vNp
X-Received: by 10.107.167.197 with SMTP id q188mr181457ioe.141.1447098318725; Mon, 09 Nov 2015 11:45:18 -0800 (PST)
MIME-Version: 1.0
References: <CAK6vND-qHU0GL5B=UB5XmsQcStBaHQ=V_nCvwiWkDUTcMtUQ-g@mail.gmail.com>
In-Reply-To: <CAK6vND-qHU0GL5B=UB5XmsQcStBaHQ=V_nCvwiWkDUTcMtUQ-g@mail.gmail.com>
From: Adam Eijdenberg <eijdenberg@google.com>
Date: Mon, 09 Nov 2015 19:45:09 +0000
Message-ID: <CAP9QY5bdGzd8hq4DS6DsgQwsaMESvyTmSdWWwWJJ=Y8LDE_5ZA@mail.gmail.com>
To: Peter Bowen <pzbowen@gmail.com>, "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141ca943e765e052420d5d7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trans/hivBLPSB3Ps5rHsFwSH9efmOS9M>
Subject: Re: [Trans] add-chain return value
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: <https://mailarchive.ietf.org/arch/browse/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, 09 Nov 2015 19:45:21 -0000

Peter, I believe that to be correct.  e.g. if you have two SCTs: sct1 and
sct2 then your SignedCertificateTimestampList would be (after base64
decoding both):

<2 bytes: 2 + sct1.length() + 2 + sct2.length()>
<2 bytes: sct1.length()>
<sct1>
<2 bytes: sct2.length()>
<sct2>

Looking at the spec in isolation it's easy to get confused about the first
two bytes - one could imagine that they represent the number of elements in
the array, but instead it's actually the total number of bytes consumed by
the entire array.

On Sun, Nov 8, 2015 at 7:19 AM Peter Bowen <pzbowen@gmail.com> wrote:

> In 6962bis, add-chain is currently defined as returning the base64
> encoded "SignedCertificateTimestamp".  In most cases, these are then
> encoded into a SignedCertificateTimestampList.
>
> Given that the SignedCertificateTimestampList is made up of
> SerializedSCTs rather than SCTs, I wanted to double check that the
> return of add-chain is a raw SCT.  To make a SerializedSCT, it needs
> to be Base64-decoded and then have a length prepended, correct?
>
> Thanks,
> Peter
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

v2.23.0 | Report a Bug | By Email