Kyle Hamilton wrote:
First off: User training is arguably more technical than computer
infrastructure.  You can't simply say "they were simply not teached
[sic]" and "that's a non-technical problem",

Let me rephrase: The decision whether users are teached is a business decision since budget has to be spent for that. This is a non-technical decision and the lack of training even though the technical infrastructure already exists is therefore a non-technical problem which cannot be solved by yet another technical infrastructure.

perhaps more important: WHY to perform a series of complex tasks.

Yes, a very valid question.

(Why should someone change the oil in their car?  Because it helps the
car's engine last longer.

Good example.

 Why should someone go through the
additional mess and morass of using S/MIME?  To let themselves in for
more user-interface headache and annoyance?)

My point was the users themselves already were aware of the problems with unencrypted e-mail. They felt better encrypting their e-mails because they want to avoid harm to their company which pays their loan.

What X.509 needs to be viewed as is not "a means of identification".
It needs to be viewed as "a means of authentication which uses the
same identity policy as the issuing realm" -- in other words, it's a
means of agreeing which set of rules is being used to identify each
person.

I agree here. As I wrote in another posting. There's no ultimate trust. And IMO in most deployments the people are quite aware of this.

Everybody is a trust manager. All day everybody is making trust decisions. But 
there's no ultimate trust.
No user can make a trust decision without evaluation of the circumstances.  Without info, 
it is called gambling.  They are indeed good at evaluation, given the limited resources 
that they can apply at any time.  However, as S/MIME does not provide any 
"circumstances" that suggest a reliable framework for agreements, it should 
drop the suggestion entirely.

(Users as a mass have already rejected S/MIME as a signing framework, so this 
is more about protecting those users who might otherwise be mistaken or might 
otherwise be sold a product by their IT supplier.)

Sure there's ultimate trust.

I disagree. You are making trust decision only in a certain context.

To avoid getting too philosophical a PKI-related example: You would trust your employer to issue certs for encrypting corporate business-related e-mails and even accept that the private keys are subject of key recovery/escrow within the company's context. You would probably not want to use these keys for personal communication exchanging intimate details of your private life.

 The problem is that there are as many
points of ultimate trust as there are people.

I'd argue that there even are many points of trust per person. ;-)

But the trust model is not the main obstacle.

Ciao, Michael.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to