- From: dan ash <dash@68summit.com>
- Date: Mon, 18 Aug 2003 06:09:49 -0800
- To: "Ryan M. Hurst" <rmh@windows.microsoft.com>
- Cc: ietf-pkix@imc.org, www-xkms@w3.org
> 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.
> 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.
dan ash
--
dan ash
danielash@fastmail.fm
--
http://www.fastmail.fm - The professional email service
Received on Monday, 18 August 2003 10:10:53 UTC