Re: "Onion model" explained

Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Thu, Jul 11, 2002 at 07:06:14PM -0700:
> > From: Pete Wenzel [mailto:pete@seebeyond.com]
> > Sent: Thursday, July 11, 2002 5:59 PM
> > To: Joseph Hui
> > Cc: Christopher B Ferris; Hal Lockhart; www-ws-arch@w3.org
> > Subject: Re: "Onion model" explained
> > 
> > 
> > Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Thu, Jul 11, 
> > 2002 at 04:27:32PM -0700:
> > > [snip]
> > > >> >Presumably she requires some proof of possesion, a certificate
> > > >> >alone proves nothing, but this is a side issue.
> > > >> 
> > > >> A certificate proves nothing?  By certificate I meant a cert 
> > > >> that Alice
> > > >> deemed trustworthy, say a CA signed cert.  Now, if a CA 
> > signed cert,
> > > >> which millions of Internet shoppers trust their money to, 
> > > >> means nothing
> > > >> to you, then I don't think we'll go anywhere on the issue.
> > > > 
> > > > A certificate alone means nothing, even one that is CA 
> > > > signed, absent a CPS.
> > > 
> > > Well, it means whatever Alice deems trustworthy or otherwise,
> > > assuming Alice already practices "safe certs," such as
> > > checking the CRL (Cert Revocation List) with due diligence.
> > > [snip]
> > 
> > These are all important considerations for establishing a
> > certificate's trustworthiness, but I think you are both still missing
> > Hal's "proof of possession" point. 
> 
> If there was point there, that wasn't a salient one wrt
> the gist in my original (first) response to Hal: authN
> alone can suffice in some cases.

I have paid careful attention to your authentication-only examples,
but still believe that they involve a binary authorization policy,
whether it is implicitly or explicitly stated.  For Alice & Bob, it is
"All authenticated parties are authorized to submit messages, which I
will in turn accept for further processing."  If Bob can authenticate
his identity, Alice will accept.  If he cannot, she will reject.

Or, "If I succeed in authenticating the server at the other end of my
connection that claims to be www.amazon.com, it is then authorized to
receive my credit card info, so I will type it in.  Otherwise, it is
not authorized, and I will not proceed with the transaction."

Yes, authentication happens first, then an authorization decision is
made, so they can be treated separately; but having authentication
alone is not useful.  It is not a very interesting application that
performs authentication, then continues in the same manner regardless
of the outcome of the authentication.

> > The fact that I can present some
> > random certificate to you, even if it passes all validity checks, only
> > serves as identification.  My identity is not authenticated (bound to
> > the identifiers in the cert) unless I can actively prove to you that I
> > am the subject of said cert.  (This by demonstrating that I can sign a
> > challenge nonce, verifiable using the cert's public key; or that I can
> > decrypt something that you have encrypted with it.)
> 
> Again, let me reiterate what I expressed in previous messages of
> this thread, it all comes down to Alice's discretion: in what
> she trust?  In trust and sec, you get you pay for, but don't
> pay for what you don't need.  There're many happy PGP folks
> out there.  Not everyone, in fact most e-commerce practitioners
> don't, find it necessary to add challenge/response on top of
> trusted certs.  (BTW, this has been a well treaded area by
> non-repudiation enthusiasts.)

True, the authentication I spoke of need not be of a
challenge/response form.  The PGP or e-commerce user's goals may be
satisfied as long as *something* is signed or decrypted, proving
possession of the correct private key.

> Say, if you buy stuff from an
> https website, do you chllenge the sellers?  I bet you don't,
> even though it's your money that's at stake. 

I trust that my SSL/TLS-enabled browser challenges the seller's web
server.  It encrypts the pre-master secret using the (supposed)
server's certificate.  If the server is unable to decrypt it, that
proves it likely to be unauthentic, and the protocol terminates.

--Pete

> Joe Hui
> Exodus, a Cable & Wireless service
> ========================================
> > 
> > --Pete
> > Pete Wenzel <pete@seebeyond.com>
> > SeeBeyond
> > Standards & Product Strategy
> > +1-626-471-6311 (US-Pacific)

Received on Friday, 12 July 2002 02:28:52 UTC