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

From: Peter Sylvester <[email-masked]>
Date: Mon, 17 Jul 2000 22:16:41 +0200 (MET DST)

> 
> >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.
> 
> 
> The reasoning behind this is that it makes it:
> 
> 1.) Easier to build relying party applications because you dont burden them
> with RFC.2459 section 6.1 compliant path processing.
> 
> and
> 
> 2.) Allows the banks to provide value add services beyond certificate
> validation.  i.e. validation of the transaction itself.  The thinking is
> that the relying party (in some transactions) the seller doesn't simply want
> to know whether or not the buyer's certificate is good.  He may want to know
> if she is good for money, has the required funds/credit rating etc.
> 

If I look at the models that are visible in the identrus web server:

One type of transactions seems to be something like:

Customer A  creates a 'money transfer statement' and presents it
to merchant B. The statement is 'secured' by the customer in a way
that can be verified by customer A's bank, e.g. by a signature, and
the statement contains sufficient information to allow an identrus
participating bank to find customer A's bank (at least to identrus);

Merchant B presents the statement (the whole one) to its bank Bbank
in order to get an assertion. 

Merchant B asks knows how to extract the identification data from the
statement and asks identrus about where is Abank.

Bbank then asks Abank to validate the statement. 

Abank answers with an assertion. Bbank adds its own signature and
returns assertion to merchant. 

If this is one of the models, then I do not see whether B should
be required to know much more than the ability of validating the
signature of its own banking server, or better, the ability of 
validating the assertion of Bbank.

Peter Sylvester

---

From: Khaja Ahmed <[email-masked]>
Date: Mon, 17 Jul 2000 19:19:08 -0400

Denis,

You certainly have thought through the scenario and are quite right in all
your observations.  Additional infomation below:

-----Original Message-----
From: Denis
>> 2.) Allows the banks to provide value add services beyond
>> certificate validation.  i.e. validation of the transaction
>> itself.  The thinking is that the relying party (in some
>> transactions) the seller doesn't simply want to know whether or
>> not the buyer's certificate is good.  He may want to know if she
>> is good for money, has the required funds/credit rating etc.

> ... but in that case some details of the transaction would need to
>be passed along on that protocol (this is not the case today).
>However, as soon as this is done, there are deep implications.

>Let us take an example: Let us assume that the request is for funds
>up to 100.000 $. Is the bank going to count down a credit line ?

For "transaction validation" as distinct from just certificate validation,
this is precisely the kind of hook(s) into financial systems that would be
needed.  Clearly banks have the ability to provide such services.  This is
really the sort of processing done with credit card and ATM card
transactions.  This is the true value of the Identrus system.

>If no, then 8 relying parties might be fooled because everything was
>nice for 2 such transactions, but not 10.

>If yes, then there is some count down, but then the requesters had
>better to be authenticated otherwise there would be some easy denial
>of service attacks.

Requestors are indeed authenticated.  All requests are to be signed.  We
have adopted xmldsig for such signatures.

>So what are your views on that topic ?

Regards,

Denis

---

From: Khaja Ahmed <[email-masked]>
Date: Mon, 17 Jul 2000 19:42:54 -0400

Regardless of the structure of the PKI, path validation has to be done
somewhere by someone the relying party trusts.  This is normally done by the
relying party itself.  It can however be done by a party the Relying part
trusts - Their bank for example.

The benefit of having path validation done at the bank is to off load the
relying party.  Two substantial and obvious benefits are:

1.) Decrease the computation burden on the relying party application -
possibly a web server.  Of course, one could argue just as easily
"distributed processing" is more efficient but when the dust settled the
decision was in favor of putting the burden on the bank.

2.) It was felt that by taking the burden of PKIX compliant path processing
off the shoulders of those developing applications for relying paries, we
would speed up adoption of the Identrus system.

Khaja

-----Original Message-----
From: Rich Salz
To: Khaja Ahmed
Cc: [email-masked] ' '
Sent: 7/17/00 2:26 PM
Subject: Re: Need for an XML based cert check protocol with RPP capability.

I'm still confused.  Identrus is a closed PKI, each customer speaks only
to its bank and banks speak to each other. There is no
cross-certification.
There is a single root, and a single path from between any two Identrus
participants.  Taking those things together, I still don't see how/why
RPP is necessary.

---

From: [email-masked]
Date: Mon, 17 Jul 2000 22:16:00 -0400

>trusts - Their bank for example.

In the general case, yes.

As I last understood it, the Identrus business rules said that the
relying party always asks its bank.  And all the background processing the
bank did was completely hidden by the bank.  Bank A never exposed
the *presence* of any other bank to its customers.

If your rules say "ask the bank" then there is no need to encode
this in a protocol.  Encode it in your code. :)

Second, Identrus is a closed PKI without cross-certification.
Identrus certs are only to be used among Identrus participants who
agree to follow Identrus rules.  That's a linch-pin for making the
whole risk-management aspect fly.

Have those rules changed?

If not, then I'm still stumped.  Could you provide a worked example?
(This might be falling outside the general interest of the list...)
	/r$