[194] in WWW Security List Archive
Re: what are realistic threats?
daemon@ATHENA.MIT.EDU (Robert M. Polansky)
Thu Oct 6 16:35:44 1994
Date: Thu, 6 Oct 94 08:34:34 EDT
From: polansky@chaplin.ndhm.gtegsc.com (Robert M. Polansky)
To: rosenthl@mcc.com
Cc: www-security@ns1.rutgers.edu
Reply-To: polansky@chaplin.ndhm.gtegsc.com (Robert M. Polansky)
> From www-security-owner@ns1.rutgers.edu Wed Oct 5 22:43:38 1994
> Date: Wed, 5 Oct 94 14:47:11 CDT
> From: rosenthl@mcc.com (Doug Rosenthal)
> To: smart@mel.dit.csiro.au
> Cc: www-security@ns1.rutgers.edu
> Subject: what are realistic threats?
> Sender: owner-www-security@ns1.Rutgers.EDU
> Reply-To: rosenthl@mcc.com (Doug Rosenthal)
> Content-Length: 3150
>
>
> Thanks for the reply. Let's continue the discussion further ...
>
> A certificate asserts a property of a public key and is signed by
> other public keys. A lot of different things get lumped into
> revocation:
> ...
>
> Do you not think that key pairs might be "routinely" regenerated, just
> like a user password should be changed periodically? I.e., you may
> not know that your private key has been compromised; perhaps it was
> just copied from your local disk, etc. This seems true especially
> since digital signatures will be a primary application of public key
> mechanisms, with a fair amount of trust associated with those signatures.
>
It is expected that key pairs will have an expiration date, but the
period between regeneration of keys might be a year or longer. The
reason is that this is different from your password which only
authenticates you to a system that can keep up with password changes.
You key pairs are used for digital signatures. If you change your key
pairs (and thus your certificate) too often (without reason),
reverification of old transactions and messages become impossible. Once
you change key pairs, all of your old signatures will become invalid
because your old keys will now be on the Key Revocation List.
>
> I agree that there are some applications where an on-line check of
> the status of a key might be needed. But certainly not for the small
> amounts of money that will be needed for purchasing most information
> through the WWW. On the other hand if you are buying something physical
> which has to be physically delivered then an on-line check is again
> not needed, as long as the check is made sometime before final delivery.
>
> Hmmm ... it seems that even for small purchases, the service provider
> would want some reasonable assurance that the user's claimed ID is
> indeed authentic, at least for certain payment mechanisms (electronic
> check, credit card, etc.). An analogy would be having to show a
> picture ID (e.g. a drivers license) when writing a check or using your
> credit card at a store. Given the "faceless" nature of the network,
> a user's digital signature and corresponding certificate (signed by a
> certification authority) would be akin to their hand written signature
> and photo ID (with signature).
>
I think the point is that the service provider will verify the
signature on the buyers certificate and the signature on the
transaction message, but the keys used will only be checked against a
locally cached Revocation List. For a small transaction, it is not
necessary to check the keys against *the* most up to date list; a list
that is a couple hours old might be good enough. So the user is not
authenticated, but there is a chance that the keys are revoked and the
announcement just hasn't reached the provider yet.
So... the service provider has a reasonable assurance of the user's ID
due to verifying the signature on the user's certificate, it just isn't
guaranteed until he makes an on-line check.
-Rob Polansky
