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

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 15 Aug 2003 17:09:22 -0700

Hi Ryan,

Thanks for the comments.  I agree that we need to address all of the issues
you raise.  However upon thinking about the best way to address them it
seems to me that instead of defining XKMS profiles and the like, which may
not be an easy task (i.e. rat hole), we should probably just use WSDL to
define what is and what is not supported.   

So the XKMS AIA would simply point to a WSDL file that defines where the
XKMS service lives, what transport should be used, is a SOAP envelope
required, what services are provided and even perhaps even details as to
what key identification forms can be sent and what the trust model is. 

Comments?

Alex

> -----Original Message-----
> From: Ryan M. Hurst [mailto:[email-masked]]
> Sent: Monday, August 04, 2003 11:08 AM
> To: Deacon, Alex
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
> 
> 
> 
> Alex - Glad to see some one has put together a story for how 
> this can be
> represented in the X.509 world. I have a couple comments/questions
> though,
> 
>    1. XKMS supports several different services (key 
> information and key
>       Registration) and implementations will likely only support a
> profile
>       of each.
>       
> 	Should we assume the AIA only points to a XKMS Key Information
> 	service? If so should the OID be labeled as such?
> 
>       Should there be a PKIX profile of what a server 
> supports when this
>       OID is present in the AIA? For example what forms of key
> 	Identification are supported, I assume if it's being referred to
> in a
>       X.509 certificate it would minimally support the X.509 key
> 	identification form. What about the types of information that is
> 	available?
> 
>    2. XKMS may used in a variety of protocols, shouldn't the draft
> indicate which transport that should be assumed in PKIX environments? 
> 
> 	Is it assumed that this is just a post of a XKMS request, if so
> is
> 	There a need for an application mime-type? Is it assumed it will
> be
> 	Wrapped in a SOAP envelop and be routed based on that?
> 
>    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 have to admit I am not a XKMS pro, so some of these questions may
> sound out of place but they were the first ones to come to mind when I
> saw this.
> 
> Ryan M. Hurst
> 
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, August 04, 2003 7:14 AM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-deacon-xkms-aia-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: AIA Access Method for XKMS Services
> 	Author(s)	: A. Deacon
> 	Filename	: draft-deacon-xkms-aia-00.txt
> 	Pages		: 5
> 	Date		: 2003-8-4
> 	
> Authority Information Access extension that is used to indicate how
> to access CA information and services for the issuer of the
> certificate in which this extension appears.  This document defines
> an access method identifier that indicates the location of XKMS
> [XKMS] services.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-deacon-xkms-aia-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-deacon-xkms-aia-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-deacon-xkms-aia-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Fri, 15 Aug 2003 17:44:29 -0700

Thats a resonable approach, however I hate the idea of multiple connections; e.g. I think it would be better to say its allways a HTTP POST or similar; from a client standpoint you get to share 15 seconds or so for the entire validation process, the more wire retrievals you have the worse off you are :)

Ryan

From: Deacon, Alex
Sent: Fri 8/15/2003 5:09 PM
To: 'Ryan M. Hurst'; Deacon, Alex
Cc: [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt

Hi Ryan,

Comments?

Alex

---

From: Rich Salz <[email-masked]>
Date: Fri, 15 Aug 2003 21:12:18 -0400 (EDT)

> what key identification forms can be sent and what the trust model is.

Uhm, yuck. :)

Are you really expecting every XKMS request to start out with a
GET If-modified-since request?  And then have to parse WSDL to understand
what do do?  Again, every single XKMS request and every single XKMS client?

If you don't expect XKMS applications to do the conditional GET, then it's
not a URL, but is instead a URI.  At that point, it becomes an identifier
for *a particular instance* of a WSDL file defining the service.  At that
point, you might as following standard AIA practice, and let the OID
define the service and transport, and the value define how to find it.

The only profile worth defining is XKMS over SOAP 1.1 and SOAP 1.2,
and the value of the OID is a URL of the service that can tell you
how to Validate the certificate.  Mandate "ds:X509Data/ds:X509Certificate"
MUST be supported, and that other forms MAY be supported.  Leave it
up to WS-I (when they get to us) to profile what MAYs should become
MUSTs.

I think it makes little sense, for example, for a cert to
say "here's the Register service if you want to make more like me." :)

I think Ryan's questions are slightly interesting, but only if you
think a certificate is going to contain multiple AIA's.  I don't.
In general, his questions are leading us to the morass of "PKI-ness"
that has, so far, managed to throttle PKI in its crib.
        /r$
--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 18 Aug 2003 08:07:14 -0700

Rich - in-line

From: Rich Salz
Sent: Fri 8/15/2003 6:12 PM
To: Deacon, Alex
Cc: Ryan M. Hurst; [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt

Uhm, yuck. :)

[rmh] I agree, however in the case of a certifcate validation engine I can't imagine a case when anything other that a X509Certificate would be used for key evaluation, but with that being said as long as there is the MUST for support of x509 based identification thats workable.

[rmh] I agree,  my point is that we should be explicit in the draft.

[rmh] I think support for multiple AIAs is important, also these concepts must be explicit in a PKIX draft like this otherwise existing certificate validation engines would make a different set of assumtions resulting in non-interoperable deployments.

/r$
--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com/
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html

---

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 18 Aug 2003 08:00:06 -0700

Dan - in-line

From: dan ash
Sent: Mon 8/18/2003 7:09 AM
To: Ryan M. Hurst
Cc: [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt

> 	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.

> 	to operate their own or explicitly choose a third-party to do

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 [email-masked] http://www.fastmail.fm - The professional email service