On 11/6/2013 6:09 AM, Ted Lemon wrote:
I assume that what we want is a mechanism for authenticating the
content; in this case there is no need to encrypt the content. We
are just talking about HTTPS because no mechanism exists to do the
one without the other. So the problem you are talking about, which
I agree is real, is simply evidence of a missing feature; maybe that
is where this debate ought to go.
G'day.
I'm glad this discussion has distinguished between wanting content
authentication vs. content confidentiality. While some uses of https
can do both, it's good to note that a) it can't do only authentication,
and b) requiring https prohibits many current, legitimate scenarios.
I take this state of affairs -- combining the goal of authentication
with a desire to preserve an extensive operational base -- as meaning
that we need to create something to solve the problem. This would, of
course, mean that participants in the new mechanism do need to adopt new
software, but it also would mean that non-adopters do not -- and won't
be bothered by the presence of the signature, if it's packaging is
designed properly.
There happens to be a solution lurking close by, just the other side of
this door... The door is marked "transparent authentication of content".
The base technology is DKIM:
http:dkim.org
which affixes a signature using a special header-field to email. The
signature is transparent to any engine that doesn't recognize it,
including human readers who are typically being shown a common subset of
the full email header.
(DKIM semantics do not match the authentication goal here. It uses
authentication technology, but it uses it only to authenticate an
identifier it affixes to the message; the presence of that identifier
means that its owner of the identifier is taking 'some' responsibility
for the message, not that the owner is certifying the content or
claiming ownership of the content. So my suggestion is about underlying
DKIM technology, not DKIM itself.)
The mechanisms of DKIM could be rather easily adapted to provide content
authentication semantics, with the signature carried in a header field.
It would therefore provide authentication for any web client that
upgraded and would be transparent to others.
There's been an effort to define a flexible version of this underlying
mechanism, for just this sort of adaptation. It's called DOSETA:
http://www.trusteddomain.org/doseta.html
This leaves some real engineering work to be done, but provides a very
high point of departure for solving the problem of content
authentication that does not bother the legacy installed base.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net