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 13:41:30 UTC