RE: generation of private keys

Carlisle Adams <carlisle.adams@entrust.com> Tue, 24 November 1998 19:10 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA02828 for <pkix-archive@odin.ietf.org>; Tue, 24 Nov 1998 14:10:58 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05761 for ietf-pkix-bks; Tue, 24 Nov 1998 08:01:29 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05757 for <ietf-pkix@imc.org>; Tue, 24 Nov 1998 08:01:25 -0800 (PST)
Received: id KAA04009; Tue, 24 Nov 1998 10:59:14 -0500
Received: by gateway id <XNGHBG0S>; Tue, 24 Nov 1998 10:54:28 -0500
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789178@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'kelm@pca.dfn.de'" <kelm@pca.dfn.de>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: generation of private keys
Date: Tue, 24 Nov 1998 10:54:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk

Hi Stefan,

> -----Original Message-----
> From: Stefan Kelm [mailto:kelm@pca.dfn.de]
> Sent: Tuesday, November 24, 1998 8:28 AM
> To: ietf-pkix@imc.org
> Subject: CMP: generation of private keys
> 
> 
> I do not want to start the discussions about key generation 
> again but the
> following paragraph from draft-ietf-pkix-ipki3cmp-08.txt 
> raises a question
> to me:
> 
> : 2.2.1.3 Location of key generation
> :
> : In this specification, "key generation" is regarded as occurring
> : wherever either the public or private component of a key pair first
> : occurs in a PKIMessage. Note that this does not preclude a 
> centralized
> : key generation service - the actual key pair MAY have been generated
> : elsewhere and transported to the end entity, RA, or CA using a
> : (proprietary or standardized) key generation 
> request/response protocol
> : (outside the scope of this specification).
> :
> : There are thus three possibilities for the location of "key
> : generation":  the end entity, an RA, or a CA.
> 
> In a legal context (esp. the German Signature law) a relying 
> party might want
> to know who generated the key pair of another end entity 
> before deciding to
> enter a contractual relationship with this entity. One might 
> place trust
> in another subject's certificate based on that question so 
> wouldn't it make
> sense to specify an optional certificate extension that indicates who
> performed the process of key generation (eg. EE, CA, RA, other)?
> 
> I don't think this is merely a policy/CPS issue since the CA might not
> address this issue in its policy. The German Signature law 
> profile, for
> example, in principle allows for the key material to be 
> generated by either
> the CA or the end entity (although the latter is very 
> unlikely to happen
> due to the technical requirements). So the relying party 
> wouldn't get an
> answer from reading the policy/CPS.
> 
> Comments?


Interesting question.  My initial reaction is to wonder if a new certificate
extension is really the right solution for this.  If the CA generates the
key pair, it can certainly populate such an extension with confidence.
However, if the CA did not generate the key pair, how will it distinguish
between EE, RA, and "other" (i.e., how will it know (with certainty) who did
the actual key pair generation so that it can populate the extension)?

Carlisle.