[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Too many options
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.
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
> 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
> 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."