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

Thanks, Joseph.  Are you going to propose one of these indirection options?  For
example, could we formalize this idea by including an optional <Resolve> tag? 
If we need this capability, I hope the spec has sufficient guidelines so that
the implementations will be consistent.

Thanks,
Rich

____________________Reply Separator____________________
Subject:    Re: Re[2]: Re[2]: ObjectReference shouldn't be signed, was R
Author: "Joseph M. Reagle Jr." <reagle@w3.org>
Date:       11/9/99 4:26 PM

Richard, thanks for your emails on this topic, I think it is driving us to
clarify a number of issues here. Thoughts follow ...

At 10:36 99/11/09 -0700, rhimes@nmcourt.fed.us wrote:
 >>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.
 
I discuss how to do it in [1] though I don't provide a syntactical proposal
(also see [2]). When I wrote [1] back in July, I even considered dropping
locations from the manifest (I'm glad this conversation finally took off!) 

However, with respect to our present design I like the requirement that you
have a URI NOT a URL. If you must, just include a random number! Now I'm not
"going charter" on you <smile> but I will say that the fact the requirements
document says that manifests includes URIs and that there is no requirement
that we provide for location invariant signatures (though Solo introduced
this as a design principle in his draft) informs my present views on what we
do. I'm of a mixed mind about dropping it, but since you can sort of achieve
that with some random number as a URN, I believe you can do what you want to
do using URIs and/or other XML (cache) applications but I presently do not
feel delivering a solution to that problem is on our critical path. (I
suspect that a lot of thought needs to be given to the protocol semantics
involved, for instance, when validating SignedInfo, if the signature
application enounters a 301 [3], is that considered non-valid?!)

[1] http://www.w3.org/Signature/Drafts/xml-dsig-design-resources-990723.html
[2] http://www.w3.org/Architecture/state.html
[3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3

 >>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.  

Here is a "pre" indirection:

<Signature xmlns="http://www.w3.org/1999/10/signature-core"> 
  <SignedInfo> 
    <CanonicalizationMethod Algorithm="http://www.w3.org/.../xml-c14n"/> 
    <SignatureMethod Algorithm="dsig:dsaWithSHA-1"/> 
    <ObjectReference Location="98"> 
      <DigestMethod Algorithm="urn:nist-gov:sha1"/> 
      <DigestValue encoding="urn:ietf-org:base64">a23bcd43</DigestValue> 
    </ObjectReference> 
  </SignedInfo> 
  <SignatureValue encoding="urn:ietf-org:base64">dd2323dd</SignatureValue> 
  <Object Id="98">
        <Resolve URN="urn:ietf:rfc959" server="http://urns.org">
          <Hint URL="http://www.ietf.org/rfc/rfc959.txt"/>
          <Hint
URL="http://info.broker.isi.edu/in-notes/rfc/files/rfc959.txt"/>
        </Resolve>
   </Object>
</Signature> 

Here is a post indirection:

<Signature xmlns="http://www.w3.org/1999/10/signature-core"> 
  <SignedInfo> 
    <CanonicalizationMethod Algorithm="http://www.w3.org/.../xml-c14n"/> 
    <SignatureMethod Algorithm="dsig:dsaWithSHA-1"/> 
    <ObjectReference Location="http://mysite.com"> 
      <DigestMethod Algorithm="urn:nist-gov:sha1"/> 
      <DigestValue encoding="urn:ietf-org:base64">a23bcd43</DigestValue> 
    </ObjectReference> 
  </SignedInfo> 
</Signature>

<trustedcache xmlns="urn:operating-system">
  <Identity>
        <ObjectReference Location="http://mysite.com">
                <Tranform>Y</Transform>
        </ObjectReference>
        <ObjectReference Location="file:/cache/aB3452xd">
                <Tranform>X</Transform>
                <Tranform>Y</Transform>
        </ObjectReference>
  </Identity>
</trustedcache>

 >We need the signature to remain valid during a process where the document
 >undergoes location changes.

Don't use a URL if you don't want to. At the FTF we've agreed to change
"Location" to "Target" at least, and maybe even distinguish and use "URI" or
"IDREF" as appropriate so as to stop confusing people as to whether it is a
URL or URI.
.

_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/