atom authenticity

[Alex Russell <alex@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 
Atom content.

The Problem:
- ------------
People lie.

Problem Detail:
- ---------------
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?

- -or-

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 
spammed"?

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 
missleading message.

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 
following charachteristics:
	- 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
		them.
	- 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?

Regards

PS: please excuse my spelling, KMail has decided that it doesn't want 
to spell check this message.

- --
Alex Russell
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)

iD8DBQFAX2NtoV0dQ6uSmkYRAuVIAJsFycz6GCYDWxUeJ7WdgTRjbfO8hQCeMpnw
avm7+7KUx/JSD1BYswvFvbA=
=qXkO
-----END PGP SIGNATURE-----