RE: I-D ACTION:draft-ietf-pkix-laap-00.txt

["Linn, John" <jlinn@xxxxxxxxxxxxxxx>]

I've a few thoughts re the LAAP draft.

I'm somewhat concerned about the definition of profile strings as AC
selectors.  If the usual practice is that profile strings' values are
meaningful only by bilateral agreement, this implies a lot of configuration
and could be susceptible to misinterpretation by punning, especially if/as
LRQs grow to interact with more than just one LRP. At the risk of a
contrived example, a Mr. Teller's name, passed as a profile hint, shouldn't
be interpreted as soliciting a role AC allowing him to handle cash at a
bank.  I think general use of an OID tag with optional text qualifier would
be safer, more general, and could contribute to more effective
interoperability among prospective LAAP peers.  Some uniform tag values
(e.g., "role") could be usefully defined.  I'm neutral as to whether the OID
is carried in string-encoded form or not, but believe that some level of
syntactic structure needs to be present to distinguish the OID from any
associated qualifier(s). 

Is the fact of LAAP's definition within CMP likely to create demultiplexing
problems in end systems where both LAAP and CMP services are provided, but
by different internal entities?

--jl

> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, October 13, 1999 6:54 AM
> Cc: ietf-pkix@imc.org
> Subject: I-D ACTION:draft-ietf-pkix-laap-00.txt
> 
> 
> 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		: Limited AttributeCertificate 
> Acquisition Protocol
> 	Author(s)	: S. Farrell, D. Chadwick
> 	Filename	: draft-ietf-pkix-laap-00.txt
> 	Pages		: 11
> 	Date		: 12-Oct-99
> 	
> The PKIX working group is profiling the use of X.509 attribute
> certificates. This document specifies a deliberately limited
> protocol for requesting an attribute certificate from a server. It
> is intended to be complementary to the use of LDAP for AC retrieval,
> covering those cases where use of an LDAP server is not suitable due
> to the type of authorization model being employed. For many other
> cases, the use of LDAP is preferred.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-laap-00.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-laap-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-ietf-pkix-laap-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.
>