Re: [pkix] PKCS #8? Re: Updated EdDSA/Ed25519 PKIX document

Simon Josefsson <simon@josefsson.org> Thu, 12 November 2015 07:49 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0C1A87C3 for <pkix@ietfa.amsl.com>; Wed, 11 Nov 2015 23:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 2SyofrYZ_TIX for <pkix@ietfa.amsl.com>; Wed, 11 Nov 2015 23:49:48 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 89CB71A87BA for <pkix@ietf.org>; Wed, 11 Nov 2015 23:49:48 -0800 (PST)
Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAC7nYqf024226 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 12 Nov 2015 08:49:35 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
References: <878u7xtu06.fsf@latte.josefsson.org> <5643175F.9070405@gmail.com> <1447244606.16388.10.camel@josefsson.org> <56435732.8020405@gmail.com>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:151112:pkix@ietf.org::AkcstbQ618QddII1:CS5w
X-Hashcash: 1:22:151112:anders.rundgren.net@gmail.com::hJhwUEM0q3w5w5sq:X1Mh
Date: Thu, 12 Nov 2015 08:49:33 +0100
In-Reply-To: <56435732.8020405@gmail.com> (Anders Rundgren's message of "Wed, 11 Nov 2015 15:56:50 +0100")
Message-ID: <87io57bqsy.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/038uvYJKNOTvOYIP6VvXVCW6cCA>
Cc: pkix@ietf.org
Subject: Re: [pkix] PKCS #8? Re: Updated EdDSA/Ed25519 PKIX document
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 07:49:50 -0000

Anders Rundgren <anders.rundgren.net@gmail.com> writes:

>> Right now we are re-using the
>> EdDSA public key OID for the private key OID too.
>
> I think this should be harmonized with JOSE who essentially have the following
> alternatives for describing public keys:
>
> jwk:
>   {
>     "kty": "EC",
>     "crv": "ED25519",
>     "x": "8dymopMICY76wfnqdpX0JDpCRYke0-Jp1p7lKPQIIRg",
>   }
>
> The above departs from the current JWK standard which requires an "y" as well
> making the the following approach a viable alternative:
>
> jwk:
>  {
>   "kty": "ED",
>   "crv": "ED25519",
>   "x": "8dymopMICY76wfnqdpX0JDpCRYke0-Jp1p7lKPQIIRg",
> }
>
> From what I can deduct, this latter scheme is more in line with your PKIX
> SPKI solution.

No, https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03 only
encodes the x parameter.  So this appears consistent.

> This would also be great for Android and Java.  In fact the only solution
> I have found for Java indeed defines a new provider key class:
> https://github.com/str4d/ed25519-java/blob/master/test/net/i2p/crypto/eddsa/EdDSAEngineTest.java#L36
>
> Of course this choice won't shatter the earth but having different solutions
> for PKIX and JOSE would IMO be quite unfortunate.

I don't believe there is sufficient overlap in implementation to matter
in practice, however the fundamental principles should be the same for
both protocols, so it would indeed be surprising if they ended up
differently.

/Simon

> Anders
>
>
>>
>> One alternative to the approach we've taken is to re-use the RFC 5915 EC
>> private key format.  Then everything is covered by the combination of
>> RFC 5915 and the NamedCurve registration in:
>> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01
>>
>> Does anyone have thoughts on which approach to use?
>>
>> Thanks,
>> /Simon
>>
>>>
>>> Anders
>>>
>>>>
>>>> I have pushed out a new version of the document describing EdDSA public
>>>> keys, signatures and certificates for PKIX.  The change in -03 include
>>>> the addition of the prehash mode, test vectors generated by GnuTLS, and
>>>> a section recommending certain human readable names.
>>>>
>>>> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-03
>>>>
>>>> I've started a thread to discuss whether it is wortwhile to be able to
>>>> use the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing,
>>>> and I'd appreciate feedback on whether people are interested in this and
>>>> generally if it is a good idea or not.  The complexity involved make me
>>>> shy away a bit from it, but it is fun to consider.  The thread is here:
>>>> https://moderncrypto.org/mail-archive/curves/2015/000630.html
>>>>
>>>> /Simon
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pkix mailing list
>>>> pkix@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pkix
>>>>
>>>
>>
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>