[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Attribute aliases
Paul Makepeace wrote:
> I would like to investigate what's involved in enabling OpenLDAP to allow
> attributes to have aliases, i.e. enable an attribute to have more than one
> name...
> The reason for this is to enable X.509 certificates to be stored in the
> directory and retrieved by clients who ask by different attributes. For
> example, both userCertificate and userCertificate;binary are requested by
> Eudora, Messenger, etc when the user's certificate is needed.
userCertificate and userCertificate;binary aren't aliases. The latter is a
subtype of the former. See RFC 2251 section 4.1.5. Among other things, this
means that an LDAP v3 server may send userCertificate;binary in response to a
Search request for userCertificate. For this particular attribute, that's what
the server must do; see RFC 2252 section 6.5.
I suggest enhancing the server to know about option/subtype semantics
generally, not just for userCertificate or ;binary, and in LDAP v2 (as well as
v3).
An LDAP v3 server
> Being able to store X.509 certificates (and retrieve them!) enables secure
> email ...
Actually, it's not sufficient. For secure email, you need more information.
The userSMIMEcertificate attribute was invented for this purpose. Details:
Subject: Re: [Fwd: Re: I-D ACTION:draft-ietf-asid-inetorgperson-01.txt]
From: Jeff Weinstein <jsw@netscape.com>
To: Tim Howes <howes@netscape.com>, patrik@patrik.com, ietf-asid@umich.edu
Date: Tue, 12 Aug 1997 22:55:09 -0700
Message-ID: <33F14C3D.DB876645@netscape.com>
References: <33E88B7F.345B@netscape.com>
Tim Howes wrote:
>
> Subject: Re: I-D ACTION:draft-ietf-asid-inetorgperson-01.txt
> Date: Wed, 06 Aug 1997 11:20:11 +0100
> From: Patrik Nilsson <patrik@patrik.com>
> To: ietf-asid@umich.edu
>
> I'm a bit confused/worried as to the use of userSMIMECertificate, instead
> of userCertificate, in this draft (and as currently implemented in Netscape
> Communicator and Directory Server).
>
> - - - - - - - - - - - - -
> 4.6. User S/MIME Certificate
>
> Certificate used for S/MIME [RFC1847]. This attribute is to be stored
> and requested in binary form, as 'userCertificate;binary'.
> ( 2.16.840.1.113730.3.1.40
> NAME 'userSMIMECertificate'
> DESC 'certificate for S/MIME"
> SYNTAX 'Certificate'
> )
> - - - - - - - - - - - - -
>
> Is it really necessary to introduce a separate attribute type for
> certificates used in s/mime contexts?
> Shouldn't it be possible to use the same certificates for s/mime as for
> other user certificate purposes, such as SSL/TLS and SASL, as long as the
> service specific attributes, ie: email address, are included in the
> certificate?
>
> Will this mean that users will have to handle (and probably get confused
> by) multiple certificates and/or that services will have to remap between
> userSMIMECertificate and userCertificate where possible and appropriate?
First some background. This is all about achieving S/MIME
interoperability, particularly between organizations. To send
someone encrypted mail you need three things:
1) Their certificate.
2) Their certificate chain - one or more CA certificates used to
chain up to a common trusted Root CA.
3) Their S/MIME algorithm capabilities - a list of encryption
algorithms and key sizes that their S/MIME software
supports.
Without all three of these you may be forced into a less secure mode
of operation (typically this means weak 40-bit RC2 encryption) or you
might not be able to interoperate at all.
Note that the algorithm capabilities are not encoded in the user's
certificate because they are a function of the end user's software and
preferences, which can change much more frequently than their certificate.
Typically users can exchange this information by exchanging S/MIME signed
messages. An S/MIME signed message contains all of the necessary certs and
the user's algorithm capabilites. The algorithm capabilities are part of
the data that is digitally signed by the user, so they can not be
tampered with in transit by an attacker trying to force the two
parties to use a weaker encryption algorithm.
There are several reasons why you might want to store this information
in a directory. The first is to avoid having to do the initial handshake
of exchanging signed messages as a prerequisite for sending encrypted
messages. The second is to avoid requiring each user to store the
certificates and capabilities of every person they wish to correspond
with.
Now we come to the question of why we felt we needed a new directory
attribute for S/MIME certificates. I was told by our directory
engineers that the existing userCertificate attribute was defined as a
single raw certificate. That leaves no place to store the other
certificates needed for chaining, and no place to store the algorithm
capabilities. We had an existing package available to us that could
contain both the certificates and the capabilities. That package is
an S/MIME signed message.
The format of the userSMIMECertificate attribute is an S/MIME signed
message with a zero length body. It contains the user's entire
certificate chain and the signed attribute that describes their
algorithm capabilities.
When a user uses Netscape Communicator to send their S/MIME
certificate to the directory, it creates one of these signed messages
and puts it into the userSMIMECertificate attribute.
When a user uses Netscape Communicator to fetch another person's
S/MIME certificate from the directory, we search for a record that
matches a given e-mail address, and ask the directory to return
both the userCertificate and the userSMIMECertificate attributes.
If the userSMIMECertificate attribute is present, we use it. If it
is not present we use the certificate from the userCertificate
attribute.
If we only have the userCertificate attribute available, then
we run into two problems:
1) We may not be able to verify the certificate due to
missing intermediate CA certificates required for
cert chain validation. This will not generally
be a problem if the two users belong to the same
organization, or if they are using some common
public CA such as verisign, but it may be common
in other cases.
2) Due to lack of algorithm capabilities we will most
likely have to use 40-bit RC2 to encrypt the message,
even if both sides support strong encryption. The
S/MIME spec does provide a set of heuristics for
dealing with this situation, but they are
problematic. They are based on the state of
US export rules as of about a year ago. These
rules are in a state of flux which may continue
for some time, and seem to be rendering the
heuristics useless.
One final point. Patrik asks if users will have to deal with
multiple certificates. It is definitely possible for many users
to have a single certificate that can be used for SSL, email,
and other things. However it is a reality of the world today
that many users will have multiple certificates. Some people
will have one certificate for email within their organization,
and another one for use outside the organization. There will
be services offered to the public over the internet that will
require users to have an SSL certificate from the service's
own CA.
I'd be happy to discuss any of these points in more detail.
Also, if there is a better way to meet our requirements that
is more in line with "the ldap way", then I'd be happy to
migrate our code in future releases.
--Jeff