On Wednesday, May 25, 2005, at 06:14 PM, James M Snell wrote:
Ignoring the overhead that it adds for now, isn't this the kind of
situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures
in the near term (and more importantly, how many aren't?), and who
knows how many consuming applications will support them. Until digital
signatures start providing more help with this kind of thing, let's
provide a warning to developers so that they can at least consider what
they might do to safeguard the quality of their users' experience.
And I just thought of another thing (I don't know how digital
signatures work in this case, so I may be missing something, but I'm
pretty sure the following is at least partially valid): if I get an
entry with a valid digital signature and one with no signature (both
with the same atom:id, of course), then what? Do I always accept the
one with the signature? If so, then DOSing/spoofing unsigned entries
will be even easier, because all you'd have to do is sign your fake
entry. So even in that case, some extra checking might have to be done
before concluding that the entries are duplicates, and that the
unsigned one is the one that's disposable.
Without any kind of cryptographic guarantee of this sort, the best you
could do is make an educated guess.
Wouldn't that be better than nothing until digital signatures become
more ubiquitous?
Would it make sense to include some language along these lines?
Sure.
