Re: [stir] Choice of STIR signature algorithm
Eric Burger <eburger@standardstrack.com> Fri, 06 May 2016 14:18 UTC
Return-Path: <eburger@standardstrack.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 2BD7A12D5FC for <stir@ietfa.amsl.com>; Fri, 6 May 2016 07:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level:
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com
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 tZCV-nmN1XQz for <stir@ietfa.amsl.com>; Fri, 6 May 2016 07:18:34 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3A712D0F4 for <stir@ietf.org>; Fri, 6 May 2016 07:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type; bh=qoL0QjxkAH4ZJovhmsuYCapyRWuaA79oB6LIyH7KYTc=; b=s29BwV9RszHIqqMt5CCoeB580w A4CHuUnaibSySU2068FMfIKt6yrwtoC1wzT+BU90iAp9wYbpRYAbBtjDElZF+3PRyAanKtEXagWSa 3Dqsk2JcbJ+hG4E9LkkdSyl7b6qZ6kCE8GiVAqCRRQ6WYgmsblXIrwbMT63Y2xkQIk24=;
Received: from [141.161.133.176] (port=52932 helo=[10.129.225.145]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <eburger@standardstrack.com>) id 1aygaM-0003i3-3c for stir@ietf.org; Fri, 06 May 2016 07:18:34 -0700
Content-Type: multipart/signed; boundary="Apple-Mail=_08F41927-89DF-4853-A5F7-C98338DB3445"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Pgp-Agent: GPGMail 2.6b2
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <26AE9662-B919-4B22-AFF8-45CF351AA03F@vigilsec.com>
Date: Fri, 06 May 2016 10:18:27 -0400
Message-Id: <2C466A8A-D638-49AE-9698-699D67762FF1@standardstrack.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>
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/stir/e3ukYaGtKPqb5AkddpFfjcB1SRA>
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: Fri, 06 May 2016 14:18:36 -0000
FINALLY, a cogent *engineering* reason for needing RSA. How about: MUST support ECDSA SHOULD support RSA unless you know you will not need it Rationale: ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. Pretty much everything else s*cks in comparison. However, especially for delegated certificates, there is a chance that one of the intermediate certificates will not be signed with ECDSA but with RSA. As such, if you know you will be deployed in such an environment, RSA is OK. I would also suggest putting in a toxic waste warning in the document that the support of RSA is *not* a built-in downgrade attack. This is something that is covered by policy, not necessarily engineering. As such, a note to the implementor suggesting that if they know they should only see ECDSA (or better) signatures, they can feel free to reject an INVITE signed with RSA, even if it looks legitimate. > On Apr 12, 2016, at 4:57 PM, Russ Housley <housley@vigilsec.com> wrote: > > >> I don’t know why so much of the discussion during the Tuesday meeting was >> about root certificates. As Eric pointed out on the mail, it is not hard >> to get a ECDSA certificate as Digicert, Entrust, Globalising, Symantec, >> Certicom, Comodo, and soon Let’s encrypt will happily give you one. As >> Russ pointed out most (or all) of these ECDSA certificates will be signed >> by a RSA root certificate. But root certificates and verification of the >> credentials seems to be out of scope of STIR and does not affect the >> PASSporT object. As far as I understand, the only thing STIR should >> specify is verification of the PASSporT object. > > We will need to say that the validation will include RFC 5280 path validation to a trust anchor. This means that the signature on each certificate will be validated. So, for quite some time we will need to be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT object or on a certificate, even if we state a strong preference for ECDSA. > > Russ > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir
- Re: [stir] Choice of STIR signature algorithm Sean Turner
- [stir] Choice of STIR signature algorithm John Mattsson
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm DOLLY, MARTIN C
- Re: [stir] Choice of STIR signature algorithm John Mattsson
- Re: [stir] Choice of STIR signature algorithm Peterson, Jon
- Re: [stir] Choice of STIR signature algorithm John Mattsson
- Re: [stir] Choice of STIR signature algorithm Richard Shockey
- Re: [stir] Choice of STIR signature algorithm Russ Housley
- Re: [stir] Choice of STIR signature algorithm Richard Shockey
- Re: [stir] Choice of STIR signature algorithm Robert Sparks
- Re: [stir] Choice of STIR signature algorithm Richard Shockey
- Re: [stir] Choice of STIR signature algorithm Eric Burger
- Re: [stir] Choice of STIR signature algorithm Eric Burger
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm Richard Shockey
- Re: [stir] Choice of STIR signature algorithm John Mattsson
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm Richard Shockey
- Re: [stir] Choice of STIR signature algorithm Russ Housley
- Re: [stir] Choice of STIR signature algorithm Gorman, Pierce A [CTO]
- Re: [stir] Choice of STIR signature algorithm Richard Shockey
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm Eric Burger
- Re: [stir] Choice of STIR signature algorithm Russ Housley
- Re: [stir] Choice of STIR signature algorithm Eric Burger
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm Peterson, Jon
- Re: [stir] Choice of STIR signature algorithm Eric Rescorla
- Re: [stir] Choice of STIR signature algorithm Russ Housley
- Re: [stir] Choice of STIR signature algorithm Eric Rescorla
- Re: [stir] Choice of STIR signature algorithm DOLLY, MARTIN C
- Re: [stir] Choice of STIR signature algorithm Eric Rescorla
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm Chris Wendt
- Re: [stir] Choice of STIR signature algorithm Eric Burger
- Re: [stir] Choice of STIR signature algorithm Russ Housley