Ian G wrote:
Michael Ströder wrote:
The root cause is that protecting e-mails is not enforced/endorsed
within companies even if they have a working infrastructure. The lack of
training is the consequence of this.
OK, so would you agree that this is not very useful for the non-company
people, like yours and my mum?
If so, if we agree on that, we might also say "well, companies can look
after themselves;" and/or "Mozilla has no offering suitable for secure
email for ordinary users."
Let me check that. I'll try to teach my friends to use S/MIME and see
what happens.
I don't know about you, but I'm here at Mozilla to get a solution to
everyone.
I appreciate that.
Companies come second in my book, because they can pay.
Probably, this is just a personal fetish of mine, and I don't mind being
told that Mozilla doesn't agree. But currently, its mission seems to
suggest that *all users* and especially non-corporate users are the ones
that Mozilla targets.
Agreed in the focus of Mozilla project.
Right, but that doesn't change the underlying economic model: the use
of S/MIME does not sustain itself. You need to put in fines or
penalties or additional costs in order to make it work. Without that,
it is not "economic". However, you always have to pay those
fines/costs/penalties ... and these need to be balanced against the
benefit of S/MIME. So even with the fees/rules/contracts, S/MIME is not
economic until you have shown the benefit.
This is a classical failing of the security world. Having established
the absolute need for "secure X" we then run around and organise the
business such that there are incentives to ensure "secure X". However,
there is no particular analysis that it was worth the cost, because it
is assumed to be "worth any cost".
Well, I'd argue that the classic failing of the economic world is that
it always wants to have a proof for monetary fines/costs/penalties of a
risk. But there are other fines/costs/penalties too, especially for the
non-corporate users.
Additionally even when having a strictly economic view the real costs
are never calculated exactly since the real world is too complex to come
to a precise result.
Security models are individual to businesses and individuals. They
derive from threat to the persons, which again are peculiar to
businesses and individuals. WYTM? Without walking that path, we are
simply "protecting what we can" rather than "protecting the business."
Yes, like in various other parts of our life.
I know there is a thing called
profiles, but where does one import & export them?
By simply copying files? That's how I'm doing it.
Right, this is out of scope for users. (And, sure, I have enough unix
experience to figure it out too, but, these days I treat such a thing as
a bug.)
Then this would be a room for improvement of Mozilla products.
Consider that most systems use password and username. This is *the
standard* albeit defacto. To move this to a "personal key store on the
net" scenario, we encrypt the private key with the password. Indeed, we
encrypt the entire account store with the password. This way, we can
log in from whereever and get access to the whole lot. The client
downloads the encrypted store, decrypts it with the password, then
extracts the private key.
I know at least one commercial implementation of that roaming scheme
with which I worked in a customer project.
Hey presto, an application that is better than today's standard.
As usual there are pros and cons. I'd consider this to be applicable for
the corporate user, not our moms.
And if you plan to implement such a thing for Mozilla be prepared to
work around some patents.
And most of my friends (non IT people) don't use webmail. They
use MUAs on their PCs with POP3/SMTP.
It is odd! There are two big groups here, with no real favourites. The
market isn't giving us any clear signals.
Yes, I vaguely remember having read some survey results (hope that's the
right word) that European (especially German users) prefer having a MUA
on their own PC. In contrary U.S. users preferring webmail.
Maybe it's me but frankly I don't understand what you say here.
Especially I don't see the need for a "UI vendor" to define a CPS (if
Certificate Practice Statement is meant here).
Not quite, what I mean here is that somehow, the user has to figure
out what is happening.
Yes.
The PKI view is that this is done by referring to the CPS.
No.
How so? How do you define any use of certs without referring to the CPS
or equivalent set of documents?
You have to distinguish that the user is informed once what to do with a
certain cert. Yes, that involves the CPS of the CA.
Recall Nelson's view that he does not sign anything without reading.
The wider principle here is that one should not enter into an
agreement unless it is understood.
Yes.
Remember that in another posting I expressed my doubts about whether the
content to be signed can be displayed in such a way that the signer
knows what he signes and can archive the signed blob. I'd like to keep
this separate from the SecureMessaging Trust Infrastructure.
In order to satisfy users' needs for clarity, the governance UI
should present a workable human signing view to the user. But, as we
have seen in recent threads, that is fantasy. It's a non-starter.
Ergo, S/MIME client UI implementations should be modified to drop any
sense of signing, by default, and the digsigs should be used for
integrity protection and key distribution.
You're wildly mixing stuff here.
That's partly the point. If the user can sanely untangle the stuff,
then well and good. I claim she cannot. If you-as-insider can, then
that's a start, but it needs to be put in a framework that is both safe
for users and understandable. That we haven't got.
The main use-case of S/MIME is encryption, not legally signing
something. So bashing S/MIME means you have to come up with something
else. Anders and you seem to propose something like networked
key-containers. I dislike that because I often write encrypted e-mail
while traveling by train and thus being off-line.
If you really want to sign e-mails with S/MIME and now only viewing at
the UI aspect: IMO a S/MIME e-mail is more clear for the sender than
form signing since he completely creates the content to be signed and
can archive it. Nowadays, with current implementation. And no web
designers are involved. ;-)
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.
In fact evaluation of the circumstances is never done completely.
Of course.
Without info, it is called gambling.
Yes, that's exactly what we all do each and every day when making
trust decisions:
If I go to a bakery in the morning buying a brezel for breakfast I
have a very vague idea of whether I can really trust them for not
doing any harm to my health with the food they are selling. Even
though this shop has a certificate in the sales room proving that this
baker has the title "Meister" (needed in Germany) it's completely
impractical to evaluate all the circumstances of this little deal. So
yes, it's simply gambling with high risks.
No, not at all. When you go to the bakery you get a brezel. The risk
of you not getting a brezel is very low. The information you get is
reliable, even if you do not "audit" the very making of your brezel.
This is called risk management.
The risk isn't me not getting a brezel at all. I can even see the
availability of the brezel in the sales room. The risk is to get ill by
eating it because they might have salmonellae or similiar in it.
Fortunately the probability of this risk is also very low and that's why
we gamble each day that there will no harm. But the potential damage is
very high.
(BTW, what is a brezel?)
http://images.google.com/images?q=brezel
(Not every baker, even being entitled a "Meister" can produce a good
brezel but it's not a high risk to just try. ;-)
It's a tough subject :) But I think we have got to the point where your
context is more or less the corporate usage, and my context is more or
less the individual user.
Hmm, not really since being a freelancer I have both roles even in my
business life.
Ciao, Michael.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
