All the slides presented by any presenter are available from the WG’s
website – only relevant discussion is noted
here.
No discussion.
This was the first meeting of the first joint W3C/IETF WG. Joseph Reagle (JR) and Don Eastlake (DE) presented the "history" of this WG. From the process point of view, regular conference calls are planned besides meetings at the IETF’s and someplace in September.
Paul Hoffman (PH): are those Conference and Meetings calls design or process
meetings?
DE: Conf.Calls for status and ad-hoc technical discussions, face to face
for substantial work. But WG can decide.
Joseph presents requirements document.
Mary-Ellen Zurko: what is meant by validity of a signature: valid now or
court-validity.
David Solo (DS): this is external to the draft.
Semantics: only simple meaning – no trust semantics. Extensibility.
Bob Blakeley: is concerned about the semantics extension mechanism. Those
have to be protected too.
JR: reason to push semantics out of scope: let other people define
semantics.
Paul Lambert (PL): concurs, push semantics off even further, concentrate
on crypto-validity and make sure we do
this all the way correctly.
No specification of serialization or canonicalization:
DE: necessary for interoperability. Need not too many of them, but not exactly
one at least. Extensibility necessary and useful.
Eric Rescorla (ER): options confuse security semantics.
DE: canonicalizers can also remove information. NULL-canonicalizer will also
be useful.
DS: 2 places for canonicalization: canonicalization of the structure we create,
canonicalization of the resources.
Different. Canonicalization ensures: (a) given valid XML-document –
produce single strong-representation (b) defer
unique string-encoding for semantic value represenation.
Bob Blakeley: Canonicalization algorithm must not be able to manipulate content.
NULL is fine, others might not be. Constraints required – guidelines.
ER: Canonicalization algorithm must be included into the signature.
XLink: JR: XPointer provides for alot of ambiguity.
PH: be explicit about if the thing some XLink points to is included within
the signature or not. Ambiguity!
ER: Iffy proposition to allow different Canonicalization-Algorithms with
different security properties. Users don’t see the difference –
see key-symbol in Netscape for SSL. Programmers make mistakes like that
too.
DS: suggest to profile XML for use in browser to restricted choices but not
generically. Application problem.
PH: profile XLink/XPointer is fine, XPointer itself too generic
Implementation Philosophy
JR: do you want OID’s? DS: unambiguous way to say what we mean (either
URN or OID)
Ryan Boats ATT (sp?): Michael Meally, NSI has done some work on URN’s
for OID’s
Crypto:
Specify a few mandatory algorithms for interoperability
PL: why have key exchanges and push of encryption? Controversial
requirements
Richard Brown (RB): no redefinition of these schemes. If people use
DH-credentials they shall be able to use it (also for other symmetric
stuff)
PL: different properties for different algorithms. This is a slippery slope,
maybe better move into separate
documents.
DE: gets nervous by hearing “management” or “negotiation”.
Just by allowing secret keys – maybe call it something else than a
signature.
RB: we need to provide people with a solution, like IOTP has symmetric stuff
in the first proposal.
PL: the diversion of validity and trust is not clear yet. Be careful!
Discussion about inconsistencies of info within a BLOB (such as CMS) within
an XML-signature and info within the XML-structure deferred until a better
understanding is aquired.
Christopher Smithies: points out importance of packaging all necessary info
(intention, time, id, signature) which is what products by Penop do. Worth
while replicating some of that info in the outside structure.
Coordination
PH points out the importance of internationalization issues and coordination
with the internationalization WG
JR: Brown-Draft not a product of the WG, but possible to get there.
RB presents his proposal.
Bob Smart: is there an option to put in the public key or only a reference
to it using the DN?
RB: Not bound to that. Originator info might offer different ways. One common
way needed.
Denis Pinkas: can attribute certificates be included?
RB: could be accomodated within the credentials within the originator information
section.
Denis Pinkas: no provision to support non-repudiation (e.g. include
timestamp)
RB: not part of spec because not necessarily part of signature process.
JR: we don’t support non-repudiation
DS: we neither support nor not support it.
Stefek Zaba: incorporation by reference – what if hash of resource does
not verify?
RB: application level problem, signature verifier verifies only manifest
signature
SZ: this needs to go into the draft
Presentation of an evolutionary, non-counter-proposal by DS (co-edited with
Barb Fox)
No attributes within that proposal.
DE: how to stop people from putting attributes within the resources?
DS: we don’t want to stop them. An attribute is just a resource –
uniform syntax.
[Reagle: later, we may wish to create restrictions as to the type of "invasive"
semantics people can introduce using namespaces.]
ER: what would you specify from the hash standpoint?
DE: calculation of the hash of the manifest. Calc of hash of resource is
resource-dependent. Signature validator logic never verifies that
PL: we need to touch on semantics. Multiple signatures could be interpreted
in different ways. Must be described well to know what it means.
DS: potential partitioning of the problem-space might influence that
decision.
DE: suggest a meeting on the west coast for geographic diversity.
Meeting adjourned.
DS presents a slide sketching a more formal version of an alternative syntax
proposal.
Open problems are
Proposal will be summarized and sent to the list.
Q: David Burdett: should there be defaults like a default hash or canonicalizer
for all ressources to avoid repetition?
ER: saving a few bytes not worth it
Chr. Smithies: how to make clear what was within the original document and
what has been added during the signature process
DE: Semantics could go into the attributes
JR: no, semantics of signatures are statements and should go into the resources.
[Reagle hindsight clarification: properties of the signature of the signature
itself can be considered properties, but the manifest attributes are a resource
themself.]
Michael Myers: should the keyinfo be a subsection of the document or separate
document(s)
DS: not sorted out yet
ER: is one-pass processing planned? Would be a nice feature
DS: not sorted out yet
RB points out that removing attributes from this proposal we would end up
with something quite similar to the current specification
DE: open question if users should be able to insert arbitrary attributes
Don Smith: reminds us of things we went through in PKIX; lets have something
where people can put in things otherwise those will come up later anyway.
Poll: no oponents.
Joseph presents draft of W3C-XML group (not publicly available at this
time).
Comments to the list.
Roughly 16 people would come to a September meeting. Offers available from Micrsoft and UC-Irvine. Suggestion Aug 30/31.
Conference Calls every other week, starting in week 30.
RB points out that there is a separate comment document, input on this sought.