[Cfrg] ASN.1 in IEEE 1609.2 (was Re: Curve selection revisited)

William Whyte <wwhyte@securityinnovation.com> Tue, 29 July 2014 03:38 UTC

Return-Path: <wwhyte@securityinnovation.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2171A0294 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 20:38:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 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] 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 qH-tHcKrEqPh for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 20:38:29 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE991A0242 for <cfrg@irtf.org>; Mon, 28 Jul 2014 20:38:28 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so9686546qgf.21 for <cfrg@irtf.org>; Mon, 28 Jul 2014 20:38:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=G9TUZGO9SWx2nJ1bPs/ZbFd4Ie3HMf5iZZWdjgTbCVk=; b=A2XF/c2ovYlo7J5CKqcp6Qpep33mFM4kTzqrXql3QUIKdXToWxZWBAGnRyW/WEynhA osIhUH5cgnyOygHCbEs/XhZw91ozlzwHXw+d6SfGweW0cWS04fMhQLo2vXFGvRFA9kul qv+Ci+Q2Iy8z33ZAgKSsn+3bmFRnV7tThpL9I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=G9TUZGO9SWx2nJ1bPs/ZbFd4Ie3HMf5iZZWdjgTbCVk=; b=gIlOfujBKFGzvc675qkTAJYUoPXl0zUUjtb62jyD13T0gNiFYNh2Yq1ArhLqvOd+1O YBrbog8sKRycM9+f5yWbqHBeUOD83bdTaGH5pUlTbOoNjCiaVievauaxKE75P9nP1JKM tMZno1WG7qAQpHj7mvEbQ4Oengyz4u99SyYJJ/+fkEfz8Hri92GLNWXyUkExN69R3Uy+ eHJvL0r7c5eXdo4AYjAsdx8Cf5ZzigKVmKrD0W3HqT5FhoJ/fjlSGrBSjUO+e/3bxEma v637J24VeX2REojTh09F2qvRS9QuEVXzO1WBjIBRHdvF4xrs8a52JKQP8lx43j1GqyQr 12Zg==
X-Gm-Message-State: ALoCoQnQ83jWZyIkjax2EtsGlmHKHGz9+2faA2OOr2J/5x0OquwZqwA8rVB67hPaHgvrpaJGlwS1
MIME-Version: 1.0
X-Received: by 10.224.88.129 with SMTP id a1mr67645668qam.23.1406605107375; Mon, 28 Jul 2014 20:38:27 -0700 (PDT)
Received: by 10.96.172.194 with HTTP; Mon, 28 Jul 2014 20:38:27 -0700 (PDT)
Date: Mon, 28 Jul 2014 23:38:27 -0400
Message-ID: <CACz1E9rUhwErnP_eG_=UC2EpT7M6z89ZdNr7ijNJxnaBA+RJAQ@mail.gmail.com>
From: William Whyte <wwhyte@securityinnovation.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/_o5KgZPeXas1vmK1BO9cNsbFkf4
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] ASN.1 in IEEE 1609.2 (was Re: Curve selection revisited)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jul 2014 03:38:30 -0000

Hi all,

> [Hannes Tschofenig]
>> PS: Regarding the ASN.1 format I am wondering whether the IEEE has done
>> some more detailed analysis of the over-the-wire and the software
>> implementation cost. This would be useful for us in the ACE working group.
>
> [Bob Moskowitz]
> Actually, I mispoke a bit on this.  ASN.1 can be a syntax to describe data.
> It is the BER that defines what is really in the object.  So 1609 as
> developing a task to create an ASN.1 discription of their format and the
> specific BER to create it.  ETSI will be much happier once this is done.

I'm the editor of 1609.2, which currently describes the data
structures in a TLS-like notation and is considering moving to ASN.1.
We've analysed both relative packet size and relative encoding speeds
with ASN.1 (with various different encoding rules) and with the
current encoding. The results are still a bit rough so I can't
distribute them publicly, but we anticipate that they'll be
publishable in a month or so. (I don't know if they're relevant to
this list -- let me know where else I should send them if this list
isn't the place). The high-level outcome, though, is that if you pick
a good set of encoding rules (Octet Encoding Rules, or OER, rather
than the BER/DER that's used in X.509 certs and bloats nested
structures by putting tag and length at every level), then encoding
speed and encoded size are competitive with the current 1609.2 custom
format -- slightly larger and very competitive in speed -- and we
understand ASN.1 has advantages in tool availability, maintainability,
extensibility, and completeness, as well as being preferred for ETSI
standards and for standards sponsored by USDOT.

I would put Bob's statements slighltly differently:
> ASN.1 can be a syntax to describe data.
ASN.1 is a language used to define data structures.
> It is the BER that defines what is really in the object.
The encoding rules (which there are many of, including BER but also
other more compact ones) describe the encoding and decoding for
transmission.
> So 1609 as
> developing a task to create an ASN.1 discription of their format and the
> specific BER to create it.
Yes -- we're creating an ASN.1 description of our structures, and
we're looking at which set of encoding rules it makes sense to specify
for use.

Hope this helps.

Cheers,

William