RE: CA enforcement of centralized key generation?

[Trevor Freeman <trevorf@xxxxxxxxxxxxx>]

Hi Bob,
I am NOT advocating that with the key generation function being split
from the CA, it is mandatory for a CA to enforce the fact that central
key generation has occurred. I can see that my original email can be
interpreted that way, but that was not my intent, so let me try and
clarify things. 
The CA is a policy animal. Its policy may want it to find out more about
the keys following a certificate request. When it generates
certificates, this generation occurs under the policy of the CA
operator. In this new world where key management is separate from
certificate management, we are in agreement that by default, the CA will
not know from the certificate request where the keys were generated, and
in many environments that's fine. The CA MAY operate a policy where its
wants to find out more about the keys, like where the keys generated by
key management system? where they generated with a good random seed? are
they backed up \ escrowed?. It's policy may or may not choose to issue
the certificate based on information it finds out about the keys. Its
policy may or may not add policy OIDs to the certificate, reflecting
information it finds out about the keys. As all these considerations are
all policy based, then they should form no part of a mandatory protocol
profile.

Hope this clears things up.
Trevor

> -----Original Message-----
> From:	Bob Jueneman [SMTP:BJUENEMAN@novell.com]
> Sent:	Thursday, September 04, 1997 3:50 PM
> To:	Trevor Freeman; ietf-pkix@tandem.com
> Subject:	CA enforcement of centralized key generation?
> 
> Trevor,
> 
> >Separating key generation and key management from certificate
> management
> >seems the best solution all round. How keys are generated and managed
> is
> >an implementation issue which has lots of technical/political/legal
> >baggage which will vary by implementation, by country and by  lots of
> >other things. The CA can now get on with its job of managing
> >certificates without being tainted by these other considerations. 
> 
> We're certainly in agreement here.
> 
> >If
> >someone wants to implement a central key generation scheme, then the
> CA
> >will just have to check with the key management system before it
> issues
> >the certificate. This may mean that some key management to CA
> management
> >messages are required. This can be accommodated by existing pkix3
> >messages as the key management system only has to do a proof of
> >possession for the CA.
> >Trevor
> >.
> 
> You seem to be bringing up a point I hadn't thought of. You seem to be
> suggesting that there may be a requirement within some organizations
> to
> PREVENT the use of other than centralized key generation, and more
> importantly, that the CA should play a role in enforcing such a
> restriction.
> 
> I had envisioned a system where the user/client would send off a
> request for
> key generation to some designated server, and would receive a reply
> consisting of the private key plus the public key.  Depending on the
> environment, it may be necessary for the key generation facility to
> digitally sign the public key (or at least a separate message digest
> of it)
> in order to establish its "political correctness".  But I had assumed
> that
> it would be sufficient to merely extract the public key and include it
> in
> the prototype certificate to be sent to the CA.  The CA would require
> proof
> of possession of the private key, of course, but in my original
> thinking the
> certificate request would have been indistinguishable from one where
> the
> keys were generated locally.
> 
> I really don't want to start down the slippery slope of having the CA
> refuse
> to issue a certificate unless a government-approved key recovery
> center has
> generated or otherwise approved a public/private key, but I am willing
> to
> discuss whether corporations might have a legitimate need to ensure
> that
> keys were generated using their central system prior to that corporate
> CA
> issuing the individual a certificate.
> 
> Could you say a little more about what you think the requirement is,
> before
> we 
> jumping into discussing potential mechanisms?
> 
> Bob
> 
> Robert R. Jueneman
> Security Architect
> Novell, Inc.
> Network Services Division
> 122 East 1700 South
> Provo, UT 84604
> 801/861-7387
> bjueneman@novell.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>