Tim wrote, On 03/30/2009 12:51 PM:
That sort of decision would be based on popularity (a problem you'd like
to see overcome, and could be overcome, given enough of a push, but
whether we have the numbers is another matter), and whether the
certificate authority is effective enough to support (i.e. why add any
root certificate that proves very little).
Then there's trying to convince organisations to use less trust worthy
root certificates. Who wants their service to be flagged by web
browsers as "encrypted but a bit risky"?
It's perceptual, and ignoring the fact that existing, apparently better
certificates, are currently used by some services that don't prove who
they are any better than the lesser known root certificates. But that's
the point of certificates - how things *look* to the casual observer.
It is too bad we can't (as currently implemented) take a slightly less brutal
tact than Mr. Wolff has suggested.
i.e., sure all the root CA's that the browser producers want to include can
come in, but they should have trust DBs that allow each user to tick:
* Never trust this key. (and by extension anything it has signed. Perhaps with
a pop up indicating 'the sig is ok, according to bla, but bla is a known idiot.')
* Marginal trust. (pop up something saying 'the sig is ok, according to bla,
but you are uncomfortable with bla.')
* Fully trust. (operate as CA's in web browsers since they started getting CA's.)
And by default (as released by the browser producers) the keys should be set
to either Never or Marginal.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
