- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Thu, 16 Dec 1999 15:13:29 -0500
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Today's minutes are below. Also, the San Jose Logistic info is at [1].
[1] http://www.w3.org/Signature/Minutes/SanJose/Logistics.html
__
[2] http://www.w3.org/Signature/Minutes/991216-tele.html
99-December-16
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle
Participants
* Donald Eastlake 3rd, IBM
* Joseph Reagle, W3C
* Mark Bartel, JetForm
* Ed Simon , Entrust Technologies Inc.
* John Boyer, UWI
* Barbar Fox, Microsoft
* (regrets) Richard Himes, US District Court of New Mexico
* (regrets) David Solo, Citigroup
Review of Outstanding Action Items
* ...
Status of documents < 5 minutes
* Reagle editing, will post something be end of week.
Signature Syntax & Processing draft questions:
1. Renaming ObjectReferecne to Reference
Telecon: ok. RESULT: ObjectReference --> Reference.
2. Grouping repeating elements (ObjectsReference inside SignedInfo).
Telecon: Not very strong opinion: people not strongly opposed (but
concerned about potential bloating) nor strongly in favor (though
should provide cleaner in exposition). RESULT: Change to Solo's
suggested "References".
3. When Object is used for data (as specified in the Type attribute),
do not include start/end tages in hash and auto-decode per any
Encoding attribute. (If 5 and 6 below are adopted it might be
possible to drop the Type attribute on Object and use it only for
data, or change to a MimeType
attribute or the data, which is what it was earlier. Currently the
Type attribute is used up to distinguish between
data/manifest/package/signatureproperties.)
Eastlake: this would make the type reference in manifests
mandatory.
Simon: would like an attribute that says whether you want the
container tags or not.
Reagle: what happens if you have a ::child() and a reference with
a strip="" attribute? Telecon: The application would strip the
object, then find the child (basically take the granchildren of
Object).
Reagle: If our concern is referring to manifests, just use an ID
in the Manifest element and refer to that! Concerns about moving
an encoded object from within an object to elsewhere would be more
tricky. Boyer: wrote an email to Himes on how to do this, will
send to list.
RESULT: no change, but clarify text that references can ref to
Manifest directly.
4. Permits Object(s) inside SignedInfo.
Might make the signature more compact, but might complicates
things with respect to understanding how to process (flexibility =
complexity). RESULT: no change.
5. Pull Manifest/Package up to the level of Object.
6. Pull SignatureProperties up to the level of Object.
Eastlake: removes extra level of nesting.
Reagle: likes to keep an Object as the bucket to place non-core
syntax and semantics.
Fox: wants a strong reason for us to make a change.
RESULT: no change, but add some text that manifests and signature
properties can appear anywhere the paren'ts content model permits;
the signature content model only permits them in Object.
7. Accomplish 2 and 4 by using the existing Mainfest element.
RESULT: no change (given above).
8. Proposed Comments text.
Eastlake and Simon talked on list. If text is agreed to, will be
sent to editors.
Reagle: We still need to adopt a minimal canonicalization anyway
(should we adopt Simon's?) Simon: wait till January.
Bartel: we could add a summary to the c14n algorithms on how they
treat comments and PIs.
9. Plenary discussion of attribute ordering.
Need text on XPath ordering, c14n order seems to be the way to go.
Boyer will send reagle text for inclusion.
Face to Face meeting arrangements < 10 minutes
* Meeting is in SanJose on the 21st, [5]further logistics should
follow within a day.
[5] http://www.w3.org/Signature/Minutes/SanJose/Logistics.html
_________________________________________________________
Joseph Reagle Jr.
Policy Analyst mailto:reagle@w3.org
XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Thursday, 16 December 1999 15:13:30 UTC