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?
Bob Wyman wrote:
Paul Hoffman wrote:
It is much better to say "..having feeds, not people, be
associated with keys...". That is, the identifier that is
associated with the key is a URI of the feed, not a person
or company name.
You are, of course, correct. My apologies for being sloppy and
letting the "ownership" concept slip in. The correct concept is an
association between things, not ownership.
A different method would be to have multiple identities
associated with keys. My key might be identified with "Paul
Hoffman" and "http://lookit.proper.com"; and
http://saladwithsteve.com/osx/"; and so on.
This is certainly possible. However, I quite like the idea of
rooting the hierarchy in an association between keys and a verifiable
network resource. Presumably, it will be much easier for us to gather
"reputation" information concerning feeds and having such verifiable
resources at the root of the hierarchy will make it somewhat harder for
people to generate spurious keys.
Much simpler, but completely insecure. :-)... 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.
I agree. In many ways, the process of getting keys from a small
number of centralized certificate authorities may be viewed as "more
correct." However, we have decades of experience with "correct" solutions
that are simply not used. They are often elegant, but useless... If we're
ever going to get signatures in wide use, we're going to have to compromise
a bit and focus on what is practical -- not just what is technically
superior. An unimplemented solution is *not* superior, in any useful sense,
to a less elegant but implemented solution that delivers the same result.
bob wyman
