On 25/3/09 08:45, Kyle Hamilton wrote:
However, the fact that the NSS layer handles
authentication of data makes this the only logical place to bring up
these issues.
Agreed, either here or in the new policy list, iff it can be sustained
as a security policy. But I suspect not.
The reason that this appears to be the logical place to bring up the
issues is that this is the only place (AFAIK) where security
architecture is discussed. Although it might be pointed out that
such&such is a UI issue or a high level issue or a client issue or a
PKIX issue or a CA/B Forum issue ... the people on those groups do not
do think so much about the full top-to-bottom, end-user-to-server
security ramifications. And the people in those places rely on the
expertise of the people in these places to do their security.
Remember, security works best when it minimizes the disruption of
workflow. That's the key to EVERY failure to the adoption of X.509 by
the general public -- the fact that IT DISRUPTS WORKFLOW. This is why
Ian proposed an automated protocol to make it possible to enable
cryptography everywhere in the mail system, and I ran with it to
describe a possible mechanism (not specify such a mechanism, but merely
describe).
This was written about first in 1883 by a chap called Kerckhoffs, who
wrote that the security system needs to be handled by the end user with
the minimum of effort. The insight was that if there is any effort that
goes beyond some minimum that is easily undertaken under stressful
conditions, then the user will simply bypass the system and do the
insecure thing. So the security system fails completely.
Which is to say, the first requirement of security is usability.
...as such, Mozilla goes a step fuhrer and tells you correctly "hey,
we can't know if you are connecting to the site you intend to connect
to and we recommend not to connect to the site...it might be somebody
different really".
...and interrupts the workflow, thus preventing users from using the
site. The "Great Experiment" of having to have at least 4 clicks in
specific sections of the viewport to add an exception, 5 if you don't
want the exception to be stored permanently, has (to my knowledge) failed.
Yeah. Not to mention the ludicrous situation of saying:
insecure open plaintext: totally cool, dude, get some Internet love :)
unknown certificate: OMIGOD, you are SURE to be PILLAGED!
known certificate: Oh, padlock, um, yellow, no GREEN, er, white
This is why I want to be
able to use those certificates as, for example, iChat/AIM encryption
certificates.
What does prevent you from doing that? With and without CA issued
certificates?
Lack of documentation on what extensions are necessary. Lack of
integration into the keystores. Lack of easy importation of these CAs
into keystores.
Ah, keystores. I didn't want to complicate the basic proposal ... but
there is one big missing element, which is the ability to search or
aquire someone else's public key.
(I look at it this way: for every click necessary to accomplish a given
task, the chances of someone doing it are reduced by an order of
magnitude.)
I look at it this way: every click halves your market.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
