Subject: I-D ACTION:draft-ietf-pkix-ac509prof-01.txt

From: [email-masked]
Date: Tue, 12 Oct 1999 06:57:10 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: An Internet Attribute Certificate Profile for         
                          Authorization
	Author(s)	: S. Farrell, R. Housley
	Filename	: draft-ietf-pkix-ac509prof-01.txt
	Pages		: 32
	Date		: 11-Oct-99
	
Authorization services are required for numerous Internet protocols,
including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate
provides a structure that can form the basis for such services
[X.509]. This specification defines a profile for the use of X.509
Attribute Certificates to provide authorization services for
Internet protocols. Some optional features are also specified which
are not required for conformance to the base profile.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-01.txt

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-ietf-pkix-ac509prof-01.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-ietf-pkix-ac509prof-01.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: Francois Rousseau <[email-masked]>
Date: Tue, 19 Oct 1999 16:34:24 -0400

Russ and/or Steve,

The syntax of the issuer field in version 2 ACs was modified in the X.509
FPDAM such there would not be a need for the authorityKeyIdentifier
extension in an AC to assist the AC verifier in checking the signature of
the AC. By instead filling the optional baseCertificateId component of the
issuer field, the intend was that you would achieve the same result without
using any extensions, which is also the approach recommended in the X.509
FPDAM. The only reason the issuerName component of the issuer field was
left was for backward compatibility with version 1 ACs as defined in
X.509(97).

In addition, I do not see the argument at paragraph 4.3.3 when you say
using the baseCertificateId field to reference the AC issuer would mean
that the AC verifier would be dependent on the AC issuer's public key
infrastructure.

François

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Oct 1999 23:33:45 +0100

Hi Francois,

> left was for backward compatibility with version 1 ACs as defined in

Fair enough, we can add text to say that AKID is not needed if
baseCerificateId is used.

> that the AC verifier would be dependent on the AC issuer's public key

I guess we meant that use of baseCertificateId means that the 
AC relying party is also a relying party for whoever the AA
puts in as its PKC issuer. I can envisage some interdomain
cases where the AA is within one PKI (say certfied by CA-1)
but the AC relying party doesn't trust CA-1. If some CA the
relying party does trust (CA-2), issues another PKC for the AA,
then the relying party can use the AC is the AC has the
AA's name in the issuer field. Not sure if this'll be a 
real case, but I think its useful to allow such a split.

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Oct 1999 13:23:42 -0400

Francois:

This is a topic for the IETF meeting.  There is also an issue of 
compatibility with RFC 2530.

Russ