Skip to Content.
Sympa Menu

per-entity - RE: [Per-Entity] implementing a cache on the client

Subject: Per-Entity Metadata Working Group

List archive

RE: [Per-Entity] implementing a cache on the client


Chronological Thread 
  • From: "Cantor, Scott" <>
  • To: Tom Mitchell <>, "" <>
  • Subject: RE: [Per-Entity] implementing a cache on the client
  • Date: Thu, 28 Jul 2016 17:26:06 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.216) smtp.mailfrom=osu.edu; bbn.com; dkim=none (message not signed) header.d=none;bbn.com; dmarc=bestguesspass action=none header.from=osu.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

> [Apologies, I’ve realized this week that our corporate mail filters are
> stopping
> Tom Scavo’s emails to InCommon lists from getting to me. I anticipate no
> resolution.]

Can I start putting "I anticipate no resolution" in my sig? That's all
purpose.

> This seems to me to be a much larger concern. In my mind verifying the
> server is not in any way comparable to, or a sufficient substitute for,
> verifying
> the XML signature. And if a client is willing to trust the XML without
> verifying
> the signature, what’s to stop them from failing to verify the server against
> the certificate sent over TLS?

It is in fact essentially guaranteed. Most software "uses TLS" by blindly
assuming their HTTP client works right and does "stuff for security".

Tom's not wrong, though, that is in fact what they will do.

The question has always been: Do no harm? Or actively prevent it? By hosting
over http only, you can force the issue, at the cost of guaranteeing no
security at all for a wide range of software. It's a trade off with no clear
answer. The ornery side of me favors no TLS as a means of stripping people of
fig leafs, but the pragmatist says "improve security when you can" and that
standing on principle just makes your legs tired.

-- Scott




Archive powered by MHonArc 2.6.19.

Top of Page