[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Designer Certs




On Wed, 11 Feb 1998, Phillip M. Hallam-Baker wrote:

> >>Another camp says, this is the area where humans have to enter,
> >>where trust is going to be established in long meetings with lots
> >>of lawyers sitting round the table.
> >
> >It seems to me that the two "camps" you describe are really the same
> >people sitting in the same campground.  The only thing the first camp is
> >saying (as far as I can tell) is that once the humans have entered, once
> >the trust has been established in long meetings, there is a need to
> >define a bits-on-the-wire protocol so that the certification can
> >actually take place.
> 
> 
> I don't think that the protocol you describe is necessary. My 
> experience of such negotiation suggests that such negotiations 
> are likely to be long and expensive, even for a simple bilteral
> deal between two CAs. 
> 
> Think about negotiating an EDI exchange agreement as a likely
> cost base - last I heard those still cost about $10K a pop. 
> Interdomain CA certification is much more complex since
> the first thing you are going to have to do is educate all the
> company lawyers about what PKI is and what to be worried about.
> 
> >The lawyers sitting around the table will not pass around public keys
> >like they pass around business cards. 
> 
> Why not? If it is going to take the $10K to negotiate each 
> agreement does it really matter if the implementation requires 
> ten minutes or ten seconds?
> 
> Exchanging the certificate is not the problem. The problem is
> deciding whether you want to do that, whether by doing so you 
> will discover you are taking on a huge liability you are unaware of.
> 
> 
> > This exchange will happen
> >electronically (probably after the paper documents have been negotiated
> >and signed by hand), so there needs to be an automated mechanism whereby
> >an electronic request for cross-certification is sent and an electronic
> >response (containing the cross-certificate) is returned.
> 
> 
> I still think you be putting cart before horse. 
> 
> I don't think that the existence or not of an automated mechanism
> makes any difference. I think that the critical misunderstanding
> that CMP is based on is the idea that decisions about forming
> business relationships involving trust are minor ones which can
> be handled cheaply at the administrative levels of an organization
> rather than a central preoccupation of mid and senior level
> management.
> 
> 
> In practice there has to be some means of simplifying the 
> agreements. That will in most cases entail some form of
> standardization of certification practices. 
> 
> Furthermore it is cheaper for a specialist to do this than it 
> is for a non specialist, even for a single time since they will
> presumably have built up experience and infrastructure to
> streamline the process. Should Citibank decide to make a
> practice of issuing cross certificates via CMP are they going 
> to insource or outsource that activity? My guess is outsource
> as they do with credit data.
> 
> In any case what business model is that activity going to follow?
> Where is the profit to any organization allowing their senior
> level management to be tied up in an endless series of cross 
> certification deals? Surely it is easier for an organization to
> require anyone who does business with them to be recognized
> by an acceptable third party?


I do not agree at all with this affirmation for the simple reason that in
the business world all the agreements are essentially directly negotiated
among the partecipants (in other words the negotiaton is the basis on
which they establish a trust level) this happens in the same way in case of 
small or large business. 

pay a little attention at the simplest negotiaton that you can have (no  
much money and no strategical importance of the business) 

Suppose I want to buy a book in a bookstore: the negotiation begins with a 
presentation of the payment methods offered by the bookstore (i.e. cash, 
credit card, check) note that all the methods implies the existence of a 
certificate (yes even cash... after all even the littlest coins are 
"certified" credits from an institution).

After I have chosen the certificate (suppose the credit card) and the 
merchant have agreed (it trust my credit card issuer) we have two further 
possibilties: in the first case the merchant have a P.O.S. wired with an 
authorization center that can give an on-line response (with the 
apropriate protocol) to an auth. req. (note that the merchand must even 
authenticate itself in order to obtain the response) if he obtains an auth. 
number he decides to trust me; in the second case the merchant is not 
wired via a P.O.S. (or simply the P.O.S. is out of service) so he can 
request me a document (such as as driver license) to verify that I am the 
person that own the credit card (the driver license is obviously a 
certificate coming from another third party) an then he can decide to 
trust my signature on the plain paper module that the credit card issuer 
has given him.

But in all the two cases the only credit card (in theory a trusted third 
party certificate) is not the only basis of the agreement, it must be 
"enforced" with a negotiation involving  a VARIABLE NUMBER of other trusted 
third parties until we have not reached an agreement. And, no one can 
replace the final decision of the merchant and me about the quantity of 
risk that we decide to assume in our business.

I want to point out to the fact that we have negotiated (even for the 
simple action to buy a book) a relatively large number of "cross 
certifications" where the relation among the "certification 
authorities" are (even if they can exist) meaningless for our goals.

A real model of certification must look at the endpoints (where the 
negotiations are made) if it does not want to fail (the merchant.. and I 
don't care about the eventual "intra-ca" relationships).

A monolithic "outsourced" TTP model will die (even in this simple case ... 
imagine if it can survive in a more complicated case!).

It needs too many "real-phisical" connections to live in the real 
(multimillions of users) world.

Is hard to find two partecipants (sure you cannot find two business men) 
that waant condut a business exclusively on the basis of the eventuality 
that they trust exclusively on the same TTP this is unrealistic.

They in fact (in the real life) present to the other a list of choiches 
and  then they agree on a COMMON (NOT necessarly SINGLE) basis.

I think that our best efford can go in a direction that can unify the 
protocols of the negotiations but I think that we cannot impose the 
methods .... in other words we cannot impose a trusted chain .... we must 
stop where others (the partecipants of the business) must decide... 


Remo Tabanelli

  //)
 //\emo.

> 
> Pretty soon we arrive back at the idea of a public certification
> authority to manage public trust. Go to a public CA, get 
> notarized and you have a credential that is transportable.
> 
> One does not need a mechanism to exchange certificates with
> public CAs, you read their CPS and decide whether to trust
> them or not. People have a vested interest in chosing a CA
> which is widely acceptable. This in turn is likely to keep the
> numbers down to managable proportions.
> 
> 
> In cases where there is no public CA which is acceptable,
> communities of interest will create one. 
> 
> 
>             Phill
> 
> 
> 
> +--------------------------------------------------------------------------+
> + For information about the cert-talk mailing list, including archives     +
> + and how to subscribe and unsubscribe, visit:                             +
> +                http://mail.structuredarts.com/cert-talk                  +
> +--------------------------------------------------------------------------+
> 

References: