minutes.html 30.3 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<html>

<head>
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
<title>W3C XML Encryption Workshop</title>
<style type="text/css">
  body {
    margin-left: 10%;
    margin-right: 10%;
    font-family: sans-serif
  }
  pre {
     color: green; font-weight: bold;
     white-space: pre; font-family: monospace;
  }
  tt { color: green }
  em { font-style: italic; font-weight: bold }
  strong { font-weight: bold }

u {
    color: red;
}

strike {
    color: silver; }

CODE {
    FONT-FAMILY: monospace;
    FONT-WEIGHT: normal
}

.ietf {
    DISPLAY: none;
    FONT-FAMILY: monospace;
    FONT-SIZE: 100%;
    FONT-WEIGHT: normal
}

.discuss {
    COLOR: red
}
.link-def {
    COLOR: teal;
   FONT-STYLE: italic
}

.comment {
    BACKGROUND-COLOR: #fffff5;
    BORDER-BOTTOM: navy thin solid;
    BORDER-LEFT: navy thin solid;
    BORDER-RIGHT: navy thin solid;
    BORDER-TOP: navy thin solid
}


}
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body text="#000000" bgcolor="#FFFFFF">
<!--
<a href="http://www.w3.org"><img border="0"
alt="W3C logotype, link to home page" align="Middle"
src="w3c_home.gif" width="72" height="48" /></a> and <a
href="http://www.wapforum.org"><img width="90" height="55"
alt="WAP Forum logotype, link to home page" border="0"
align="Middle" src="wap_logo2.gif" /></a>
-->

<h1 align="center"><a href="http://www.w3.org"><img border="0"
alt="W3C logo, link to home page" align="middle" src="http://www.w3.org/Icons/w3c_home"></a></h1>
<!-- <h1>Call for participation</h1> -->

<h1 align="center">Minutes <a href="http://www.w3.org/">W3C</a> XML-Encryption Workshop</h1>

<h2 align="center"><a href="http://www.xcert.com/corp/Contact_Us/walnut_creek.html">San
Francisco, CA</a><br>
2 November 2000</h2>

<hr>

<h1>DRAFT MINUTES</h1>

<p>These minutes are not necessarily a complete capture of the presentations nor
discussion. Instead, the goal is to clearly represent the identification of an issue, and
the resulting proposals, straw polls, and action items. Four scribes took the minutes
which were they tweaked and massaged together by Reagle, upon the final responsibility for
any error rests -- since he may have tweaked the original thing incorrectly! However, if
you have a question, comment, or correction, just send it on to the <a
href="http://lists.w3.org/Archives/Public/xml-encryption/">list</a>!</p>

<p>Also see:

<ul>
  <li><a href="../../09/XML-Encryption-Workshop.html">Call for Participation</a></li>
  <li><a href="attendees.html">Attendance</a></li>
  <li><a href="http://lists.w3.org/Archives/Public/xml-encryption/">Email Archives</a></li>
</ul>

<h3>Resulting Action Items:</h3>

<ol>
  <li>Barb Fox: proposals and scenarios for CBC mode and the need for sequence numbers, and
    for threshold encryption schemes. Due 11/27/00.</li>
  <li>Dave Solo: Scenarios for using XML Encryption with XML Encryption (signed/encrypt,
    encrypt/sign, etc.)</li>
  <li>Jim Schaad: Brief description of candidate algorithms: Key transport RSA V, key info,
    key name, padding algorithms, mandatory implemented algorithms.&nbsp; In case of mandatory
    implemented algorithms, one of each category must be implemented by default.&nbsp; No more
    than one is mandatory in a particular category is necessary (result after issue brought up
    by Nimisha, Groove Networks and answered by the group).</li>
  <li>Joseph Reagle: Check with Patent Working Group and look into Protocols Charter (Eric,
    W3C) about issues on Intellectual Property and Licensing Fees.</li>
  <li>Joseph Reagle: Propose text on validation.</li>
  <li>Joseph Reagle: Update requirements document.</li>
  <li>Joseph Reagle: Move charter forward.</li>
