Apparently there are people on the list who don't have
S/MIME compliant readers, and I accidentally used
base64 encoding. Here is the message in clear text form.
I'm afraid I strongly disagree with Paul and Rik, and
agree with Bartlett and David Kemp instead.
I'm speaking as an architect who is responsible for defining our
future direction with respect to our GroupWise S/MIME V3
implementation, in addition to our PKI product line, including
the Novell Certificate Server 2.0 (which was released just
hours ago as a FREE web release -- see
as well as our LDAP direction in this space.
I believe that providing multiple "standard" ways of doing
something that is relatively simple inevitably leads to
unnecessary duplication of effort, and more importantly,
serious interoperability problems between vendors.
It's difficult enough to get multiple vendors to do something
right when there is only one way to do it. If there are multiple
options, as with the current logic for determining what encryption
algorithm to use, someone is bound to screw it up, with the
result that two different products have difficulty communicating.
If I could turn the clock back a year or two, I would have preferred
that the SMIME Capabilities attribute be included in the end-user's
Failing that, I would have liked to see a "Capabilities" certificate that
is issued and signed by the end-user herself, that in addition to containing
SMIME stuff regarding what algorithms were supported, might
also have contained the equivalent of a CPS statement that defends
the user, and not just the CA, from unwanted reliance on a signature, for
example. If the end-user published such a certificate, it would have made
sense to put it in the same LDAP bucket as the end-user's own certificate.
Both of those options are probably foreclosed by now, unfortunately,
so we are left with the problem of where to put the SMIME Capabilities, and
where to put the user's S/MIME certificates.
With respect to the certificates themselves, I don't think there is any
question at all -- all, or nearly all, of the public CAs and CA toolkit vendors
publish the certificates in the already defined LDAP attributes.
And from a certificate management perspective, the last thing that either the
user/system administrator or the vendor wants is to have to manage TWO
sets of certificates stored in separate places. The possibilities for errors
are obvious -- one certificate gets deleted/replace, and the other one
I suppose that it could be argued from an LDAP user's perspective that
it might be convenient to be able to browse through a directory, find the
desired user, and click on one directory attribute to retrieve the SMIME
Capabilities and the entire certificate chain in one operation. I'm relatively
certain that's the scenario that the authors had in mind for this capability.
However, I don't think that's what will happen in practice.
Instead, I expect that an e-mail user will type in or select names from
his personal or system address book. Then he or she will decide to
encrypt the message, without regard to whether or not all of the certificates
for all of the addressees have already been cached locally.
At that point, the MUA should automatically fetch the certificates and
SMIME capabilities for all of the users, and perhaps prompt the user
to make sure that those are in fact the right certificates for those users.
But the management of the certificate chain, the SMIME Capabilities, and
any other "plumbing" that the user doesn't absolutely have to be exposed to
should be handled by the MUA. So the retrieval of the end-users
the CA certificates, and the SMIME Capabilities should all be handled
automatically, without user intervention. Since it is software that is going
to be doing the retrieval, and not a human user, retrieving from multiple
is not a problem.
From this perspective, I think it is obvious that there should be one and only
way to store and retrieve such certificates. Otherwise, it will be necessary
to implement both types of directory fetches, just in case, and that just
causes more complexity, code bloat, system and interoperability testing, etc.
The current way of retrieving certificates is completely adequate, IMHO.
If it ain't broke, don't fix it.
<bartley.o'malley(_at_)citicorp(_dot_)com> 10/26/99 10:16AM >>>
From: phoffman [SMTP:phoffman(_at_)imc(_dot_)org]
Sent: Monday, October 25, 1999 5:09 PM
Subject: Re: Working Group Last Call:draft-ietf-smime-certdist-04.txt
At 09:51 AM 10/25/99 -0400, David P. Kemp wrote:
Since LDAP directories have both user and CA certificate attributes,
and LDAP is the Internet mechanism of choice for publishing and retrieving
Disagree. We are far from understanding how certificates are and will be
published. LDAP certificate retrieval is well-defined, but not yet widely
implemented, particularly for S/MIME MUAs.
Is this sufficient grounds to junk it? If it is not widely implemented yet
because of inherent problems, then fine, but if it is simply due to its
newness(my vote) we risk delaying the implementation of either by muddying the
water with the introduction of a second.
it would seem that a draft which proposes an alternative
cert publishing mechanism as an Internet Standard would have a high
burden of proof to justify the duplication.
If this draft was coming out three years from now, yes. As it is, we have
so little understanding of S/MIME customer needs, I don't think having an
alternative mechanism is harmful.
The IESG is relatively
strict in discouraging the definition of overlapping mechanisms.
We only wish. :-) A topically relevant counterexample: S/MIME and OpenPGP.
Pause for a moment... Do you really?(wish that is)
If you did, why would you support the introduction of an overlapping standard.
--Paul Hoffman, Director
--Internet Mail Consortium
Description: S/MIME Cryptographic Signature