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

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: ietf-pkix@imc.org; www-xkms@w3.org
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt


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:rmh@windows.microsoft.com]
> Sent: Monday, August 04, 2003 11:08 AM
> To: Deacon, Alex
> Cc: ietf-pkix@imc.org
> 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: owner-ietf-pkix@mail.imc.org 
> [mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Internet-Drafts@ietf.org
> Sent: Monday, August 04, 2003 7:14 AM
> Cc: ietf-pkix@imc.org
> 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:
> 	mailserv@ietf.org.
> 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.
> 
>