David P. Kemp wrote:
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.
David,
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
them.
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,
etc.
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
used.
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.
Not bad! If a user has to exercise positive seeking behavior to get a
self-signed CA cert which didn't meet generally accepted and audited trust
requirements, and there were no possibility of an inadvertence (as there could
be if it were passed via an S/MIME message and the user given an
"accept/reject" choice), that would meet many of my objectives. I would add
only one thing--a mechanism that prevented such accepted CA certs from being
transitive--that is: EACH user who wished to accept such a cert would have to
engage in similar positive seeking behavior with respect to getting the CA's
cert. I recognize that this makes it more difficult to propagate such
self-signed CA certs, and makes it harder to authenticate/decrypt traffic
received for the first time that is certified BY such CAs, but that's the
point of protection.
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."
I'm not quite comfortable with this, since again the user is presented with
the CA cert and has to go through a (more difficult) accept/reject process. It
is not positive SEEKING behavior since the user doesn't have the additional
responsibility of going himself to a site he trusts to get the CA's cert via
pull. Instead, he gets it via push, albeit with decision points.
No, I didn't think you were advocating micromanagement of the user
interface either. Besides, the IETF does not do UIs, it does protocols.
How the thing is implemented could be left to the software designers. But the
rule--"no self-signed push CA certs" is easy enough to put in the standard.
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.
David
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.
I think that while in principle you're correct, in practice proper systems
design can either enhance confidence or make its achievement more difficult.
Best;
David