RE: ID Mapping

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
>

Received on Monday, 23 August 1999 11:58:55 UTC