Subject: RE: generation of private keys

From: Carlisle Adams <[email-masked]>
Date: Tue, 24 Nov 1998 10:54:27 -0500

Hi Stefan,

> -----Original Message-----
> From: Stefan Kelm [mailto:[email-masked]]
> Sent: Tuesday, November 24, 1998 8:28 AM
> To: [email-masked]
> 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.

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 24 Nov 1998 10:44:13 -0800

>the actual key pair generation so that it can populate the extension)?

It seems the most a CA could do is indicate either that it did, or did not
generate the keypair, correct?

___tony___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

---

From: Warwick Ford <[email-masked]>
Date: Wed, 25 Nov 1998 06:36:07 -0800

I think the case of a CA generating key pairs is the least interesting of
all.  Generally, for security separation purposes, it is considered highly
undesirable for a CA to generate user key pairs.  Having the key pair
generated by an RA or another "authority" devoted to key management, maybe
within the same enterprise, are better.  In the case of an RA or other
authority, there is generally an established trust relationship between the
CA and that entity, supported, for example, by their inherent organizational
relationship or by a contractual relationship, plus trusted communications
paths.  Hence, it is likely quite reasonable for a CA to have confidence
that, when an RA or key management authority says it generated a particular
key pair, it did, in fact, generate that key pair.

Warwick

-----Original Message-----
From: Stefan Kelm [mailto:[email-masked]]
Sent: Wednesday, November 25, 1998 1:57 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: generation of private keys

Tony,

> generate the keypair, correct?

You're probably right. So it comes down to a boolean indicator. Do you agree
that such an indicator would be a useful enhancement?

If we don't use an extension, what other means would we have to indicate
the key generation location?

Cheers,

        Stefan.

____________________________________________________________________________
__
Stefan Kelm            PGP key: "finger [email-masked]" or via key
server
DFN-PCA, University of Hamburg
<[email-masked]>
Vogt-Koelln-Str. 30
http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494
2241

---

From: Larry Layten <[email-masked]>
Date: Wed, 25 Nov 1998 09:09:18 -0600

It would seem to me that if an RA is certifying information to
be contained in a certificate, to be signed by a CA, that policy
could be implemented that would also allow it to certify that
it did in fact create the key-pairs -- or to take it further, to 
certify the strength of the token that the subject is using,
which also should be of interest.

Larry

-----Original Message-----
From:	Stefan Kelm [SMTP:[email-masked]]
Sent:	Wednesday, November 25, 1998 3:57 AM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	RE: generation of private keys

Tony,

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger [email-masked]" or via key server
DFN-PCA, University of Hamburg                               <[email-masked]>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 25 Nov 1998 18:10:34 -0500

Hi Warwick,

:-----Original Message-----
:From: Warwick Ford [mailto:[email-masked]]
:Sent: Wednesday, November 25, 1998 9:36 AM
:To: [email-masked]'; [email-masked]; [email-masked]
:Subject: RE: generation of private keys
:
:I think the case of a CA generating key pairs is the least 
:interesting of
:all.  Generally, for security separation purposes, it is 
:considered highly
:undesirable for a CA to generate user key pairs.  

The above sentence should probably be clarified because it is misleading as
it stands (which I'm sure was not your intention).  I prefer "Generally, for
security separation purposes, it is considered highly undesirable for a CA
to generate user key pairs when the CA is at 'arm's length' from the user.",
or something similar.  In particular, a CA that is external to an
organization (e.g., a CA service provider) may have nothing in its CPS
discussing such functionality and may take no legal responsibility for user
key pair generation.  This is a case where separation of duties makes sense.

However, for other environments the CA, the RA, and the key generation
facility may effectively be the same entity within an organization.
Separation of duties need not be required in such cases and there is no
reason for it to be "undesirable" for this entity to perform both key
generation and CA functions.

:Having the key pair
:generated by an RA or another "authority" devoted to key 
:management, maybe
:within the same enterprise, are better.  

Absolutely.  "Better" if the CA is outside the enterprise.  Not necessarily
"better" for any inherent reason if the CA is within the enterprise.

:In the case of an RA or other
:authority, there is generally an established trust 
:relationship between the
:CA and that entity, supported, for example, by their inherent 
:organizational
:relationship or by a contractual relationship, plus trusted 
:communications
:paths.  Hence, it is likely quite reasonable for a CA to have 
:confidence
:that, when an RA or key management authority says it generated 
:a particular
:key pair, it did, in fact, generate that key pair.
:
:Warwick

Does this, then, argue for Stefan's original suggestion of an extension
specifying the location of key generation?  Do you think that because of
such relationships, trusted communications paths, etc., the CA can have
sufficient confidence in the location to encode it into a certificate and
stand by it in a legal sense?

Carlisle.

---

From: Warwick Ford <[email-masked]>
Date: Fri, 27 Nov 1998 06:29:20 -0800

Hi, Carlisle:

No, I would not restrict my comment to only the situation you describe.
Even within one organization it is generally good security practice to
separate security functions such as certification and key management.  This
may, of course, be of varying importance in different environments and,
admittedly, may not be a requirement at all in some organizations, subject
to complete risk analysis.

I think we should leave all options open, but I would not want to bias the
technical protocol in favor of a questionable security practice.  Therefore,
if we were to do anything, I would prefer Stefan's extension with an
enumeration rather than just a Boolean.

Warwick

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Wednesday, November 25, 1998 3:11 PM
To: 'Warwick Ford'
Cc: [email-masked]'
Subject: RE: generation of private keys

Hi Warwick,

:Having the key pair

Carlisle.

---

From: Warwick Ford <[email-masked]>
Date: Sun, 29 Nov 1998 00:42:49 -0800

Carlisle:

Thanks for pointing this out. When the book is revised, I'll ensure that
that passage is reworded to address the other options that are now apparent.

Warwick

-----Original Message-----
From: Carlisle Adams [mailto:[email-masked]]
Sent: Friday, November 27, 1998 9:46 AM
To: 'Warwick Ford'
Cc: [email-masked]'
Subject: RE: generation of private keys

Hi Warwick,

A couple of quotes (from W. Ford, "Computer Communications Security:
Principles, Standard Protocols and Techniques", pp.97-98):

"To minimize vulnerabilities, the key generation process is best carried out
either within the owner system or within the certification authority system,
thereby necessitating only one protected key transfer."

"If keys are generated with the certification authority system, transfer of
the private key to the owner system will require both integrity and
confidentiality protection.  In either case, if key archiving is required,
reliable copies of both keys will need to be sent to an archiving system
(which may be co-located with the certification authority system)..."

Not a word about "highly undesirable", "questionable security practice", or
"might be O.K., subject to complete risk analysis".  What could have
happened in the past couple of years to cause you to alter your view so
radically?

In any case, we are in full agreement that all options should be left open
(in order to suit the needs of all environments).  I'm not sure what
"technical protocol" you're referring to below, since Stefan's suggestion
was simply to add an extension to a Certificate, but an enumeration rather
than a Boolean is perfectly fine with me.

Carlisle.

-----Original Message-----
From: Warwick Ford [mailto:[email-masked]]
Sent: Friday, November 27, 1998 9:29 AM
To: 'Carlisle Adams'
Cc: [email-masked]'
Subject: RE: generation of private keys

Hi, Carlisle: