[TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS

Michael StJohns <msj@nthpermutation.com> Mon, 01 June 2015 17:48 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4450F1B2FEC for <tls@ietfa.amsl.com>; Mon, 1 Jun 2015 10:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Q2wTEwR3dc1O for <tls@ietfa.amsl.com>; Mon, 1 Jun 2015 10:48:46 -0700 (PDT)
Received: from mail-vn0-f48.google.com (mail-vn0-f48.google.com []) (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 5F3511B2FD3 for <tls@ietf.org>; Mon, 1 Jun 2015 10:48:38 -0700 (PDT)
Received: by vnbg129 with SMTP id g129so17122642vnb.11 for <tls@ietf.org>; Mon, 01 Jun 2015 10:48:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pJI7h/6Rs2PiI3d80gxmYOkXzJiJ1KEz658VoAdRKgA=; b=ipwUyDak6kA4U0nfR2gWxj+oNxEwSyqUlTzw+0aNndYL5aZf2kbuZKNFC8in5K9zC6 0X6rc8f/PAyDk+02tFATfnCK2MrdNlrA/2+AZTqPSdA/x4LvIYaHvDjnDS6Dlia/D1El hL6lTN9jI9tXMK6NDGNZw1ITmpPmqiubqaTb9zJ+KNAIoOieH8qOQLorZC2bYy3SQ9HK 9hLdcXdFkN19OnlG2fxIQdUAicnH+Ws+TS29im9f/IzOqG2t5CCaFglvOxvuCRdHlDfv jCKkI46lo2QHi+Z2clkPtFn6KEllim3HpIEWld/EBU8f1MVT32w8QcVXwu+glwgSE/Xn xMKA==
X-Gm-Message-State: ALoCoQlme2ntDZ/yQyWGAlkfEfjEl25F4QmRId1l48mJOqxoTgwZlz7rimr5qM8N4cInZN9nX2Xz
X-Received: by with SMTP id d10mr30032063vdw.49.1433180917325; Mon, 01 Jun 2015 10:48:37 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:6116:7309:4731:ca15? ([2601:a:2a00:84:6116:7309:4731:ca15]) by mx.google.com with ESMTPSA id de3sm22419766vdc.17.2015. for <tls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2015 10:48:36 -0700 (PDT)
Message-ID: <556C9AF4.7030607@nthpermutation.com>
Date: Mon, 01 Jun 2015 13:48:36 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: tls@ietf.org
References: <556C4ACD.9040002@azet.org> <CABcZeBNsYmto4F-J0mFoxcq-qfL=NJrvDu67fyY9bpBmRp16mQ@mail.gmail.com> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII>
In-Reply-To: <20150601125302.GA19269@LK-Perkele-VII>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/b84Uw3TdenzLUD_ooAx7n4dcXd0>
Subject: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 17:48:50 -0000

On 6/1/2015 8:53 AM, Ilari Liusvaara wrote:
> I think the current plan with EdDSA and related certficates are to reuse
> ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate.
I may be misreading this and all you're talking about are code points 
for TLS, but in case you're talking about the more specific issue of 
reusing the current SubjectPublicKeyInfo definitions of id-ecPublicKey 
for certificates containing EdDSA public keys:

RFC 5480 defines the format of an EC public key (as identified by 
1.2.840.10045.2.1 and for that matter by and  Note specifically the second bullet on the format of the 
ECPoint octet string.

> 2.2.  Subject Public Key
>     The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
>     ECC public keys have the following syntax:
>       ECPoint ::= OCTET STRING
>     Implementations of Elliptic Curve Cryptography according to this
>     document MUST support the uncompressed form and MAY support the
>     compressed form of the ECC public key.  The hybrid form of the ECC
>     public key from [X9.62] MUST NOT be used.  As specified in [SEC1]:
>        o The elliptic curve public key (a value of type ECPoint that is
>          an OCTET STRING) is mapped to a subjectPublicKey (a value of
>          type BIT STRING) as follows: the most significant bit of the
>          OCTET STRING value becomes the most significant bit of the BIT
>          STRING value, and so on; the least significant bit of the OCTET
>          STRING becomes the least significant bit of the BIT STRING.
>          Conversion routines are found in Sections 2.3.1 and 2.3.2 of
>          [SEC1].
>        o The first octet of the OCTET STRING indicates whether the key is
>          compressed or uncompressed.  The uncompressed form is indicated
>          by 0x04 and the compressed form is indicated by either 0x02 or
>          0x03 (see 2.3.3 in [SEC1]).  The public key MUST be rejected if
>          any other value is included in the first octet.

This RFC mirrors equivalent language in both X9.62/63 and the SecG stuff 
(and for that matter NIST).

So, don't try and overload the current meaning of id-ecPublicKey - 
you'll break a *lot* of things.  And we (the IETF that is) don't 
actually have change control over what that OID means.

Instead, get a new allocation and write a document that looks like 
RFC5480 for the ED and Curve public keys.  You want certificate 
representations for *both*.

Later, Mike