[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-CARM] PKI, CAs, TTPs &c.
A third, equally legitimate operational scenario, especially for businesses
who are using digital signatures for their own purposes, is that the
public/private key pair is generated on a secure server under the control
of the network administrator, perhaps at the same time that the user's
account is created. The certificate may also be created at that time.
The private key can be wrapped (encrypted) so that only the designated user
can access it, which he does by authenticating his access to say the trusted
directory where it is stored. The key is then downloaded over a secure, encrypted
session to the user for use during a limited time period.
This is not fundamentally different than the case where a user uses a smart
card or token which contains pregenerated keys, or keys that are
manufactured on the card. all we are talking about is the security of the
I'm often amused by people who insist on closely controlling their keys,
even during the key generation process, and then perform that process
on a platform with no credible evidence of computer security (but lots of
demonstrated weaknesses), no evidence of cryptographic module
integrity a la FIPS 140-1, no access control mechanisms -- not even at logon,
no trusted path, no audit controls, etc., etc.
But then, I guess I'm easily amused.
> [Massive recipient list deleted, particularly as the cert-talk list
> manager has ruled this topic out of scope.]
>> From: "J. Andres Hall" <email@example.com>
>> Hell will freeze over before I'll use a crypto digital signature
>> system that relies on a third party to generate key pairs, because
>> the whole idea of non-repudiation rests on the concept that the
>> private key is *never* in the hands of anyone *except* its
>> legitimate user, and this certainly includes the key generation
>That is a legitimate belief, but the assertion is false. You may wish
>to handle your keys that way, but "the whole idea of non-repudiation"
>does not depend on everyone else agreeing.
>An equally legitimate operational scenario is that the private key is
>*never* in the hands of the legitimate user. Only a piece of equipment
>which generates the key and squirts it into a token, but never reveals
>it to the equipment operator, would know the key. Once initialized,
>the token would never cough up the key to anyone, so the only way the
>user could share the key is to physically hand over both the token and
>the PIN. One could argue that non-repudiation is stronger with the
>third party key generator than without.