Paul Hoffman / IMC wrote:
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
the
huge body of arms-length users unable or unwilling to check such a CA's bona
fides adrift.
A valid concern, but one that I do not agree with.
I understand that you disagree. Without in any way delegitimizing your
opinion, some comments:
This is a mail spec, not
a banking spec.
Mail is used for many things, including placing orders and passing legal or
other documents which require strong validity. In citing the evolution of
banking and credit card systems I did not mean to suggest that we're
discussing that here, but rather that the trust issues, and the "bad money
driving out good" issues (as for example when anyone could issue scrip money
and the burden was on the user to check out the issuer), apply as well to any
standard intended to provide a fecund base for internet-wide trusted mail at
scale among arms-length participants.
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".
I think that for the standard itself to carry trust, it is not enough to rely
on the good sense of MUA makers and the ability of recipients alone to ignore
possibly untrustworthy self-signed CAs. Just as it is the rules of the
Comptroller of Currency that inspire some of the trust required by users of
the banking system, and just as it is VISA and MASTER CHARGE rules that
inspire some of the trust required for international credit card systems to be
workable, so for trusted e-mail we need a "gilt-edged" standard and not one
with a lot of loopholes in it, in my view. This is in no way to denigrate web
of trust for purposes it is suited for. But just as the discount coupons any
advertiser may print in the newspaper aren't legal-tender-trust-grade but are
managed separately, and just as state and even individual institutions'
"money" had to be outlawed just after the Civil War to make a national
monetary system work, just so for the trust purposes I'm citing it is
important for the current spec to exclude "roll your own" CAs in creating at
least one global Internet trusted e-mail standard. Other standards can
certainly compete in the marketplace, but they should be separate.
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.
This is a valid concern. But there are three alternative choices for such
people:
1. Use the ietf-s/mime structure but violate the spec by using self-signed
CAs. This will clearly encapsulate such sub-networks (since standard
ietf-S/MIME compliant applications won't accept such certificates), while
allowing them (at their option) to use the technology. It will thus separate
them from the trusted e-mail analogue of the "check clearing system"--the
rigid hierarchical CA structure. It's the analogue of a supermarket coupon
clearing system handled outside the money and banking system and with far
fewer forced safeguards, while using the same cash register scanners (in this
case the same computers and modems but different software)--think of it as a
"tunneling" system.
2. Use Open PGP. I like this best since PGP from the start was based on a
"roll your own", web of trust model and in effect that's what's being proposed
in the case you're discussing.
3. Use something else--there is no reason the IETF can't, for example, develop
a separate standard for self-signed CAs which borrows heavily from the
presently developing one without weakening it.
Other solutions not requiring loosening of the ietf-smime standard will
doubtlessly occur to readers.
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.
There were many reasons states or institutions wanted to continue issuing
their own money. But the narrow good was the enemy of the general good in such
a case.
We specify
S/MIME and its application to Internet mail only here.
See my opening comments.
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.
I understand your view, but for a trust standard whose main purposes are what
I think most want--arms-length trust at Internet scale with a minimum auditing
burden on the users of certified keys, I think that greater good sufficient to
move self-signed CAs to a separate standards domain. This was the basis of my
earlier "all things to all men" remark. Just as you can't be a "little bit
pregnant", and "Kosher-style" means "tref", I think it a bad idea to weaken
the model in this particular standard.
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.
I'm not smart enough about the fine structure, nor have I studied trust models
in as much depth as some here who have thought and labored long and deeply
over the above issue. I would thus rather a real expert (that's not me folks,
when it comes to this topic, though I can speak as a competent economist with
respect to what seem to me to be apt historical parallels) take this on
formally, since the group is making a historical decision whose consequences
will echo for some time to come if it's done well. I'd be glad to comment
privately to such an author on any pre-circulated drafts.
--Paul Hoffman, Director
--Internet Mail Consortium
David Sternlight
Los Angeles