Re[2]: Re[2]: ObjectReference shouldn't be signed, was RE:

>How do you make an assertion sans location semantics, such that:

>        B: some object when found and transformed yields the 
>        following DigestValue  ?

>I think this is a valid question. We have a requirement to identify 
>objects via URIs. The URI need not be a URL. (In fact, I think the 
>DigestValue is a good URI). We could relax that requirement and remove 
>"Location" from the signature and only provide it as a resolution hint; or 
>we permit a level of indirection pre/post signature creation. Pre: 
>ObjectReference uses some mechanism such as a directory, URN, manifest 
>etc. that provides resolution.

>Post: you allow a "redirect" or "cache" statement to be associated with 
>the signature that states "the URI found in ObjectReference resolves to X"

I'd like to see samples of these approaches.

<snip/>

>If the fact that those statements were found at www.gigacorp.com was not
>part of the semantics you wanted to be bound by (and I agree with Phillip
>that some people do want to assert this) I'd recommend using an IDREF as 
>the URI of the resource that is digested, and the IDREF points to an 
>object in the signature which includes "hints" for finding and resolving 
>content.

I think I agree, but again, I need to see an example.  

I should back up a little and address the specific point that John Boyer raised,
because there might be a better solution than moving the transform out of
SignedInfo.  I do believe we need to find a way to allow the location to reside
outside SignedInfo.

Federal and state courts are now working together on an electronic filing
standard which involves filing documents over the Internet.  During
transmission, the document would be embedded in an "electronic envelope".  For
now (until it is possible to get common word processors to produce WYSIWYG XML
documents), we are transmitting PDF documents with basic identifying and
processing information carried in XML tags.  We need to allow signature on the
unencoded PDF (by attorneys, litigants, etc.), even though it is carried base64
during transmission.  The final URI will be assigned on arrival at the court,
and the PDF will be written in its native format to the document management
system (DMS).  

We need the signature to remain valid during a process where the document
undergoes location changes.  In stage 1, the signature is applied to the PDF
(temporary URI?).  In stage 2, the document is inserted in the envelope
base64-encoded (internal IDREF?).  In stage 3, the document is written to the
DMS in its unencoded (native) format and a "permanent" URI is assigned.  In
future stages, the document may be transferred to the Court of Appeals or
elsewhere and again undergo a URI change.  Note that the signer and consumer are
different entities, and we need persistent signatures during this process.  It
is unlikely that we would get the bureaucratic inter-agency cooperation needed
to assign a permanent URI to these documents.  A similar situation will probably
occur in other problem domains.

Perhaps we could keep Transform* inside SignedInfo, but give one of the
transforms a clue that "If the content is base64, then decode it" (I'd like this
to specified as a required-to-implement transform).  I believe location should
be outside SignedInfo, but we need to be able to find it.  My preference is that
it be outside SignedInfo, but inside Signature.  Maybe we could point to it by
IDREF or positionally (Location* maps to ObjectReference*)

Thanks,
Rich

Received on Tuesday, 9 November 1999 12:37:45 UTC