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

Irvine Rough Minutes

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 01 Sep 1999 15:19:35 -0400
Message-Id: <>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
[I'll plug in Daniel's notes once he sends them.]

   Editor: Joseph Reagle [5]reagle@w3.org
   Authors: Milt Anderson, Daniel Woycke,  Joseph Reagle
August 30-31 1999 Face to Face Meeting

   The following minutes capture points of discussion, consideration, and
   action items resulting from the face-to-face meetings. Participants
   should send the editor corrections; others on the mailing list should
   suggest alternatives or document opposition to views/consensus
   achieved in this meeting by 990910. Those issues in black are ones
   that should still be investigated.
   Name Company
   Joseph Reagle W3C
   John Boyer UWI
   Mark Bartel JetForm
   Don Eastlake IBM
   Milton Anderson FSTC
   Shinsuke Honjo Hitachi
   Ed Simon Entrust
   Terry Hayes Netscape
   Todd Vincent GSU
   David Solo Citigroup
   Barb Fox Microsoft
   Rohit Khare UCI
   Peter Norman FactPoint
   Stephen Keung CIS, SC
   Roberta D'Amico CSELT
   Daniel W. Woycke MITRE
Monday, August 30

  0900-1030 [6]Scenarios , John Boyer (Notes: Reagle)
     * [7]Enveloped Internal Content
          + Signature element is the root element. Doesn't need to be
            supported directly, more elegant ways to do things.
     * [8]Direct Envelopment
          + Everyone's syntax does this, no worries mate.
     * [9]Unenveloped Indirect Signature
          + Application element is the root element.
          + Encrypted hash is over the actual application element. (Want
            it for symmetry in the enveloped case.) We need exclusion in
            the Indirect since the signature is a child of the root
          + Conversation on when you exclude the signature, how you worry
            about signing signatures.
     * [10]Unenveloped Direct Signature
          + Not a lot of support, but people think having the encoded
            version is not hard. Don't need it just to avoid another
            level of hashing. We do need to sign the original content,
            but what about the original content plus other stuff?
     * [11]Signing External Resources (Detached Signatures)
          + [12]Signing Partial XML Documents
            Boyer shows and argues that July XPointers (or more
            specifically XPath) seemingly offers the
            filter/select/exclude capabilities we need. When asked how
            many people would expect to implement XPointers shortly, only
            one person raised their hand. However, people do seem
            comfortable in using a subset of Xpointer. Or can we just use
            URIs to do what we need to do?  Not for selection in the
            manifest, but perhaps in the core signature.
            Norman: can we do this in a simpler way, with a dsig:exclude
            attribute? Which requirements does Xptr meet that can not be
            met through an easier method? Group: The insertion of
            dsig:exclude is problematic when you have multiple
            signatures, how does which signature know which dsig:exclude
            belongs to it.
            Boyer raises unrelated point that if the canonicalizer strips
            out the DTDs, you won't know which attributes are IDs
            Norman: how do I seen pieces of documents that were not
            structured with many names? With a dsig:target element one
            can add to other documents to point out what it is you are
            signing for poorly structured documents. But the removal of
            these things happen before or after dsig (this affects the
            nesting) -- just like in dsig:exclude. Reagle suggests you
            could use XPtr as described, or take the document apply XSLT
            to effect the transformation and sign both of them. (still
            dsig one-pass-processing: get feedback to people on
            implementation side as to whether this is useful. (not clear
            that there is additional utility.)
  1015-1030 [13]Data Model, Joseph Reagle (Notes: Daniel Woycke)
   [Insert Woycke's notes.]
   [Reagle summary:]
   Reviews his proposed data model, explains:
    1. The goal is to make as much of the relationships between the
       elements in our signature as explicit as possible, such that other
       non-dsig applications could still derive interesting information
       out of a signature, even if they don't care about signature
  1030-1200 [14]Syntax and Processing Model (Notes: Milt Anderson and Reagle)
   C14n will be dealt with this afternoon.
   Notes for David Solo ---
   Don plus discussion -- Distinguish between three levels.
    1. Core signature syntax -- the syntax for creating a signature over
       a set of bytes within the scope of the signature
    2. Signed objects syntax -- how you sign referred to and signed
    3. Application -- trust is in the application layer.
   First Slide -- XML Syntax and Processing
   Second Slide -- General Issues
     * Keyinfo compromise is to put the keyinfo at the top level outside
       the scope of the signatures, and then put some added key
       information in the signature for binding. This is not necessarily
       a duplication of the keyinfo, since the application may wish to
       bind different information into the signature.
     * Putting keyinfo outside the scope of the signature was the
       predominant application requirement. 97.44% of the cases according
       to David Solo.
     * Hayes -- felt that there are many cases where keyinfo should be
       signed. We need to make it clear and explicit that key information
       is allowed within the scope of the signature when the application
       needs to put it there.
   Third Slide -- General Structure.
     * All "sigs" have been changed to "signature".
   Fourth Slide -- signedinfo
     * What are signedattributes? Could be signing time, key information
       discussed above,
     * Where does the signedobjectdata refer to an object that has been
       already signed.
     * Anderson wants signedattributes in order to simplify creation of
       the signature element by security tokens in such a way that the
       signedattributes are inserted automatically by the token device.
       That way they have the security associated with the security and
       tamper resistance of the token device, and don't depend on the
       host systems security or on the integrity of the signer herself.
       [Milt wasn't there for the second day, where we moved to removing
       special attribute blocks, so Milt should weigh in on David's
       latest proposal -- Reagle.]
   Fifth Slide -- signedobjectdata
     * Boyer: does this support enveloped? Response: signedobjectdata
       always refers to an object, but the object may be within the scope
       of the signature element. There is always indirection.
     * References to signed objects can be to an object within signature,
       to an object within the same document, or to an object in another
     * Transformations include c14n and encoding. It may also include
     * Change signedobjectdata to signedobjectreference?
     * May use a default c14n and hashing algorithm or inherit the ones
       from the computation over signedinfo.
   Sixth Slide -- algorithms
     * Currently there is no definition of the Identity c14n. This is not
       c14n plus fixing up CRLF and charset.
     * Null and Identity c14n are specific to digsig and are for the
       point to point application. The case of unique production of a
       canonicalized output of the DOM is in the "more extensive" c14n
       algorithm, as is the Syntax WG's proposal based on InfoSet.
     * Question about whether hash and signature algorithm should be
       combined and whether the dual signature should be combined in a
       single type. The parties would need to have the combined hash/sig
       algorithms and the combination of signing capabilities. When a
       combination of signatures is used, then the signaturevalue is sent
       to the appropriate combined algorithm. It simplifies processing to
       not have the discrete combinations of algorithms visible at the
       core syntax level.
   Seventh Slide -- keyinfo types
     * Hayes: multiple keys are required for multiple signatures. Then we
       have multiple instances of certs in keyinfo.
   Eighth Slide -- Eye test and example
   Ninth Slide -- Open Issues
     * Do we always go forward with signedobjectdata being a reference?
       Advantage is that signature can always be calculated over
       signedinfo and doesn't matter whether the object is inline or
       outside. Canonicalization of singed info may have to take into
       account that the reference may be a URI or an ID depending on
       whether the referenced object is external or internal.
     * Is there only one or more than one instance of signedobjectdata in
     * attributedata and keyinfodata are candidates for promotion to the
       next level and the corresponding wrappers might be eliminated.?
     * Long discussion regarding whether it was necessary for the
       signature core to chase down and verify the hash of the object
     * Is it possible to have a manifest where the URIs are not signed,
       therefore allowing to move the referenced objects.
   [Reagle's addition summary of this discussion.]
     * solo: the benefit of the indirection is:
         1. switching: could refer (depending on how you reference it) an
            object that is external or internal, and signature wouldn't
            break. reagle: I dispute this, if they have different URIs
            they are different things, unless there is a statement of
         2. transformations: keeping it external means one can have one
            single c14n over the signedinfo, that are indistinct of the
            content transformations (no nesting/multiple-c14n)
     * Fox: will XML content be too small sometimes (particularly if
       signature is also over siginfo, pretty static information) in
       order to permit a dictionary attack, do we need padding and salt?
       Solo: jokes XML is never small. Should investigate.
   [Reagle summary of Open Issues from Syntax:]
   [The resolution to many of these issues will be reflected in the
   [15]next draft Solo will send since we went back and forth on some of
   this stuff quite a lot.]
    1. signature attributes: if we have signature semantics and include
       it in <signature-attributes> they must be relevant to the
       cryptographic signature, nothing about the signed object itself.
       Semantics about the object should be in maninest attributes (or
       reagle argues in a new signed object see [16]tomorrow's discussion
       where both types of attributes are removed.)
    2. signed object ref (data), should we limit it to one? Go with one
       with caveats that it must make sense in a DLG (can someone else
       sign your signature attributes?).
    3. algorithms (crypto/hash): mandatory, recommended, optional
    4. c14n, syntax WG, null and simple/minimal c14n
    5. exclusion/xptr. the dsig:exclude declaration, which signature does
       it belong to?
         1. <X dsig:exclude> ...</X> everything is hashed and signed, now
            someone adds a
         2. <Y dsig:exclude> ...</Y> it will get rendered differently,
            but not break the signature because other applications won't
            know the dsig:exclude semantic.
       John, in XFDL had something that did it differently, but not any
       easier. consensus that we should bite the bullet and use XPtr in a
       limited way as possible. Need to check if XPtr returns the whole
       resource and a view, or a different resource (check the DOM that
       is returned.) Are we better off use XML with XPtr to select or XML
       with XSLT? Boyer: they are supposed to be converging with XSLT ->
       XPtr -> XPath as ordered in terms of complexity.
       Consensus. The reference from SignedInfo will just be a URI. This
       can then point to a manifest or package which can use
       Xlink/Xptr/Xpath as appropriate. This means you don't have to
       worry about Xptr in the core signature syntax.
       Question: Are things like c14n, encoding, XSLT, etc., ordered or
       non-ordered? <transformations> is an ordered list.
    6. Which crypto algorithms do we choose and mandatory to implements
       and defaults? Also need to include security requirement such as
       avoiding Phillip's downgrade attack mentioned on the list.
       Need to references specs, define algorithm, take from Brown.
       hash: SHA-1 (mandatory), MD5 (recommended) AES-H (keep an eye out)
       MAC: HMAC-SHA1 (recommended), HMAC-MD5 (optional)
       PK Signature: DSS=DSA with SHA-1 (mandatory); RSA with SHA-1
       (recommended); RSA with MD-5 (optional); ECDSA (coming along)
       Key Agreement: DH (optional) as defined/specified in the keyinfo
    7. Do you do combined signature types, or have two different
       signatures? reagle: if they are two different signatures, can make
       statements about each. Solo: could do it either way. Discussion:
       why you might choose one or the other. Solo: it'll be clearer when
       we go to implement.
    8. Definition: encoding is arbitrary ways to represent a set of
       characters; c14n is one particular representation of multiple
       permissible representations.
         1. Null (mandatory)
         2. Minimal (mandatory) CR/LF, encoding, UTFF-8,
         3. Minimal':  white space handling?
         4. DOM (optional)
         5. SyntaxC14N (optional)
       Boyer: we use the "<?" at the beginning of the document to
       determine the encoding, but what if we only have a part of an XML
       document? Reagle: good question!
       Action item: Ed Simon, find someone to do minimal c14n.  Milt will
       propose whitespace handling.
       Action item: Don poke on a specification of DOM-c14n (right now it
       is wrapped in DOM-HASH. (Boyer, would DOM-c14n do attribute sorts
       and white space handling?)
Tuesday, August 31

   Regrets: Barb Fox, Milt Anderson,
  900-1015 Wrap Up of Syntax
     * Peter Lipp's object location proposal on the list is accepted.
  1030-11 Requirements
    1. add security requirements.
    2. Don and ? has a few comments will send to list.
  1100-1200 Signature Semantics (Notes: Reagle)
   Rohit: point of clarity: a signature on a manifest may very well
   validate, while the manifest  (assertions) do not -- these are
   distinct things.
   Manifest is a collection of things, you need not validate.
   Package is a collection of things, plus assertion of identity between
   Manifest and Package. Do we define attributes given a reference
   stating the references should be fetched and validated? Or is it part
   of the definition?
   Reagle: argues against permitting external semantics to be introduced
   into our definition through ambiguous manifest-attributes (Whether
   those references are confirmed is up to the application.) Others can
   define their own threshold XML application
   <someoneelse:threshold>...</threshold> or make a statement about the
   dsig:manifest using something like RDF.
   First, a non-dsig application isn't going to know what the
   relationship between manifest and man-attributes is, have to read the
     <dsig:manifest id="1">
       <signed objectref/>
       <signed object/>
   However, if man-attributes is merely a signed-object with defined
   policy assertions that reference "1", relationships are much more
   Second, lets avoid things like:
     <dsig:attribute type="CDATA" and value="CDATA"/>
   Make people introduce a new qualified namespace element with clearly
   defined semantics, or make a statement about an existing resource.
   Solo and consensus.: reconsideration on signedattributes,
   signedattributes are merely a signedobject, referenced by the
   signedobject reference. the signedobjectreference has a t ype
   describing if its a manifest, package, signedattributes. Same with
   manifest attributes but at a lower level.
   Todd: we need a good way of binding the XML, style sheets, schemas,
   and DTDs. Group members may work on a paper addressing the legal
   issues of this and potential package requirements but not critical
  1030-1100 Scheduling and Allocating future documents and con calls
   Calls now on Thursday on Noon.
   CP (critical path), ST (standards track)
     * Requirements (Reagle). CP
     * Core Syntax (Fox, Solo, Brown). CP, ST
     * Manifest & Package Application Defn. (Vincent). ST to be
       integrated into other docs.
     * Algorithm Definitions. (Bartel) CP, ST
     * Scenarios (Boyer) to be integrated into other docs.
     * Implementation (Simon) CP. will start playing with implementations
       as soon as feasible, might propose how to do interop.
  1300-1400 Marketing and Promotion
   Once we have something we are comfortable with, we need to get on XML
   sites and get people talking on XML-dev. Might have a marketing plan.


   1. http://www.ietf.org/
   2. http://www.w3.org/
   3. http://www.w3.org/Signature/Overview.html
   5. mailto:reagle@w3.org
   6. http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html
   7. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#one
   8. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#EnvelopedDirect
  11. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#three
  12. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#Four
  13. http://www.w3.org/Signature/Drafts/xml-dsig-datamodel-990823.html

Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Wednesday, 1 September 1999 15:19:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:56 UTC