[Cfrg] Keys for multiple cryptographic uses (was: Re: Outline -> was Re: normative references)

Rene Struik <rstruik.ext@gmail.com> Thu, 16 January 2014 22:31 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA621AC85E for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 14:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 eLe4QY6c3zMv for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 14:31:42 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF4981AC4AB for <cfrg@irtf.org>; Thu, 16 Jan 2014 14:31:41 -0800 (PST)
Received: by mail-ig0-f178.google.com with SMTP id uq10so8893772igb.5 for <cfrg@irtf.org>; Thu, 16 Jan 2014 14:31:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jGIITbb2bd4xEeDa5kJbdTQUbVwheh/NmgkOi66KPbA=; b=cmzHmr9CGhKao+/4cePyxKIiXQGnLgtmZiZr0T4YjZw+8jdEvviB0goXIUWmSaMDww MlE1nMgAUW7mxGfczYaQ2bDtr9UIA2IAybd3FTkUimnMNYeAvJrpgp4b+8Z/mghFAa6O rLnTf9wvdoKUSt+jGepzEaM07BTRmD7F/c2GJg12VhvyvR2xz72kE/Nb2yN0qSJz844o NUYM+KCr7lFoi4dNGNhLgiFE0xUAmc1xr181ySDmL3Q3dPnVOwmaBs3treQKUhKxSoHh 07aoNTYgi35yjvuN6gWdu+mCoWGzTVkcTf/woCxC7uYqkZLVIdEAW+xEsrYuwSXl9d38 nSrg==
X-Received: by 10.42.215.80 with SMTP id hd16mr10221926icb.17.1389911489741; Thu, 16 Jan 2014 14:31:29 -0800 (PST)
Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id f5sm14300709igc.4.2014.01.16.14.31.27 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 14:31:28 -0800 (PST)
Message-ID: <52D85DBB.1010505@gmail.com>
Date: Thu, 16 Jan 2014 17:31:23 -0500
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: David McGrew <mcgrew@cisco.com>, "Igoe, Kevin M." <kmigoe@nsa.gov>, 'Paul Lambert' <paul@marvell.com>, Watson Ladd <watsonbladd@gmail.com>
References: <CEFC6B5C.2C6E8%paul@marvell.com> <CACsn0ckSMUbEJ4F3bQ5KVMbhdPQw1MTMCce6B8uhMfA_V0Nupw@mail.gmail.com> <CEFCBB2E.2C792%paul@marvell.com> <3C4AAD4B5304AB44A6BA85173B4675CABA9A493F@MSMR-GH1-UEA03.corp.nsa.gov> <52D8417B.9030908@cisco.com>
In-Reply-To: <52D8417B.9030908@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] Keys for multiple cryptographic uses (was: Re: Outline -> was Re: normative references)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 22:31:43 -0000

Hi Paul et al:

A counter example in practice to the "received wisdom" not to reuse 
public keys both for key agreement and non-repudiation is during 
certification requests, when the key to be certified is to be used for 
uses including key agreement and where the request is signed.

[see also NIST SP 800-56a-2013, Section 5.6.3.2, item #5:
A static key pair may be used in more than one key-establishment scheme. 
However, one static public/private key pair shall not be used for 
different purposes (for example, a digital signature key pair is not to 
be used for key establishment or vice versa) with the following possible 
exception: when requesting the (initial) certificate for a public static 
key-establishment key, the key-establishment private key associated with 
the public key may be used to sign the certificate request. See SP 
800-57, Part 1 on Key Usage for further information.
]

While key separation seems prudent, it is not entirely clear (to me) 
whether the conditions under which this is required are precisely known 
(even in the above-mentioned case of signed certificate requests).

Best regards, Rene


On 1/16/2014 3:30 PM, David McGrew wrote:
> Hi Kevin, Paul, and Watson,
>
> On 01/16/2014 02:42 PM, Igoe, Kevin M. wrote:
>> Paul Lambert
>> On Thursday, January 16, 2014 1:43 AM Paul Lambert wrote:
>>
>>> A truly ‘unified' public key system would support both signatures and
>>> key establishment with the same key.
>>>
>> Received wisdom is that using the same key for both key establishment 
>> and
>> signatures is a bad idea.  I believe the concern is that one protocol
>> might be used an Oracle to subvert the other.
>
> Agreed on that point, but there is a background issue here that I want 
> to ask about.
>
> [snip]


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363