Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

From: [email-masked]
Date: Thu, 5 Nov 1998 09:55:00 -0800

in order to  complete a transaction/operation ... if a account record has
to be accessed at all (because of real-time, privacy or other reasons),
then seperating attributes into those in a certificate and those in the
account record can, at best, represent superfulous effort and significant
increase in complexity .... and at worst increase various kinds of risk and
significantly lower availability of the infrastructure.

there is nothing implicit about partitioning the attributes needed to
complete a transaction/operation into several places ... however, each such
partitioning typically significantly increases complexity and risk while
lowering availability. Reasons for partitioning can include requirements
for account-based operations because of things like real-time attributes
and/or sensitivity/privacy issues associated with attributes.

the simplest example is an existing online, account-based, electronic
authorization environment (say like an ISP RADIUS environment that uses
passwords for authentication).  Contrast in terms of risk, failure modes,
complexity two implementation modes:

1) registering a public key in a RADIUS account record in lieu of a
password, modifying the RADIUS serrver to do digital signature
authentication with the registered public key, and modifying the RADIUS
client to accept a digital signature (in lieu of a password).

2) create a CA, create a CA database, create a CA customer call center
and/or tieing an existing customer call center into the CA database,
getting a signed CA certificate, registering public keys at the CA, issuing
certificates, modifying RADIUS client to accept certificate and digital
signature, modifying RADIUS server to verify certificate and authenticate
CA digital signature on the certificate, checking for a CRL entry for the
certificate, retrieving the CA's digital certificate, verifying the CA's
digital certificate and the digital signature on the CA's digital
signature, checking for a CRL entry for the CA's digital signature (etc ...
possibly on up to the root-CA tree) and finally accessing the RADIUS
account record.

First off, the transaction in neither mode will complete if the RADIUS
server and RADIUS account record is unavailable. However, in addition, the
second mode won't complete if none of the remaining PKI infrastructure is
unavailable (and/or if it chooses to continue in spite of it being
unavailble opens up fraud and risk potential completing the operation w/o
completing the authentication process).

At NISS conference last month a financial institution talked about
migration to relying party certificates because of privacy and liability
issues .... i.e. a certificate containing only the account number and
public key. In this scenerio, the certificate is stored in the account
record when the public key is registered and a copy returned to the owner.
This about reduces privacy, liability, complexity, risk, availability and
fraud exposures to a minimum (associated with using both a certificate and
an account record). At this point, the question becomes why does the owner
have to send a digital signature and the certificate to the institution on
every operation .... if the institution already has the original of the
certificate. The downside risk is that the certificate signing key at least
becomes a point of attack ... unless the institution totally ignores the
sent certificate and alwas relies on the original in the account  for
verifying the account owners digital signature ... in which case sending
the certificate even becomes more superfulous.

---

From: Jun Yoshitake <[email-masked]>
Date: Fri, 06 Nov 1998 23:09:25 +0900

I am beginning to be afraid we have been thinking
of a differnet situation or application ...
But, anyway, my comments are in line.

> client to accept a digital signature (in lieu of a password).

I think you don't necessarily have to register the public key
in your record.
A client can send all the certificates that are needed to
validate the client's certificte.
(I don't know RADIUS, so I am explaining in a general
 PKI case.)

> completing the authentication process).

If you are saying, for example, what if no directory servers can be
available to get necessary CRLs, I admit this is a big point.
And this issue - how revocation information is surely provided -
has been one of big points in this mailing list, I think.
I think in a real system a high availability server (for example,
a dual server system) is used for a directory server (if you use
a directory server as a revocation information provider).

> certificate.

Again, you don't necessarily have to store a client's certificate.
And I think it depends on an application or a protocol whether
a client has to send its digital signature and its certificate
every time it sends a message to the server.
(SET Protocol might be of some help in this point.)

> The downside risk is that the certificate signing key at least
> becomes a point of attack ...

If you mean "the certificate signing key" is the CA key
which signs a client's certificate, I think the real world CAs
(especially for financial applications) protect thier facilities
including their private keys and  in highly secure and strict
manners.

Regards,

Jun Yoshitake

Mitsubishi Electric Corp.