[Curdle] Comments regarding draft-ietf-curdle-pkix-07

Steffen Jaeckel <s_jaeckel@gmx.de> Fri, 16 February 2018 15:22 UTC

Return-Path: <s_jaeckel@gmx.de>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 79753126579 for <curdle@ietfa.amsl.com>; Fri, 16 Feb 2018 07:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JfJ_sG5uFdWu for <curdle@ietfa.amsl.com>; Fri, 16 Feb 2018 07:22:50 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (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 F3F6B120454 for <curdle@ietf.org>; Fri, 16 Feb 2018 07:22:49 -0800 (PST)
Received: from [] ([]) by mail.gmx.com (mrgmx103 []) with ESMTPSA (Nemesis) id 0M24Vr-1eWpci3HyN-00u1S3 for <curdle@ietf.org>; Fri, 16 Feb 2018 16:22:47 +0100
From: Steffen Jaeckel <s_jaeckel@gmx.de>
To: curdle@ietf.org
Message-ID: <588bbde5-988c-7883-f70c-279863f25334@gmx.de>
Date: Fri, 16 Feb 2018 16:22:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yYuT5igmKvjGGR3KI7C1ZZl9ToTYL1BfM"
X-Provags-ID: V03:K0:FCFovczg80ypuo9Aklqt8xtCJuj6BlaDcdSEOJhXshysTK+7XQj CMydN792Aw6PGTwJQkssNvWriYtZE+6KxCh182F2zSbm4AtEWOPrPx5ChvRP0ioPlRAuqGg G3ozBifcnCHcXSa/A8fYxen0TEqlrStUt7qZpAwNrt9hDtbNWLbq1HzQkXgI7zWZs9OJpK5 AqJO0MnSmOdeNoURbhXrw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:nidsTww1dH4=:bjRwP+pK2nT0b/QE+slwns 2m9+EzPPziZYEWhpc6V9X+xd1EcMIPNhkQbPyq76xv6D/qwfOy3H+HrvGoAvTSYiEh2EUYvyF tr7ULVN5TOp1GWGtZsqWz/nEwjCwsMPHH8Vs7wPZKIMJ8F1DsuiidWFr5s6Mu+KqPLy/l3lg0 Hs6CVg7J+UdGuDjOJG/10RAO9fZjENEctZLioiTUxhLERlq5UBk423QTJvmApvNg5ge6jA83V A+PkTt5cYi+W1gnsbP2/PG5vos36Uc/zVTpGJn8F2EF/Sh0M1lgnVtn7o8Em8tPVvxf1Z9fC4 itW7S7hhtdopsLBozHuLUVQ2cjPXF0n0XcJTRPvM02SjMCsibs8IFbFygrtbLOSMXCkmGO5qY 6q82YQdSA6epn3WC0S63VGdNTt2TQ5NghH4lx3bM40FjAlpLEAoKlYGzBmdEmkLAPdL7IEsqP mp0UgMZTvDRy7z0BMoLM0a5LJg+iIEjBP6FOjISttWVUCK+M752mbvabsgjhW19x/3CWbsurK detUC466sCcDYZ/fdBJm41dEoYpDNDFW1SQxrsJtnUplSBojL7vlTWTPN40bc3vEfuS9nFY8Y 7zosGCQVI8fJupaux8J6yJwaD0x7eMVko3UiHEzycyABq1T1j4VM79ELG7d04KIJvsIgjIN+A uxOGSMVKDxSRcYgi0vpQs/366TzGI5lMaoHF1ptsX3V72u9zi59muAVienGXvIfRISiE1B3Rf c93WwRsjMtDFMaPpSfO/nfA5SZ0lcT2n9Gei2HOu8LMwshcpmb63QlfpvR8t6IAan4TdZQlu4 mOzNdQnHJ+TvK5yMcoypRnKZvYoPw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/COlUYqFYoI9CRXcotGKD2rSuASs>
X-Mailman-Approved-At: Fri, 16 Feb 2018 07:24:12 -0800
Subject: [Curdle] Comments regarding draft-ietf-curdle-pkix-07
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2018 15:22:52 -0000


I'm currently adding curve25519 support to libtomcrypt.

That's why I've just read through
https://tools.ietf.org/html/draft-ietf-curdle-pkix-07 and I've got some

# why don't you use the same public/private key throughout the examples?

that would make life easier to recognize what is where in which format

# why is there no ASN.1 dump of example 10.1?

# why are the examples in 10.3 not formatted the same way?

first example is like:

>    12 04   34:   OCTET STRING
>              :     04 20 D4 ...

second example is like:

>     12  34:   OCTET STRING, encapsulates {
>     14  32:     OCTET STRING D4 ...

# why is the private key an OCTET STRING in an OCTET STRING?

I already got pointed to
https://www.ietf.org/mail-archive/web/curdle/current/msg00572.html ff.
which also discusses this and I follow the opinion of Nikos to not carry
technical debt in the standard if it's already found before final
standardization. It shouldn't be the problem of later implementors that
there were some early adopters who implemented a non-standard version.

# a correction proposal to Ch. 8:

> When the curve is known, use the more specific string of X25519 or
> X448.

should be

> When the curve is known, use the more specific string of "X25519" or
> "X448".

Steffen Jaeckel - s_jaeckel@gmx.de
GnuPG fingerprint:  C438 6A23 7ED4 3A47 5541 B942 7B2C D0DD 4BCF F59B
My OTR key has changed on 30. Sept. 2015!
jabber: jaeckel@jabber.ccc.de F052DE29 4FA9A02D 44A794E5 AE5AC0FB C5865C64