From: David Sternlight <david(_at_)sternlight(_dot_)com>
This isn't about openness or freedom. It is about arms-length trust when the
parties are pretty much all at the ends of wires and there are massive
economies of scale/effort in having trusted, audited,
certification-operation-standards-meeting CAs and only those CAs in at least
this ietf standard.
I agree with your ends, but do not believe that your means (putting
restrictions in the S/MIME protocol spec) can be effective in achieving
We agree that there must be some mechanism whereby a "domain
administrator" (individual user, IT staff person, security officer,
software manufacturer, the Federal Reserve, etc) is able to control
which CAs are to be trusted within a particular domain. A "domain" as
used here could be a single machine at home, a corporation or division
or branch, a political/regulatory environment such as the banking system,
If I understand your argument, you are claiming that software
manufacturers (or the IETF?) should be the only entities capable of
specifying the list of acceptable root CAs, and that the consumer's
control should be limited to disabling entries on the list, not adding
CAs to it. It should be obvious that that solution would never fly -
the MUA vendor could not possibly be expected to be the trust
administrator for all possible domains in which the product might be
So perhaps you are arguing for a more limited form of technical control -
users should be able to specify the list of trusted CAs, but an entry
on that list could not be received in an S/MIME message, it would have
to be retrieved by LDAP, floppy disk, non-secure email, ftp, http, or
any means except S/MIME.
No, that's not what you meant?
Perhaps you want S/MIME to mandate the form of user interface to be
used to administer the trusted CA list - it would be unacceptable to
present a dialog box saying:
Root cert received via S/MIME - click on:
a) accept for this message,
b) accept for all messages,
c) don't accept.
But it would be acceptable to, for example, present a box that said:
"Root cert received via S/MIME. To enable use of this cert as
a trusted CA, save it to a file, then enter it into the certificate
registry using the TrustEdit utility."
No, I didn't think you were advocating micromanagement of the user
interface either. Besides, the IETF does not do UIs, it does protocols.
I think it very important that this sub-topic not be clouded with ideological
issues. I think, instead, it's about (as much as feasible) reliable,
dependable, count-on-able systems for global trust.
To the extent that "global trust" is not oxymoronic, it must be
accomplished by social means (legislation/regulation, advertising /
brand loyalty, consumer reporting, insurance, etc), not by technical
controls. Attempting to establish a foundation for "global trust" by
manipulating the S/MIME protocol specification is doomed to failure.