[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
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:chokhani@cygnacom.com]
> Sent: September 27, 1998 12:32 PM
> To: 'Internet-Drafts@ietf.org'
> Cc: ietf-pkix@imc.org
> Subject: RE: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.txt
>
> 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: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org]
> > Sent: Thursday, September 24, 1998 10:27 AM
> > Cc: ietf-pkix@imc.org
> > Subject: I-D ACTION:draft-ietf-pkix-ldapv2-schema-02.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 : 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 ietf-pkix@imc.org
> > 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.tx
> > t
> >
> > 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: mailserv@ietf.org. 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. << Message: Untitled Attachment >>
>