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

From: Ambarish Malpani <[email-masked]>
Date: Tue, 18 Jul 2000 09:18:54 -0700

Hi Rich,
    Let me try and provide part of the justification:

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

Identrus is trying to provide an infrastructure that will be
used across a whole slew of products - e-mail, web, databases,
etc. Sure, they could come up with their own "standards" for
how validation would be done. Then, they would have to convince
all relevant vendors to implement that standard. Tomorrow, if there
is another similar body that comes up with their own "standard",
they will need to do the same thing and software vendors will
end up choosing which of the n different standards they should
follow.

The whole point of trying to use work that comes out of the IETF
is that you avoid this segmentation of how different groups
choose to do the same thing.

> 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.
>

[My personal opinions here]: Identrus members are banks. These
banks will want to issue certs to their members that are useful
in both Identrus and non-Identrus environments. I would fully
expect, over time, that banks will use the same CA for both
purposes and have the CA certified by both Identrus and
non-Identrus roots. As long as they follow the Identrus rules,
it is unclear to me that Identrus would object to their doing so.
Some certs might also be issued with policies that map adequately
to Identrus policies.
So, over time, I would fully expect Identrus path processing to
become pretty complicated.

Thirdly: Identrus has a set of rules and types of certificates it
issues today. Again, I would expect these rules to evolve over
time with new and different types of certificates, issued for
different applications, under different policies. It would be
pretty hard to imagine client applications that were smart
enough to understand these new certificates types, when they
haven't even been defined today. By having a merchant application
just ask the bank whether a certificate can be used for a particular
purpose, you significantly reduce the deployment problems
somebody like Identrus will have with new certificate types and
different policy rules.

Hope this helps clarify the need for remote path processing and
SCVP.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 17, 2000 7:16 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Need for an XML based cert check protocol with RPP
> capability .
> 
> 
> >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.
> 
> 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$
>

---

From: Rich Salz <[email-masked]>
Date: Tue, 18 Jul 2000 12:32:53 -0400

If the protocol says "you can ask this server" then code must be written
to put "this server" into the request packet. If the rules say "ask the
bank" then you must open your connect to "the bank."  Either way, there
is no savings.  Please post a worked example.

> By having a merchant application

Exactly.  Just ask the bank.

It's a business/programming rule, not a protocol issue.
	/r$