Re: Help! I'm trying to understand PKI - especially CA's role
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 10/08/04
- Next message: F. Sun: "DoS Attack"
- Previous message: Wimbo: "Re: Help! I'm trying to understand PKI - especially CA's role"
- In reply to: Wimbo: "Re: Help! I'm trying to understand PKI - especially CA's role"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 08 Oct 2004 11:12:40 -0600
Wimbo <wimbo_online@_REMOVETHIS_hotmail.com> writes:
> The CA verifies the credentials and signs the public key with the
> private key of the CA and sends it back to Alice. (The verification
> credentials depend on the requested certificate class. Class 1
> certificates are only validated by e.g. a valid credit card
> number. The higher the class, the more personal it gets. With a
> class 3 certificate the CA knows for sure that you are the person
> you say you are.)
certificates were originally targeted at the offline email scenario
from the early '80s to handle a situation where a recipient was
receiving email from somebody which they had no prior contact and/or
knowledge. the scenario was that the recipient dialed their local
"post office", downloaded email, hung-up, and then needed to
authenticate email from total strangers w/o resorting to any
additional operations.
the typical business scenario has been that parties establish some
prior interaction and maintain local information about their
interacting parties. this information ... including possibly a public
key is stored and managed by the recipient (aka the PGP model). this
has been expanded with the pervasive spread of online infrastructure
so that a recipient can either have access to the information (about
the sender) locally or remotely.
in the (offline) certificate model ... the local recipient's
authentication table instead of having information about the sender
(and their public key), it contains information (and public key) about
a certification authority.
the sender of the offline communication packages the message, their
digital signature and a certificate issued by a certification
authority ... containing various information about the sender
(including the public key) and sends it off. the recipient then uses
their authentication table to validate the certificate (i.e. the
certification authority's public key) ... and then they use the
information contained in the certificate (supplied by the
certification authority) about the sender to validate the actual
message (in lieu of having their own information about the sender).
in the early 90s, you found x.509 identity certificates that were
starting to have more and more information about the sender. in the
mid-90s, there was starting to be some realization that spraying
identity certificates all of the world with lots of personal
information could represent signfiicant liability and privacy issues.
this somewhat gave rise to relying-party-only certificates
... containing nothing more than possibly a sender's account number of
some sort (like a payment card number) and the sender's public key.
1) the relying party registers the senders/applicants information and
public key
2) the relying party creates a relying-party-only certificate
containing an account number and a public key and sends a copy to the
applicant.
3) for some subsequent operation, the application creates a message,
digitally signs it, and packages the message, the digital signature
and the certificate and transmits it to the relying party.
4) the relying party receives the message, extracts the account number
from the account record, retrieves the sender's public key from the
account record, uses the public key to validate the sender's digial
signature and accepts the message
the above four steps are typical online business operation using
relying-party-only certificates that were appearing in the mid-90s.
however, it is trivial to see from step 4, that the relying-party-only
certificates in online operations are redundant and superfluous since
the relying party needs to never reference the certificate.
the other thing of note from various of the mid-90s operations
involving financial transactions and relying-party-only certificates
was that the typical payment card transaction is on the order of 60-80
bytes and the relying-party-only certificates could be on the order of
4k to 12k bytes.
the issue was that the recipient/relying-party had the original of all
the information that might be contained in a relying-party-only
certificate (or otherwise had access to it using an online
environment). the sender might possibly generate hundreds of financial
transactions, appending the redundant and superfluous
relying-party-only certificate to each one and send it on its way to
the relying-party (which has the original and superset of all possible
information contained in the certificate). Since the
relying-party-only certificate is otherwise redundant and superfluous,
the possible remaining purpose for having a relying-party-only
certificate is to cause enormous payload bloat (by a factor of 100
hundred times) in the transaction traffic.
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
- Next message: F. Sun: "DoS Attack"
- Previous message: Wimbo: "Re: Help! I'm trying to understand PKI - especially CA's role"
- In reply to: Wimbo: "Re: Help! I'm trying to understand PKI - especially CA's role"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
