Re: ID Mapping

Yes, this solution addresses the case where the elements are from diverse
origins, for example, a summarization of legal events from different historical
documents.  If the application has enough information at the time of the
signature, it can eliminate ambiguity.  If it doesn't have the information,
there will be a conflict.  So the question becomes whether or not requiring all
signed elements to have a unique permanent ID is too restrictive.  There are
hacks, but they will be implemented as inconsistent or proprietary solutions
unless it is addressed in the standard.

Thanks,
Rich

rdbrown@Globeset.com wrote:

> Rich,
>
> I do not think that we should address this problem at the xmldsig level and
> would rather let the upper layer defines an adequate naming-scheme. This is
> the position adopted by IOTP.
>
> However, this implies that all the elements being combined have been
> originated by a same application (true in most circumstances). When the
> elements are from diverse origins, I tend to feel that the application
> consists of an 'interchange' (xMail :-) and, in such circumstances, would
> promote encoding and packaging.
>
> Sincerely,
>
> Richard D. Brown
>
> > -----Original Message-----
> > From: w3c-ietf-xmldsig-request@w3.org
> > [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Richard Himes
> > Sent: Thursday, August 19, 1999 12:27 PM
> > To: w3c-ietf-xmldsig@w3.org
> > Subject: ID Mapping
> >
> >
> > I posted this problem recently and didn't get a response, so I'm
> > guessing it hasn't been addressed.
> >
> > Suppose that there are two (or more) signed elements in two (or more)
> > different documents, that they are signed by local reference (href to
> > #id), and that they are to be combined to form a new
> > document, perhaps a
> > legal document that has collected a history of signed events for a
> > brief.  Suppose further that it is inescapable that, in general,
> > duplicate ids will result, which is not well formed XML (and confuses
> > the signature algorithms.)  These ids will have to be
> > renumbered, which
> > will break some of the signatures.
> >
> > I believe we should include a mapping element for each affected
> > <Signature> element, which is outside the manifest (not
> > signed), such as
> >
> > <IdMap>4=1 5=2 6=3</IdMap>
> >
> > Thus, if this signature signed  elements with id='1', id='2',
> > id='3' in
> > the original document, and these ids had to be changed to 4, 5, and 6
> > respectively in the combined document, the map would allow the ids (of
> > these pieces) to be converted back to their original state for
> > authentication.  AFAIK, the map would be unable to "lie" (breach
> > security) and still obtain valid signatures for the
> > referenced elements.
> >
> > Thanks,
> > Rich
> >
>
>   ------------------------------------------------------------------------
>                     Name: RFC822.TXT
>    RFC822.TXT       Type: Plain Text (text/plain)
>                 Encoding: base64
>              Description:

Received on Wednesday, 25 August 1999 15:01:36 UTC