Re[2]: Omitting Location and Transforms from SignedInfo

>> This is quite problematic.  Our core processing rules state that we 
>> verify SignedInfo, then we verify the digest values of the 
>> ObjectReferences.  HOW IS CORE BEHAVIOR GOING TO DO THIS IF CORE 
>> BEHAVIOR DOESN'T KNOW HOW TO RETRIEVE THE DATA?

> I am still wondering if this is a typical case. How often do you find a
> signature somewhere on the floor where you then need to get the data you
> want to verify? Most of the time you will get the signature with the data
> anyway. Somtimes you will have the data and look for a signature. And 
> then, any name is sufficient, need not be a location in the first place.

> Peter

It really concerns me that there is so little concern about locating objects. 
Sounds like we are supposed to give the document some permanent
location-independent name and some magic outside our specification will be able
to find it (not our problem).  Maybe I could have
US_District_Court_of_New_Mexico.CourtFiling.Case_98cv123.Document_123
which would give me a unique global name for one of our filings.  Now do I need
to register this name with some global naming authority that will keep track of
the current official location? Is the official location the District Court?  Was
it handed over to a certified vendor that handles storage?  Is it officially at
the Court of Appeals?  Sent back to state court (incidentally with a different
case number invalidating the "permanent" name).  Is it in the National Archive? 

Is a floating location any better?  Suppose I keep the bare signed XML in an
object database and store huge signed multi-megabyte scanned documents on a file
system.  I would like to be able to move the huge files without breaking the
signature, or have an audit trail of the moves in XML (e.g. in RDF), even if
they are archived, etc.  So, it was suggested that we could leave the frozen
bad-location signatures as-is and just kludge a tag that says it has moved (no
formal proposal has been incorporated.)  How will validation engines support
validation, now that they can't find the document automatically through the
<Kludge> tag?  Not our problem again?  Yes, it is, because we created the
problem and have glibly said it isn't ours, or that it isn't even a problem.  To
me, this isn't an academic exercise.  I'd appreciate it if someone could clarify
a viable solution that works with our spec.  The problem is the need for:

an XML document containing "permanent" valid signatures that reference (internal
or) external documents which will change location and the likelihood of
off-the-shelf software that will be able to verify those signatures by being
able to easily locate those documents and verify the signed hashes.

Thanks,
Rich

Received on Wednesday, 17 November 1999 09:44:09 UTC