IETF 48 XMLDSIG Minutes [1]ascii] [1] http://www.w3.org/Signature/Minutes/000803-Pittsburgh/Overview.html,text These minutes cover the XMLDSIG Working Group meeting held on August 3, 2000, at 15:30 hours in Pittsburgh, PA, USA at the 48th IETF. They include comments from the briefing presenters. Author: Walter Houser <[2]houser@cpcug.org> Tweaks: Joseph Reagle <[3]reagle@w3.org> & Donald Eastlake 3rd <[4]Donald.Eastlake@motorola.com> [2] mailto:houser@cpcug.org [3] mailto:reagle@w3.org [4] mailto:Donald.Eastlake@motorola.com Working Group home page: http://www.w3.org/Signature/ [5]Agenda [slides] Donald Eastlake (DE) [5] http://www.w3.org/Signature/Minutes/000803-Pittsburgh/agenda.html * 15:30 Agenda Bashing * 15:35 Document Status * 15:40 Technical comments and discussions re Canonicalization - namespaces -XSL * 16:20 Interoperability Results * 16:40 Technical comments and discussions re Syntax and Processing - Internationalization * 17:10 Other, Announcements - XML Encryption (B. Fox) * 17:25 Future Meetings/Calls (if any) Agenda Bashing - Donald Eastlake said that a later time in the week was requested for the working group meeting so some interoperability testing could be done earlier in the week. John Boyer stated he would cover enveloped signatures during his presentation on canonicalization. [6]Documents' Status [slides] Joseph Reagle (JR) [6] http://www.w3.org/Talks/2000/0804-ietf-xmldsig/slide2-0.html Joseph Reagle (JR) - We have two documents in process and one completely through the process. IESG and W3C have resolved their copyright language questions and the Requirements document, whose text was final long ago, is now out as RFC 2807. On the main Syntax and Processing document, IESG had changes on format and copyright. W3C asked for internationalization and canonicalization. We see these two as doable in the short term. Canonicalization - John Boyer (JB) @[link] The process of canonicalization requires that XML be consistent. For example, we chose to use double quote marks instead of single quote marks. The most serious issue that remains is how to handle the xml:base tag. The xml:base tag defines a base uri. Canonicalization requires the replacement of a URI with the content of the base document. Most XML parsers do not distinguish the resulting document content by it source - internal or external. There are also subtle changes that can occur with the incorporation of URI content in the document. It is likely that this will cause problems as signatures do not typically require further processing. I see two options: Do nothing or embed the xml:base attribute. JR - Do you have a preferred solution? JB - Each has its problems. Perhaps we should wait. JR - My bias is to do nothing so we can move the document forward. What is the preference of the WG. If you don't know the issue or don't care, do not raise your hand. Twelve supported the Do Nothing option. None supported the embedding of attributes. JR noted for the record that the WG was not happy with either. Donald Eastlake (DE) - Currently canonicalization makes start tags longer. What about adding a new line before the close angle bracket at the end of start tags to make the lines shorter and the canonicalized output more human readable. JB - this may mess up indenting. It does not change meaning. JR - We have been through last call; won't the implementers have a concern with a change? Brian LaMacchia (BL) of Microsoft - I am against this change to the draft. Canonicalized output is not viewer friendly. We have had implementation problems with white space preservation under other circumstances. DE - My interest in this is not that strong. JR - Let's leave this unchanged. Are there any other concerns? JB - The enveloped transform is messed up. The inside transform is an xpath. The processing model calls for octets to be returning a node in the wrong node set. It isn't necessary to express __ . When the document comes with a signature element, the hash is created and then placed in the signature element, breaking the enveloped signature. A fragmentary URI [one ending with a # fragment specifier] would have a different transform model. We could push the problem off as a reference URI rather than do a down path transform. But when the URI is a fragment, how do we get from a location set to an octet stream? JR - Where is the location set defined? JB - [7]XPointer. It's definition is similar to a node set but also includes points and/or ranges. When a range node includes portions of other nodes, we should throw an error as we are only interested in full nodes. Or we could change xml:path to xml:pointer. [7] http://www.w3.org/TR/xptr#dt-locset JR - I can check on that [the reference is ambiguous] JB - Those implementers that have already done the xml:path transform may see the xml:pointer transform as extra work. JR - In the spec we discourage the use of fragment identifiers within the Reference URI and limit it to "" or "#fragment" (XPtr bare name). Are we arguing otherwise now? JB we are indicating people should specify Reference URI="#xpointer(...)". The bare name XPointer indicates the signature property but not ___________ . JR - So you believe we are being ambiguous and should specify this. What do the implementers say? BL - After our powwow, we are concerned that we are pointing at a node stream when we don't know how we can canonicalize it. We rather that it be that whenever you reference something, you are ALWAYS returned a octet stream. JB - Perfect. If we write the enveloped signature Xpointer/Xpath expression and call the canonicalization method. We should assume that the URI process always returns back a byte stream. So the following would be required: BL - Should we continue special processing when the referenced document may or may not have be previously canonicalized? JR - That's a question for the XPointer people. JB - We should put the canonical transform into the signature transform. But how do we know if the URI is capable of canonicalization? BL - We need a _____ step. Phil Hallam-Baker (PHB) - What if the XML is not well formed? JB - Good point. We should assume that a reference URI returns an octet stream. But we do not assume that the stream is not itself canonicalized. To have interoperable signatures, a canonical transform should be added. For example, see section 2.2 Extended Example Object Signature Properties. It will now have to look like: k3453rvEPO0vKtMup4NbeVu8nk= The fragmentary URI is typically a location set. It may be well formed. It may not. Different XPath engines may yield different results. JR - We should include this in the definition of Enveloped Signature. Are we going to assume every step is an octet stream? JB - If we have two successive transforms, we can treat it as if it were one. The enveloped signature will rewrite a reference URI and we will add a transform for canonicalization. Interoperability DE - The next topic is interoperability testing. BL - We held interoperability tests this past week. Petteri Stenius (PS) - The test results have been good, despite some minor ambiguities. Our implementation does interoperate [with IBM's] on all current features except Xpath transforms and its new features. Those features are coming up. We have enveloped signatures per the current specification, which is the most important. BL - We have tested with three implementations using three different XML parsers and two and a half different crypto systems. I have enveloping signatures working. We are using both RSA and DSA key values. White space is inside the tags is currentlybeing removed by my XML parser, breaking most signatures, but this will be fixed shortly. JR - Thank you. We appreciate this work. ?Baache - Was the parser with the white space bug shipped? JR - They fixed it first. We need the working group's ideas about auto responders? Next is Ed Simon (ES) from Entrust to talk about earlier interoperability test findings. ES - Here are the results from the May-June interoperability tests for REMTEC [now Done Information, Inc.] and IBM. This testing is important as the IETF requires two interoperable implementations before an RFC becomes a ["Draft" or higher level] standard. Note the sample code to build a simple auto responder. I also want you to see the Multimedia's report of their interoperability tests for their SMIL player. The first is a table of test results for XML schema by vendor. The second table shows results for test cases by vendor. It appears that vendors can enter their own test results. We should consider a similar set of tables. JR - No comments? Thanks Ed. We have nearly closed our last call save for a few small issues I would like to cover today. First, Ed Simon asked that we require style sheet root nodes. Within a namespace, one could pick any element. But we want people to pick the root elements only. We should change the text to read _______ [8]Syntax Issues from the list [slides] Joseph Reagle (JR) [8] http://www.w3.org/Talks/2000/0804-ietf-xmldsig/slide4-0.html ES - Hard wiring the schema will enable validation. JB - Previously we decided to use named parameters in our namespace. We should keep XSLT wrapped by a dsig parameter tag. JR - My recollection was that this was a placeholder. JB - I am happy with your proposed prose. But I want the XSLT wrapper around the style sheet reference. Decison: Retain XSLT element type in DSig name space. JR - Comments? Hearing none, the next question is whether the X.509 keyinfo element types should be removed? Brian Lamacchia (BL) has noted we are not doing this very well. It is not in our charter and should be worked out by other working groups. I see two options: clean up these specifications or drop them. BL - If you want multiple certificates, you can use the X509 data clause. We propose the use of multiple certificate clauses, like the PK bag of certificates. Russ Housely (RH) - Are we allowing attributes in the bag? BL - That would require different decoding code. Would the PKIX WG want to add yet another type? This sort of creeping complexity is part of the reason why I raised this issue in the first place. For any decision we make here, there will be questions as we aren't PKIX. PHB - Let's focus on what's out there. There is a lot of PKIX and X509 deployed, but attribute certificates and TSP tokens are not common. RH - CMS [Cryptographic Message Syntax, RFC 2630] allows both certificate types with separate tags. BL - This is an issue for the list. Steve Farrell - Just use Public Key certificates. DE - I will draft the language for the list to comment and decide. Decison: Donald Eastlake will propose text that is sufficiently general so as not to be ambiguous, otherwise we still have the option of removing this section. JR - We should be more specific about our definition of XML signature type for the purpose of conformance requirements. For example, Gregor said the term signature properties should be singular as the plural form was confusing to non-native English speakers. JB - If we change that, we should review the entire document for similar instances. JR - The term has no real significance. DE - The signature properties does not have to be inside an Object. If we make this change, then could be used outside of an Object. As you know, that's something I wanted to do anyway. JR - Given the manturity/status of the document, we should keep it in unless there's consensus to chage. Are there any other comments? Decison: Retain SignatureProperties element type in DSig name space. JR - OK. The next comment was that the DTD example was not realistic. The example, was a generic illustration and would need modification before application. JR - The final comment was one I had. I am concerned that a style sheet could be changed to hide content while not invalidating the signature. JB - Should we change the language from SHOULD to MUST with respect to style sheets? Signing the XML and the style sheet should be enough. We do not need to sign the rendering. ES - The scenario is valid. We should mention the possibility of it happening. But other equally plausible scenarios suggest that a requirement would not be appropriate. Dave Solo - I echo Ed Simon. MUST would mandate behavior that is unimplementable. JR - Fine, let's take a straw vote. If you don't know the issue or don't care, do not raise your hand. How many in the WG say we should put this in lower case? [Eleven raised their hands]. [None indicated the specification should stay the same]. [One asked for a stronger position]. Decision: convert directive in Section 8 to lower case as they don't relate to the conformance of the syntax or signature application. DE - Other topics? BL We are planning an informal discussion of XML encryption at Crypto 2000, Thursday, August 124 at 1:30 in the Anacapa Formal Lounge. The conference is at UC Santa Barbara. Barbara Fox is coordinating the event. For more on Crypto 2000 see http://www-cse.ucsd.edu/users/mihir/crypto2k.html DE - Given the nearness to completion, I suggest we hold two or three weekly teleconferences to nail down the final details. We've held them on Thursdays at 1:30 pm Eastern time which seems to be the best time for overall convenience. The issues will be X509 and canonicalization. JR - Signature is waiting for Canonicalization. If we can finish canonicalization within a 2-3 weeks, I'd estimate 2-4 weeks of process before it reaches Candidate Recommendation in the W3C. We can have the Signature specication cued up right behind that. Canonicalization is to be issued as an Informational RFC in the IETF.