Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

David Benjamin <davidben@chromium.org> Fri, 16 December 2016 07:18 UTC

Return-Path: <davidben@google.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDA129849 for <curdle@ietfa.amsl.com>; Thu, 15 Dec 2016 23:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.595
X-Spam-Level:
X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 PrJ-y8xkRMTI for <curdle@ietfa.amsl.com>; Thu, 15 Dec 2016 23:18:46 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 3133D12986C for <curdle@ietf.org>; Thu, 15 Dec 2016 23:18:23 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id p16so77566163qta.0 for <curdle@ietf.org>; Thu, 15 Dec 2016 23:18:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IImgLd0mWE20aW6s9kNy6daXi0WXK3Pmts6wu2tIM1w=; b=IDiyFKnFZInt8L4P3JKrUvLZmwcMSlHKND8ZPaUJwHZUeS5qk5fB+dfTSmpXek+0BR O9V0DYUNFcLxza43CRP9Pu4vZBDuj9bSkGxARVXzT9u1fw59NEpV5Og8b8Mo121egeJP 3K0VQrIi91/GIsbKZRQDDpeZGxCSupQx/EQh8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IImgLd0mWE20aW6s9kNy6daXi0WXK3Pmts6wu2tIM1w=; b=UBko+8qry4YdK7HJRbpGTuwNyTV8UyAR+6l/puwWeWE/y/mnUH3dK+PMwrMRvXkLe+ Cx1bVSZLGqKfmdZuguLWohTs6VSHWM16hbg+CkInwwod6xLaPqraGs/cVs39WvuIMxxx ef8S3+n4xfWYS3jvxojiw3aDveRXydfBjHTp+t86laaZIvxcYaLqW0wdTdZo4vj/2HIr l0tmrtJti3YRYub+l64pLhyVdHUltuztutmobY6l6bKnT7CdkWlf7kPIeeBpvsROlV7h dVMi7MFUBY0amKLRz0hgwBoN94AsixH0O8ZMe4F5eNRrriBYj/KoXlorljr0mxYuPXZs Pkpw==
X-Gm-Message-State: AIkVDXKrP2tB+tc7WXjcz252T8mwvK8HjixH1tMH/wqfrDZQuK5uOzxDILoj5pzRiFUq2Wxvy+dOSo6W/sE5FhaR
X-Received: by 10.237.62.38 with SMTP id l35mr1224414qtf.175.1481872702028; Thu, 15 Dec 2016 23:18:22 -0800 (PST)
MIME-Version: 1.0
References: <20161214105434.418FAADD1C@smtp.postman.i2p> <20161214121515.GA10791@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaCWAx8Vp67VZz4G5DQpTGf5DX-sMN+1i40acgCYT8_NVA@mail.gmail.com> <002501d25760$a75c0bb0$f6142310$@augustcellars.com> <CAF8qwaDzC8C0czSPrCdTgKH-3_YqW8KeVQ291p+SNcOo-NyGxg@mail.gmail.com>
In-Reply-To: <CAF8qwaDzC8C0czSPrCdTgKH-3_YqW8KeVQ291p+SNcOo-NyGxg@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 16 Dec 2016 07:18:11 +0000
Message-ID: <CAF8qwaASPih==KC9NKSy6KtEeySjEf4ByM1JkzCuu2bF8EP1xQ@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="001a11408cb602119c0543c160b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/x22RDbwlfXu168Wwzg9ljDWqCxE>
Cc: curdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.17
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 Dec 2016 07:18:48 -0000

So we don't end up with two variants of this floating around (this thread
gives one data point of the current text being misinterpreted), What do you
think about these editorial changes?

1. In the paragraph beginning "For the keys defined in this document
[...]", add a sentence like "Note the opaque byte sequence is wrapped in
OCTET STRINGs twice in total."

2. EdPrivateKey sounds like this only applies to Ed* rather than both Ed*
and X*. It should probably be renamed. But the best name I can come up with
right now is PrivateKeyWrapper, which is terrible. Another option is to
avoid defining a type and just say:

   For the keys defined in this document, the private key is always an
   opaque byte sequence.  This is encoded in a OneAsymmetricKey
   object by wrapping the sequence in an ASN.1 OCTET STRING
   and placing its DER encoding in the 'privateKey' field. Note that
   'privateKey' is itself an OCTET STRING, so the original byte
   sequence is wrapped in OCTET STRINGs twice in total.

David


On Fri, Dec 16, 2016 at 1:56 AM David Benjamin <davidben@chromium.org>
wrote:

Ah, yes, I see OpenSSL has already shipped code which serializes X25519 in
this way, as early as OpenSSL 1.1.0 in September. That's unfortunate. It
would have been preferable to avoid this confusing double wrapper, but so
it goes I guess.

David

On Fri, Dec 16, 2016 at 12:53 AM Jim Schaad <ietf@augustcellars.com> wrote:

I believe that the OpenSSL people would be sad if we changed this at this
time.  I did some interop testing with their developers before the last
version was released and the OCTET STRING wrapper on the private key is
what we were doing at the time.

Jim

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David Benjamin
Sent: Wednesday, December 14, 2016 5:23 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; str4d <str4d@i2pmail.org>
Cc: curdle@ietf.org
Subject: Re: [Curdle] Key examples in draft-ietf-curdle-pkix-03

On Wed, Dec 14, 2016 at 7:15 AM Ilari Liusvaara <mailto:
ilariliusvaara@welho.com> wrote:
On Wed, Dec 14, 2016 at 10:54:34AM +0000, str4d wrote:
> Hello,
>
> I am currently updating my EdDSA Java library to implement the current
> spec for key encoding [0] (previously I used
> draft-josefsson-pkix-eddsa-04 for public keys, and the equivalent in
> PKCS#8 format for private keys). The example public key given in
> draft-ietf-curdle-pkix-03 [1] passes my tests, however the example
> private key [2] does not.
>
> It appears that the private key material within the example is 34 bytes,
> but according to Section 3.2 of draft-irtf-cfrg-eddsa-08 [3] (which
> AFAICT the present draft defers to for encoding), the private key is the
> b-bit seed k, which is 32 bytes.
>
> Am I missing something? If the example keys in the present draft are
> correct, it would be helpful to add a reference that clarifies their
> exact encoding.

Apparently the key is wrapped in OCTET STRING twice for some reason,
so the length is actually 32 bytes (the first 2 are second OCTET STRING
header).

Is it too late to change that / was there any particular reason for this?
Not that saving or using two bytes really matters, but it seems unnecessary
when we already have an OCTET-STRING-shaped hole to put our octet string in.



David

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle