IETF 46, XMLDSIG Minutes, Session 1 Evening of 8 november 1999 Notes by: Thomas Gindin Editor: Joseph Reagle Agenda [See Slides XMLagenda1.ppt] Introduction (Joseph Reagle) History - IETF BOF and W3C Signed XML Workshop in March and April 1999 - WG chartered, IETF meeting in Oslo in July. - Had Brown proposal in July, present draft evolved from a smaller proposal from end of August. Requirements document completed W3C - Last Call, now working its way through the IESG towards Informational RFC. - Near Future, Meeting in Washington DC at IETF (8-9 Nov), we will discuss reliance upon XPath/XPtr and XSLT - Canonicalization - algorithms and parameters - nteroperability testing - XML schema (presently usingDTD) Anticiapted Future Schedule: Charter Milestone Expected Date - "Consistent Draft" (push out to wider community for comments) - Nov 27 - XML Core to Last Call for Proposed Recommendation/Standard - Nov - Dec 21 - Face-to-Face - Early Jan - Jan 21 - Interoperability Test Cases and Results document to Last Call as NOTE / - Informational RFC - Dec - Dec (1st draft) - Recharter - Jan - Jan - Publication of Signature Syntax and Processing document as Proposed - Recommendation / Proposed Standard RFC - Jan - March - Face-to-Face IETF47 - March 27-31 Requirements (Donald Eastlake) [See Slides XMLreq.ppt] Scott Shorter: why are some of the algorithms mandated as part of interoperability requirements? Eastlake: It's the IETF way, and interoperability testing tends to show up and fix ambiguities. Denis Pinkas: are there equivalents to PKCS-7 Authenticated Attributes? Discussion: place information in SignatureProperties an Object. Eastlake: we should document how similarities between our specification and PKCS-7 on this topic. Pinkas Doubts that this can be done. Tom Gindin: In time, one might try producing an example. Barbara Fox: KeyInfo will permit the inclusion of certificates, but we don't define them ourselves. Syntax (David Solo) [See Slides soloxmldsig.ppt] Russ Housley: What hash algorithm is needed for ECDSA? Solo: It is just a placeholder for now. Tony Lewis: Do we handle RFC 2047 (Coded Words)? Eastlake: Optional to implement, since XML has its own method for this sort of thing. Michael Zolotarev: Is there any way to force the signature profile in the document definition? Eastlake and Solo: Not in the core syntax. Zolotarev: Can the signature policy for the document be in the document? Solo: Not in the core syntax, you put policy in an object and reference it from within SignedInfo. Zolotarev (clarification) Request: is for a way in which the document definition can stipulate the sets of data included, the objects included, and any transforms applied. Eric Williams How does s relying party (RP) make an assumption about the default KeyInfo when it is missing? Solo Typical use is protocol with negotiation (e.g. SSLv3) Schema (Ed Simon) Schemas are more extensible and precise than DTD's Especially name space handling. Reagle: Re Schema, proposes we try replacing DTD in our specification. URNs: Phillip Hallam-Baker: IANA is a more typical place for cryptographic algorithm URN's than W3C, as PEM already used it. Paul Lambert (or Housley): IPSec did too. Reagle: as long as it is registered (or otherwise normative) IANA URNs is fine. Please send me points to such URNs. KeyInfo (Jim Schaad) Paul Lambert: There is a trust ambiguity if multiple certificates have the same key. Barbara Fox: It is just a matter of policy to distinguish multiple certificates with the same key. Zolotarev: Certificate is a legitimate alternative to key. Pinkas: Is a reference to a certificate a legal value of KeyInfo. Schaad: Yes, it's legitimate. Gindin: Is Key Identifier the right name for issuer + serial number? Tom Gindin: if excluding signed location from the base is useful, why don't we define an optional keyword 'excludeLocation' in the object reference which would default to false? Reagle: we've been through the exclude flag idea before and choose to avoid that option. Fox Yes - the X.509 extension names are not relevant. Schaad: Parameter set is implicitly qualified by algorithm name. Gindin: Is hash algorithm a legal parameter to an RSA key? Schaad: It isn't even a legal parameter to signature method. Solo: We use signature algorithm ID's which include hash algorithm ID's. Open Questions 1 (Donald Eastlake) Notes by: Winchel 'Todd' Vincent Editor: Joseph Reagle [See Slides openQues1.ppt] Should We Put Dynamic Fields First or Use a Nonce? This would require changing the order. We do not want a variable order, we want a fixed order. Comment: Russ Housley: when we were doing this in PKCS7 and CMS ...the rule was put them in the order the validator needs them ... this supports pipelines . . Makes processing easier Comment: Hallam-Baker: I'm not aware of attack that uses preloading ... not talking about HMACS Answer: [Eastlake?] Yes we are talking about HMACS Comment: Hallam-Baker: we are talking about naive [??] ... asked on list of anyone could cite an example of a credible attack . . the only issue is with MD5; otherwise, to require constraints of re-ordering or a nonce, people should be able to cite a specific attack ... this is not well motivated ... please cite an example Reagle: Can anyone speak to this? Answer: [Someone] We should anticipate what might happen Reagle: Is this something we should worry about? Eastlake: Assuming this is a problem, seemed to me that this wouldn't save the attacker more than 15-20% ... Hallam-Baker: If someone showed that by preloading that there was a 1% advantage, then throw out the algorithm ... we assume cryptographers have their stuff right Eastlake: There is an advantage to putting elements in order then will be used Jim Schaad, Microsoft: I'm convinced that even putting them in the order they are used ... is not useful ... you need a lot of this stuff before you get to it anyway . . order is not important ... you cant parse and compute hashes at the same time Russ Housley: It must be two pass processing Eastlake: Could have one pass processing, but would need a way to delare what digesting should be done. Reagle: We also need readability Eastlake: Current ordering is logical Reagle: Need to have default . . Unless someone can cite an example, then we are going to stick with current order ... is everyone Ok with that? Otherwise, we assume the same order if no one can cite an example. NO NONCE Eastlake: Current signature algorithms do not need nonce ... Do you want to do these things optionally ... last time, conclusion was no nonce ... unless someone comes up with something, we'll confirm this decision. No response ALGORITHM PARAMETERS Eastlake: There are various types of algorithms ... there is consensus that parameters should be labeled for algorithms ... given this, other questions, if it is the case that an element takes only a single parameter, then you don't need the extra element ... two examples Decisions Needed (1) Optimize one parameter algorithm (2) type attribute versus namespace (3) generic element name versus integer/real/boolean/string/binary Other question ... Some parameters might be encoded attribute (orthogonal) Eastlake: Any comments? Reagle: I would like us to be consistent; would not like to make special considerations; would like namespaces, like integer . . etc. Dave Solo: agree with first two, but not sure about the third ... optimizing parameters is not a good idea ... I like the namespace approach ... not sure about third approach ... . Eastlake: This gives you an immediate data type up front ... Eastlake ... I don't care on the last question . . depend on how big of type [set??] you have. Someone: Don't see the value Eastlake: any other comments ... probably not enough to come to conclusion ... fist two points ... no one seems to be in opposition Eastlake: on the third point . . may lend robustness to parsers ...may help to know the data type Eastlake: might help the parser ... Not sure if this is really correct ... show of hand on last one ... (1) Generic Element (2) specific Element Schaad: want element name to be the comment . .. Don't care about a namespace ... Solo: This is what I thought I was advocating Eastlake: I will write up three examples for tomorrow UNSIGNED LOCATIONS AND TRANSFORMS Four Possibilities 1. Nested manifest 2. Move location outside of signed info 3. clever URIs 4. allows transforms to remove the location Reagle: my opinion: if receiver changes location, then it should make an assertion that the object at old location is the same as the object at the new location. Eastlake: but to verify the signature, you do need to get hand on data and digest it. Reagle: true ... Eastlake: the signature processor has to process the assertion Option 1: Nested Manifest: Comment [Someone]: one thing I will say, whatever we can say about nested manifest ... this makes it the simplest form, this keeps the core syntax simple, simpler than transforms Eastlake: agree, but not simpler than anything else Question: is it really harder to move an object than to just resign it; don't understand; if it moves, then resign it Solo: What if you can't get hold of the signer? Part of the question is what if the receiver wants to move it? Hallam-Baker: if we use URLs and URIs, and we keep semantics of URLs what they are supposed to be . . if it changes, then you have a problem ... examples, suppose we're doing trade . . .. Eterms ... doing things according to ETerm . . .ETerm is revised ... now you come along with signed document and data is changed ... whey you go to verity, the fact that ETerms has change is relevant Solo: if this is a URL, you can't do this . . if this is a URN, then might be OK ... pick the right name for what you are tying to support Hallam-Baker: person who creates the manifest should have control over whether object can move it if want ... instead of calling it resource or location ... call it a hint Solo: I agree Hallam-Baker: table of mappings . .. . Option 2: Locations Outside of Signed Info Problem: can have multiple ObjectReferences ... why don't we just move location outside and could optionally sign location ... but not as [??] Answer: Scott Laurence: the question as to whether to sign location is a unsolvable problem ... the fundamental problem is that you should not change things whose location has changed ... just shouldn't do it ... URL and URN distinction does not help ... if people change URL then they'll change URN ... . does not help to have an extra level of direction . . .behavioral problem on part of users ... Just shouldn't do this ... if you publish and sign it, then don't change it ... lots of ways to solve this problem ... gone through this same debate in XML schema ... Comment: URN gives idea that URLs are OK to change . . .cant solve with another level of indirection Eastlake: This will be used for variety of situations ... easy to imagine ... should be able to have it the same way Answer: But if you sign it, then it shouldn't change ... if you don't' want to sign it, then dont ... if you sign it, then there is an immutable relationship Eastlake: I think I agree with you ... in every situation ... .every case I'm showing Reagle: I agree with last speaker ... I signed the content of the dereferenced URL Boyer: ... then don't remove the location Reagle: Unfortunate that this is "location" ... should be "target" ... Location is inviting has URL semantics thata we are not intending. Thomas Gindin: if excluding signed location from the base . . ..[missed this] Eastlake: it is not different that putting it in different place ...don't want to be able to put it in two different places ... would have to put something in low level hash stuff Comment (Someone): I'm uncomfortble having a signature over a hash . .without a target ... ... Crowd: No . . if you can do that . .. Hallam-Baker: A hack that could work ... you've got the resource, what you are really signing is a resource that has been retrieved on a particular date and time, . . .. Would be . . .what was resolved from this URI on a particular date and time . . .XYZ . . data, optionally date ... Pretty gross . . .but perhaps that [??] ... You can't ever retrieve it again Greg Whitehead: one case is where signer moves the resource and the other is the situation where the retriever moves it; in the first case, if the resource moves, then the signature breaks. In the latter, we can handle that the cache has moved something Reagle: This is what I was saying Eastlake: in IOTP . . you sign an element with an ID . . the intent is that parties can cache it over . . messages, organization by . .. Move message forwards ... all Ids globally unique ... this is a case of caching . . Option 3: Smart URIs Eastlake: Another possibility ... smart URI ... if the transform changes, not clear how you would handle that SOLO: they all seem to relate to ... I'm not sure tha complexity of . .. Apply X versus make it X . . the extent of cleverness Option 4: Transforms of SignedInfo Eastlake: This was described by John ... dangerous to security, but not clear this is anything worse than what you can do with transforms Reagle: earlier we decided not to go the exclude route for our selections, would be somewhat inconsistent to apply it here now Solo: There is a difference in applying transforms to core syntax than to objects ... Reagle: if someone screws up an object reference, then that is their problem (resource validation), but if we let people mess with signed info that is a larger problem (signature validation) Boyer: I don't agree ... what is the difference between when signed info breaks ... and when the object is changed and breaks Solo: Gives you potential to have a valid result for something that shouldn't be and that is the difference versus having a invalid response for something that should be valid! Question: Terry Hayes: . . .: Is Xpath stuff required as basic capability? Answer: Eastlake: It is recommended, not required Question: Terry: if you rely on this, then basic applications aren't going to be able to ... [?? Missed it] Answer: Eastlake: Recommended: you should do it unless you have a good reason not to Eastlake: We need to decide what to do ... main alternative ... allow location to occur in two places ... same as putting flag on it and not including it in the digest . . not sure what the solution is ... we'll revisit tomorrow Reliance on Xpath/sprt/xslt Eastlake: This provides filtering functionality that we need . Reagle: This is recommended not required; I'm comfortable with this . Eastlake: I don't see a problem ... will stay this way . ============================= IETF 46, XMLDSIG Minutes, Session 2 Afternoon of 9 November 1999 Notes by: Winchel 'Todd' Vincent Editor: Joseph Reagle [See XMLagenda2.ppt slides] New Scenarios (John Boyer) Problem with current draft: You can't change the location of an object without breaking the signature. Presented three scenarios brought up by WG members that need the problem solved. Question: Phillip Hallem Baker, VeriSign: I'm mystified ... if I say the signature should fail if the URL is changed ... and if this [the URL] is not where it actually is, but is where you might causally pick it up ... then we don't need a signature spec ... this is a hint resolution mechanism . . . Answer: John Boyer: Is this a question? What I am hoping for is a situation where we are able to solve this problem ... I want to sign it, but I want to move it around ... can't do that unless location is out entirely, but this is application specific Question: Davo Solo: Can we table this for tomorrow; I agree with most of what Phil is saying; there are security and processing problems if you allow transformations to be applied to signed info; I think this is slightly bad to a very bad idea; I would prefer something different Comment: Eastlake: There are various solutions in the open issues Answer: John Boyer: Its an idea, maybe not the best idea ... people want to do this . . propose something different. Comment: Hallam-Baker: direct transform ... I don't' like this ... it is a great way to play with the digest value ... if this was a mapping to where it was to where it is, then OK John: I agree this is a security problem (C++ example ... but is a standard nevertheless) ... the more flexible we get, the less secure ... the whole issue of transforms hurts Question: Carl Hewitt, MIT: Why not pull the URL out and have a separate signature ... Answer: John Boyer: We could bring it out into the manifest (one of Don's suggestions) Question: Someone: What we are discussing is how to exclude parts of signed info, might be easier to do by having a multipart ... signature = exclude Answer: John Boyer: sure ... we already have transforms and they do the job ... we have the C18N ... I"m not saying you need the full flexibility of the transforms ... it is one idea . . it also solves the second problem ... Rich Himes pointed out that if you have this simple idea of signing a data record ... want to do a database lookup ... all identified by their ID . . if you put 23 [??] in the same document, then the ID is the same, then identifying by the ID attribute ... have a need to toss out the ID, I want to validate the contents . . this is just a way ... [??] ... need to drop the defendant record ... I want to change it to d record 1 ... 2... 3... this could be solved by the same mechanism John Boyer: Third scenario (Rich Himes also mentioned this and Solo): I want to take a document and transform into base 64 and envelope it in an XML-Signature ... use the signature element as a method of delivery ... suppose it is a Word Processing document ... want to pull it out and store it in binary format, throw the object away and retain the signature ... needs to be stored in binary format to be useful to application ... A person puts the document in base 64 in markup ... transforms ... go get base 64 and decode it and then ... want to take the object and put it somewhere ... change the location . . want to drop the transforms out ... because you no longer need to decode it ... dropping the location and the transforms ... not dropping the digest ... John Boyer: Of course, you can shoot yourself in the foot with this method ... if we did go with something like this, then we wouldn't have to worry about where to put the C18N, because it is in the transforms Question: Joseph Reagle: What is the first set of assertions ...content is content ... when you start moving it around, get scary ...I would prefer ... that the receiver ... the thing I decode and store at location is the object that was yeilded by dereferencing ... . Answer: John Boyer: not a good idea, because the recipient wants to prove the signer signed [??] Comment: Reagle: If this is the case, he could reencode ... he should keep it in his native form ... [people are] not going to trust all of these manipulations Reagle: The first and third scenarios ... I'm not sure this is our problem to solve ... not our problem ... this is an XML packaging problem Eastlake: In these cases where you are modifying something later and there is a transform to drop the thing that changed because you moved something . .. That would have to be there when it was first signed ... Implementation (Ed Simon) XML Signatures, Notes III, afternoon of 1999.11.09 Author: Hilarie Orman Editor: Joseph Reagle Introduction to canonicalization issues, C14N Implementation by W3C presented by Reagle. Currently: Canonicalization over objects; WG agrees it is an option of the signer; Canonicalization over SignedInfo is option of the signer -- but we probably should have a mandatory to implement. Three proposals have been considered for Mandatory: none, simple, XML according to canonical/XML/infoset XML Canonicalization (Joseph Reagle) XML Canonicalization (Donald Eastlake) [see canon.ppt slides] Emphasizes that equal objects must canonicalize to exactly the same value. Some parsing is DTD dependent. Both DOM and SAX destroy attribute ordering; canonicalization must result in a serial stream in a deterministic manner. Need to have something that designates the type of canonicalization and the algorithm. Currently the CanonicalizationMethod is optional, but if present the Algorithm attribute is mandatory. Suggest that most implementations will use DOM, possibly SAX. Suggest that W3C method be the normal solution for that case and that the mandatory to implement be Minimal canonicalization. Poll on changing (removing optionality) vs. staying the same: audience seems to favor adopting a fixed method if possible. However ... Dave Solo: suggests it is too hard. Asks why not have fixed set. ??: says that this is different from S/MIME because different application areas will not interoperate; need to have assurance that the infrastructure supports the goals, but need to allow application areas to choose the best canonicalization methods for their uses. John Boyer: prefers specification of canonicalization methods because XML itself does not change ordering as does DOM or SAX. Eastlake: notes that there is no default in current spec; that is very minimal. Boyer: the XML spec is clear on minimal input processing ; would like default to be XML 1.0 compliant. Says that some attribute normalization is specified, depending on whether or not processor is a "validating" one. It will resolve entity references immediately; the data after that resolution is what should be signed. Reagle suggests that comments should be written up. Don Walky? (of Mitre?) says that he could see requiring everything in SignedInfo? Open Syntax Questions 2 (Donald Eastlake) [see openQues2.ppt slides] Algorithm parameters for SignatureMethod Shows three methods, using parameters from different namespaces (for the truncation length and signature value). On The Desire to Have Data Move Around: 1. One option is nested manifests; have the option of signin second manifest separately. 2. If the Location is outside of the SignedInfo, then must also move the transforms outside. Notes that this does not require any format changes. 3. Allow transforms that omit Location from the SignedInfo. Boyer: transforms on signed info are not really a big deal. Eastlake: it allows techniques that don't need Transforms. Boyer: notes that "where you get the information" doesn't matter in many cases. Reagle: this can be left to the application; no one is forced to include Location in signatures. Reagle says that Location should be called "Target" or "Reference" and as a URI could be a URL or URN or some other URI scheme. Poll on how many people would like to change; options are the three Eastlake options above: 1. about 15-20 for first option 2. one 3. one Eastlake: notes that only a few people expressed a preference. If Location is missing, application can make assumptions from its history. Speaker notes that Location is already basically optional (it can be omitted and you could put it somewhere else. Reagle: asks why multiple references must have Location; Dave Solo: this is necessary for consistent processing; suggests changing current wording to "if more than one object, all but one must have Location" from current all must have Location if more than one are present. Eastlake: receives no objection to "multiple locations can have 'something' for Location" and one can omit it Composite/Orthogonal Algorithms A composite name doesn't allow one to discard a component algorithm (e.g. MD5), but orthogonal names are bulky in comparison. Dave Solo: comments that Composite makes sense. Roy, UC Irvine: Composite allows you to forbid certain combinations as in TLS; it a nuisance to have to register each composite. Jim Schaad (Microsoft): the signature algorithm element identifies "everything"; he favors orthogonal because they can be processed sequentially. Rohit Khare: seems to favor composite. Poll shows about 30 for composite, under 10 for orthogonal. Reagle: continue with composite but he'd like to see more discussion and examples on list. Administrative Matters Teleconferences have been held on weekly basis. Reagle asks if it is still favored. One person requests that they be an hour later. Another person states that time would conflict. Reagle comments that a goal is to be "European friendly". Result: continue at same time. Discussion of when RSA conference will happen; January 13th or 14th is suggested for an XML DSIG meeting. Overlapping with another meeting (SETCo). Looks like only a few people would be affected. Plans will be settled accordingly. Expect new core syntax and processing draft in week or two.