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

From: "Ryan M. Hurst" <[email-masked]>
Date: Mon, 4 Aug 2003 11:07:48 -0700

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.