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. Bob 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 http://www.novell.com/press/archive/1999/10/pr99130.html), 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 certificate directly. 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 doesn't, etc. 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 certificate(s), 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 attributes 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. Yuck! The current way of retrieving certificates is completely adequate, IMHO. If it ain't broke, don't fix it. Bob >>> <bartley.o'malley@citicorp.com> 10/26/99 10:16AM >>> -----Original Message----- From: phoffman [SMTP:phoffman@imc.org] Sent: Monday, October 25, 1999 5:09 PM To: ietf-smime Cc: phoffman 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, Agree. >and LDAP is the Internet mechanism of choice for publishing and retrieving >certificates, 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. [O'Malley, Bartley] 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. [O'Malley, Bartley] 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
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Robert R. Jueneman TEL;WORK:801-861-7387 ORG:Novell, Inc.;Network Security Development TEL;PREF;FAX:801-861-2522 EMAIL;WORK;PREF;NGW:BJUENEMAN@novell.com N:Jueneman;Bob TITLE:Consultant Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A= PRV-F331=0A= 122 E. 1700 South=0A= Provo, Utah 84606 TEL;HOME:1-801-765-4378 TEL;CELL:1-801-361-1410 TEL;PREF:1-801-861-7387, 1-800-453-1267 X-GWUSERID:BJUENEMAN END:VCARD
S/MIME Cryptographic Signature