Re: generation of private keys

["Tammy Carter" <TCARTER@xxxxxxxxxx>]

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 (bjueneman@novell.com) 
directly.


Tammy Green Carter
tcarter@novell.com


>>> Juergen Walter <walter@deh.de> 12-4-98 7:27:25 AM >>>

Hallo Stephan,

comments in line,
Stefan Kelm wrote:
> 
> Hallo Juergen,
> 
> > 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.
> 
> 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]

> > 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?
> 
> 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]
 
> 
> > 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.
> 
> Agreed.
> 
> > [...]
> > Finally, I do not see that the German digital signature law implies the
> > usage of a key generation extension. [...]
> 
> Indeed it doesn't.
> 
> Cheers,
> 
>         Stefan.
> 
> ______________________________________________________________________________
> Stefan Kelm            PGP key: "finger kelm@www.pca.dfn.de" or via key server
> DFN-PCA, University of Hamburg                               <kelm@pca.dfn.de>
> Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/ 
> 22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

-- 

Juergen