- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Thu, 18 Nov 1999 13:30:00 -0500
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
http://www.w3.org/Signature/Minutes/991118-tele.html
[1]IETF [2]W3C [3]XML Signature WG
[1] http://www.ietf.org/
[2] http://www.w3.org/
[3] http://www.w3.org/Signature/Overview.html
99-November-18
Chairs: Donald Eastlake and Joseph Reagle
Note Taker: Joseph Reagle [[4]ascii]
[4] http://www.w3.org/Signature/Minutes/991118-tele,text
Participants
* Donald Eastlake 3rd, IBM
* Joseph Reagle, W3C
* Mark Bartel, JetForm
* David Solo, Citigroup
* Ed Simon , Entrust Technologies Inc.
* Marc Pashoa,
* Todd Vincent, GSU
* John Boyer, UWI (regrets, couldn't get through to bridge)
(Sorry for the teleconference problems to that didn't join.)
Review of Outstanding Action Items
Clean up from IETF meeting: slides/minutes < 5 minutes
* Need slides from Boyer and Schaad
* Boyer will send today, Schaad's were hand drawn, will check with
him.
Signature Syntax & Processing draft questions:
* need someone to rewrite Parameters (and KeyInfo) such that we use
elements like <prime>...</prime>.
* Aside: Processing Model and reporting errors.
+ Do we need to specify a processing model whereby you
determine what failed (signedInfo or the ObjectValue).
Applications can do this at their option (Simon's prototype
did) but we don't need to standardize on this.
+ ACTION: Solo, add a sentence or two security consideration
that speaks that applications can do this sort of thing.
Schemas &/or DTDs < 10 minutes
* Include both.
* Solo: IETF will likely want one to be normative. No opposition to
DTD being normative if Schema is not stable.
* However, people are happy with continuing to use the schema
declarations in the body of the text as they are more expressive.
Other questions/items from latest posted draft < 15 minutes
* push the latest spec out to xml-dev and xml.com
Securing Location/Transforms & Levels of indirection, Manifests,
References, ... < 15 minutes
___
Reagle Summary:
[
defn:DigestContent
The content that is digested (versus earlier intemediary
contents that are processed/transformed).
Provoked email thread because
1. Detected a lack of common understanding of core validation.
2. Wanted further clarity on the assertions made is Signed Info (as
distinguished from Manifest): Distinguish between:
1. Does SignedInfo mean DigestValue are checked: yes! (If in a
Manifest: no, one might take those as trusted assertions.)
2. Does SignedInfo mean the URL must be dereferenced: no! Only
means that the signature operates over the Digested Content.
3. Does SignedInfo mean the Transforms must be applied? not
necessarily. Transforms specifies a set of Content that when
Transformed yields DigestedContent.
To rephrase: we are not signing a URL. We are signing the Digested
Content, and in an odd sense, the class of documents that yield
DigestedContent when transformed in as far as those parts that are
kept.
]
__
Bartel: Since encoding seems to be different from the other
Transforms, propose that we move encoding into Target (as part of the
hint):
<ObjectReference URI=[5]"http://www.mypage.com" Encoding="UTF-8">
<Transforms>
...
Call seems happy with this.
[Notetakers Question: Can Encoding still appear in the transform, in
both places?]
Reagle: say one has to dereference the URL, decode it, XPath it and
C14Nize it., if I have a document on hand that has already been
XPath'd but no C14Nized, can I just start it mid process?
Solo: Yes: Signer is only saying he signed the DigestContent.
Everything else is a hint. If an application knows it does something,
it can pick up the chain where it wants.
Bartel: Agrees: if an application applies some of the transforms, save
an intermediary step, and completes the other steps later, that is
fine
Reagle: The thing I'm not sure about is says there's a sequence of
tricky transforms, could someone play a trick?
Reagle: Is there some sort of assertion by the signer such that "there
is a class of documents related to this DigestConent via these
transforms?"
Solo: No normative assertion, in the end the you are hashing/signing
the DigestContent, and if you don't get the right DigestValue, the
signature obviously doesn't work.
Eastlake: David might be too stringent, there is some sort of
assertion about those other documents.
Boyer: In the users context, he's looking at the thing that is
transformed, where certain parts may change or not, not necessarily
the DigestContent min I'm focussing.
Reagle: I think we agree that we don't need to make major change in
the syntax, we do need to better define the semantics of the
assertions within an ObjectReference. Let's take this to the list,
please propose a set of assertions that you think are made by
ObjectReference.
Todd: in the legal context, sill concerned about the issue of what the
user sees and what is signed (particularly) XSLT's. Call feels that
the specification makes these distinctions fairly well. ACTION Todd:
propose some text (a sentence or two) that he would like to add to
spec, WG can then point out where it exists, or adopt.
Boyer: Orthogonal quick question before the call ends: If you use a
IDREF, does it include the element within which the ID sets, or only
the element's content. Call: IDREF probably returns the element.
Boyer: in Richard Himes' scenario, he only wants the content (because
that is what is fed into the Base64 decoder if an encoded document is
embedded in XML).
Call: suspect if you want only the content, you will have to use a
simple XPath like child::text().
[Note taker question: is the IDREF still listed in the
ObjectReference, and then the further qualification is in the
transform, or does the IDREF/URI="" and the complete Transform
follows?]
Con calls versus Thanksgiving/Christmas < 5 minutes
* Nov 25th is holiday
* Dec 2nd (Reagle Jury duty), Scheduled call. On that call
reconsider the next two.
* Dec 9, bridge reserved
* Dec 16 bridge reserved
* Dec 23th Christmas Eve
* Dec 30th Holiday
Face to Face meeting arrangements? < 5 minutes
* Call feels one day (a Friday) is good enough.
* Had said January 14, looking for location near San Jose, potential
hosts include Verisign and Sun.
* Solo: has asked about a location in San Francisco on the 14th,
probably can handle 20 people.
* Boyer: since the RSA conference ends on Thur (20), why not have it
on 21? (Then people don't have to loose a weekend if they are
doing both.)
* ACTION Eastlake: confirm when RSA ends and propose one of the days
(ask for RSVPs).
* Solo's room might only be available on the 14th, doesn't know
about 21.
_________________________________________________________
Joseph Reagle Jr.
Policy Analyst mailto:reagle@w3.org
XML-Signature Co-Chair http://www.w3.org/People/Reagle/
Received on Thursday, 18 November 1999 13:30:01 UTC