Phillip M Hallam-Baker wrote:
3. Either has "unique" advantages
see above. If they had, why not listing them and join all advantages
into one standard?
Perhaps I should have said "unique and mutually exclusive" to drive the
point
home, though I thought I had done that with my examples. For instance it is
mutually exclusive to allow anyone to be a signer and to allow only those
meeting certain standards to be signers.
With respect David this is simply not true.
It is logically true. There are ways around it, as you show with respect to
S/MIME.
<way round it via user intervention omitted>
The only sense in which the built in client certs are in any
way special is that the browser company (Microsoft/Netscape)
has reviewed their Certification Practices Statement and
their operations and determined that their certificates
may generally be considered trustworthy. If you disagree
with this assement then uncheck the box next to VeriSign,
MCI, Thawte etc and you are entirely OK.
This is the point, though I may have expressed it imprecisely. For
S/MIME-X509-Verisign et al (what can we call that as shorthand?) there are
"Certification Practices Statements" and sets of hardware and software
standards for CAs. Second of all they are reviewed and only those considered
trustworthy in general are pre-installed in general-user browsers (as distinct
from some possible intranet practice). This is a distinct advantage of the
model, as implemented, for arms-length interaction between strangers.
In contrast, the web of trust model, as practiced, doesn't require such
practice statements, nor central checking, nor any particular CA
standard-sets. Instead each user creates his own trust heirarchy and rules.
This is a distinct advantage of that model, for small workgroups where
participants know each other and have an opportunity to verify fingerprints or
keys to identities directly.
Clearly the first approach is useful in some environments, and the second in
others. It would be a mistake for users in arms-length interaction to trust
unverified signatures just as it would be a mistake to force small
self-contained work groups to adopt the overhead of CAs, trust statements,
etc. And unless the canonical models are distinct, a degree of user education
well beyond pragmatic practice is required, and the possibility is opened for
much mischief.
In your own prior message you speak about the mountains having decided how
it's going to be. This is another such example. One may argue (and such
arguments may be interesting and even useful during design of some new
standard if the mountains will go along) that in theory it could be different.
But the proof of the pudding is in the eating and the current menu on offer
involves Certification Practices Statements on the one hand, and roll your own
on the other.
Thus I continue to disagree that there ought to be a single standard in its
base form, but rather two. PGP fans who believe your earlier sketch about
Phil's unmoving view vs. the "mountains" ought to take delight in that
position. The alternative--under your sketch--is for PGP to go away except as
a niche application and S/MIME to continue to be the de facto standard and
eventually become the de jure standard. It would also mean, under a
single-standard view and the reality of the mountains, that the IETF PGP group
is largely wasting its time. Note that I do not hold that view.
To avoid misunderstanding I repeat my basic mantra--each trust model in its
pure form has its place and to combine one with the other in the base design
is a bad idea, thought providing a fail-safe multi-step escape hatch giving
users some flexibility (as you've illustrated for S/MIME in Explorer) may be
useful. Nevertheless I suggest the canonical forms are distinct, and should
remain so: In S/MIME-X509 as practiced, users are provided with high-level CA
keys which meet CPS tests; in web of trust as practiced, users must build
their own CA structure on a case by case basis but aren't limited by anyone
else's idea of CPS tests (pace Thawte).
Frankly speaking, I have the impression this is really not a useful discussion
to continue in the PGP and S/MIME 3 IETF lists since I think de facto we've
got two standards evolving and the commonality is likely mostly to be in the
area of envelopes. But it is not for me to try to shut off discussion on this
interesting topic, if others find it useful.
David