</ol>

<h2>THURSDAY 02 NOVEMBER</h2>

<h3>9.00 - 9.35: Introduction</h3>

<ol>
  <li>Group, Introductions Around the Room</li>
  <li>Joseph Reagle, Agenda <ol>
      <li>Thanks to XCert for hosting</li>
      <li>Volunteers for Minute taking</li>
    </ol>
  </li>
  <li>Group, Agenda Bashing</li>
</ol>

<h3>9.50 - 10.30: Encryption, Authentication, and Authorization (scribe: Eric
Prud'hommeaux)</h3>

<ol>
  <li>Mark Scherling [<a href="scherling.html">slides</a>], XCert: Encryption requirements
    resulting from <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0006.html">proposed
    authorization model</a> <p>[A few questions on the particulars of authorization levels.]</p>
    <p>Ed Simon: if folks are interested in Authorization work they might consider the PMI
    forum: Privileged Management Forum</p>
  </li>
  <li>Christian Geuer-Pollmann [<a href="geuerpollmann/index.html">slides</a>], Uni-Siegen: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0042.html">Comparison/analysis
    of encryption and authorization</a>.</li>
</ol>

<blockquote>
  <p>[Discussion about whether the motivating scenario (leaving a node in the clear when its
  parents are encrypted is merited.]</p>
  <p>Lapp: you might have a nested date that should be in the clear.</p>
  <p>Prud'hommeaux: or an email address.</p>
  <p>[Further discussion about designing the schema appropriately, or re-arranging the tree
  under a new schema and using subtree encryption so you don't need to worry about this
  scenario.]</p>
  <p>Reagle: is the position of a node from its parents relative or absolute to the root?
  Geuer-Pollmann: Absolute</p>
  <p>Schaad: what about a write-back/insertion, how do you deal with their position
  information? Geuer-Pollmann: haven't thought this through yet.</p>
  <p>Nimishi: does this absolute position release information about its confidential
  parents? Geuer-Pollmann: potentially, but since spurious nodes can be added, this
  information can be obfuscated.</p>
  <p>Mike Wray: the more granular you get in encryption, the more vulnerable the information
  becomes to attack. If you use a cipher over attribute names you could figure out the
  length of the attribute name.</p>
  <p>Parez: does this scheme assume every client has same algorithm for public key?
  Geuer-Pollmann: No. Algorithm can be a URI for any scheme. Parez: how do you add a new
  client without re-encrypting the node? Geuer-Pollmann: add key material, possibly dynamic.
  Parez: then every client knows the secret. Geuer-Pollmann: secret is only used once. Wray
  : transporting shared key to multiple clients : Geuer-Pollmann: Yes, also two clients can
  collaborate to see more of a document.</p>
  <p>Reagle: if we don't want to limit ourselves to elements and attribute values, we need
  to come away with a comfortable level of generality, this is not easy, but Christian's
  approach is an interesting exploration of &quot;node&quot; based encryption.</p>
  <p>Simon: if you want to encrypt structure, then worrying about validation isn't important
  any more.</p>
</blockquote>

<hr>

<h3 class="break">10.30 - 10.45 break</h3>

<hr>

<h3>10.45 - 12.50 <a href="../10/06-xml-encryption-req.html">Requirements</a> (scribe:
Marc Briceno)</h3>

<ul>
  <li><h4>Applications, Parsers, References, and&nbsp;Protocol -- or lack thereof!</h4>
  </li>
</ul>

<ol>
  <li>Steve Wiley, MyProof: <a href="wiley.html">Requirements with respect to deployed
    parsers, target document fragments, nested encryption, etc.</a> <p>Requirements with
    respect to deployed parsers, target document fragments, nested encryptions.<ol>
      <li>One of biggest issues:</li>
      <li>Legacy applications. Little latitude to replace original documents.</li>
    </ol>
    <p>Requirements<ol>
      <li>needs to be able to use detached docs</li>
      <li>needs to be able to use XPath as reference</li>
      <li>Access control issues may not be avoidable.</li>
      <li>How to implement signed receipts for anonymous donations?</li>
    </ol>
    <p>Would like to see clear processing rules for encrypting and decrypting.<ul>
      <li>We will use nested encryption. Absent good processing rules, the document structure can
        easily be destroyed.</li>
      <li>If an element and its children are already encrypted, the processing rules should warn
        the user that she is not getting access to all the data.</li>
    </ul>
    <p>Problems due to the use of detached documents<ul>
      <li>How to deal with lists of decryption info? After decryption, do you strip the decryption
        info from the document?</li>
      <li>Level of granularity: so far only have to encrypt seed data for elements, element
        attributes, and the elements themselves.</li>
    </ul>
    <p>[Discussion] Joe Lapp: seemed to have an idea distinguishing between a person to person
    encryption, versus a complex multiparty system.</p>
  </li>
  <li>Eric Cohen, PriceWaterHouseCoopers [<a href="cohen.txt">slides</a>]: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/0007.html">XBRL
    requirements and lots of questions (process and technical).</a> <p>XBRL and Encryption<ul>
      <li>XBRL is the Extensible Business Reporting Language. It is an XML-based language to
        represent financial and business reporting information by American Organization of
        CPA&#146;s and accounting profession around the world.</li>
      <li>Allows the sharing of all information in the business and financial process. Trading
        partners, accountants, regulators.</li>
      <li>Deliverables: technical specifications. Currently has representation of financial
        information according to generally accepted accounting practices (GAAP).</li>
      <li>Objective: Speeding up the information pipeline</li>
    </ul>
    <p>Underlying technology<ul>
      <li>XML-based Instance Document</li>
      <li>XML-based Taxonomy Document</li>
      <li>Not traditional, hierarchical DTD-based instance document. Not element-based, but
        attribute-based.</li>
    </ul>
    <p>Question: Eric (W3C) What&#146;s the relationship between the nested groups<ul>
      <li>Nested element</li>
      <li>Parent element</li>
      <li>Group can also be used for tuples in which multiple sets can be grouped together</li>
    </ul>
    <p>Question: Eric (W3C) Relationship between data types and XSD<ul>
      <li>Made a decision long ago to extend XSD. Will provide more information later.</li>
      <li>Needed child-parent relationship, not child-parent relationship.</li>
    </ul>
    <p>Encryption Scenario<ul>
      <li>How can public schema customer taxonomy extensions be kept private?</li>
      <li>How to limit general ledger granularity to authorized managers?</li>
    </ul>
    <p>Encryption Questions<ul>
      <li>How can namespaces be used to control access?</li>
      <li>How can information access limited by levels?</li>
      <li>How do deal with real-time feeds?</li>
      <li>How to deal with patents?</li>
      <li>Do we mandate cipher suites?</li>
      <li>What assumptions do we need to make about processing speed and data size?</li>
      <li>Time/date authentication?</li>
      <li>Encryption and decryption using XSL and other XML-standard tools only?</li>
      <li>Do we need to lock access to attributes as well?</li>
    </ul>
  </li>
  <li>Thane Plambeck, Verisign [<a href="plambeck.txt">slides</a>]: Verisign requirements for
    XML Encryption <p>Primary applications<ul>
      <li>Authentication and Validation</li>
      <li>Payment Services</li>
      <li>Focus of examples will be on payment services real life examples.</li>
    </ul>
    <p>Make it easier to build PKI-reliant apps.</p>
    <p>Traditional inhibitors<ul>
      <li>Complexity inherent to PKI</li>
      <li>Patents, licensing</li>
      <li>Need for special PKI toolkits to perform PKIX logic.</li>
      <li>ASN.1 encoding complexity</li>
    </ul>
    <p>How XML helps<ul>
      <li>Move away from ASN.1</li>
      <li>Move towards clients with XML runtimes and base crypto only (no ASN.1, no PKIX logic).</li>
      <li>Delegation of trust processing to server-side components.</li>
    </ul>
    <p>Goal<ul>
      <li>Enable one schema XML for unified payment processing. Already uses &quot;XML Pay&quot;
        implementation.</li>
    </ul>
    <p>XML Pay<ul>
      <li>In pilot (Ariba, Amex, others)</li>
      <li>Multiple payment types and payment processors.</li>
      <li>XML-Dsig compatible</li>
      <li>Password-based authorization also possible.</li>
      <li>Between merchant and payment processor, with VeriSign in-between.</li>
    </ul>
    <p>Where to add encryption<ul>
      <li>Content-only model for encryption is very attractive.</li>
      <li>First choice: encryption of element content (but not element name and attribute).</li>
      <li>Element wise encryption adds complexity.</li>
      <li>Granularity</li>
      <li>Must be down to element level</li>
      <li>Limiting to entire elements would be OK.</li>
      <li>Extending to element content is very attractive.</li>
      <li>Found no requirement for selective attribute encryption.</li>
    </ul>
    <p>Wants &quot;Encryption Only&quot; specs.</p>
    <p>Should look like XML Dsig</p>
    <p>Question: Dave Solo: what about signing and encrypting? Answer: danger of separately
    encrypting each element under the same key.</p>
    <p>Q: how do you prevent taking of blob of ciphertext and re-insert it into a subsequent
    message? (i.e. to reuse an encrypted credit card number). A: has not yet considered issue,
    since no encryption is currently taking place.</p>
    <p>Canonicalization: Prefers enforced use of canonicalized XML even for encryption-only
    applications.</p>
    <p>Q: why bother for encryption? A: just because it is cleaner</p>
    <p>Q: Ed Simon. Besides character encoding, you have a reference. Other documents might
    use different entity reference and get different data. Is reluctant to make canonical XML
    required.</p>
    <p>Q: Ed Simon. Does Verisign have their own XML parser? A: use compiler that maps schema
    to objects. Application specific.</p>
    <p>Q: Lapp: will Verisign change their XML parser? Plambeck: Verisign parser is not
    relevant outside Verisign. Not an issue.</p>
  </li>
  <li>Mike Wray, Hewlett-Packard [<a href="wray.html">slides</a>]: XML and end-to-end security
    . <p>We need to ensure that similar things encrypted under the same key don't look alike</p>
    <p>Questions.<ol>
      <li>Reagle: should the standard state to not rely on unauthenticated data? Wray: yes, users
        should be warned that unauthenticated data cannot be trusted</li>
      <li>Reagle: do you want mandatory algorithm support? Wray: prefers standard, but can work
        with optional key info.</li>
      <li>Solo: is this an XML Encryption mechanism or payload? Wray: TBD. Dsig support this
        functionality.</li>
    </ol>
  </li>
  <li>Barb Fox, Microsoft [sides]: Fire-and-forget encryption. <p>Requirements<ul>
      <li>Need encryption and signature to do anything interesting.</li>
      <li>Should be syntactically aligned with Dsig.</li>
      <li>Must use exclusively XML tools.</li>
      <li>Encryption work retroactively impacts Dsig.</li>
    </ul>
    <p>Temptation<ul>
      <li>Lose Focus</li>
      <li>Do not build new protocol. Do not define expected recipient behavior.</li>
      <li>Do not get lost in edge cases: multi-party, sub-tree encryption.</li>
      <li>Key management/Trust Management</li>
      <li>Authorization schemes</li>
    </ul>
    <p>Q Dave Solo: why is multi-party an edge case?A: need to support multiple recipients,
    but not pass through workflow.</p>
    <p>Proposal<ul>
      <li>Restrict an encrypted message to one KeyInfo per recipient.</li>
      <li>Narrow scope of this to WG to &quot;encrypt this node and all its children&quot;.</li>
      <li>Punt additional work to Technical Notes and follow-on working groups.</li>
    </ul>
    <p>Q Joseph Reagle: what of the element are we encrypting? Subtree with start and end
    tags?A: align with Dsig.</p>
    <p>Q Joseph: can you just encrypt content or do you need to encrypt tags?A: is arguing
    against encrypting attribute value?</p>
    <p>Q: Steve Wiley, Ed Simon: is it node or element?A: element (the discussion was
    non-structured. The scribe is not certain that he captured the discussion correctly).</p>
    <p>Base requirements<ul>
      <li>KeyInfo</li>
      <li>Conceptual extension to Dsig KeyInfo</li>
      <li>Dsig syntax alignment <ul>
          <li>Algorithms, modes, format</li>
        </ul>
      </li>
      <li>AES <ul>
          <li>Basis set RSA, AES, SHA-1 [remember to mention need for SHA-2, ed.]</li>
        </ul>
      </li>
      <li>Implementation impact</li>
    </ul>
    <p>New requirements<ul>
      <li>Transform &quot;Decrypt under Signature&quot; for signed and encrypted documents.</li>
      <li>Impose processing order.</li>
      <li>Partially encrypted subtree</li>
    </ul>
    <p>Q Dave Solo: should output be definition as a Dsig transform. Define the encryption
    transform as something that can be placed into Dsig. There should be URI that can point to
    transform. A: agreed</p>
    <p>Q Ed Simon: was in original transform. Need reversibility of transform. A Dave Solo:
    will need two transforms. Encrypt and decrypt.</p>
    <p>AES will need Keywrap algorithm. Should be coordinated with S/MIME. WG is working with
    NSA on the algorithm.</p>
    <p>Need threshold system support. Distribution of encrypted content where encrypted
    content and Keyinfo are shipped separately.</p>
    <p>Conclusions<ul>
      <li>Lots of hard problems</li>
      <li>Basic building block for protocols</li>
      <li>Let&#146;s limit scope</li>
    </ul>
    <p>Q Joseph Reagle: could you provide an example for state mechanism? A: need to do cipher
    block chaining. Where do you hold the IV? Modes need additional info.</p>
    <p>Q Mike Wray: chaining requires state</p>
    <p>Q Joseph Reagle: if error, decrypt will fail. Which is different from us having to
    place in mechanism to prevent it from failing.</p>
    <p>Q Joseph Reagle: can you provide a scenario for the threshold? A: need to indicate that
    a key may only be a share, not entire key.</p>
  </li>
  <li>Owen Roberts, Baltimore [slides] <p>No specific requirements</p>
    <p>Interested in providing high-level toolkits, just cares that what goes into the
    standard is sensible.</p>
    <p>Scoping is the biggest challenge.</p>
    <p>Let&#146;s get one small spec going rapidly that will a small part of the requirements.</p>
    <p>Agreement that we should finish a small chunk of work first that can be delivered.</p>
    <p>B: Barb Fox. Once the deliverable goes towards proposed standard, it will become
    difficult to make changes. Let&#146;s not address protocols and assure alignment with
    Dsig. It is important to not limit implementation, either.</p>
    <p>B Ed Simon: PKCS #7 is unusable until the secure blob is unsecured. Not so in XML. Part
    of the data can still be used.</p>
    <p>B Joseph Reagle: keep Keyinfo in separate parts of the spec?</p>
    <p>A Barb Fox: should we split work?</p>
    <p>B Young Etheridge: as long as we establish intent up front, we won&#146;t later find
    that we forgot something that needs to be done.</p>
    <p>B Joseph Reagle: requirements document will establish scope.</p>
  </li>
</ol>

<hr>

<h3 class="break">12.50 - 2.00 lunch</h3>

<hr>

<h3>2.00 - 3.30 Proposals&nbsp; (scribe: Joe Latone)</h3>

<ul>
  <li>Ed Simon [<a href="simon/index.html">slides</a>, (<a href="simon/images/eds_slides.html">GIF
    version</a>)]: <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0001/01-xmlencoverview.html">XML
    Encryption Syntax and Processing</a> and XmlEncryptor - An XML Encryption Demonstrator:
    &quot;Presenting an overview on the XML Encryption spec that focuses on encrypting various
    content. Will also report on techniques for coding XML Encryption in various scenarios
    (eg. encrypting element, element content, attribute values in DOM and XSLT
    frameworks).&quot;</li>
</ul>

<blockquote>
  <p>Clarification: DecryptionInfo is the same as EncryptionInfo in Ed's current (as of 2
  Nov 2000) document.</p>
  <p>Reagle: Are PIs and comments children? Simon/Eastlake: Yes, they are.</p>
  <p>Fox, et al: The spec for encrypted attributes is a &quot;very undone deal.&quot; E.g.,
  where should the encrypted attribute value go? Should the manifest always be a child? In
  any case, the slide should read, &quot;XML Attribute Value Nodes.&quot;</p>
  <p>Wray, Solo: Sign-then-encrypt or encrypt-then-sign are more subtle than presented. This
  transform is one of those.</p>
  <p>Fox: might need a&nbsp; retroactive DSig requirement in order to get encryption and
  signature to work together. Also: Need to look at how this is really used, e.g., XML doc,
  XML message, etc.</p>
  <p>ACTION Solo: write up encryption/signature scenario.</p>
  <p>Schaad: Note that there was no schema or DTD validation with XMLEncryptor demo. Started
  with question about the fact that one of today's off-the-shelf parsers could be used.</p>
  <p>Clark: What parser call backs would you use? See Fox example(s). The main example has
  to do with validation. [?] If you want to validate your new DOM tree, then you would need
  a call back.</p>
  <p>Reagle call for straw poll: Are people ok with the encrypted document not conforming to
  original schema that did not consider specification of encryption?</p>
  <p>Simon mention, given that everything is typed in schema, encrypting even element
  content (e.g., CDATA) will invalidate the instance.</p>
  <p>[Discussion]: no vote since confused. ACTION Reagle: propose something on the list.</p>
  <p>Schaad: Can we push on the schema group for an encryption specification?</p>
  <p>Lapp: A schema is part of a &quot;contract&quot; between the two parties exchanging the
  document. If they want portions to be encrypted, that should be in the schema.</p>
  <p>Reagle: Good point, however we found in xmldsig that we couldn't always presume all
  schema and instance authors would have enough foresight to design their applications to
  work with signatures (before signature was even complete!).</p>
  <p>Prud'hommeaux: Why not just decrypt it? Schaad: One example, of many, is encryption for
  access control.</p>
  <p>Cohen, Reagle: Should XML encryption work with WAP? Big issue that we shouldn't go into
  now, though we have to consider &quot;small devices.&quot; With respect to WAP,
  convergence is likely and the&nbsp; next version will be more XML'ish on IPv6.</p>
  <p>Shaad: Option for element names and attribute names in the clear, with everything else
  encrypted. This can be done, but there should be a simpler way to do it</p>
</blockquote>

<ul>
  <li>Hiroshi Maruyama&nbsp; [<a href="imamura.txt">slides</a>(<a href="imamura.pdf">pdf</a>)]:
    <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0005/01-xmlenc-spec.html">Specification
    of Element-wise XML Encryption</a> and <a
    href="http://lists.w3.org/Archives/Public/xml-encryption/2000Oct/att-0002/01-note.html">Note
    on XML Encryption</a></li>
</ul>

<blockquote>
  <p>Clarification: Simon is doing data part, Hiroshi is doing the key part.</p>
  <p>Clarification: Did not consider encryption of attribute values at the time this
  presentation was prepared.</p>
  <p>Reagle poll: ~12 for EncryptionInfo, ~5 for DecryptionInfo. No one opposed to
  &quot;CryptionInfo&quot; element (but not clear how serious that proposal is.</p>
  <p>Reagle poll: Nobody is opposed to EncryptionPropertyList.</p>
  <p>Latone (unvoiced opinion): Why not CryptoInfo/CryptioProperties.</p>
  <p>Reagle poll: anyone want to use bi-directional XLink? Or should we stick with
  &lt;Reference URI=&quot;#foo&quot;&gt;. Consensus to stay with URI.</p>
  <p>Reagle: However, it's starting to get confusing understanding the relationship between
  these things.</p>
  <p>Simon proposes: &lt;EncryptedData DecyrptionInfoURI=&quot;foo&quot;&gt;...&lt;&gt;.
  Folks seem to think some qualification of this sort is a good idea.</p>
  <p>Solo, Fox, Asthagari: KeyInfo should be more generic and less &quot;protocoly.&quot;</p>
  <p>Reagle prompted by Ferguson: Goal of spec is that one could implement it well, easily.
  This is especially important for the not-so-well understood topic of security. However, we
  won't tell people how to implement.</p>
  <p>Ferguson: Voiced concern about how XML security is implemented. Can the WG ensure that
  it's used properly? Consensus: No, but the WG recognizes that security is unique in
  several aspects wrt implementation and will take responsibility for writing good notes
  regarding security attack issues.</p>
  <p>Solo, Fox: The issue of sign-then-encrypt versus sign-and-someone-else-encrypts versus
  encrypt-and someone-else-signs was brought up again. Can we distinguish these cases
  syntactically?</p>
  <p>Wray: Layered processing needs to be specified. This is true for any transformation
  processing.</p>
  <p>Reagle call for volunteer to write use cases on the last two items in this minutes
  list: Solo volunteered to write up a short note.</p>
</blockquote>

<hr>

<h3 class="break">3.30 - 3.45 break</h3>

<hr>

<h3>3.45 - 5:30 Content IV (scribe: Shivaram Mysore)</h3>

<p>Speaker - Joseph Reagle, <a href="http://www.w3c.org/">W3C</a><br>
Scribe -&nbsp; Shivaram Mysore, <a href="http://www.sun.com/">Sun Microsystems, Inc</a></p>

<h4>Summary of W3C Process</h4>

<ul>
  <li>Informal Meetings</li>
  <li>Workshop</li>
  <li>Birds Of Feather (BOF) Sessions</li>
  <li>Proposal, Beta Requirements</li>
  <li>Call for Participation</li>
  <li>Others</li>
</ul>

<h4>W3C WG &quot;Officers&quot;</h4>

<ol>
  <li>(Team: someone who works for the W3C)</li>
  <li>Chair: responsible for generating consensus over deliverables in a timely manner</li>
  <li>Staff Contact: represents director/team, interface to Tech Report Process</li>
  <li>Editor: ultimately responsible for regular publication of document and tracking changes</li>
  <li>Author: responsible for section of a document and assuring closure of issues raised for
    that section</li>
</ol>

<h4>Potential Deliverables</h4>

<ol>
  <li>Requirements Document</li>
  <li>EncryptionData and Processing</li>
  <li>DecryptionInfo</li>
  <li>Algorithms</li>
  <li>?Encryption/Signature Scenarios</li>
  <li>?Data Model</li>
  <li>?Canonicalization</li>
  <li>?A signature transform.</li>
</ol>

<h4>Questions</h4>

<ul>
  <li>How long before the WG starts, and how long would it last? Reagle: ~2-3 months from
    November is when the WG would officially begin. starts.&nbsp; Then it takes around 6-8
    months to complete the Working Draft.&nbsp; Then there is a last call for participation
    which&nbsp; takes about 2-4 months. Next Working Group Meeting around February 2001 if the
    WG is approved.&nbsp;</li>
  <li>Schaad: When would teleconferences start? Reagle: The W3C does use teleconferences in
    order to move quickly on its work, but this won't start until the WG is officially
    chartered.</li>
  <li>[Later in the day] Geuer-Pollmann: will the WG be open like xmldsig? Reagle: Yes.</li>
</ul>

<h4>Straw Polls on Requirements Document:</h4>

<ol>
  <li>Reagle: on this note of granularity (how specific do we want to be in encrypting
    portions of a document): who wants to preclude attribute encryption versus those who want
    to encrypt attribute values <p>11 votes (preclude) / 13 votes (encrypt attributes)</p>
    <p>Ok, there's no consensus to make a change from present proposals; needs further
    discussion.</p>
  </li>
  <li>Ed Simon: Encrypt Node list within element? <p>Majority opted for encrypting everything
    between Start and End Tags</p>
  </li>
  <li>Reagle: Should we enable others to preserve the validity of the document. <p>Discussion:
    Action Reagle, sent proposal on text to list about if you want to encrypt the structure,
    then by definition you aren't too concerned with the original structures (and its
    DTD/schema). If you do want to encrypt structure, you should design your schema according,
    created intermediary schemas, or only encrypt CDATA use an external XML document to
    contain the DecryptionInfo and such.</p>
  </li>
  <li>Reagle: While we wish to not change present parsers (Simon: this was not necessary in my
    case) we acknowledge we may have to tweak when necessary. <p>No objection.</p>
  </li>
  <li>Reagle: We use URIs for algorithm and namespace Identifiers. <p>No objection.</p>
  </li>
  <li>Reagle: Which algorithms should we require for mandatory interop? <p>[Discussion] ACTION
    Schaad: send a profile of candidate algorithms (including padding) with recommendations to
    the list.</p>
  </li>
  <li>Schaad: do we worry about compression algorithms? <p>[Discussion about whether it would
    be optionally specified or required.] Many people answer strong NO because of prior
    experiences in IETF with patent related issues. A few people like the idea, but no
    consensus to include compression algorithms.</p>
  </li>
  <li>Should we invent our own (a compact binary form) or use Canonical XML. <p>[Discussion]
    It was agreed that mandatory implementation of Canonicalization, but optional use would be
    the right thing to do.&nbsp; It was mentioned that Encoding, entities, and namespaces
    could all be problematic if canonicalization is not used.&nbsp;</p>
  </li>
  <li>Licensing fees: do we want an unencumbered/free license with respect to any claims on
    the specification? <p>Fox: general sentiment is probably ok, but your wording isn't quite
    right. Needs further work. ACTION Reagle: investigate W3C WG and post summary of issue on
    the list.</p>
  </li>
  <li>Clark: XPath can cause serious performance be hit: should we consider performance in
    implementation specifically with XPath and buffering; Where URI or XPath could be used <p>Lapp:
    Union operations and recursive descent are problems with performance</p>
    <p>[Discussion about whether all use of XPath is costly and whether mandatory use of XPath
    optional features is acceptable.]</p>
    <p>Reagle: Ok, don't think we'll resolve this today, let's continue with Motherhood and
    ApplePie statement that we want good performance wherever possible and keep an eye on this
    issue as we progress.</p>
  </li>
  <li>Should an encrypted element in an unencrypted from be Augmented? - Mandatory
    Canonicalization solves this problem.</li>
</ol>

<hr>

<address>
  <a href="http://www.w3.org/People/Reagle/">Joseph Reagle</a> &lt;<a
  href="mailto:reagle@w3.org">reagle@w3.org</a>&gt; Last updated: 19th September 2000.
</address>
</body>
</html>