You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
642 lines
30 KiB
642 lines
30 KiB
<!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. In case of mandatory
|
|
implemented algorithms, one of each category must be implemented by default. 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 "node" 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 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’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’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 "XML Pay"
|
|
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 "Encryption Only" 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 "encrypt this node and all its children".</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 "Decrypt under Signature" 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’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’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’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’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 (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:
|
|
"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)."</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 "very undone deal." E.g.,
|
|
where should the encrypted attribute value go? Should the manifest always be a child? In
|
|
any case, the slide should read, "XML Attribute Value Nodes."</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 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 "contract" 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 "small devices." With respect to WAP,
|
|
convergence is likely and the 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 [<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
|
|
"CryptionInfo" 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
|
|
<Reference URI="#foo">. 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: <EncryptedData DecyrptionInfoURI="foo">...<>.
|
|
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 "protocoly."</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 - 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 "Officers"</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. Then it takes around 6-8
|
|
months to complete the Working Draft. Then there is a last call for participation
|
|
which takes about 2-4 months. Next Working Group Meeting around February 2001 if the
|
|
WG is approved. </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. It was mentioned that Encoding, entities, and namespaces
|
|
could all be problematic if canonicalization is not used. </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> <<a
|
|
href="mailto:reagle@w3.org">reagle@w3.org</a>> Last updated: 19th September 2000.
|
|
</address>
|
|
</body>
|
|
</html>
|