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

From: [email-masked]
Date: Mon, 04 Aug 2003 10:14:21 -0400

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: "Faisal" <[email-masked]>
Date: Wed, 13 Aug 2003 16:38:57 +0500

Hi,

    In X509Certificate, there is extension which guides us about ocsp
server. I request to write a draft for scvp-aia-extension for future support
of SCVP in X509Certificate.

Kind Regards,
Faisal

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Aug 2003 15:39:06 +0200

Faisal,

> of SCVP in X509Certificate.

I do not think it would be a good idea, since an SCVP service is not part of 
CA services. An OCSP service on the contrary is, and this is why this is 
supported in a certificate extension.

Denis

>>A New Internet-Draft is available from the on-line Internet-Drafts
> 
> directories.
> 
>>
>>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
>

---

From: "Faisal" <[email-masked]>
Date: Thu, 28 Aug 2003 10:24:14 +0500

Denis,

- Why is SCVP considered not part of a CA service and
OCSP is?
- Where is this defined?
- Also whether the SCVP service is provided by a CA or provided by some
other trusted third party, would it still not be a good idea for the CA
to identify how to locate the responsible SCVP service for its
certificates (assuming there is one)?
- Why does it matter who is providing the service?

I don't understand

Regards,
F a i s a l

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 28 Aug 2003 11:34:48 +0200

Faisal,

> - Why does it matter who is providing the service?

An SCVP service can be provided by anybody. It is able to verify 
certificates according to one or several validation policies.

RFC 3280 states :

    Message formats and protocols supporting on-line revocation notification
    are defined in other PKIX specifications.

SCVP does not replace CRLs or OCSP.

SCVP is not simply an on-line revocation notification service, since it does 
more: path construction and revocation validation checking for all the CA 
certificates from the path up to one or more trust points.

Using an extension to indicate the location of a SCVP service would be a 
pointer to a "useful" service in the same way like a CA could indicate the 
location of useful Time-Stamping Units (TSUs). So, if we accept this 
extension, we will have to accept pointers to TSUs and in the future 
pointers to some other "useful" services like an *electronic* signature 
validation service, and maybe more.

Either we open the door to "useful" services like SCVP, or we don't.
I wonder whether we should open that door.

Denis

>>>server. I request to write a draft for scvp-aia-extension for future
>>
> support
> 
>>I do not think it would be a good idea, since an SCVP service is not part
> 
> of
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Aug 2003 21:07:36 -0400

>- Why does it matter who is providing the service?

OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
CAs. Thus a CA issuing a cert can reasonably choose to insert a 
pointer in AIA to an OCSP server that the CA (or its designee) 
operates, just as it would have inserted a pointer to a repository 
for retrieving CRLs signed by that CA.  In contrast, the choice of an 
SCVP server is a local matter, relative to an RP, and thus it would 
generally be inappropriate for a CA to direct an RP to an SCVP server.

Steve