Tim Bray wrote:
On May 27, 2005, at 11:23 AM, James M Snell wrote:
In general, the idea of associating the signing keys with the
network resource (feed or entry document URI) makes a lot of sense
but I think there may be some issues there with aggregate feeds and
intermediaries (e.g. Feedburner) that would need to be worked out.
In any case, this is definitely something that should be worked up.
If there is interest in coming up with a ID on the topic, I
volunteer to help write it up. The question is whether or not this
list is the right place to discuss extensions like this or whether
we should take this offline?
I think that this list is the perfect place to discuss this stuff,
the people who care are here.
Also, until we get AtomPubIssuesList cleaned up and the format I-D
filed, the WG is kind of between tasks, so now is a good time. -Tim
Excellent.
Ok, so given that, continuing on what Paul and Bob have already put forward:
Associating the keys with the feed rather than with the individual is
goodness. The issue of how we establish trust of those keys is going to
be the sticking point (as always).
>> * The much simpler method of the feed including an extension element
>>that identifies its signing keys -- it could either point to a file
or to a
>>key server.
>Much simpler, but completely insecure. :-) It's a self-signed
attestation that
>has to be verified by out-of-band means that, from a security
standpoint, are
>equivalent to the first if done right and horribly dangerous if done
wrong.
>Having said that, I support the latter more than the former, and believe
>that >90% of signed feeds that people actually use will follow that
model.
Agreed that the second approach is better, but both approaches should be
supported (that is, it should still be possible to use certificates
issued by a centralized CA). Can we articulate the right and wrong ways
of doing the second option?
Other important questions that need hashing out (just throwing these out
as I think of 'em for discussion)
1. What is being signed? In a feed document, is it the entire feed, the
collection of entries as a whole, individual entries, entry metadata,
etc. and where does the signature go?
<feed><entry/><signature/></feed>? <feed><entry><signature/></entry></feed>?
2. What is the purpose of the signature? That is, is it saying "This
feed/entry really was generated by x" or is it saying "This entry really
did come from source x". If the latter, how do we authenticate the
origin of "source x"?
3. What about aggregate feeds (e.g. feeds produced by intermediaries
that contains entries from multiple sources, some set of which may have
already been signed by the source generator).
4. How should intermediaries handle signatures? For example, what
should happen if someone asks Feedburner to augment a digitally signed
feed? Is FeedBurner a client that is generating a new feed from the
source original (and therefore may or may not be required to produce a
new signature) or is FeedBurner modifying the existing feed and required
to pass along the existing signatures in tact?
5. What are the validation requirements? How should clients handle
feeds/entries that don't validate?
- James
