At 04:33 PM 12/29/97 -0800, David Sternlight wrote:
The provision of self-signed CA certificates corrupts the rigid heirarchical
model, and I think the hand-waving "should use some other mechanism" casts
huge body of arms-length users unable or unwilling to check such a CA's bona
A valid concern, but one that I do not agree with. This is a mail spec, not
a banking spec. We have exactly two choices: allow self-signed certs or
disallow them. I think the current wording, which tells MUAs that they
might want to allow them but the must think about how, is sufficient to
keep most MUA makers in the camp of "not on my software".
However, if we disallow them, then the people who have a very good reason
for using them in their application circle are prohibited because of the
spec, not because of the technology. For example, there are many non-mail
or quasi-mail Internet applications that might want to use S/MIME as an
end-to-end security mechanism, but they have very good reasons for wanting
(or even requiring) self-signed certs in their own protocol. We specify
S/MIME and its application to Internet mail only here.
Said another way, I don't see why we should prohibit self-signed certs in
the spec if they work on-the-wire. We should explain why they might be a
Bad Idea (and maybe do so more forcefully than we do now), but from a
protocol and security perspective, I don't see a good reason to prohibit
them. As the wording stands now, MUA makers are not required or even
suggested to support them.
My recommendation is that the subject paragraph, and any other opening for
self-signed CA certificates be dropped from the standard.
As you can tell, I disagree. I would, however, be happy to see someone
(maybe you, David?) write a couple of paragraphs describing the current
model and explaining why it is good, and why willy-nilly self-signed certs
would be bad. This would be quite appropriate for this document, both at
the point of discussion and in the Security section.
--Paul Hoffman, Director
--Internet Mail Consortium