Re: [stir] Choice of STIR signature algorithm

Russ Housley <housley@vigilsec.com> Mon, 16 May 2016 21:01 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED88812DA6A for <stir@ietfa.amsl.com>; Mon, 16 May 2016 14:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 FZJgfkwceDot for <stir@ietfa.amsl.com>; Mon, 16 May 2016 14:01:53 -0700 (PDT)
Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3655412DA6E for <stir@ietf.org>; Mon, 16 May 2016 14:01:53 -0700 (PDT)
Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 11C86F2402E; Mon, 16 May 2016 17:01:53 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id rnC2uN8B4JBn; Mon, 16 May 2016 16:44:44 -0400 (EDT)
Received: from [192.168.7.153] (70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net [70.91.193.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 6170CF24013; Mon, 16 May 2016 17:01:52 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6ADA6AA5-3243-40C0-85A6-6DA3B71DCDFD"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CABcZeBN3OLiaea10cWrtyv6R9KxHHVMuAsC56o=xmj6MWn_RYg@mail.gmail.com>
Date: Mon, 16 May 2016 17:01:51 -0400
Message-Id: <AA4D2199-3A8D-4015-86F3-DEE04120E51C@vigilsec.com>
References: <D32953D1.4770F%john.mattsson@ericsson.com> <1A843300-AEB7-4EC6-8256-C88F6847B82E@neustar.biz> <D329995E.477D9%john.mattsson@ericsson.com> <A3723DBB-476C-4F22-95E0-37AE0872FBBD@shockey.us> <F4F09888-780B-4725-9A74-AD2EF661C5C0@vigilsec.com> <0DD82221-E79D-4F15-B2B5-93165EC98919@shockey.us> <570534D4.6010707@nostrum.com> <5195FEBC-8395-4E77-B768-2B2D81144121@shockey.us> <56DF2D20-9381-45CB-8057-6B1AB99B05E9@chriswendt.net> <BB4B8171-BF3E-4D3F-B81B-73AC9768ED75@shockey.us> <D3316C0C.485E4%john.mattsson@ericsson.com> <2EC06927-2614-491E-A499-C86ABB30573C@chriswendt.net> <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com> <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.com> <EED4C512-B57C-47EC-9CE4-07C64365D246@vigilsec.com> <CABcZeBN3OLiaea10cWrtyv6R9KxHHVMuAsC56o=xmj6MWn_RYg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/QT5ZjXKBHrCYvK3RuOqVQj-9u2A>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] Choice of STIR signature algorithm
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2016 21:01:55 -0000

Eric:

I was thinking P-256, but I could be talked into:

	MUST support P-256
	SHOULD support P-384

Russ


On May 15, 2016, at 11:36 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> This seems largely reasonable. I would consider removing the SHOULD for RSA for
> PASSporT signatures, for two reasons:
> 
> 1. There's no legacy to deal with
> 2. Because these objects are just sent out with no negotiation, it's not that useful
> to know that relying parties might or might not support your algorithm. The safe
> thing to do would be ECDSA.
> 
> I would also note that the above doesn't specify a curve, but I assume we're talking
> P-256.
> 
> -Ekr
> 
> 
> On Mon, May 9, 2016 at 1:37 PM, Russ Housley <housley@vigilsec.com> wrote:
> I would rather be a bit more granular.
> 
>         MUST support ECDSA for PASSporT signatures
>         SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures
> 
> and
> 
>         MUST support ECDSA for certificate signatures
>         MUST support RSA PKCS#1 v1.5 for certificate signatures
> 
> Then, we should say something to product planners that at some point in the future, we expect support for RSA to be downgraded.
> 
> Russ