On Wed, Feb 18, 2009 at 7:05 AM, Lindsley Brett-ABL001 < [email protected]> wrote: > One issue in particular is handling *signed* > entries. Any modification to the entry breaks > the signature. One thought I had is to use > foreign markup to indicate the aggregation chain, > but to exclude the foreign markup in computing > the signature. This is essentially the approach that I argued for when this was debated years ago on this list. The idea is to define some new element that is used to encapsulate annotations. Additionally, the entry canonicalization rules for Atom would be modified to require that the encapsulated data should be removed from the entry prior to signing or signature verification. Unfortunately, at the time this was discussed on the list, there was little understanding of why it was even useful or reasonable to sign Atom entries. Thus, proposals that made signature processing any more complex than it already was were not received well. Perhaps now that we've got more people using Atom and more folk understanding the utility of signatures, we can get such an extension accepted.
> Of course, this then begs the issue of > authenticating the aggregation information... Clearly, if one goes to the trouble of defining a new element and extended canonicalization procedures, one should also ensure that: 1. There is a way to sign third-party annotations 2. The annotations can themselves be annotated and such annotations would be excluded via canonicalization from the signing of their parent. The remaining problem comes in defining a means to allow an annotation to be composed of several signed annotations which are themselves included in the signature of a parent... This gets complicated.... bob wyman
