[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
-----BEGIN PGP SIGNED MESSAGE-----
I've been watching the list for about a week with some trepidation at
suggesting this, but it seems to me that Atom needs to make some
provision for being able to guarantee that a trusted agent generated
Lying is often profitable, reducing the ability to lie (shorthand here
for "abuse trust") in a programmatic and near-zero-cost fashion is
key to keeping Atom from being used as a lie-broadcast mechansim.
XML and most syndication syntaxes to date make very little note of
and affordances to accomidate the problems of trust and trust
management. At least one of Atom's intended purposes is as a
syndication format for widespread dissemination of content from a
single location, often in a repeated fashion. This repeating of
syndicated content through Atom and non-Atom formats presents an
oppourtunity to lie (abuse trust) at near-zero incremental cost.
Imagine an application where an application developer (we'll call her
Alice) at Another Oligopolistic Leviathan Inc. wants to incorporate a
news feed from the Commedic Ninnies Network website, but would like
to be able to ensure that the content is covered by the content
sharing agreement the corporations have negotiated (and not the wire
services). How to gurantee this?
Imagine another scenario in which Bob, a bulk email originator of ill
repute, decides that email just isn't working well enough for him.
Bob decides that what he's going to do is get his spam gang in Brazil
to stop hacking zombie relay boxes and start hacking web servers,
looking for atom files on disk. They then replace the files on disk
with their Atom feed outlining how to enlarge various bodily organs.
Now imagine that process being automated (think worm). What's to keep
the newsreaders of thousands of people from getting "aggregator
Clearly, Atom presents some interesting oppourtunities for expressing
existing trust relationships for mutual benefit.
In the case of Alice's problem, if the reporters sign their posts with
a key issued by the corporate PKI (or their tools do it for them),
she can easily discern which posts should be let through, thereby
also insulating her from attacks against the wire services.
In Bob's case, Charlie (our blog reader) can check that Delores (our
blog author) has GPG signed his post, and therefore ignore Bob's
Authenticity is a hard problem, but there are some mechanisms which
can be used to start to address it.
Problems Not in Scope:
- authorization (who can add something to a document)
- availability (making sure that everyone can get to it all the time)
- authentication (who gets to read it)
Charachteristics of Good Solutions:
While I don't have a fully-formed solution after several weeks of
turning the problem over in my mind, I would like to propose that
reasonable and workable addition to the Atom spec may have to
- auth system agnostic.
The Atom API as currently drafted is silent on the point of
authentication mechanisms. I beleive that this is wise.
- allows both PKI and organic trust mechanisms
GPG/PGP spring to mind as initial trust declaration mechanisms, but
I don't realisticly expect that all newsreaders and blog authoring
systems will suddenly get GPG-clued. PKI is likewise a middling
solution, but one that can be rolled out by blog and content
authoring system vendors a bit more easily.
- lightweight syntax
The XML-Signature specifications are (IMHO) too heavy. While
extensibility is good in many cases, I beleive that if
authenticity-ensuring mechanisms are to be implemented widely,
that a small set of sane and conservative options must be codified
by the spec with the least ammount of syntax required to represent
- must also extend to metadata
Interesting attacks are possible not only against message contents,
but also against their metadata. Consider DoS via timestamp
manipulation or spamming via summary sections.
- support must extend through the API as well as the format
I fully expect a TFH to emerge out of this suggestion, topics for
which will likely include:
- if this is something Atom should deal with
- key management
- PKI vs PGP
- signing format
- hash algorithm choice
- normalization of whitespace for signing
Any I'm missing?
PS: please excuse my spelling, KMail has decided that it doesn't want
to spell check this message.
alex@xxxxxxxxxxxx BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
alex@xxxxxxxxxxxxxx F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
-----END PGP SIGNATURE-----