[Cfrg] One Key -> RE: considering new topics for CFRG

Paul Lambert <paul@marvell.com> Thu, 09 January 2014 01:10 UTC

Return-Path: <paul@marvell.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 447C71ADF69 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 17:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 z-cJPDUcBM5N for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 17:10:09 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 66FCE1ADF60 for <cfrg@irtf.org>; Wed, 8 Jan 2014 17:09:59 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0919kwd022121; Wed, 8 Jan 2014 17:09:46 -0800
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1h919ratnm-35 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Jan 2014 17:09:46 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 8 Jan 2014 17:09:43 -0800
From: Paul Lambert <paul@marvell.com>
To: Watson Ladd <watsonbladd@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Wed, 08 Jan 2014 17:09:42 -0800
Thread-Topic: One Key -> RE: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8LM7gonDptIzDhR9+BTyVpg1yJAAAATO7wAAPVX2A=
Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D018B7ED7028@SC-VEXCH2.marvell.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com> <CACsn0cmBFwQ3bxpNd1fNaPWAqsEtgXe7fdTSOz2npbSAEYYVwA@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E173@SC-VEXCH2.marvell.com>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E173@SC-VEXCH2.marvell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-08_09:2014-01-07, 2014-01-08, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401080170
Cc: Sean Turner <turners@ieca.com>, David McGrew <mcgrew@cisco.com>
Subject: [Cfrg] One Key -> RE: considering new topics for CFRG
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, 09 Jan 2014 01:10:10 -0000

More on this single topic:

> > >> >   - Public key based methods that can be readily be used
> > >> >     to both sign data and be used to develop encryption keys

Here are the NIST guidelines that generated my wish:
   http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-56Arev1_3-8-07.pdf

"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"

This immediately divides any PK architecture in half with
separate signature and key establishment PKs.

It's odd that the guidelines allow the key 
establishment key to sign once, but not after the
certificate request.

Questions for the group:
1) Are there any demonstrable attacks on the 
combined usage of key establishment and signature algorithms?

2) What are the known safe combinations?
(I've seen at least one Edwards curve paper on combined usage)



Paul