Subject: Re: generation of private keys

From: Stefan Kelm <[email-masked]>
Date: Tue, 1 Dec 1998 15:59:37 +0100 (MET)

Dan,

> whether this set of keys was gen'd by XYZ?  Of course,
> whether gen'd on the up-and-up or not, incompetently
> escrowed trumps competently gen'd any day.

sorry, but I don't get this last sentence...

> Bottom line:
> one bit answer to _CA_takes_responsibility_for_key_gen?_

So we're back to a boolean extension again?

Warwick and Carlisle: could you please elaborate on why you'd prefer an
enumeration rather than a boolean?

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: Tue, 1 Dec 1998 14:35:07 -0500

Hi Stefan,

> -----Original Message-----
> From: Stefan Kelm [mailto:[email-masked]]
> Sent: Tuesday, December 01, 1998 10:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: generation of private keys
> 
> Dan,
> 

All he's saying is that it may not matter who generated the key pair
(regardless of how wonderfully competent they were).  If the escrowing is
done in an incompetent way, then it's all pointless.

> enumeration rather than a boolean?

I did not say that I would prefer an enumeration; I said that an enumeration
would be perfectly fine with me (i.e., if that's what people want then I
won't object).  My concern was that the CA may not be able to determine who
generated the key pair in such an air-tight way as to be able to state this
authoritatively in a certificate and stand behind it in a legal sense.
Warwick suggested that the CA may be able to do this based upon its trust
relationships with other entities and upon secure communications paths
between itself and those entities.  Fair enough (I am not a lawyer, so I
won't hazard a guess on this).

A Boolean is certainly simpler (and presumably a CA can say with confidence
whether or not it generated the key pair itself).  However, an enumerated
provides more information (which may, in fact, be needed for the German
digital signature law) and so may be more useful.  I could live with either.

Carlisle.

---

From: Juergen Walter <[email-masked]>
Date: Wed, 02 Dec 1998 19:00:05 +0100

Hi all,

I would like to add few comments to the key generation extension. It was
suggested to give the relying party a hint at the assurance level of the
certificate adding a key generation extension to the profile in [PKIX
CERT].

The suggested key generation extension represents only one aspect of
certification policy. It SHOULD be stated in the CPS of the issuing CA.
There are two extensions refer to the underlying policy in the
certificate, the CPS pointer and User Notice qualifiers.

The relevant text taken from[PKIX CERT] and [PKIX CPS] follows at the
end of the message.

The disadvantage of these extensions I see is that they are not
customizable for automatic processing. Even the reading and
understanding of CPS may be difficult. Supposed if there any need for a
key generation extension for some communities nowadays; next year there
may be some need for another extension refering to other elements of CPS
in a formal and automatically customizable representation.

Is this the way we want to go?

Surely, I can live with a key generation extension as a boolean or
whatever. But I can not recommend use of this extension in such a way
that the relying party only sticks on this to decide whether accept a
certificate or not under certain circumstances. A look on the whole CPS
is strongly recommended.

I agree the bare location of key generation is worthless. At least there
are two features of key generation influencing the assurance level of a
certificate:

Who takes control over the key generation process?

Which cryptogaphic module is used for key generation? (alternatively:
approved classification scheme)

(For a comprehensive essay see [PKIX CPS] framework.) If I want to get a
answer to these questions I have a look at the CPS published by the
issuing CA. Now trust is focused on trust in the CA. This is fine
because it is the underlying canonical trust model of any public key
infrastructure, there must be a trust in at least one root CA. Hence the
issuer field of a certificate is the clue the relying party should use
to decide wether accept the certificate or not. Using a table to bind
the issuer to a boolean (or more complicated logic stuff if appropriate)
the relying party may control automatically the acceptance decision of a
certificate. Such a table must be generated under the control of the
relying party. The generation itself may be delegated to a trusted third
party.

Under the risk stating the evident, a key generated by FIPS level 4
cryptographic module under control of criminals provides no assurance to
the relying party; and vice versa, a key generated by a not trustworthy
cryptographic module under control of a notary provides no assurance
too. There are many other configurations showing that only the whole CPS
guarantees a dedicated level of assurance to the relying party, supposed
he/she/it trusts the top level CA designated in this CPS.

There exists a common method for formalization of CPS. Some CA provider
has been transformed varying features of certification policy to
assurance levels. This gives guidance for relying parties and applicants
for certification as well. Every assurance level is a representant for a
set of designated policy features. The CA signs the certificats
according to distinguished assurance levels with different CA`s private
key.

As a result, I see five alternatives for stating CPS features in the
certificate:

(1) definition of separate extensions for needed CPS features (like key
generation extension)

(2) pointer to CA`s CPS [PKIX CERT]

(3) definition of an assurance level extension 

(4) formalization of the CPS as a whole (definition of the features of
CPS and a range of variety for each feature, if appropriate)

(5) utilizing the User Notice [PKIX CERT]

Finally, I do not see that the German digital signature law implies the
usage of a key generation extension. In general, key generation appears
at the CA in this setting. The reason is twofold. Firstly, there are
cost-intensive requirements to the key generation module, and secondly,
the CA must guarantee the signing key has been generated by such
equipment. One solution is the certification of the key generation
device. The CA must validate this certificate before processing the end
entity`s certificate. Should the end entity`s certificate include an
extension CERTIFICATE_OF_THE_KEY_GENERATION_DEVICE? More generally,
should all aspects which should be covered by CPS, but actually, they
are not there for some reason (probably there is not any identified CPS)
go the way to become a certificate extension? See above.

Juergen

[PKIX CERT] 
This specification defines two policy qualifier types for use by cer-
tificate policy writers and certificate issuers. The qualifier types
are the CPS Pointer and User Notice qualifiers. [PKIX CERT]

[PKIX CPS]
4.6.1  Key Pair Generation and Installation

         Key  pair generation and installation need to be considered for
         the issuing CA, repositories, subject CAs, RAs, and subject end
         entities.   For  each of these types of entities, the following
         questions potentially need to be answered:

            1. Who generates the entity public, private key pair?

            2. How is the private key provided securely to the entity?

            3. How is the entity's public key provided securely  to  the
            certificate issuer?

            4.  If  the  entity  is a CA (issuing or subject) how is the
            entity's public key provided securely to the users?

            5. What are the key sizes?

            6. Who generates the public key parameters?

            7. Is the quality  of  the  parameters  checked  during  key
            generation?

            8.  Is the key generation performed in hardware or software?

            9. For what purposes may  the  key  be  used,  or  for  what
            purposes  should  usage  of the key be restricted (for X.509
            certificates, these purposes should map  to  the  key  usage
            flags in the Version 3, X.509 certificates)?
[PKIX CPS]

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  PoP Leipzig/Halle/Jena
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: [email-masked]            Fax:  +49 3461 415072
--------------------------------------------------------------------

---

From: Stefan Kelm <[email-masked]>
Date: Thu, 3 Dec 1998 13:24:17 +0100 (MET)

Hi Carlisle,

> done in an incompetent way, then it's all pointless.

It certainly is. That's why I thought an indicator for the key generation
location would be a good thing. Someone might not want to use another
end entity's certificate because the corresponding private key was
generated by a CA and therefore might be escrowed somewhere (of course, the
contrary scenario might happen as well).

Anyway. Thanks for the clarification.  :-)

> authoritatively in a certificate and stand behind it in a legal sense.

I would tend to agree. That's why I suggested a boolean in the first
place. An enumeration sounds much mure useful though.

Putting on a "legal hat" on the other hand (I'm not a lawyer either), things
could become even more difficult because one might argue about how to
define the term "CA", i.e. is the key generation unit part of the CA or
is it part of a separate organizational unit in a legal sense?

> digital signature law) and so may be more useful.  I could live with either.

The German law explicitly allows for the keys to be generated by either the
user or the CA although key generation by the user is unlikely to happen
due to the requirements (see Juergen's mail). My motivation for suggesting
an extension was the standpoint of an end entity, the law does not
require such information.

Cheers,

        Stefan.

---

From: "Tammy Carter" <[email-masked]>
Date: Fri, 04 Dec 1998 11:16:33 -0700

Juergen,

I think you are hitting at something here that we at Novell (specifically Bob Jueneman)
have also been concerned about.  Namely:  The location of key generation
does not matter nearly as much as the cryptographic properties of the machine
the key was generated on, and, thereafter, how the private key will be stored.
Thus, a single boolean or even an enumeration doesn't seem to be enough.
Nor would a CA's policy be enough, since the CA can say nothing about
how the private key is stored by the end entity.

Bob Jueneman has architected an extension which Novell is including in our 
root level CA certificates as well as in the certificates which our customers 
can generate using our PKI offering.  A document describing the extension can 
be found on our web site at: 
   http://developer.novell.com/repository/attributes/certattrs_v10.htm
Comments and criticisms can be directed to me or to Bob ([email-masked]) 
directly.

Tammy Green Carter
[email-masked]

>>> Juergen Walter <[email-masked]> 12-4-98 7:27:25 AM >>>

Hallo Stephan,

comments in line,
Stefan Kelm wrote:
> Hallo Juergen,
> I absolutely agree. Still, some CAs might not state anything about the
> key generation location in their policy (or CPS, respectively), or the
> policy allows the keys to be generated at either side (e.g. the German
> digital signature law where CAs probably won't have their own policy).

[Juergen] This is a prudent practice that CAs have their own policies.
Even if the CA does not publish its policy there is still a policy
behind the scene. The relying party either trusts in a CA or not at a
certain level of assurance. [Juergen]
> 
> Why not consider the suggested extension as an additional mechanism?
> As I said in my first mail I don't think this is a pure policy issue.
>
[Juergen] I tend to disagree. I would not hilighten the location of key
generation feature. Every further extension will lead to long vehicle
certificates. I do not see that it is an additional mechanism. The
authentication of the cryptograhic module generating the key and the
identification of the individual who takes control over this process
would be a better extension providing there is any need for this.
[Juergen]

> I don't think that this is the point.

[Juergen] I agree. But I think that your suggestion is the first step
into this direction.

> I can follow your arguments but I
> do think that there are certain issues (like the key generation location)
> that may be considered important enough to specify a dedicated extension
> or some other means. Personally, I think that the key generation location
> is one of the crucial points of every PKI, hence my suggestion.

[Juergen] I disagree. Even if the key is generated by the CA there might
be many snares during the life-time of end entity`s private key. If the
end entity uses a insecure cryptographic module for storing his private
key, it does not matter that the CA properly generates the key. The key
management that you probably have in mind is this, that the CA
distributes a smart card including a key generated by the CA. Does your
`location_of_key_generation = CA` then imply this? In this case I think
that the serial number of the smart card is a good candidate for the
extension. If I remember right, this extension is suggested in the
Interoperability Guide Draft published by the Bundesamt fuer Sicherheit
in der Informationstechnik (BSI Germany), but I am not sure.

The longer I am thinking about the location_of_key_generation extension
the more I am worry about it. 
Can you point out to me what your CA guarantees if the
`location_of_key_generation = CA` is included in the issued certificate?
[Juergen]
 
> Agreed.
> > [...]
> > usage of a key generation extension. [...]
> 
> Indeed it doesn't.
> 
> Cheers,
> 
>         Stefan.
> 

-- 

Juergen

---

From: Stefan Kelm <[email-masked]>
Date: Tue, 8 Dec 1998 19:22:29 +0100 (MET)

> After all this discussion of whether it would be possible to cope with
> a CA that doesn't do POP, it still isn't clear to me why that would be
> a USEFUL option.
>
> If it adds no value, don't do it.  Especially since it introduces a
> security hazard.
>
> Could you give an example where having a non-POP CA is a thing of
> significant value?

Well, it seems that we're drifting away from my initial suggestion. I
conclude that there's no general interest in adding an extension, right?

Cheers,

        Stefan.