| Activity | Charter | Expected |
| "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 | Jan 7/10 21/24 | |
| Interoperability Test Cases and Results document to Last Call as NOTE / Informational RFC | Dec | Dec (first 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 |
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 (Passport check) later.
Barbara Fox: KeyInfo will permit the inclusion of certificates, but we don't define them ourselves.
Canonicalization open for future standardization. Open issues on location changes. Transforms may include canonicalization.
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)
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.
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 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.
This would require changing the order. We do not want a variable order, we want a fixed order.
[SLIDES]
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
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 ... <HMAC length ... namespace>
Solo: This is what I thought I was advocating
Eastlake: I will write up three examples for tomorrow
Four Possibilities
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
[SLIDES]
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: (Missed it)
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 . .. .
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 . .
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
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
Person In Front Row: signer might think ... [Missed this ?? ... to fast]
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
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
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.
SLIDES
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 [agenda]
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 ...
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
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?
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:
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:
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.
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.