On Mon, 15 Apr 2013, MFPA <expires2...@ymail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Monday 15 April 2013 at 2:54:19 AM, in
<mid:pine.neb.4.64.1304142149510.15...@panix3.panix.com>, Jay
Sulzberger wrote:
What telephone number, what email address should I use
to help me make the decision as to whether to "trust
the site"? Whom should I speak to? What method do you
recommend to help me make the right decisions?
You could look at the certificate your browser doesn't trust and
follow up the information it contains. You could also search the
internet (and other sources) for information about Intevation GmbH,
and see if it matches what the certificate says. Depending how
paranoid, you could even turn up at their offices and ask relevant
questions.
Decide on the trust level you wish to establish for your intended use
of the site. Then take whatever precautions you think are commensurate
with that level of trust.
Blindly clicking to dismiss the browser's "untrusted" warning is
arguably no more irresponsible than blindly having the browser accept
a certificate signed by a "certification authority" it recognises. I
suspect if you were to look at the list of CAs trusted by your
browser, you would encounter plenty that you see no reason to trust.
- --
Best regards
MFPA mailto:expires2...@ymail.com
MFPA, thank you for a very clear and useful answer!
I have just now read the Wikipedia article on X.509 and the article on SSL:
http://en.wikipedia.org/wiki/X.509
[page was last modified on 12 April 2013 at 06:34]
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
[page was last modified on 18 April 2013 at 09:31]
I read the standard documentation once, but I read it many years
ago, and I never wrote any code, nor ran any simulations of how a
"network" of X.509 certificates might work. There is much to
think about here.
Here is a short version of what I think is a good question:
Many people buy stuff from Amazon and other
companies/organizations/people by communicating over the Net.
For explame, people use credit cards. I believe that certain
data is in transit between the buyer and seller, and the reverse
too, encrypted, using as part of the communications stack SSL
(actually TLS nowadays, I think). I have the impression that
many people learn how to buy stuff by this method, that is, using
a credit card with SSL in the stack. But learning to use GnuPG
seems much harder to most people who have learned how to buy
stuff using a credit card over the Net.
Here are some pieces of my question:
1. Is the stack used for credit card use over the Net sufficiently "secure"?
Indeed this question is ill defined: "secure" for what, against what?
2. In what ways does the problem of email encryption differ from
the problem of encrypting credit card and other money-valuable
data in transit, with http as the transport protocol?
3. If the stack used for credit card use over the Net is good
enough for most purchases, could we use a similar stack to secure
email in transit? In particular, could we use a similar stack,
with a similar ease of learning and ease of use, as perceived by
most of the people who today buy stuff using a credit card over
the Net?
oo--JS.
Change is inevitable except from a vending machine
-----BEGIN PGP SIGNATURE-----
iQCVAwUBUWx6O6ipC46tDG5pAQqxxwP8CIH5zx1y7Q2aO0ARlVmKdfJKElUodhkC
KyWZNH7diu9OhbEMGQyPc9/YR9lGCRp3jlZ6IvJUlYY3Xo5oon+A+cElh7eH2Gyk
taNaPSU8B61Ih9LorAN3uuOWD8Xzbug6zXNFjLXFSfZPwN3aQStT7aYLQ7XE5DhX
yB3NBgyoqSg=
=4gaV
-----END PGP SIGNATURE-----
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
