RE: Working Group Last Call:draft-ietf-smime-certdist-04.txt

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(_at_)citicorp(_dot_)com> 10/26/99 10:16AM >>>

-----Original Message-----
From: phoffman [SMTP:phoffman(_at_)imc(_dot_)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

Bob Jueneman.vcf
Description: Vcard

smime.p7s
Description: S/MIME Cryptographic Signature