Transforms are a mandatory part of processing (was RE: 991118 Tel econ Minutes)

The point I thought of but lost during the conference call was this:

If the application does not apply all the Transforms to an untrusted
resource, then much mayhem is possible.  There is potential for cases
similar to the favorite colour example I gave in another message
(http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0305.html).
I believe that performing all the Transforms on the data should be a
mandatory step of signature processing.  I have no problem with the scenario
where some of the Transforms are applied, the data is stored in a trusted
place, and then rest of the verification is completed later.  However, I see
no need to mention this scenario in the specification (and don't think we
should) since conceptually it is merely a matter of having the signature
verification process extended over time, and not a matter of an application
processing the signature differently.

-Mark Bartel
JetForm Corporation

-----Original Message-----
From: Joseph M. Reagle Jr.
To: IETF/W3C XML-DSig WG
Sent: 11/18/99 1:30 PM
Subject: 991118 Telecon Minutes

http://www.w3.org/Signature/Minutes/991118-tele.html

                     [1]IETF [2]W3C   [3]XML Signature WG

      [1] http://www.ietf.org/
      [2] http://www.w3.org/
      [3] http://www.w3.org/Signature/Overview.html

  99-November-18
  Chairs: Donald Eastlake and Joseph Reagle
  Note Taker: Joseph Reagle [[4]ascii]

      [4] http://www.w3.org/Signature/Minutes/991118-tele,text

Participants

     * Donald Eastlake 3rd, IBM
     * Joseph Reagle, W3C
     * Mark Bartel, JetForm
     * David Solo, Citigroup
     * Ed Simon , Entrust Technologies Inc.
     * Marc Pashoa,
     * Todd Vincent, GSU
     * John Boyer, UWI (regrets, couldn't get through to bridge)

   (Sorry for the teleconference problems to that didn't join.)

  Review of Outstanding Action Items

    Clean up from IETF meeting: slides/minutes < 5 minutes

     * Need slides from Boyer and Schaad
     * Boyer will send today, Schaad's were hand drawn, will check with
       him.

    Signature Syntax & Processing draft questions:

     * need someone to rewrite Parameters (and KeyInfo) such that we use
       elements like <prime>...</prime>.
     * Aside: Processing Model and reporting errors.
          + Do we need to specify a processing model whereby you
            determine what failed (signedInfo or the ObjectValue).
            Applications can do this at their option (Simon's prototype
            did) but we don't need to standardize on this.
          + ACTION: Solo, add a sentence or two security consideration
            that speaks that applications can do this sort of thing.

    Schemas &/or DTDs < 10 minutes
     * Include both.
     * Solo: IETF will likely want one to be normative. No opposition to
       DTD being normative if Schema is not stable.
     * However, people are happy with continuing to use the schema
       declarations in the body of the text as they are more expressive.

    Other questions/items from latest posted draft < 15 minutes

     * push the latest spec out to xml-dev and xml.com

    Securing Location/Transforms & Levels of indirection, Manifests,
    References, ... < 15 minutes

   ___

   Reagle Summary:
   [

   defn:DigestContent
          The content that is digested (versus earlier intemediary
          contents that are processed/transformed).

   Provoked email thread because
    1. Detected a lack of common understanding of core validation.
    2. Wanted further clarity on the assertions made is Signed Info (as
       distinguished from Manifest): Distinguish between:
         1. Does SignedInfo mean DigestValue are checked: yes! (If in a
            Manifest: no, one might take those as trusted assertions.)
         2. Does SignedInfo mean the URL must be dereferenced: no! Only
            means that the signature operates over the Digested Content.
         3. Does SignedInfo mean the Transforms must be applied? not
            necessarily. Transforms specifies a set of Content that when
            Transformed yields DigestedContent.

   To rephrase: we are not signing a URL. We are signing the Digested
   Content, and in an odd sense, the class of documents that yield
   DigestedContent when transformed in as far as those parts that are
   kept.

   ]
   __

   Bartel: Since encoding seems to be different from the other
   Transforms, propose that we move encoding into Target (as part of the
   hint):

   <ObjectReference URI=[5]"http://www.mypage.com" Encoding="UTF-8">
     <Transforms>
     ...


   Call seems happy with this.

   [Notetakers Question: Can Encoding still appear in the transform, in
   both places?]

   Reagle: say one has to dereference the URL, decode it, XPath it and
   C14Nize it., if I have a document on hand that has already been
   XPath'd but no C14Nized, can I just start it mid process?

   Solo: Yes: Signer is only saying he signed the DigestContent.
   Everything else is a hint. If an application knows it does something,
   it can pick up the chain where it wants.

   Bartel: Agrees: if an application applies some of the transforms,
save
   an intermediary step, and completes the other steps later, that is
   fine

   Reagle: The thing I'm not sure about is says there's a sequence of
   tricky transforms, could someone play a trick?

   Reagle: Is there some sort of assertion by the signer such that
"there
   is a class of documents related to this DigestConent via these
   transforms?"

   Solo: No normative assertion, in the end the you are hashing/signing
   the DigestContent, and if you don't get the right DigestValue, the
   signature obviously doesn't work.

   Eastlake: David might be too stringent, there is some sort of
   assertion about those other documents.

   Boyer: In the users context, he's looking at the thing that is
   transformed, where certain parts may change or not, not necessarily
   the DigestContent min I'm focussing.

   Reagle: I think we agree that we don't need to make major change in
   the syntax, we do need to better define the semantics of the
   assertions within an ObjectReference. Let's take this to the list,
   please propose a set of assertions that you think are made by
   ObjectReference.

   Todd: in the legal context, sill concerned about the issue of what
the
   user sees and what is signed (particularly) XSLT's. Call feels that
   the specification makes these distinctions fairly well. ACTION Todd:
   propose some text (a sentence or two) that he would like to add to
   spec, WG can then point out where it exists, or adopt.

   Boyer: Orthogonal quick question before the call ends: If you use a
   IDREF, does it include the element within which the ID sets, or only
   the element's content. Call: IDREF probably returns the element.
   Boyer: in Richard Himes' scenario, he only wants the content (because
   that is what is fed into the Base64 decoder if an encoded document is
   embedded in XML).

   Call: suspect if you want only the content, you will have to use a
   simple XPath like child::text().

   [Note taker question: is the IDREF still listed in the
   ObjectReference, and then the further qualification is in the
   transform, or does the IDREF/URI="" and the complete Transform
   follows?]

    Con calls versus Thanksgiving/Christmas < 5 minutes

     * Nov 25th is holiday
     * Dec 2nd (Reagle Jury duty), Scheduled call. On that call
       reconsider the next two.
     * Dec 9, bridge reserved
     * Dec 16 bridge reserved
     * Dec 23th Christmas Eve
     * Dec 30th Holiday

    Face to Face meeting arrangements? < 5 minutes

     * Call feels one day (a Friday) is good enough.
     * Had said January 14, looking for location near San Jose,
potential
       hosts include Verisign and Sun.
     * Solo: has asked about a location in San Francisco on the 14th,
       probably can handle 20 people.
     * Boyer: since the RSA conference ends on Thur (20), why not have
it
       on 21? (Then people don't have to loose a weekend if they are
       doing both.)
     * ACTION Eastlake: confirm when RSA ends and propose one of the
days
       (ask for RSVPs).
     * Solo's room might only be available on the 14th, doesn't know
       about 21.




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

Received on Thursday, 18 November 1999 15:58:22 UTC