NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99
J. Reagle <email@example.com>
Donald Eastlake 3rd <firstname.lastname@example.org>
Security Area Director(s):
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Security Area Advisor:
Jeffrey Schiller <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: Nothing. Enter (un)subscribe in SUBJECT line
Description of Working Group:
Digital signatures provide integrity, signature assurance and non-repudiatability over Web data. Such features are especially important for documents that represent commitments such as contracts, price lists, and manifests. In view of recent Web technology developments, the proposed work will address the digital signing of documents (any Web resource addressable by a URI) using XML syntax. This capability is critical for a variety of electronic commerce applications, including payment tools.
The mission of this working group is to develop an XML compliant syntax used for representing the signature of Web resources and portions of protocol messages (anything referencable by a URI) and procedures for computing and verifying such signatures. Such signatures may be able to provide data integrity, authentication, and/or non-repudiatability. The meaning of the signature may be extensible by a set of semantics specified separately.
JOINT IETF / W3C COORDINATION:
This effort is equally and strongly dependent on XML expertise and coordination, which is in the W3C, and Internet cryptographic expertise and coordination, which is in the Internet Engineering Task Force (IETF). Therefore, the working group will be a joint body operating simultaneously as an IETF WG and a W3C WG. Procedures may differ from the norm for either organization (IETF RFCs 2026 / 2418 & World Wide Web Consortium Process Document). Details are give in the sections below.
The core scope of this activity will be in specifying the necessary data model, syntax, and processing to bind a cryptographic signature to a resource in XML. The working group will focus on:
1. Creating a data model that permits XML-DSig to be an integral part of developing metadata and object model technologies.
2. Creating a extensible canonicalization framework. In addition, specify application requirements over canonicalization. At least all XML-DSig applications must be able to sign - at least - the binary byte stream. The group may also require applications to support XML syntax or Unicode canonicalization if those mechanisms are widely understood and necessary. This group will coordinate its requirements with activities delivering XML, RDF, or DOM canonicalization mechanisms.
3. Syntax and processing for XML signatures.
4. Document the WG's position on signature semantics with a non-standard-track document. At the Chair's discretion the WG may develop a (small) set of signature semantics. Such a proposal would define common semantics relevant to signed assertions about Web resources and their relationships in a schema definition (XML/RDF) or link type definition (XLink).
5. Defining the charter for subsequent work once (1-4) has been achieved.
The following requirements must be met by the WG:
1. Define a simple signature XML syntax that is highly extensible. We wish to create a simple digital signature syntax that can be used with other application semantics (through XML-namespaces) so as to create arbitrarily sophisticated assertion capabilities.
2. Ensuring that applications can create and process composite/compound documents consisting of XML and non-XML data as well as for processing detached or external signature blocks and assertions.
3. XML-DSig must be coordinated with and use the work product of other mature XML technologies.
4. XML-DSig syntax expresses data model semantics; we do not require applications to make inferences on that data model.
5. Mandatory portions of the specification must be implemented in at least two independent implementations before being advanced to Proposed Standard.
The working group will not address the following issues:
1. Trust engines
2. Public key infrastructure
3. Trust management systems
4. XML schemas for certificates
It is hoped that the following applications being developed by members of the WG will provide a useful test of the completeness:
1. Internet Open Trading Protocol v2.0
2. [some document / web-page application TBD]
3. Financial Services Mark Up Language v2.0
This working group will deliver the following:
- Informational RFC (W3C NOTE) further specifying the requirements and dependencies for the remaining deliverables.
- Proposed Standard RFC (W3C Recommendation) that defines a highly extensible XML syntax and processing used for associating a signature with XML data without semantic specification but having provisions for the inclusion of such specification.
- Informational RFC (W3C NOTE) on signature semantics labeling and, if appropriate, an additional (small) set of signature semantics in a schema definition (XML/RDF) or link type definition (XLink).
- Informational RFC (W3C NOTE) documenting a set of test cases for interoperability testing and a report on interoperability results.
- If appropriate, charters for further work.
COORDINATION WITH OTHER W3C GROUPS:
A central characteristic of this activity is its dependencies on other XML working groups. The WG chair will likely be a member of the W3C XML Coordination Group. During W3C Last Call, the Chair will procure reviews from the following W3C WGs before the specification will be advanced further:
1. XML Syntax WG: Canonicalizing XML which involves finding a single or "canonical" version of every possible form of the same document by reducing white space, mapping quote marks to a standard form, etc. etc.) with a view to using that standard form for the purpose of applying digital signature technology.
2. XML Linking WG: The objective of the XML Linking Working Group is to design advanced, scalable, and maintainable hyperlinking and addressing functionality for XML
3. XML Schema WG: The XML Schema Working Group is addressing means for defining the structure, content and semantics of XML documents.
4. Metadata CG: The RDF Model and Syntax provides a uniform and interoperable means to exchange the metadata between programs and across the Web. Furthermore, RDF provides a means for publishing both a human-readable and a machine-understandable definition of the property set itself.
Working group members are expected to participate in an electronic mailing list, periodic teleconferences, and face-to-face meetings. The sole WG consensus venue is the mailing list.
Group Home Page:
In order to maintain shared context of the group and to provide access to the proceedings of the group, the Chair maintains a web page at http://www.w3.org/Signature.
Active participants are expected to have ready access to this page and be familiar with its contents.
There are expected to be teleconferences held every few weeks at a time set by the Chair. The exact frequency of calls will be determined by working group consensus.
The Chair is responsible for producing an agenda at least 24 hours in advance of each call, posting it along with the call details to the mailing list, and causing minutes of the call to be posted promptly after the call.
Face to Face Meetings:
The working group will have a two day face to face meeting in or near September 1999 and meet at the July and November 1999 IETF meetings and may have additional physical meetings by consensus of the WG. Meeting notice, advance agenda, and posting of minutes shall follow W3C timing rules.
IETF / W3C PROCESS SYNCHRONIZATION:
WG documents will be dual published in both the IETF as Internet-Drafts or RFCs and in the W3C, via the web. Differing delays in the processes may cause skew in the appearance of a document in the two locations.
When a document is subject to a Last Call in both organizations (Working Group or IETF Last Call in the IETF, W3C Last Call or AC Review in the W3C) comments received in both venues must be considered and responded to. In effect, the Last Call period will be longer of the times allowed in the IETF and W3C.
The rough equivalence between document types in the IETF and W3C is as follows:
IETF -- W3C
Informational RFC -- Note
Working Group Internet Draft -- Working Draft
Working Group Informational RFC -- Working Draft
Proposed Standard RFC -- Proposed Recommendation
Draft Standard RFC -- Recommendation
Full Standard RFC -- Recommendation
If a document is substantively changed such that it recycles to a lower status in either venue, the corresponding document classification in the other venue should also change.
IETF Last Calls for joint WG documents which are on the IETF standards track will be 4 weeks per the Variance section of RFC 2026.
DECISON PROCEDURES AND APPEALS:
The working group itself will operate by consensus as provided in the IETF rules.
Appeals from decisions by the working group chair may be taken using eithern the W3C or the IETF appeals mechanisms. It is expected that these mechanisms will coordinate and differences are not anticipated. Nevertheless, if and when the appeal mechanisms of the W3C and IETF come to irreconcilable decisions, the group will thereby cease to be a working group of either the W3C or the IETF and may not take further official action under the procedures of either organization without explicit rechartering.
Should either the W3C or the IETF unilaterally terminate the Working Group status so far as that organization is concerned, the WG will continue to be a working group of the other organization.
Working group members must disclose intellectual properties "that are reasonably and personally known" to be relevant to this WG in accordance with IETF (RFC2026) and W3C procedure; including notice and disclosure of such information to the WG, and the IETF Executive Director.
Once established, the Working Group can decide to parallelize more tasks by forming subgroups. The Working Group can also decide to reschedule tasks that do not have to meet deadlines imposed by other groups. However, the schedule must fit into the total timeframe given below.
Also, document dates may not be rescheduled without notifying the W3C Domain leaders, the W3C director, and the IETF Area Director. Note that delay of deliverables can be a reason for the Working Group to be terminated.
Goals and Milestones:
Submit first Requirements draft
Meet in Oslo Norway at IETF
Submit first Syntax and Processing Draft
Requirements document to Last Call for Informational RFC / W3C Final Working Draft
Hold two day Interim Meeting
Submit Internet-Draft of interoperability test cases
Meet during IETF in Washington DC
XML Signature Syntax and Processing document to Last Call as Proposed Standard / W3C Proposed Recommendation
Signature Semantics document to Last Call as Proposed Standard / W3C NOTE
Signature Semantics document to Last Call as Proposed Standard / W3C Proposed Recommendation
Interoperability Test Cases and Results document to Last Call as Informational RFC / W3C NOTE
Submit Signature Syntax and Processing document to IESG for consideration as a Proposed Standard RFC / Proposed Recommendation
WG recharters if appropriate
No Request For Comments
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)
- 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
- 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.
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.
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
UNSIGNED LOCATIONS AND TRANSFORMS
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
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.
On XMLDSIG Canonicalization
XMLDSIG Open Syntax Questions
XMLDSIG Open Syntax Questions 2
XML Signature Core Syntax