Re: Too many options

[John Horton <jehorton@xxxxxxxxx>]

I guess now that Bob has written a response, I would like to throw in my
$.02 to this discussion.  

IMHO the difference between these 2 scenarios can be explained in one
word - TRUST.  Not that these 2 systems can't be trusted, but the
perception of trust by the those that must buy into a system - the end
users and owners of these types of systems.  Any system that is to be
used widely and effectively must be able to be trusted beyond a shadow
of a doubt by everyone.  

Scenario A provides Alice an opportunity to actively participate,
therefore allowing buy-in and building the trust factor.  

Scenario B removes Bob from any involvement, thereby creating doubt and
the possibility of misperceptions about the trustworthiness and
integrity of the system.

Regards,
John Horton
===============================================================================

Arsenault, Al W. wrote:
> 
> Okay, I'll bite.
> 
> Bob Juenman wrote:
> 
> >And as I have previously stated, I think
> >that combining centralized key generation with certificate management is a
> >bad idea for several reasons.
> 
> What are those reasons?
> 
> Consider the following scenarios.
> 
>      Suppose that a company is using hardware tokens (e.g., smart cards, PC
> cards, etc.) to provide signature and encryption services for its employees.
>  The architecture of these tokens is such that removing a private key is not
> supported; e.g., there's no way for someone to find out the private key
> without physically attacking the token.
> 
> Scenario A:  A new employee, Alice, gets a new, uninitialized token from the
> supply system.  Alice commands the token to generate signature and
> encryption key pairs.  She takes the public keys off the token, puts them in
> certificate request messages, and sends them to the company CA.  The CA will
> put the public keys in certificates, sign the certificates, and send them
> back to Alice.  Alice will load the certificates onto her token, and start
> working.
> 
> Scenario B:  A new employee, Bob, sends a request to the CA for certificates
> AND KEY GENERATION.  The CA gets a new, uninitialized token from the supply
> system.  The CA commands the token to generate signature and encryption key
> pairs.  The CA takes the public keys off the token, puts them in
> certificates, signs the certificates, and then loads the signed certificates
> onto the token.  The CA then distributes the token to Bob.
> 
> Question 1:  from a security standpoint, why is Scenario B worse than
> Scenario A?  Why does B facilitate key recovery, allow the private signature
> key to be surreptitiously duplicated, etc. any more than A?  To me, they are
> approximately equal.  Yes, there are logistical reasons why an organization
> might choose A over B, or vice versa, such as controlling the stock of cards
> (they cost money), preventing the CA from learning the PIN of the token,
> etc., but they can all be dealt with.
> 
> Question 2:  if A and B provide approximately equal levels of protection for
> the cryptographic keys, should not both be supported in PKIX?  I agree with
> Steve Kent in that we should discuss whether support for A should be
> mandatory or optional, and whether support for B should be mandatory or
> optional.
> 
>  I don't think that support for B should be eliminated from PKIX because of
> a perception that CA generation of keys is inherently a bad thing, or that
> it facilitates key recovery, to which the IETF is opposed,...
> 
>                     Al Arsenault
> 
> "I speak only for myself.  My opinions do not necessarily represent those of
> my employer."