On Tue, 2012-01-31 at 17:14 -0800, Paul Lambert wrote: > >-----Original Message----- > >From: therightkey-boun...@ietf.org [mailto:therightkey-boun...@ietf.org] > >On Behalf Of Jon Callas > ... > > > >On Jan 26, 2012, at 2:55 PM, Richard L. Barnes wrote: > > > >>>>> As security engineers, our role is to (a) reduce the number of > >>>>> entities we trust; (b) reduce the extent to which we trust the > >>>>> remaining trusted entities; and (c) determine the trustworthiness > >of > >>>>> trusted entities. > >>>> > >>>> Really? > >>> > >>> Yep. > >> > >> +1 > >> > >> One of the better definitions I've heard. I would question whether > >(c) is even in scope; seems like a relying party function. > > > >We should run screaming from (c). Not only do there be dragons there, > >but there be dragons even in saying what "trustworthiness" means. Surely > >this is not a real-world reputation system. > > > > Jon > > Yes! ... but, we can define "who we trust for what" ... who being a key, what > being some Domain of Discourse with appropriate constraints. > > Trustworthiness as a probability or metric yields contradictory and > nondeterministic evaluations. > > Paul
Paul, is this necessarily bad?
All three statements above are sort of correct IMHO. A slight
modification:
"As security *protocol* engineers, we have to [...] and (c), give the
users the capacity and ability to enforce their own trust-policies, for
their own purposes, according to their own desires."
Let's go deeper.
I (still, thankfully!) have the ability to remove root CA's from
my /etc/ssl/cert when I see fit to do so. And I do so. But it's
extremely cumbersome and obviously "does not scale". Let's do better?
Obviously, not all users on the planet can by decree of a small group be
mandated to verify trust in the same manner, at least not very
successfully. The choice of what you want to trust has always been
there.
From this I can't say that I either fully - or not at all - trust any CA
in my root-cert store on an individual basis -- some are even there, not
because I trust them indefinitely, but because of a combination of
a) my browser becomes full of extra clicks without them,
b) they do provide a varying-but-greater-than-zero % expectation that a
TLS-connection that validates to them can be reasonably expected not to
also be MITM:ed somewhere.
This doesn't mean *I* have 100% trust in any of them. These are
different things.
Adding to that: having multiple inputs to your trust policy generation
engine, as has been discussed here, can't possibly hurt the objective
here? Similarly, having an output from this trust resolution engine
that motivates its calculation (according to your policy), can't hurt
either?
configuration bar = list of various input sources;
trust_policy_compile(policy foo, configuration bar) ->
trust_resolve_data[policy=foo]
(Policy and configuration may actually just be one and the same.)
Obviously, a computer program wouldn't work very well if a 67% trust
implies that it should proceed with a computation in 67% of the
instances:
The validation result through my trust verification engine using
policy X ought to be that I either can (based on my policy!) proceed
with the computation, or, that I have to abort it because of a lack of
trust.
validate_with_policy(trust_resolve_data data, policy foo, certificate
bar) -> (valid|invalid, {details})
The policy can define things such as, a >X% fail-rate from
convergence/observatory (using convergence/observatory-configuration
foobar...) -> invalid cert verification, and list of root-CA's, etc.
Note that this does not at all exclude putting multiple certificates in
the handshake! That seems smart, for those who can afford the extra
bytes transferred.
So, perhaps having browser vendors and operating systems declare who The
list of trustworthy entities according to their Process is, is not the
best solution for all purposes? Having defaults is fine, I guess, but
for all I care this entire apparatus could (successfully, overall, I
bet) be externalized to institutions dealing more solely with trust, and
individual users would then get the option to choose between these. The
feedback-loop this could provide is not without merit.
For example, there appears to me to be a natural place for someone to
define these foo's, that users can use. And also [inputlist]
configurations.
Offline, people trust different things. Would there be a
protocol/standard/method to model this in a more scalable way online, so
much better, I think.
Best,
Martin
signature.asc
Description: This is a digitally signed message part
_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
