- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Thu, 18 Nov 1999 13:30:00 -0500
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
http://www.w3.org/Signature/Minutes/991118-tele.html [1]IETF [2]W3C [3]XML Signature WG [1] http://www.ietf.org/ [2] http://www.w3.org/ [3] http://www.w3.org/Signature/Overview.html 99-November-18 Chairs: Donald Eastlake and Joseph Reagle Note Taker: Joseph Reagle [[4]ascii] [4] http://www.w3.org/Signature/Minutes/991118-tele,text Participants * Donald Eastlake 3rd, IBM * Joseph Reagle, W3C * Mark Bartel, JetForm * David Solo, Citigroup * Ed Simon , Entrust Technologies Inc. * Marc Pashoa, * Todd Vincent, GSU * John Boyer, UWI (regrets, couldn't get through to bridge) (Sorry for the teleconference problems to that didn't join.) Review of Outstanding Action Items Clean up from IETF meeting: slides/minutes < 5 minutes * Need slides from Boyer and Schaad * Boyer will send today, Schaad's were hand drawn, will check with him. Signature Syntax & Processing draft questions: * need someone to rewrite Parameters (and KeyInfo) such that we use elements like <prime>...</prime>. * Aside: Processing Model and reporting errors. + Do we need to specify a processing model whereby you determine what failed (signedInfo or the ObjectValue). Applications can do this at their option (Simon's prototype did) but we don't need to standardize on this. + ACTION: Solo, add a sentence or two security consideration that speaks that applications can do this sort of thing. Schemas &/or DTDs < 10 minutes * Include both. * Solo: IETF will likely want one to be normative. No opposition to DTD being normative if Schema is not stable. * However, people are happy with continuing to use the schema declarations in the body of the text as they are more expressive. Other questions/items from latest posted draft < 15 minutes * push the latest spec out to xml-dev and xml.com Securing Location/Transforms & Levels of indirection, Manifests, References, ... < 15 minutes ___ Reagle Summary: [ defn:DigestContent The content that is digested (versus earlier intemediary contents that are processed/transformed). Provoked email thread because 1. Detected a lack of common understanding of core validation. 2. Wanted further clarity on the assertions made is Signed Info (as distinguished from Manifest): Distinguish between: 1. Does SignedInfo mean DigestValue are checked: yes! (If in a Manifest: no, one might take those as trusted assertions.) 2. Does SignedInfo mean the URL must be dereferenced: no! Only means that the signature operates over the Digested Content. 3. Does SignedInfo mean the Transforms must be applied? not necessarily. Transforms specifies a set of Content that when Transformed yields DigestedContent. To rephrase: we are not signing a URL. We are signing the Digested Content, and in an odd sense, the class of documents that yield DigestedContent when transformed in as far as those parts that are kept. ] __ Bartel: Since encoding seems to be different from the other Transforms, propose that we move encoding into Target (as part of the hint): <ObjectReference URI=[5]"http://www.mypage.com" Encoding="UTF-8"> <Transforms> ... Call seems happy with this. [Notetakers Question: Can Encoding still appear in the transform, in both places?] Reagle: say one has to dereference the URL, decode it, XPath it and C14Nize it., if I have a document on hand that has already been XPath'd but no C14Nized, can I just start it mid process? Solo: Yes: Signer is only saying he signed the DigestContent. Everything else is a hint. If an application knows it does something, it can pick up the chain where it wants. Bartel: Agrees: if an application applies some of the transforms, save an intermediary step, and completes the other steps later, that is fine Reagle: The thing I'm not sure about is says there's a sequence of tricky transforms, could someone play a trick? Reagle: Is there some sort of assertion by the signer such that "there is a class of documents related to this DigestConent via these transforms?" Solo: No normative assertion, in the end the you are hashing/signing the DigestContent, and if you don't get the right DigestValue, the signature obviously doesn't work. Eastlake: David might be too stringent, there is some sort of assertion about those other documents. Boyer: In the users context, he's looking at the thing that is transformed, where certain parts may change or not, not necessarily the DigestContent min I'm focussing. Reagle: I think we agree that we don't need to make major change in the syntax, we do need to better define the semantics of the assertions within an ObjectReference. Let's take this to the list, please propose a set of assertions that you think are made by ObjectReference. Todd: in the legal context, sill concerned about the issue of what the user sees and what is signed (particularly) XSLT's. Call feels that the specification makes these distinctions fairly well. ACTION Todd: propose some text (a sentence or two) that he would like to add to spec, WG can then point out where it exists, or adopt. Boyer: Orthogonal quick question before the call ends: If you use a IDREF, does it include the element within which the ID sets, or only the element's content. Call: IDREF probably returns the element. Boyer: in Richard Himes' scenario, he only wants the content (because that is what is fed into the Base64 decoder if an encoded document is embedded in XML). Call: suspect if you want only the content, you will have to use a simple XPath like child::text(). [Note taker question: is the IDREF still listed in the ObjectReference, and then the further qualification is in the transform, or does the IDREF/URI="" and the complete Transform follows?] Con calls versus Thanksgiving/Christmas < 5 minutes * Nov 25th is holiday * Dec 2nd (Reagle Jury duty), Scheduled call. On that call reconsider the next two. * Dec 9, bridge reserved * Dec 16 bridge reserved * Dec 23th Christmas Eve * Dec 30th Holiday Face to Face meeting arrangements? < 5 minutes * Call feels one day (a Friday) is good enough. * Had said January 14, looking for location near San Jose, potential hosts include Verisign and Sun. * Solo: has asked about a location in San Francisco on the 14th, probably can handle 20 people. * Boyer: since the RSA conference ends on Thur (20), why not have it on 21? (Then people don't have to loose a weekend if they are doing both.) * ACTION Eastlake: confirm when RSA ends and propose one of the days (ask for RSVPs). * Solo's room might only be available on the 14th, doesn't know about 21. _________________________________________________________ Joseph Reagle Jr. Policy Analyst mailto:reagle@w3.org XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Thursday, 18 November 1999 13:30:01 UTC