Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt

From: [email-masked]
Date: Thu, 24 Sep 1998 10:27:24 -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		: Internet X.509 Public Key Infrastructure LDAPv2 Schema
	Author(s)	: S. Boeyen, T. Howes, P. Richard
	Filename	: draft-ietf-pkix-ldapv2-schema-02.txt
	Pages		: 7
	Date		: 23-Sep-98
	
     The schema defined in this document is a minimal schema to  support
     PKIX  in  an  LDAPv2  environment,  as  defined in draft-ietf-pkix-
     ipki2opp-07.txt. Only PKIX-specific components are specified  here.
     LDAP  servers, acting as PKIX repositories should support the auxi-
     liary object classes defined in this  specification  and  integrate
     this  schema  specification with the generic and other application-
     specific schemas as appropriate, depending on the  services  to  be
     supplied by that server.
 
     The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
     and  'MAY'  in  this document are to be interpreted as described in
     RFC 2119.
 
     Please send comments on this document to the [email-masked] mail
     list.

Internet-Drafts are 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-ldapv2-schema-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ldapv2-schema-02.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ldapv2-schema-02.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: Santosh Chokhani <[email-masked]>
Date: Sun, 27 Sep 1998 12:32:11 -0400

I find the schema acceptable for the certificates.

I do not find the schema acceptable for delta CRL.  I thought we had a
mechanism by which delta CRL could be stored in the object class pkiCA.
It does not seem to be the case.  Sharon, I assume you recall the
comment and resolution in this forum.

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Thursday, September 24, 1998 10:27 AM
> Cc:	[email-masked]
> Subject:	I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
> 
> Internet-Draft. << Message: Untitled Attachment >>

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 28 Sep 1998 08:13:13 -0400

Hi Santosh, 

This mechanism does allow Delta CRLs to be included in pkiCA entries. Both
pkiCA and deltaCRL are auxiliary object classes. Multiple auxiliary object
classes can be present in the same directory entry. Only one structural
object class can be present in that same entry. 

For example, a CA entry could also be an organization entry. In that case,
organization would be the structural object class. pkiCA would be an
auxiliary class present in the same entry. If that CA used delta CRLs then
the deltaCRL auxiliary object class would also be present in the same entry.

The primary difference between structural and auxiliary object classes is
that the structural object class is the one that is used to base the naming
and the entry's location in in a directory tree structure, that's the reason
there can only be one present in each entry. Auxiliary classes do not have
this restriction. By defining the separate class for deltas we are now able
to add them, in a uniform way, to entries of other types in future (e.g.
possibly in attribute authority).  

Hope this helps. Happy to discuss further if required, give me a call.

Sharon

> ----------
> From: 	Santosh Chokhani[SMTP:[email-masked]]
> Sent: 	September 27, 1998 12:32 PM
> To: 	[email-masked]'
> Cc: 	[email-masked]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
>