Subject: Need for an XML based cert check protocol with RPP capability.

From: Khaja Ahmed <[email-masked]>
Date: Mon, 17 Jul 2000 00:29:43 -0400

There are many applications being built under the Identrus trust model,
which collectively will provide a global framework for e-commerce.  Identrus
has demonstrated that OCSP is a widely deployable standard that is not
limited by specific application context or PKI implementation. The
availability of OCSP from the IETF has been a key factor toward the
interoperability goal.

As a result of our work deploying OCSP and developing a global e-commerce
framework that uses it, we see the need for some enhancements in protocols
for certificate validation. 

The qualities we will need in a protocol for certificate checking in
applications now being developed include, along with some background, the
following:

1.) Remote Path Processing:  In this model, the relying party (corporation
or individual) has a relationship of trust with their banks. When there is a
business decision to be made regarding trust in an on-line transaction,
including certificate status, certificate path validation, and policy
application, the customer must be able to rely on a simple response from
their bank.  Hence we would like the protocol to support path validation by
the responder (Bank).

2.) XML encoding:  The applications being developed and deployed use XML to
encode messages.  Given this, we would like to have a protocol that uses XML
to encode the request.

3.) XML signatures: Identrus requires that all certificate checking requests
be signed.  We would like to use XML signatures for such requests.

4.) The Identrus model, shown at <http://www.identrus.com/solution.htm>, is
based on the standard banking four-corner model.  Hence a relying party will
always go to his bank to validate a certificate even if the certificate was
actually issued by some other bank.   The protocol must support this.

5.) The protocol must support use of cached responses.  As a corollary, it
must permit the relying party to request a freshly generated response rather
than one from it's cache.

6.) The protocol must permit checking of status on expired certificates.

Identrus has a task force that is examining a couple of protocols to see if
these capabilities.  One is a proprietary protocol and the other is SCVP.
For numerous and obvious (at least to this group) reasons we would prefer to
use SCVP rather than anything proprietary.  

Does SCVP meet the above needs?  Is it a matter of enhancing / modifying it
to some degree to bring it in line with these needs?  My limited
understanding of these things suggests that SCVP is not an unreasonable
candidate.  Is there something else that, more fully, meets the above
requirements?  Are there other issues we should be considering?  

A discussion on this subject will be of great help in developing and / or
selecting a suitable protocol.  If the tremendous brainpower of this group
could be brought to bear on this subject, it will undoubtedly yield the
necessary results.

Do let me know or contact me for further information / clarifications.
Thanks and Regards. 
Khaja 
=========================================== 
Khaja E. Ahmed 
Chief Technology Officer 
Identrus, LLC. 
16th Floor 
140 E 45th St. 
New York, NY 10017 USA 
Telephone: 01.212.622.0673 
Fax: 01.212.622.9196 
[email-masked] 
Office Direct: 01.925.989.6564 
Office Main: 01.212.622.1524 
============================================

---

From: Rich Salz <[email-masked]>
Date: Mon, 17 Jul 2000 10:01:17 -0400

I don't understand why RPP is necessary in the Identrus model.
You only need to set up peering relationships among banks, as long as
each cert has a service locator of some type.

	/r$