W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

Frag ID's in URI, was RE: Minutes 99-October-28

From: John Boyer <jboyer@uwi.com>
Date: Thu, 28 Oct 1999 11:35:45 -0700
To: "Joseph M. Reagle Jr." <reagle@w3.org>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIIENMCBAA.jboyer@uwi.com>
Hi Joseph,

Yes, I remember why we don't just do fragment IDs as it has been the subject
of a number of archived emails.  It's not that we can't do it, it's simply
that it is insufficient as well as harder to implement.

1) Insufficient

It may be necessary to apply transforms such as base64 decoding before the
fragment is applied.
Thus, we certainly need fragment identification as a transform, making the
URI-reference redundant (see my upcoming letter on not signing Location).

It is quite fine with me to use Location="" to indicate 'this' document,
then to have an XPath, XPointer or other transform to refine 'this'
document.  This is what I thought would be done.

2) Harder

A transform identifies the algorithm to be applied to the data, and the
fragment appears in the transform content.  If the fragment does not match
the syntax for the algorithm, error.  If the input data does not match the
syntactic requirements of the algorithm, then error.

A URI-reference provides the fragment, but the choice of algorithm is made
based on the type of the input data.  But what if more than one type of
fragment can be applied to a given document?  One must refine the choice of
algorithm by trying to parse the fragment with various algorithms until no
error occurs.  These errors then have to be distinguished from errors in
parsing the input data.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company



-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Thursday, October 28, 1999 10:42 AM
To: IETF/W3C XML-DSig WG
Subject: Minutes 99-October-28


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

  99-October-28
  Chairs: Donald Eastlake and Joseph Reagle
  Note Taker: Joseph Reagle [[4]ascii]

Participants

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

  Review of Outstanding Action Items

Agenda

     * Misc
       For encoding issues, why not just use Base64 for SignatureValue
       and DigestValue. Solo: one day, the resulting might be XML CDATA,
       but till then, the algorithms that we use need to be encoded and
       Base64 makes sense. Call agrees to define encoding for those two
       values as Bas64.
       We shouldn't appropriate the control of other institutuional
       namespaces, we should move back for dsig:foo for the short term
       until we resolve the issue satisfactorily.

     * Location - < 10 minutes
       Leave an attribute but change name to HREF?
       Make an element with an HREF attribute?
       Make an element with URI content?
       Is it mandatory to support a non-null Location?

       List proposal to allow the location to exist outside of
       SignedInfo. Call wants to keep location in the signature, it is a
       URI (not necessarily a URL) and the call prefers the employment of
       redirection/indirection through URIs not this syntax.
       Leave <ObjectReference Location="http://www.ietf.org"> as is.
       Define null-location as <ObjectReference Location=""> as referring
       to this document, must be supported. Do we extend it to mean
       "#ID". No: Location is URI (including null) or IDREF.
       (Can anyone remember the reason why we just don't use
       FragmentIDs?)

     * Field ordering - < 5 minutes
       More volatile fields first?

       Placing more volatile fields first might make it harder for
       bruteforce attacks. Are things like c14n expansion, field ordering
       really important to the security given our hash algorithms? Do we
       add a nonce? Call: take to list. (Bartel doesn't want nonce just
       for static text. Eastlake: some algorithms are weak and might need
       a nonce, but those are not the best algorithms.) Fox will talk
       with Jim and crypto guys as to whether we need about how sensitive
       we need to be about small bits of text, field ordering, and
       redudancy.

     * Transforms - < 10 minutes
       Parameters as Parameter elements?
       Provide for Quoted-Printable decoding?

       No one on the call is opposed to "parameterizing" transform, but
       Boyer had voiced opposition in the past. (No decision, continue
       discussion with Boyer present or on list.)
       Call agrees to list Quoted-Printable as an optional encoding, part
       of the same MIME reference as the Base64.

     * KeyInfo - <10 minutes
       Who will do draft of next level of detail?
       Should recipient identification information not necessary to key
       agreement be provided for?

       Fox completed her action item; Eastlake acknowledges.
       Couple of additions, KeyInfo should be defined as ANY and should
       also have an ID attribute associated with it.

     * "Properties" - < 10 minutes
       Is properties the best name?
       Should we define a signing time property?

       Solo: "signature properties" everyone agrees.
       KeyInfo is also a type of property of an Object. There's
       discussion as to if you want to have the signature include the
       KeyInfo, whether you place a KeyInfo in an Object, or just point
       to the KeyInfo (under Signature) from an ObjectReference.
       Eastlake: ObjectReference could just point to KeyInfo ID instead
       of sticking it inside an Object. Call seems favorable but need to
       think about it more.
       Put signed-properties as a sub-element of an open content model
       Object. This allows us to say the stuff in the signed-property
       bucket can include external XML elements, but that they
       should/must only carry semantics about the signature generation
       (like device, or time.)
       If we define signing time, should be part of a non-normative
       chapter or seperate document (Reagle would like to have its own
       namespace for purposes of demonstration.)
       ...
       <Object>
         <SigningTime
       xmlns="http://www.w3.org/1999/10/signature-core/time">
             <Date>...</Date>
             <Time>...</Time>
             ...
         </signing-time
       </Object>
     * Reagle aside: one thing we need to address in our defininitions
       are things like attribute, property, and such given there are so
       many collisions.

     * Schema? - 5 minutes
       We need someone to try writing a schema, based
       on the W3C schema draft, of our syntax to
       see how it goes.

       Ed Simon said he would attempt a Schema.

     * Canonicalization
       Reagle: restate what I though the consensus was
          + no mandatory to use c14n anywhere.
          + no mandatory to implement c14n in transforms
            no mandatory to implement in SignedInfo though hopefully
            implementation experience can inform further dicission.
       Solo restatement: SignedInfo: the absense of the c14nMethod then
       there is no c14n, this is also consistent with Transform. Continue
       discussion on list.

References

   1. http://www.ietf.org/
   2. http://www.w3.org/
   3. http://www.w3.org/Signature/Overview.html
   4. http://www.w3.org/Signature/Minutes/991028-tele,text



_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Thursday, 28 October 1999 14:35:47 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT