>What I'm interested in is ideas on storage and retrieval of X.509
>certificates and CRLs in X.500 directories, both via DAP and LDAP. I've
>been looking through some RFCs and ISO standard documents, and from what
>I gather there are some problems with the currently defined standards:
>
>- only possible to store 'un-signed' user and CA certificates, without
>the CA-signature
Incorrect: the definition of Certificate syntax includes a signature,
and that's what the Directory stores. Works with QUIPU (PD, IC, CDS,
et. al.), ICL, Digital, TransIT 500, just to name a few.
>- maximum size of a CRL is 32503 bytes, which is highly insufficient, at
>least with v2 CRL:s
I just re-checked X.509 to be sure: there are no size restrictions on a
CRL defined in X.500. Even if the limit you indicate was in place, that
would still allow for many thousands of entries: assume that the
overhead information (algorithm ID, issuer name, update times) take up
1KB (and that's assuming a pretty big issuer name), you've got tens of
thousands of bytes to store certificate serial numbers, which are going
to be on the order of 5-15 bytes each, depending on the size of integer
being used by the CA.
I may be wrong, but I don't think so. If I am, kindly quote the
references from which you obtained the limit above.
>- no real standard for the actual content of the certificate, i.e. how
>to compose a RDN from the subject, that is possible and natural to use
>when searching a certificate in the directory.
X.500 defines the content of the certificate in detail, including the
issuer and subject name; when it comes to composing DNs, there are
hints and vague suggestions in X.500, but the usual approach is
something along the lines of (expressed in RFC 1779 format)
cn=Your Real Name + serialNumber=Some Unique Identifier,
ou=A Department,
o=An Organization,
c=Your Country
A few comments on the name format:
The serialNumber attribute included in the name is used to make this DN
temporally unique, as well as to guarantee name uniqueness in the
directory, without requiring mangling of the user name, i.e., the unique
identifier is managed by an administrative autthority such as a human
resources department, and is assigned to one and only one person,
forever. The value of this scheme is that mutliple J. Smith's can be
distinguished based on information unique to them that has been embedded
in their names; this is especially important for applications that make
use of DNs for access controls, et. al.
There really is no need for the organizationalUnit in the DN, especially
once you've adopted unique identifiers as guarantors of entry name
uniqueness. Furthermore, the fact that organizational structure, often
considered a proprietary asset of a business, can be revealed from such
a DIT structure (and revealed to the outside world everytime you share a
certificate or shadow your DIT or allow chained requests) argues against
using organizational structure in the DIT.
I'd go for
cn=Your Real Name + serialNumber=Some Unique Identifier,
o=An Organization,
c=Your Country
myself.
Finally, a few comments on implementation details.
If you are using V3 certificates, be sure that your DSA and LDAP proxy
are configured to use ANY syntax instead of Certificate syntax, as most
DSAs that use Certificate believe Certificate to mean V1 or V2, and this
applies to most LDAP proxies (it certainly applies to all QUIPUs and to
the UMich, ISODE-based, LDAP proxy). For ISODE-based DSAs and LDAP
proxies, set the syntax to "unknown"; for most other DSAs, use ANY
syntax. These tell the process to accept valid ASN.1, and to not
attempt to validate the syntax of the certificates. Note that you will
need to roll in the big fix I submitted to the UMich ldap-bug mailing
list a few weeks ago if you are using the UMich ldapd.
While X.509 does not limit the size of a CRL, an OS might: 16 bit
Windows applications will choke on any atttribute value > 64KB. To get
around this with CRLs, consider using cRLDistributionPoints and V3
certificates, as defined in X.500(1997) (the work to define these was
completed some time ago, the definitions are stable and have been
floating about the net, they just await final publication in the next
release of the X.500 recommendations).
pww
Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~] X.500 Specialist
pww@entrust.com [http://www.entrust.com] Nortel Secure Networks
Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C
FAX:+1 613 765 3520 [______________________] Ottawa, Canada, K1Y 4H7