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