Chair Comment: Presentations are linked from the panel description, and panel notes follow inline. I apologize for those presentations in PowerPoint. Such presentations can be viewed with certain tools, if this does not work please contact me I might be willing to re-install the application and grab the text out of the document for you. Some of the issues discussed are addressed by my summary.
Introduction (85m)
Scribe: Eric Prud'homeaux
Editor: Joseph Reagle
___
frame the workshop goals for signed XML
Joseph - do URLs get too big
anyone who puts fixed length gets shot
Joseph - how much unparsed data should we have (e.g. X509)
Ralph - can't answer in a generic way
good to leverage existing infrastructures but bad to be bound by them
can recode in RDF - e.g. recode X509 in RDF
can be hard to map to RDF because you must define all ambiguities in the original data
namespaces
XML community needs to address - can I ignore this namespace
upgrade path should be machine readable
Bob Rellia (Netscape) - concerned about trying to recode security objects in RDF
need to support in SSL
the security language needs an RDF parser rather than just having that in the XML parser
<Tim:reply>
agreed with issue
all this stuff is metadata
has much personal info that appears in privacy info and other domains
found in P3P they could not isolate the privacy stuff
while walking web data - do not want to find a certificate and have to parse it a different way
<challenge>
there will be stuff that wants the raw X509
<Tim:reply>
<challange:Dave Solo from CitGroup>
balance between visual signatures against reliance on references where underlying content my change
how do we draw a line saying "this is a frozen relationship"
<Tim:reply>
<challenge>
how far do you have to recurse - what is the obligation of the signature checker
<Tim:reply>
<challange:Richard Heims>
confused about digital signature in RDF format, or is it signed RDF
<Tim:reply>
<challange:John Boyer UWI>
embedding hashes only
tendency to say this resource has this hash - breaking this has make this statement hash
web space is dynamic - people will add a space and break a million signatures
should we import a copy
<Tim:reply>
<challenge>
a lot of times in practice - folks have much less control than they thought
<Tim:reply>
<challenge>
suppose I signed a doc when there was 40 members and now there's 41
<Alan>
if it's important that there be only 40 members, then you sign the 40 members,
otherwise you need to sign the signer of the list and you need to know which you want to do
<Richard Brown>
position of W3C regarding RDF - everything is an assertion
if we go the route of RDF document, everything will be an RDF document
will XML exist tomorrow except to encode RDF?
<Tim:reply>
<Joseph>
do you think it will be a requirement of this working group to use the RDF syntax as it exists today?
<Tim>
the answer should be clear by the time we need to define data models.
<challenge>
not sure the industry is ready to store the schema with the data
I encode within the content of the message the relationships that exist between the data in the message
currently this is stored in a stylesheet
<reply>
need to revisit this after some exposition
<Tim> back to question
the product must match the RDF model - otherwise you're causing trouble for whoever is implementing it
<Joseph>
.5 hours to discuss IEFT and details
<Joseph>
hallway discussion fodder: what's you vision for who does what
<Don>
there is great expertise for handling the low-level in the IETF
higher level done by W3
<Joseph>
I think it should be part of the XML fabric underway or a least formally reviewed
In W3C that requires timelines and commitments so folks don't forget there are dependencies
<Don>
it would be difficult to include in an IEFT charter - easier to do in an informal way
<Joseph>
what level draft specification do you expect within the year
<Don>
IETF draft
probably will have implementations - though not required
<Tim>
<Don>
[missed]
<Danny>
could you give two seconds on the open trade protocol
I think the XML DSIG is a higher level
<Don>
IOTP defines different roles
these parties typically have prior relationships
need to establish payment to payment handler before a delivery handler ships
usually the relationships between parties are very well defined - signatures establish a trust for that part of the processes
<DV>
XML status
[outside] DOM - PI to look, read, modify an XML doc in memory
no direct relationship with dsig
[outside] XSL -
Needs to convey Two questions from Tim Bray:
makes canonilcaalized possible
want a way to normalize a charset
Unicode maps are expensive
Signature Semantics (105m)
Scribe: Eric Prud'homeaux
Editor: Joseph Reagle
___
<Joseph>
initial task is to get all the pieces of the puzzle out on the table, then re-arrange
[Explicit and Accessible Semantics]
[Explicit Semantics]
...
AND Data Ltd.
[I should show him Attributions]
<Daniel Veillard>
Use mechanisms provided by XLink to make assertions about the ????
<Richard Brown>
<reply>
<Danny>
What does appropriate mean?
<reply>
<Joseph>
or the size of the key for a given algorithm?
<reply>
the key a little odd as it's part of the signature mechanism
<Alan>
I interpret appropriate as "should I trust this key for this purpose"
<reply>
I am attempting to introduce as few new term as possible - just trust and trust mechanism
<???>
why wrap XML in 509 rather than the other way around
<reply>
validation processor must be able to work on the signature
[end]
<Tim>
sign assertion that you have copyright on X versus signing X
there is no need to convolute the statement with what property you're signing
if David Singer signs that A works at IBM, for our purposes, A works at IBM
using RDF's ability to make statements about statements makes this much easier
<reply>
I was trying to make sure we had the discussion
perhaps we could use RDF
but I think we need to have a way separate the signature from the document
<Martin Lee>
agree - anybody should be able to sign anything
<Dave Solo Citibank>
fundamentally your signature process is vastly overcomplicated
I'm signing this means the semantics of this have to be in the singing process
signing process may say "it was signed by this party"
<peter>
you made ref to the "what you see is what you sign document"
whatever has made implications must be signed
just started so no solutions yet
<Joseph>
in charter - I stated we need to do A and B
30 pro 0 nay
should we be using S/MIME
<David Solar>
separate the questing
look as CMS as a well designed wrapper mechanism
encoded ASN.1
<Bob Relyea>
S/MIME is a wrapper mourned PCS7
<Joseph>
how friendly are people to RDF syntax?
Richard's slide had a locator tag vs. the RDF:about tag. The same semantic is needed, you need both bits of syntax, why not use RDF?
<Bob>
opposed to representing the signature and certificates in RDF
in favor of making metadata about a remote object
<Ralph>
last thing we need is a new certificate syntax
anyone in favor of an XML equivalent certificate?
<Alan>
traditional certificate is a binding between a key and a name.
they have grown to acquire other properties
we should not stick in preexisting certificate
<Joseph>
anyone opposed to formal data model
<Don Eastlake>
would like that as a work item
<Tim>
yes.
<Boyer>
pen based signature require the notion of signed to work with verify
<Alan>
this problem keeps recursing
there is a separable task of how you define the semantics
these semantics must be defined first
I think I need to sign I'm saying X about Y
<Ralph>
<Eric>
thin you should be able to sign your own statement with internal signature
<Richard Brown>
I want to sign that "I am the author of this statement."
<Eric>
I just wrote something that I would want to say was true.
<Richard Brown>
going on to trust and authorization etc.
we need a standard to produce signature
we can break this up so we don't have such a distant deliverable: semantics, trust management, etc
<Richard Himes>
re: should we approach it from RDF or XML - what is the intent and semantics of the signature?
<Ralph>
it will take a fair bit of discussion to hammer out what peter called semantics
we need to be able to sign documents
we also need the ability for others to sign
<Milton Anderson, FSTC>
signature depends on the legal document being signed
<Jeff Schiller, MIT/IETF>
from historian's point of view:
been here before
in PKIX (CMS?) signature - there is a hash and an id for the hash algorithm
attack was to use a different hash algorithm that would give the right hash
much subtlety to this art
2 argument about meaning
if a browser is implemented such that I see on screen is one message but the SIG gets applied to another statement...
<Tim>
agree - however in something as general as html - you just have to live with that problem
in RDF you have a defined meaning so it becomes a mathematical problem
if you have a tree of the following form,
then you can make and sign this assertion - this process just maps math which is much more rigorous
<Jeff>
you avoid a lot of this if you try to figure out what meaning means
<Joseph>
Jeff, what is your recommendation on the first point
<Jeff>
don't reinvent the wheel
<Ralph>
and pay attention the the subtleties
we need to provide a rational for any differences with the DSIG process
<Tim>
adding complexity like declaring what you're signing will confound this
<Dan Geer, CertCo>
from the big dollar setting - what a signature means is what was the intent by the parties.
unless you can show the intent, it will not affect recourse
risk management
<Danny>
extra reason to reduce semantics
related to Dan's comment, we can't talk about authorship and stuff like that as it ahas different meanings around the world.
we need to support all those differences but run underneath
<Paul Lambert>
whatever we do there needs to be some text on the semantics
<Danny>
needs to be link-to:
<Joseph>
let the schema marketplace work out the best semantics
<Tim>
how to you pass the semantics through foreign markup?
i.e. - encapsulated "look what I got"
<Joseph>
extensibility mechanics - if you don't know this, choke
Canonicalization and Content Semantics (90m)
Scribe: Massimo Marchiori
Editor: Joseph Reagle
___
Content III note-taking start at 2.18pm
Alan: under what circumstances are different versions of the same XML documents are likely to appear?
Tim: why can't you keep the original bits for recomputing the signature
DEastlake: in the IOTP you have a layered approach, pieces of that signature are incorporated in XML documents
Tim: pieces?
DE: signed pieces. You can incorporate them into other documents
Tim: apart from the email problem, I think it's bad: if you sign an element and then you include it in some other context, the SIG should stay the same Richard Brown: you put the burden of the problem in the service
David Solo: problem here is that you need to retrieve the document and then recalculate the hash
Richard Brown: I want to see the value of the SIG as a block, and then if I want to see the doc again, I want to rebuild the SIG, because their view could be different. For example, first time in the USA, second time in French, the charset can change.
James Nicolson: I'm more concerned about the changes of XML, different versions means that the old signatures with the same bits will not work...
Richard Brown: the semantic level of the business, you apply it to the XML semantics. There are rules in XML that tells you this is ok; if you change xml this is not valid any more James Nicolson: this happens, same as html
Richard Brown: there's no doubt in the spec right now. XML evolves, well, sure...
DanielV: 1) DOM was not designed as a canonical form 2) whitespaces: depending on your parsers, the DOM implementation may or not may show you some of the white spaces. So, in essence, I'm not sure DOM was designed to enable you to produce a canonical form 3) problem with performance: you are computing the hash with every subpart of the doc, and propagating it. Maybe you've an algorithm that is ok, but you risk explosion with big documents
Answer panelist: there are very few things that are optional in the DOM. DOMhash is very specific about this. The whitespace stuff: XML (and DOM) is very strict about this, every XML processor must keep the white spaces. We tried this with every parser (e.g. James Clarke tested etc), and we got the same result.
DV: if you use SAX I think it's ok, for DOM I'm not really sure So, what about performances?
DV: each subtree you compute the hash, I'm not sure fpr every argument it's possible not to keep that panelist: no, it's ok.
John Boyer (UWI): on the previous question by Joseph (XML-canonicalization should be XML): it's useful for the output to be also of the same *document type*: going back to Lipp, "you sign what you see".
DE: nobody will ever see this.
TBL: but if other people need that...
DE: yes
Richard Brown: we've been using dm hash for many applications. Nevertheless, we've adopted the same approach of cannonicalization; we don't compare all the hashes as we move to the top of the tree, but we produce a tree of the output, where you than compare all the hashes; so the output is a stream rather than a linear hash; whitespaces: there's an XML:space attribute that you can define to preserve whitespaces or not; the problem is that in any case people usually ; in Xhash we had an additional parameter: what should be done with whitespaces with canonicalization
DV: one of the things I'm afraid is that a validating parser has different outputs, and that can happen with whitespaces panelist: if the DTD is provided, this should not happen...
Jeff Schiller: it could be we have as output human readable, although it's not XML. We have to explain to a court that this doc has been signed. If the "glob" is provided to a court, you'll have to explain this, can have trouble. If it's readable, you don't have this trouble. So my recommendation: not only XML, but readable; and, output of the canonicalizer should stay the same for canonicalized forms.
Danny: the important requirement is some good argument to retrace one step, Jeff: PGP history: base-64 sign's time ago: deleted that because was not readable, de-base64, but trouble e.g. with white spaces. you're strict when you send and liberal when you receive. XML: one of the dimensions is the passage of time; in 15 years I may not be able to verify the signature. Or you can do a date check... I'm advocating: output of XML is XML; then, replace the original XML with the canonical XML, so that in the future you can re-verify whether it works or not...
TBL: difference between email and web: signing can be via hyper-references, so if you modify the doc, other people referencing to it can be fooled... Jeff: hash of the canonicalization, and bits of the http response.
TBL: there'd not be ambiguity, guessing among different canonicalization algorithms... no ambiguity...
Schiller:: in reality, implementation bugs.... [example cited]
Himes: nice to have a canonical human readable, but we should not replace the canonical version. DE: "human readable" is a funny term: the word "canonicalizer" is misleading; XML to XML is good; canon stays equal is good; but, it's technically difficult...
------------------------------------
Richard Himes' TALK
Swick: I do think making the system understandable to users is important... I'm still a bit perplexed about the goals of the canonicalzation too
DW: what users end up expressing? Part of me thinks it's not our problem, part of me thinks it's really important... Any help? We are especially concerned, as T&S, about the interaction with people...
Richard Brown: XML syntax by itself needs an independent canonicalization independent of applications on top.
-------------------------------------
LEGAL-XML TALK
(Todd Vincent)
AK: signing documents with "fine prints" is not legally bounding. Is there something similar here?
Vincent: there's a sort of similar concept: you can't be bound to something you can't read. But if you read it, then you're bound. Incorporation by references is ok (but for Europe). However, if I incorporate 40/50 pages, court will complain because it's too complicated. But it could be too long to unwield legal docs. If we're trying to use metadata to understand the document we might run into trouble. I think we'd avoid this in the doc-signing process.
JR: metadata can be pretty useful, we can have rule systems that read and understand this. So I don't think it's all bad. panelist: I agree with that. I just don't know if at first stage...
-------------------------------------
PANEL by Richard Himes (federal court of new Mexico):
XCI-XML Court Interface no questions
--------------------------------------
Scribe: Marja-Riitta Koivunen
Editor: Joseph Reagle
Note: Most of the time was spent on the slides.
___
------------ Fujimura: XML Ticket
No questions
------------ Milton Anderson: FSML and E-check
Daniel Weitzner: What happens with this kind of system that requires more precision than before? With humans there are always going to be checks that don't have signatures or the date is wrong etc. If they are small they might go through the current bank system.
A: Also less precision can be built to the system. For instance, in some countries future dated checks are stopped while in other countries this could be totally legal and even offered as a service to pay the bill only at the date it is due.
Alan Kotok: Risk management point? What about lighter weight system when less security is OK?
A: There is some interest for that. Consumers might use software that requires valid signatures only after certain maximum amount is exceeded.
Tim Berners-Lee: Do the smartcards have displays on them? How does the user know what it contains?
A: No but there are some readers with display and even some buttons.
--------- Michael Merz: Cosmos (Common Open Service Market for SMEs)
Eric Prudhommeau: Is there a vulnerability in the presentations layer so that a person can see one contract and actually sign another.
A: Last resort is signing the XML contract but that does not work with normal users as they would not understand that. So some presentation is needed. There is one authorized stylesheet.
Daniel Veillard: What about standardization of vocabularies - internationalization? Do users need language specific stylesheets?
A: We did not address this.
Alan Kotok: How do you know you are signing what you think you are signing? A software company might give a guarantee that user sees everything. There is a need to see what software agent was used in the signing.
A: All components needed for signing are stored locally in PC - trusted environment.
Marja-Riitta Koivunen: If there is only one stylesheet how can we provide user control and be sure that disabled people can also access the information? Should the semantics be presented so that different stylesheets are possible?
A: There can be a list of authorized stylesheets that the user can select one for her needs.
Richard Brown: Government needs to make sure disabled people are not forgotten.
Daniel Weitzner: We should not worry so much about stylesheets and seeing what we sign. The interpretation of terms and public policy constraints is more important legally. This work is fascinating especially because there is no centralized control of terms.
A: Not much regulation is involved.
Scribe: Henrik Frystyk Nielsen
Editor: Joseph Reagle
___
Milton Anderson
<slides>
Richard Brown Presentation on signed-XML draft
<slides>
Explaining motivation:
- over the last 2-3 years : XML is very popular
- XML is just a way to structure the data but value lies in being able to access origin and authentiicty
- Existing binary syntaxes: signature is externalized from most applications - add ons etc. Need to be better integrated
- Lack of XML cryptography is holding back a large set of potential XML applications
Objectives:
- Next year: plan to start addressing syntax and procedures for computing signatures in XML
- Question: how do we use in general XML for signing Web documents
Specification Process:
- Existing syntaxes: CMS and PKCS7 - how can we leverage this?
- Looking at other non-XML proposals: DSig, PICS, SDML
- Brought in XML based protocols
BIPS: bank system protocol
FSML: writing checks
IOTP: open trading protocol
- And finally looked at AADS (means??)
- Result: Ended up with two documents:
- requirements
- bets practices of existing solutions
- Now have draft proposal with mailing list for discussion (name?)
- At first revision of draft clarifying relationships with DCD and RDF
Requirements:
- Ease native support of signature in XML as alternative to binary syntaxes
- Include *both* signatures and authentication. Some long standing relationships depend on authentication and not necessarily signatures. When saying signature really also means authentication
- Support for certificate-based as well as account-based authentication schemes. CB can handle trust without prior contact. Long lasting relationships can often be handled by account based authentication
- Should be possible to authentication any type of resource
- Support for composit document - there are many relationships that rely on some sort of workflow - need to support handling of adding/deleting parts without breaking authentication model
- Support for signing of parts of documents
Syntax basics:
- We want to specify how and what is signed: manifest, value
- Also need certificate information
- What is a manifest? resource information, other authenticated attr, originator, recipient, signature algorithm, key-agreement algotithm.
- Attributes: can ontain time stamps etc. which doesn't have/need to be in the document signed.
- Recipient: allows the originator to see what is intended for it. Recipient also allows for "half secret" algorithms where originator/recipient holds half the key needed in order to create a shared secret
- key agreement: allows for OT keys
Resources
- Is just a collection of resources being signed along with their digest along with the digest algorihtm
- We are doing an indirect signature by signing a secure manifest - not computing the signature directly over the document. The link is the digest
- Kotok: wrt RDF where you can assert something like: I assert that this signature has no virus etc. This information would go into the manifest as attributes.
- Other attributes can also be the content type etc.
- EChecks would like to include critically in the attributes
- Eastlake: Might want to have attributes associated with individual resources. Yes, it would also be nice to be able to assign attributes to packages
- Boyer: Think that in some domain: can an attribute be a resource? Yes it possible to do that
- A resource could be defined by a URI,digest but could also be defined by value. Eastlake: could be the identify digest algorithm!
Originator and Recipient
- We do not define the content of originator-info or recipient-info: can vary a lot depending on cercumstances.
Signature and Key-Agreement
- Simply refer to an algorithm
Signature in XML application
- Using XML namespaces applications can embed XML signatures directly in XML.
- Don't have to package anything although it can be done as another possibility is to use XML for packaging and then sign that. This can be used to sign arbitrary content as long as it can be expressed in XML. This is in fact similar to a MIME wrapper
- endorsement is done by signing the signature which can be done by adding another XML element into the manifest
- Supporting composite document can be done because we don't sign the document but sign the manifest. This means that it is not necessary to in fact have the value of the document.
- In some cases, a lot of documents are to be signed with different keys. This can be done without replicating the information but using XML to refer to the individual subparts
- one-time processing: it is not always to maintain all the data in on go but may have to split it up. Therefore it is necessary to be able to verify a signature even if reader can't handle the complete document. This is done using XML elements up front in the stream. This is declarative as it doesn't change the manifest
- Prud'hommeaux: How does that differ from simply sticking the manifest up front? In some cases, you need to compute multiple hashes in order to verify it.
- Davidson: One of the consequences of including the hash algorithm as attribute is to figure out when to start and when to end computing. This approach has the side effect of being implied with the hash computation itself. Answer: the hash is on the full element. Reagle: To be disussed more at the end.
- The type of the signature algorithm is a first class object
- Formalization: advocate for RDF
Specs (continued) and Forms (60m)
Scribe: Henrik Frystyk Nielsen
Editor: Joseph Reagle
___
Mikton Anderson FSTC
- We need to get to a state where we have the same mode of operation in a variety of contexts
- Goal for forms: there could be a "sign" button on an echeck form
- Can be done in two ways:
- XML doc coming from server with a style sheet laying out an HTML form. Data is sent back using HTTP POST with normal form data.
- Like to get to: XML processor creates the DOM but input would go back into DOM and sent to the server using signed XML
- REagle: This would be both a format specification, a protocol specification, and a application logic specification? Yes that is correct - currently there is no "sign" button.
- Reagle: Shouldn't be in the critical path as this can take a long time to get done. SHould be submitted as a proposal.
John Boyer on Extensible Forms Definition Language (XFDL)
- Most of the time the legal situation on whether a person was signed or not but rather the intend or understanding of the agreement. With paper documents you don't have the problem that the document changes. We need to get to the same state in e documents. We shouldn't actually loose functionality
- Document on e docs vs paper - pointer to paper?
- You aren't gonna get very far in e-commerce without signed XML
- XFDL doesn't cover all XML applications - there are scenarious that we haven't designed for.
- Forms are already widely deployed for al kind of applications
- XFDL is a techie solution that covers a certain set of problems
- Quick overview of XFDL:
- Using XFDL version number for handling extensibility
- there is a set of global options
- A form is devided into "pages" - a form can be split up into multiple pages
- The sid attribute comes from a previous XFDL, this is a scoped identifier.
this can now be taken over by xpointer
- There is not a scope identifier on options
- multiple value options are handled using arrays
- fields and formatting: support for basic types (integers, dates, etc.).
There is also support for form validation/completion (add $ sign, for example)
- Spredsheet functionality with simple computations. This is where relative scope
comes in - can identify where dependencies comes from
- Descision logic and use of CDATA because of use of '<', '>' etc.
Based on C - after all, it's a standard ;)
- Often don't want to put your business logic into a form but rather
presentational logic
- Also has other typographical information like color etc.
- supposed to be quick and easy for small as well as large scale form generation
- runs through plug-in in various browsers and can also run stand-alone or
- delivering through HTTP POST, can also be over SSL
- Doesn't use HTML form encoded data
- In XFDL you can't have any external entities
- Good color: 253, 248, 248!
- We actually sign the document within a form independent of the transport. Can handle persistent editing.
- Features of XFDL:
- data layer: user input stored in value option, user attachments stored in data items
- presentation layer: for the most part actually contains that data layer although it can be separated. Images stored in data items - this is imporant in the paper world as it allows to verify the context.
- presentation layer: compute expression and 'current value'
- digital signature on text copy of XFDL form = signature on data, presentation, and logic = tranaction non-reputiation.
- Why should we sign data, presentation, and logic together?
- what if the message is not a very good representation of the transaction? Need the context!
- Important information can be carried in ways that is very hard to detect for the user?
- It is important that a document can be signed multiple times.
- We want to sign parts of forms and also have multiple views to the same data
- Mechanics for how to fill in form data has to be nailed down
- signoptions allows for things like "omit this field" etc.
- Prud'homeaux: can you attack by adding omit tags? Not really as everything has to be rendered
- Also support penop
- Fox: Were there any interoperability problems between MS and NS security API? There was a problem but this is being fed back.
- Conclusion:
- binding data, presentaiton, and presentation logic onto signature message.
- data can include non XML attahcments
- xml signature should be as interoerable as possible
- xml element to specify how to generate message
Panel Question Session:
- Davidson: In terms of requirement section: authentication covers at least 3 broard uses: peer-peer, short lived non-reputioantion, archival requirement. In the mechanisms and some of the specifications, some are better than others for these requirements. Questions is: whether we are prioritizing among these three requirements or do we want to support all three. Brown: not sure we have to make the choice - unless there is something specific that is not handled by the specification. Solo: Complexity in handling the number of mechanism vs. simplity. Reagle: Does the requirement mean that you need more context? Solo: yes as we need to know what the document meant.
- Reagle: What should be signed?
- what to be signed involves too much of the business application
- how do I sign involves more neutral mechanisms
- Question is: what is really implied of the lower layer logic? What does it mean to validate a hash. To the extend that we can reuse already deployed systems we are better off
- Boyer: We need to account for the passage of time which is why
- Kotok: better like the idea of the specification looking like a manifest where you don't copy the content. It should be possible to do both.
- Kotok: Regard to many different types of signature mechanisms. From DSIG/1.0, requirement for having a small mandatory set of mechanisms
- Reagle: Should there be a small set of mandatory mechanisms? Sort of YES
- Henrik: Shouldn't be part of the specification but of guide lines. Need to be able to evolve over time.
- Reagle: Right, don't want to make sig-XML require a suite that falls out of favor in 5 years.
- Lambert: we should ignore hand written and symmetric signatures. Brown: We need to look at the people who are current looking at the specification - we have to support what they need. Lambert: we have to make a very concious choice.
- Boyer: problem that everything has to be XML
- Fox: from a crypto API on behalf CMS tidal wave . New reuirements are coming from . Agree with Brown.
- Reagle: we actually have a profile of what works and what doesn't.
- Fox: yes, CMS adds a lot to this
- Dubray: what needs to be signed? Does it imply authorship? Authorship is the core semantic that we should adopt.
- Swick: What does that exclude?
- Dubray: Nothing but this is the point.
- Reagle: This is not a specification requirement but more a paradigm for handling this. Doesn't nessarily agree with the authorship semantic as core.
- Dubray: Is there an opportunity to unify what needs to be authored? For example not separate protocol from content.
- Reagle: How to handle context? What about browsers that don't render something? That is very difficult to handle.
- Henrik: How to handle on non-screens? XDFL is very focused on screens - have tried to work on other mechanisms but didn't sell
- Dubray: How can signatures be compatible with versioning? Boyer: This is outside the signature realm. Signing parts of documents can be a help
- Dubray: Need support for How to handle indexes and other content aggregators?
- Bob (Netscape): First: like manifest mechanism. Second: low level crypto does not need to parse RDF/XML! As tool provider, it is important that we can incorporate non-XML as blobs.
- Bob (NS): There also needs to be a way to map URI to OIDS, TLS is, etc. I prefer OIDS.
- Bob (NS): Unique problem that we have is that our code is OOS. This means that can't contain glue code or crypto code. Trick is to make APIs that are only authentication/signing APIs but may not get away with that. Problem is that there is no specific list of what is allowed and what is not.
- Bob (NS): The binary information should be kept intact - allow for hooks to support RDF.
- Try to keep the processing structure role of CMS. How can that be carried in XML rather than ASN.1. One starting point was to take CMS and cast it as XML and see how close we get.
- Reagle: there is nothing wrong with redundancy - information can be kept multiple places.
- Weitzner: Issue of only sign what you see seems to make an important descision point. Reagle: hope that architecture necessitate where we draw the line. Danny: Potentially very difficult to handle "sign-what-you-see". Solo, it seems you are arguing for simplicity as well as archiving. Danny, would like to see archival needs out of scope. Solo: archival problems are broader but question will become important. For example, it can be problematic of being able to stick in additional information (for exmample, "this is a demo only").
- Reagle: If we have the role of what you get but not incorporating style sheets. One problem with this in disagreement between block of signature vs. other information.
- Reagle: Question: A signed XML application only handles XML but not xpointer, xsl etc. Should that be OK to say that eveything else than basic XML Syntax 1.0 is not understood by signed-XML applications? Who thinks we should say that signatures should be limited to the document at hand or do we accept links?
Boyer: If you want to include the style sheets then this can be done outside this specification. Kotok: idea of manifest was to say what the signature applies to. Are we restricting what goes into the manifest? no. Then is the question of how to compute the hash?
Solo: From receive side: validation of signature is based on validating contents of manifest but doesn't imply any fursther value judgements of what links are referring to. (You can never enforce receivers to abide by creator policies, just doesn't happen.) The thing we still have to talk about is whether the hash is strictly over the manifest or over the link? Kotok: Yes, we need to decide that.
- Henrif/Reagle: If you sign a link without a hash of the resolved value of the link then you sign that you made a link but not what that link contained. That is there are three choices: sign value, sign link, sign link and link value. ALl are legitimate in their own right. (Some people disagree, Solo thinks all entries in manifest must have hash of resource, if you want links, include them in the resource.)
- Anderson: It is often a business rule whether you want to include it or not, doesn't belong in signed-XML.
- Brown: purpose of composite document is that you don't have to recompute hashes - if rquired then you loose that benifit
- Eastlake: It is important that the signing package allows for easy recalculation of the hash
XML-Dsig ‘99
Notes from session VII, Friday, April 16, 1999, 14:00
Scribe: Alan Kotok
Editor: Joseph Reagle
Joseph Reagle: We’re confident we want to use signed-XML and not just S/MIME so that the XML content will continue to be avilable to non-signature applications.
Need unparsed data.
RDF for assertions is OK. Need the data model (Richard Brown will think about this), need to think about syntax and harmonize with on going work Tim stated for alternative syntaxes.
(General agreement on first slide)
(No objection)
We need a couple levels of semantic depth. Simpler is better.
We need at least one agreed method of canonicalization. People did not mind if the canonicalized version of XML was non-XML (Eastlake says why bother? It's only every held internally by the application) but Schiller proposes a recurisive test (useful for comformance testing!) canonical-XML should be XML, and any resulting XML should be exactly the same bytestream as that of and recursive submissions of the canonicalized XML to the processor. The group likes this idea.
Reagle: what is the minimum level of canonical depth signed-XML applications must support?
Does anyone disagree that a client application should be able to do a surface string hash? (No)
Should it be able to use a standard canonicalized XML? (Yes)
David Solo: Exactly one canonicalization for the manifest. Multiple schemes allowed for things in the manifest. Might simplify the signature processing. (Also, one should never permit the sender to set policies, either the spec sets policy or the receiver, sender policies only lead to complexity and interoperability failures.)
Richard Brown: If the purpose of the canonicalizer is to reduce the semantic content of XML, that should only apply to the manifest. Defer "what should be signed" to another working group.
Difference of can. One might canonicalize for equivalence between two documents and integrity (same document always canonicalizes to same result).
JR: What about multiple character codes?
Don Eastlake: These should be equivalent, but you don’t often have to do that. It’s hard to pin down and hard to do, especially in small devices.
TBL: This has been discussed in the Unicode group. They are of the view to canonicalize at the earliest time. Leave it to the Unicode people, not do here.
JR: But Syntax WG asked us for our thoughts.
Milt Anderson: Concern that as document moves into and out of DOM, does early canonicalization work? Will it get undone along the way?
RB: Make it possible for all applications to define a can. algorithm. Surface string is OK. UTF-16? (Not everybody happy.) UTF-8? Again: have can. WG decide.
Jeff Schiller: Impose a requirement that multiple processing of can. docs are invariant.
Milt: (about hashing surface strings)
Jeff: Processing of objects without intent of changing it should not break signature.
Bob Relyea: (disagree) If you sign the surface string and you change it, then it breaks the signature. This is obvious.
In S/MIME if you add white space that breaks signature. That’s good.
Jeff: If you have tickets and they break between sender and receiver, that’s bad.
JR: (3 levels which we should consider). Bits in file system/stream (none); standard character encodings (UTF-*); canonicalized XML (caps, whitespaces, etc.)
JR: XML canonicalized should be recursive at these 3 levels, all applications should be able to process them as such and other things (DOM-hash) are optional, but not strong view.
We don’t chase links (in this spec).
If you don’t want to sign the content of a URL in the manifest, then put that URL in a document, and include that document in the manifest. So all things in the manifest have hashes. (Where things are URLs).
A resource entry in the manifest is the pointer and the digest stuff.
AK: There should be a way to put assertions in the manifest, but not define that stuff.
David Solo: Disagree. All semantics must be in "the document".
Richard: Create an independent element to contain the assertions.
TBL: You want to assert the "bank statement", which is separate from the things in the manifest (???)
TBL: We are close.
Richard: There are no semantics in the manifest. Either we go one way or the other.
JR: Don’t allow external semantics into manifest. (How do we create a space such that other people can't insert semanitcs, the manifest needs to be "clean room" with simple semantics.)
Milt: Doesn’t like this restriction. Echeck allows such things in the signature block.
Eastlake: This is silly: It’s only a question of where the same information is located. In or out of the manifest.
TBL: Namespaces allow lots of generalization.
Argument continues. People know we want it clean and simple as far as the signature mechanisms, need to think about design and alternatives as to how best achieve this.
JR: Q6. Don’t need to.
Q7: Don’t get into. Some people think we need to select particular elements and attributes. Others don’t.
Richard: Should be allowed but not part of the spec, per se.
JR: We want a data model.
Do people like Richard’s syntax:
Richard Himes: Looks hard to read. Can you turn them into attributes? (Algorithms are described by arbitrarily nested series of <parameter value="..."><alogirthm value="..."> .
Richard Brown: You don’t have to define lots of crypto algorithm pieces.
Don Eastlake: Crypto suites are the better approach.
RB: Can do both suites (referenced by URI) and tailored descriptions using his elements pieces.
Jeff Schiller: Need to have the discussion on choosing individual pieces.
JR: We aren’t concerned about extending to confidentiality, etc. Look ahead, but not on critical path.
Forms: Do we need to "do forms"?
John Boyer: Need to have a way to package dependent docs (like style sheets) in with the signature. Wants to include the raw document if desired.
TBL: SML community realizes it needs packaging. This group needs to define the requirements to XML Plenary.
JB: Concerned that a doc that is signed turns into something else.
(Lots of discussion about packages versus signed raw documents).
Conclusion: Think about whether signed forms are a subclass of forms.
JB: Document shouldn’t become subsidiary to signature.
TBL: The software structure doesn’t have to reflect the document hierarchy.
JB: Disagrees
JB: Happy if the signature can be inserted in the document as an element. (DSIG engines generates the sig-block, application might detach and place at URI, detach and bundle/package/wrap, or insert back into an object.)
RB: Was not a real proponent of RDF before. It was too complicated. But now he realizes that the XDL model maps onto RDF graph. Can work without it, using DTDs, but later can map to RDF. Can leverage relationships of RDF to simplify spec.
JR: Does anyone object to the above proposal to integrate with RDF?
Paul Lambert: Don’t get stuck with this.
JR: IETF vs. W3C.
DW: IETF has huge crypto expertise. XML expertise in W3C community. How do we cooperate?
Jeff Schiller: A joint working group. IETF doesn’t have XML expertise. If a Joint WG, then it has to be open to all takers. Results would have to be approved by both approval processes. Then who publishes the document?
TBL: We want to make the process match W3C and IETF requirements. So can we write a charter that matches both groups requirements?
JS: Thinks we have a lot of the ingredients for success. (People are mostly local). What would JR’s role be, co-chair?
JR: Happy to do whatever it takes to get the job done and ensure coordination, had proposed staff-contact in draft charter.
TBL: See what it takes to write the charter.
JR: How long would it take to resolve this (joint WG)?
JS: Would propose today. Next IESG telechat next Thursday.
TBL: Anyone have a problem with this proposal?
David Solo: Timing could be a problem with this JWG proposal. Don't want this to be the sum of the worst hang-ups of both organizations.
DW: Maximum cooperation, but minimum convergence of process.
JS: The same document progresses in parallel in both groups.
TBL: Proposal at W3C would be under review at AC Meeting in May.
JR: No schisms allowed. A single well defined process and a management commitment from both orgs; no one can say, "we're getting annoyed and we're gonna go back home." (This isn't to say the group shouldn't be chartered with a tight deadline, and perhaps killed if it misses it.)
DW: One group of people, one document.
AK: Compare the process documents: find any conflicts.
Don E.: Doesn’t think there are any show stoppers.
B Fox: In IETF you never know who the "group" is.
JR: Do we want an explicit or loose charter?
(General agreement that specific is better).
AK: Does IETF open mean people can drop in and out?
JS: IETF last call allows for people not involved to point out unknown problems. But chair can tell people that WG has already considered the problem and to go away.
JR: When can we decide?
TBL: W3C can give indication after next Wednesday.
DW: Proposed charter by May 7 to bring to AC Mtg.
JR: Will document this on the "list".
TBL: Thanks to Joseph.
Adjourn 15:32.