[no subject]

Within the Banking industry, discussions uniformly have rejected this
idea.  We have learned from long experience - with private networks,
credit cards, funds transfer networks, and others - that the best
way to manage the risk of a transaction, a connection, or a communication
is to have on-line status checking.  This is also true with
the checking of the status of digital certificates.

The volume questions are interesting.  Bank of America processes about
10% of the US paper checks every night -- over 22,000,000 pieces of paper
at high water mark.  I think we can handle some multi-million certificate
status requests.

But we do not do things for free or manage risk of communication without
authentication.  Therefore the on-line status check is for our customers.

The NACHA Internet Council pilot of CA interoperability will demonstrate
how Banks will trust each others certificates.

We are using CRLs between banks--and I think CRLs have a place in high
volume relationships between organizations. This risk of outdated CRLs
can be managed by agreement and rules that NACHA would set.

Tim wrote:

>>1. Approximately how many OCSP responders are required to serve a
>>community of one billion relying parties and subscribers?
>>
I expect that certificate holders would go to their agents.
Therefore, the magnitude of OSCPs will be the magnitude of
agents (essentially CAs or their repositories).

>2. How do the relying parties come to trust the verification keys of the
>>OCSP responders?
>>
By contracted relationship, since they are using the OCSP to THEIR
agent - and the agent now deals with the trust to other repositories.
Admittedly, this does make the same problem at the agent's level,
but this is a less difficult problem since these agents are in this
business.  They will have contracts and associations.

>>3. How do the OCSP responders obtain revocation information from the
>>single CA?
>>
Revocation information will be by OCSP at low volumes from agent to
agent.  High volume agents will contract on risk distribution and
may use CRL mechanisms.

I do not know of a CA will offer its CRLs to all comers without
authentication. (Talk about denial of service opportunities.)

>>4. How current will the revocation information be when it is presented
>>to the relying parties?
>>
If it is OCSP, it will be as current as represented by the agency.
Between agencies, association rules and contracts will provide
this assurance.


For all the talk of CRLs, I would like to point out that CRLs
make really good sense in a military application where the
commanding officer (relying party) needs to make a decision
based on available information (certificate, roots, last CRL).
In a commercial context, we have left this model of behavior
behind with the advent of telephony.



Therefore, I state my earlier discussion: