RE: I-D ACTION:draft-deacon-xkms-aia-00.txt

Dan - in-line



From: dan ash
Sent: Mon 8/18/2003 7:09 AM
To: Ryan M. Hurst
Cc: ietf-pkix@imc.org; www-xkms@w3.org
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt


> 	Should we assume the AIA only points to a XKMS Key Information
> 	service? If so should the OID be labeled as such?

I think it's a safe assuption.  No use of the AIA for the registration
service.  Even further, I can't image the AIA being useful for 'locate'
service.  It should apply to 'validate' only.     
[rmh] exactly, but this should be clearly stated in the rfc.

>    3. Shouldn't there be a documented delegated trust model, ala OCSP
> for
> 	XKMS Key Info? Maybe we need a XKMS Key Information EKU and the
> same
>       1 level rule set used in OCSP could be applied. This is 
> important
> for
> 	clients that are base relying parties and are not knowledgeable
> enough
> 	to operate their own or explicitly choose a third-party to do
> this for
> 	them.

I believe both XKRSS and XKISS ('validate' anyway) require an explicit
relationship to be established with the client beforehand.  And would
include the URL and trust parameters of the service.  This may seem like
a shortcoming of XKMS, but it helps to deliver the level of simplicity
that was desired (at least for the client).  And besides, what other
authentication system allows a relying party to authenticate users
without having prior knowledge or a relationship, directly or indirectly
with the user or their authority.

The usefulness of the AIA is to support indirect relationships, or
through a third party.  The AIA would allow an XKISS service to locate
the authoritative XKISS service for the user in question.   This
functionality would require a trust model such as an EKU for XKISS and so
forth.  But I don't think these type of requirements should be part of
XKMS.  In fact, I think they will covered by WS-policy or something of
the like.    

[rmh] Your right, however this "flexability" is not appropriate in a internet model where clients grock PKI and the users do not. Imagine your mom having to manualy establish trust to a KISS service before she could buy that book she wants. I suggest defining a client profile that says something allong the lines that the x509 key type must be supported and the responses MAY be validated in way X,Y,Z; efectivly ca signed, ca delegated (EKU, 1 level delegation), or other.
dan ash
-- dan ash danielash@fastmail.fm-- http://www.fastmail.fm - The professional email service