Sounds good.. interested in working up some text for that ;-) On Tue, May 25, 2010 at 4:29 PM, Bob Wyman <[email protected]> wrote: > I'm a bit worried about a potential "security" concern if people overuse the > hash attribute. This is something that really should only be used when you > really need to refer to a specific version of a resource -- and it should be > a resource that you expect to be stable for a useful period of time. My > concern is that people will tend to think that it is "cool" to add in more > metadata on links and thus will just hash all kinds of stuff -- because they > can. The result will be a large number of "broken" hashes and a sense that > since most hashes are broken, the fact that a hash is broken is simply not > interesting... At that point, various social engineering operations become > possible. > We really should consider discouraging people from using the hash attribute > unless it is really necessary and unless they actually expect that the > resource they are hashing *should* be stable for a usefully long period of > time. > bob wyman > > On Tue, May 25, 2010 at 5:06 PM, James Snell <[email protected]> wrote: >> >> I've been considering either an "accessed" attribute or specifying >> terms that indicate that atom:updated element be used as the >> point-in-time for the links for atom:entry and atom:feed. The when >> attribute would serve the same purpose for at:deleted-entry and I >> assume that other containers for atom:link could specify their own >> relevant time. And you make an excellent point on focusing on the >> specific utility of the attributes. Are there are security concerns >> you can think of relating to the specific use cases for these >> attributes? >> >> On Tue, May 25, 2010 at 12:52 PM, Bob Wyman <[email protected]> wrote: >> > The way you describe the utility of the hash, you make it sound like it >> > is >> > somehow "inadequate" for the traditional use of hashes. But, that's not >> > really relevant here. This is a use of a hash for a different purpose >> > than >> > the hashes we normally use in link integrity checking. I would suggest >> > that >> > you focus on the utility of this style of hash rather than emphasizing >> > the >> > things that it doesn't even attempt to do. >> > BTW: I realize that this may be totally unnecessary, however, I can't >> > help >> > thinking that a "last-accessed-on" attribute to show when the link was >> > last >> > accessed and thus when the hash was generated might be useful... In >> > nothing >> > else, there is a good bit of precedence in things like formal standards >> > for >> > citing web resources that typically require that a "last-accessed" date >> > be >> > provided. I'm not willing to invest a great deal in fighting for this. I >> > just thought I would mention it. >> > bob wyman >> > >> > On Tue, May 25, 2010 at 3:07 PM, James Snell <[email protected]> wrote: >> >> >> >> Ok, so I'm working on finishing up the basic link extensions draft. >> >> The Security Considerations are currently TBD. I wanted to take a >> >> moment to solicit input on appropriate security considerations for >> >> these optional, advisory extension attributes. >> >> >> >> One in particular... hash digest are often used as a simple means of >> >> verifying that data has not been modified while in transit.. hash >> >> digests contained within an atom:link cannot be used for that purpose. >> >> Rather, the hash attribute is used to express the state of the linked >> >> resource at a given point in time so that a feed consumer can detect >> >> whether or not the resource has been modified since the link was >> >> created. >> >> >> >> Other than that, there really shouldn't be any further security >> >> concerns with regards to the link extensions.. but I welcome being >> >> corrected on that :-) Thoughts? >> >> >> >> -- >> >> - James Snell >> >> http://www.snellspace.com >> >> [email protected] >> >> >> > >> > >> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> [email protected] > >
-- - James Snell http://www.snellspace.com [email protected]
