-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/31/2010 12:32 PM, Perry E. Metzger wrote:
> 1 If you can do an online check for the validity of a key, there is
> no need for a long-lived signed certificate, since you could
> simply ask a database in real time whether the holder of the key
> is authorized to perform some action. The signed certificate is
> completely superfluous.
>
> If you can't do an online check, you have no practical form of
> revocation, so a long-lived signed certificate is unacceptable
> anyway.
In general I agree with you, in particular when the task at hand is
authenticating individuals (or more to the point, Joe
Sixpack). However the use case of certificates for websites has worked
out pretty well (from a purely practical standpoint). The site owner
has to protect their key, because as you say, revocation is pretty
much non-existent.
> 2 A third party attestation, e.g. any certificate issued by any
> modern CA, is worth exactly as much as the maximum liability of
> the third party for mistakes. If the third party has no liability
> for mistakes, the certification is worth exactly nothing. All
> commercial CAs disclaim all liability.
>
> An organization needs to authenticate and authorize its own users;
> it cannot ask some other organization with no actual liability to
> perform this function on its behalf. A bank has to know its own
> customers, the customers have to know their own bank. A company
> needs to know on its own that someone is allowed to reboot a
> machine or access a database.
This is one of the issues driving "Federated Authentication." The idea
being that each organization authenticates its own users (however it
deems appropriate) and the federation technology permits this
authentication to be used transitively. I view federation as still in
its infancy, so there are plenty of growing pains ahead of us.
As an aside... a number of years ago I was speaking with the security
folks at a large financial organization which does business with
MIT. Their authentication approach was pretty lame. I asked them if
they could instead accept MIT client certificates. They had a simple
question for me. They asked me if MIT would make good if a transaction
went bad and the "badness" could be attributed to us
mis-authenticating someone. I said "No". They said, well, our
authentication may be lame, but we stand behind it. If someone loses
money as a result, we will make them whole. And there you have it.
> 3 Any security system that demands that users be "educated",
> i.e. which requires that users make complicated security decisions
> during the course of routine work, is doomed to fail.
>
> For example, any system which requires that users actively make
> sure throughout a transaction that they are giving their
> credentials to the correct counterparty and not to a thief who
> could reuse them cannot be relied on.
>
> A perfect system is one in which no user can perform an action
> that gives away their own credentials, and in which no user can
> authorizes an action without their participation and knowledge. No
> system can be perfect, but that is the ideal to be sought after.
Completely agree. One of the appeals of public key credentials, notice
that I didn't say "certificate" here, is that you can prove your
identity without permitting the relying party to turn around and use
your credentials. I call this class of system "non-disclosing" because
you do not disclose sufficient information to permit the relying party
to impersonate you. Passwords are "disclosing"!
We do not require drivers of automobiles to be auto mechanics. We
shouldn't require internet users to be security technologists.
> 4 As a partial corollary to 3, but which requires saying on its own:
> If "false alarms" are routine, all alarms, including real ones,
> will be ignored. Any security system that produces warnings that
> need to be routinely ignored during the course of everyday work,
> and which can then be ignored by simple user action, has trained
> its users to be victims.
>
> For example, the failure of a cryptographic authentication check
> should be rare, and should nearly always actually mean that
> something bad has happened, like an attempt to compromise
> security, and should never, ever, ever result in a user being told
> "oh, ignore that warning", and should not even provide a simple UI
> that permits the warning to be ignored should someone advise the
> user to do so.
>
> If a system produces too many false alarms to permit routine work
> to happen without an "ignore warning" button, the system is
> worthless anyway.
I learned about this from a story when I was a kid. I believe it was
called "The Boy who Cried Wolf."
> 5 Also related to 3, but important in its own right: to quote Ian
> Grigg:
>
> *** There should be one mode, and it should be secure. ***
>
> There must not be a confusing combination of secure and insecure
> modes, requiring the user to actively pay attention to whether the
> system is secure, and to make constant active configuration
> choices to enforce security. There should be only one, secure
> mode.
>
> The more knobs a system has, the less secure it is. It is trivial
> to design a system sufficiently complicated that even experts, let
> alone naive users, cannot figure out what the configuration
> means. The best systems should have virtually no knobs at all.
>
> In the real world, bugs will be discovered in protocols, hash
> functions and crypto algorithms will be broken, etc., and it will
> be necessary to design protocols so that, subject to avoiding
> downgrade attacks, newer and more secure modes can and will be
> used as they are deployed to fix such problems. Even then,
> however, the user should not have to make a decision to use the
> newer more secure mode, it should simply happen.
Yep.
-Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFMVMG18CBzV/QUlSsRAjB/AKDlTsLgnEa0A9ahKiGtFBCBIQncowCg3/pI
WXegkQraFeSAmv9BiOgKZhE=
=4mAS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
