RE: requirements - 4-corner wording

Mack's suggestion sounds like a good one to me. What we need to be clear on
is what we mean when we say trust models are out of scope.
 
One of the main operating models I considered when designing XKMS was DNS.
Each IP device has a relationship with what is essentially a single DNS
service (OK two servers for redundancy, but one logical service). The client
sends all its queries to that one service and gets back an answer. The
details of how that answer are arrived at are actually irrelevant.
 
What I think we need to avoid adding into XKMS is the ability for the client
to describe the trust model to be applied in detail, there lies the path to
madness. We are running a McDonalds here and not a Burger King, you get your
choice of burger made as defined in Hamburger University
build-a-better-burger manual, you don't get to choose whether you have the
lettuce or pickle on the cheeseburger or not.
 
        Phill
 

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


-----Original Message-----
From: Hicks, Mack [mailto:Mack.Hicks@bankofamerica.com]
Sent: Friday, January 25, 2002 2:10 PM
To: www-xkms@w3.org
Subject: Re: requirements - 4-corner wording


XKMS List,

Now that many have had their shot - I will jump in.

I have no problem with Rich S's, or Frederick H's definitions.  Both look
adequate. However, I think there is a point that is missing here.  And I
think that Dan Ash is struggling, as I, with the same issue.  I want XKMS to
assist an application not confuse it; applications are very dumb and do not
want to "decide."

In any large organization - especially a bank - an application is going to
look to their information security department to deploy the infrastructure
necessary for PKI  and secure XML (a broad brush).  Applications have said
to me:  Where are the API's? Can't I just send the SOAP signature header to
the information security server and have it come back with "Yes" or "No"?
Why does my application have to dig down into the document and header to
look for --- well, they don't even know the terminology to know what they
need to look for.  Instead - the application coder just gives up and looks
for their in place userid/pswd schemes.

From a vendor development view:  If I get a "pre-packaged" set of XKMS
tools, I don't want to have to go to the vendor and say -- "yeah, yeah - I
know that the tool is supposed to go to the OCSP listed in the cert chain,
but instead I want you to go to a designated server."  Further the vendor
who provides the XKMS server will advertise compliance with our spec.  Then
I have to say to that vendor - "yeah, yeah - I know - but ignore that stuff
in the spec and just send back a 'yes' or 'no' to the application -- attach
all the rest of the stuff as an audit trail." Phooey - we tried a simple run
on the spec with Identrus and OCSP, but we got trapped  - yes - trapped by
auditors and others looking at the specs. We ended up OCSPing over and over
again for each element in the chain for each time. I can't have that with
XKMS - it will not be deployed.

My suggestion:  Embrace the concept that an application has a trust
relationship with one (or small number) of trusted internal servers. All
queries go to that server. All response come from that server with
validation responses binary - 'yes' or 'no'. The application is not expected
to do much validation of the response - the less the better.  The trusted
server may have to go outside the company or to internal databases or to
another XKMS server to Locate and Validate, but as far as the application is
concerned - the answer comes back from the trusted server.

As an of application dumbness example, from long personal experience, I have
yet to find one application that is willing to invest in making a
distinction in the quality of authentication (even when presented fully
implemented - for free).  They find it too hard to maintain a continuity of
state within the application. They want a binary answer -- they are willing
to provide a brief context for the authentication query, but not much more.
The other work around is to ask for re-authentication - but still that event
is not maintained in the state

The thread of most postings on the list has been oriented toward
registration and legacy PKI.  I have a different focus: How to get
applications to deploy what we have all already built? I will keep quiet on
our redo-ing what is in the past (PKCS7, 10, etc.) because they are of
little impact to me if I cannot get the current PKI I have deployed to
applications. But I will be vocal when the application (XKMS client) is
expect to do more and more - I must have less and less to get anyone to even
nibble.

From a risk management perspective, instead of locking down KXMS to the
application tightly - as the Security Considerations section does, we might
need a "here is how to play loose and simple - given a particular risk model
- some detectable fraud possible - but you won't get killed - and you can
fill the hole later if you want." This is the very successful PayPal model:
build something - check for fraud, fix it - try again - lose a little money
- fix it - try again.  The security measures are in place because they
address actual risk and events - rather than just theoretical.  

Enough ranting - sorry about a Friday rant.

So back - Rich's and Frederick's definitions are fine.   

Stephen Farrell wrote:


Since we're after "xkms MUST NOT preclude..." type language, I don't
think its crucial that we develop an exactly right definition of 
4-corner models, so I'd be ok with Frederick's suggested wording.

The only addition I'd suggest is to note that this stuff mostly 
applies at run-time and not at registration-time (i.e. its locates
and validates that need to be proxied/whatever). This could take
the form of a statement that 4-cornered registration is NOT
REQUIRED I guess.

Regards,
Stephen.


Daniel Ash wrote:

The only distinguishing factor of the 4-corner is the "peerwise trust
relationship", which is
certainly out-of-scope for XKMS... which leaves us with an environment that
supports referrals
(even less Identrus-y).  Without referrals it will be more difficult to
separate complicated trust
models (cross-certification, bridges.. etc) from the trust relationship
between client and
service.  This separation, I think, is tantamount in shielding end entities
from more complexity
than necessary.

Other trust infrastructures could benefit, as much as Identrus could, from a
referral mechanism
(I'm not quite sure what the difference is between referrals and server
chaining).  Does anyone
else agree that a referrals (or server chaining) requirement should replace
the 4-corner
requirement?

-dan


-----Original Message-----
From: Rich Salz [ mailto:rsalz@zolera.com <mailto:rsalz@zolera.com> ]
Sent: Thursday, January 24, 2002 1:02 PM
To:  hirsch@zolera.com <mailto:hirsch@zolera.com> 
Cc:  www-xkms@w3.org <mailto:www-xkms@w3.org> 
Subject: Re: requirements - 4-corner wording


How about making the definition less Identrus-y?

4-corner model
A processing and/or trust environment where end-entities
interact with a
single trusted point of contact, and each such contact has a peerwise
trust relationship with all other contacts.
      /r$
--
Zolera Systems,  http://www.zolera.com <http://www.zolera.com> 
Information Integrity, XML Security





-- 

---------------------------------------------

Mack Hicks, SVP      mack.hicks@bankofamerica.com
<mailto:mack.hicks@bankofamerica.com> 

Bank of America  +1-415-241-3654