Reported by Rohit Khare: Edited by Donald Eastlake Rohit Khare * March 16, 1999 * 9:00 AM XML DSIG BoF Meeting Notes -------------------------- Donald Eastlake presented a proposed 1 hour agenda (see slides). Turns out we were actually sceduled for 2 hours and used almost all that tiime. Eric Riscola opened with a concern that several groups have tread before here -- but that there are also new concepts on the table here (header-signature, parallel blocks, etc) Donald Eastlake presented a proposed layering: OTHER groups: cert policy, signature semantics, etc XMLDSIG group: signature syntax, XML hashing Dave Solo -- there's something in between that speaks to "behavior" and which is critical to interoperabilty -- e.g. what happens when pieces start failing (successive or embedded signatures) -- e.g. if I'm processing attributes (behavior of signatures tied to the xml tag sets, not just signing it opaquely). So perhaps we shouldn't rush ahead so soon in the BoF. Hiroshi Marayuma <maruyama@jp.ibm.com> from IBM Tokyo presented DOMHash for IBM's XML4Java toolkit. Tool kit is available from alphaworks at http://www.alphaworks.ibm.com. See Slides. Question: so this is a hash of hashes ( a hash tree)? A: yes; the API produces a hash for each element, then hashes over the child elements. Question: (DSolo) you're eliding information on comments, etc -- what if I need a signature will all the information, not just the structure of the XML document. A: XML DOM specification says DOM processors need not send comments up and a cannoncialization that any conformant DOM implementaiton supports is desireable.. There's also an XML Tree Diff tool, based on this hash API, which obtains the minimum edit distance between two DOM trees. Eric Riscola (EKR): wait, if you want diff, you *definitely* want to keep the full text (comments, etc) around. Some of this stuff is handled in ASN.1, the same conflict between the canonical rep and the on-the-wire rep. It's been very unpleasant to work with an abstract representation -- why not a canonical string format? Rohit Khare: The XML std is only *about* structure. Comment: The WAP forum has defined a canonical form: WBXML. EKR: from a security perspective, what's the point of hashing hashes vs. a byte stream. Comment: this allows you to recompute minor edits quickly. EKR: this is not a common case; most of the time you want to sign a whole document, once. Donald Eastalke: procedural point: Let's not do technical design at this BoF. The point is that there *are* different surface strings for the "same" XML. Next "speaker": Richard D. Brown's xml-dsig draft (not physically present due to snow storm). See slides. Dave Solo: should we be co-specifying a hash and a canonicalization functions, or just a pure canonicalization algorithm? JReagle: XML Syntax Working Group has defined requirements for XML surface string canonicalization Rohit Khare: and what of the XML Internal Set WG, its canonical in-memory complement? Brown's overall structure also specifies how to encode *a signature block* in XML (Signature tag with Manifest and Value (usually. base-64 signature data) subtags). Denis Pinkas (sp?): 1) can your sign part of the document (a signature at the XML level) -- if you can only sign the whole document 2) are we going to handle "electronic signature", too -- not just asymmetric mechanisms, symmetric sealing, but also formats for e-signing more than XML? Donald Eastlake: a standard in this space pretty much must address signing-by-parts. It is useful to have a standard for hashing alone, sig syntax without sig algorithms and policy, and there would, I suppose, also be value in a syntax for policy. My suggestion is a fairly focused short-term project, coming out of the Trade wg's need to sign and encapsulate document pieces Ian King: This wg's agenda seems to have 3 parts: how to hash; a structure/syntax for how to encode the hash; how does this fit with XML's parts, links, etc. Q: Why do we need more than 1 canonicalization format? dee3 A: some channels put constraints like, say UTF-7... are you saying there should only be one such function? EKR: yes. Todd Vincent: Legal XML working group (non-IETF) formed by 18 folks; we definitely feel there's a need for this WG. EKR: there are a number of flaws in draft-brown... (various technical points) Answer: Some of these have already been fixed, others still debatable. Donald Eastlake presented a slide of Milton Anderson's FTSC suggestions (e.g. criticality flag) Rob Frye: doesn't this smack of semantics? A: it only seems Anderson wants a place to put this information. comment: does this open a patch attack? a: not really, it would be signed in. Solo: it's a bad idea: experience in DMS was to remove it. dee3: my bias is that people should have places to put things if they're really determined. EKR: I reinforce dave. This bogs down every new attribute with a debate over 'criticality'. dee3: recall the only core sig attribute specified in the brown draft so far is time-of-signature. FSTC e-check itself wants to add proprietary stuff like location. EKR: pkix and smime show signs of precisely this kind of bloat. W3C will have a workshop in this space April 15-16. Eric Riscola: why ietf rather than W3C? Donald Eastlake: The IETF has more experience at this lower level and a light(er) weight process. However, it will be essential to coordinate with W3C. Mark Day: the usual model is that W3C develops stuff; some of it is deemed mature enough to transition over to another, larger or better-trained body like IETF. To my memory it hasn't gone the other way around. jreagle: coordination is the key ekr: the real problem, indeed, is coordinating the media type with the latest security technology. Less security expertise is needed; instead, it's a very, very XML-heavy problem suited to W3C jreagle: and RDF-heavy, too. balding buzzcut guy (:-): well, if you want parts, use *mime* to slice into multiparts. Donald Eastlake: yes, the brown draft does have hooks for external references and specifies simple packaging. The W3C plans to have a packaging activity. Donald Eastlake: presented the draft charter (see slide). Very aggressive milestones. Want to submit final I-Ds by August. Expecting lots of small changes, not hugely different choices. buzz-cut: there's an Application Area tendency to issue requirements documents these days. Donald Eastlake: Yes, that could be done as a first step Ian King: we need more specificity, break it down to detailed tasks. We need to contact more users (more than just financial and legal) Mark Day: at a minimum, the milestones should refer to W3C's workshop Donald Eastlake: Charter is unlikely to be approved until after the W3C workshop. W3C is an association of companies while IETF is one of individuals. Jreagle: yes, the wshop is very similar to this bof; a superset agenda of sorts, canonicalizing XML and RDF, links, processing composites, international policy, and client-signed XML Jim Galvin: this sounds a lot like a competition, semi-facetious though it sounds. I don't think 'coordination' is called for, these are two groups doing the same thing. Rohit Khare: we need to rule out-of-scope the kind of user-layer stuff such as XFDL (graphic positioning of form elements), verifying form POSTed url-encoded data. Charter could use some non-goals, too. buzz-cut: if this is just an xml-specific thing, there are other venues with more xml expertise. "show me what differentiates this from w3c" -- I suspect charter language binding this effort to other IETF working groups (like TRADE, or relates to S/MIME) JReagle: I recommend using namespaces to break out parts of the problem (semantics, etc). Barbara Fraser: we can't make these distinctions today. Jim Galvin: why do we care if other groups have xml applications calling for signatures. Answer: In the IETF there's vCard and other apps, too, ya know. Makes it valuable to have a digital signature standard early on in the process. legal sig guy: we've been having the same forum-shopping debate. I like having ietf's dsig experts and its greater accessiblity and openness. but I don't think it should be both IETF and W3C. comment: our company has a dozen different XML apps and they're all pursuing different ds strategies Rohit Khare: to state the obvious: you don't get ietf involvement for free -- let the "experts" vote with their feet. Bill Flanigan: why not have a second bof in Oslo -- what would be the functional difference than having a half-baked charter -- just let time move on. Answer: a goal of being a real WG is to raise profile, get involvement. JSchiller: there's a new rule: ONE BoF. I'd like to leave here *today* with a sense of direction, even if charter details are left to the list. Donald Eastlake: I agree the current charter is pretty generic and could be made more specific. STRAW POLL: unanimous consent that a standard in this area would be a "good thing". Paul Lambert: I'm not as comfortable ceding the whole area to W3C in the conditional-scenario. Mark Day: we could have a second BoF in Oslo on "what W3C wants to hand off". Donald Eastlake: I'd rather be prepared to carry the torch on the condition W3C is "not opposed" to IETF doing it. Poll: 40+ positive, 3-4 against. How many would actively participate in an IETF WG? Poll: about 40+. STRAW POLL on urgency: seems 3-1 for urgency, about 1/3 voting. (urgency means IETF Proposed Standard or W3C Recommedation out by end of calendar 1999.) W3C's Connolly speaks: XLink is still work in progress. Do you expect this dependency to persist in your draft? RK: DAV's experience required reference-by-copy while it was still W3C's work in progress.