- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Wed, 01 Sep 1999 15:19:35 -0400
- To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
[I'll plug in Daniel's notes once he sends them.]
http://www.w3.org/Signature/Minutes/Irvine-Minutes.html
Editor: Joseph Reagle [5]reagle@w3.org
Authors: Milt Anderson, Daniel Woycke, Joseph Reagle
August 30-31 1999 Face to Face Meeting
The following minutes capture points of discussion, consideration, and
action items resulting from the face-to-face meetings. Participants
should send the editor corrections; others on the mailing list should
suggest alternatives or document opposition to views/consensus
achieved in this meeting by 990910. Those issues in black are ones
that should still be investigated.
Attendance
Name Company
Joseph Reagle W3C
John Boyer UWI
Mark Bartel JetForm
Don Eastlake IBM
Milton Anderson FSTC
Shinsuke Honjo Hitachi
Ed Simon Entrust
Terry Hayes Netscape
Todd Vincent GSU
David Solo Citigroup
Barb Fox Microsoft
Rohit Khare UCI
Peter Norman FactPoint
Stephen Keung CIS, SC
Roberta D'Amico CSELT
Daniel W. Woycke MITRE
Monday, August 30
0900-1030 [6]Scenarios , John Boyer (Notes: Reagle)
* [7]Enveloped Internal Content
+ Signature element is the root element. Doesn't need to be
supported directly, more elegant ways to do things.
* [8]Direct Envelopment
+ Everyone's syntax does this, no worries mate.
* [9]Unenveloped Indirect Signature
+ Application element is the root element.
+ Encrypted hash is over the actual application element. (Want
it for symmetry in the enveloped case.) We need exclusion in
the Indirect since the signature is a child of the root
element.
+ Conversation on when you exclude the signature, how you worry
about signing signatures.
* [10]Unenveloped Direct Signature
+ Not a lot of support, but people think having the encoded
version is not hard. Don't need it just to avoid another
level of hashing. We do need to sign the original content,
but what about the original content plus other stuff?
* [11]Signing External Resources (Detached Signatures)
+ [12]Signing Partial XML Documents
Boyer shows and argues that July XPointers (or more
specifically XPath) seemingly offers the
filter/select/exclude capabilities we need. When asked how
many people would expect to implement XPointers shortly, only
one person raised their hand. However, people do seem
comfortable in using a subset of Xpointer. Or can we just use
URIs to do what we need to do? Not for selection in the
manifest, but perhaps in the core signature.
Norman: can we do this in a simpler way, with a dsig:exclude
attribute? Which requirements does Xptr meet that can not be
met through an easier method? Group: The insertion of
dsig:exclude is problematic when you have multiple
signatures, how does which signature know which dsig:exclude
belongs to it.
Boyer raises unrelated point that if the canonicalizer strips
out the DTDs, you won't know which attributes are IDs
anymore.
Norman: how do I seen pieces of documents that were not
structured with many names? With a dsig:target element one
can add to other documents to point out what it is you are
signing for poorly structured documents. But the removal of
these things happen before or after dsig (this affects the
nesting) -- just like in dsig:exclude. Reagle suggests you
could use XPtr as described, or take the document apply XSLT
to effect the transformation and sign both of them. (still
open)
dsig one-pass-processing: get feedback to people on
implementation side as to whether this is useful. (not clear
that there is additional utility.)
1015-1030 [13]Data Model, Joseph Reagle (Notes: Daniel Woycke)
[Insert Woycke's notes.]
[Reagle summary:]
Reviews his proposed data model, explains:
1. The goal is to make as much of the relationships between the
elements in our signature as explicit as possible, such that other
non-dsig applications could still derive interesting information
out of a signature, even if they don't care about signature
validity.
1030-1200 [14]Syntax and Processing Model (Notes: Milt Anderson and Reagle)
C14n will be dealt with this afternoon.
Notes for David Solo ---
Don plus discussion -- Distinguish between three levels.
1. Core signature syntax -- the syntax for creating a signature over
a set of bytes within the scope of the signature
2. Signed objects syntax -- how you sign referred to and signed
objects.
3. Application -- trust is in the application layer.
First Slide -- XML Syntax and Processing
...
Second Slide -- General Issues
* Keyinfo compromise is to put the keyinfo at the top level outside
the scope of the signatures, and then put some added key
information in the signature for binding. This is not necessarily
a duplication of the keyinfo, since the application may wish to
bind different information into the signature.
* Putting keyinfo outside the scope of the signature was the
predominant application requirement. 97.44% of the cases according
to David Solo.
* Hayes -- felt that there are many cases where keyinfo should be
signed. We need to make it clear and explicit that key information
is allowed within the scope of the signature when the application
needs to put it there.
Third Slide -- General Structure.
* All "sigs" have been changed to "signature".
Fourth Slide -- signedinfo
* What are signedattributes? Could be signing time, key information
discussed above,
* Where does the signedobjectdata refer to an object that has been
already signed.
* Anderson wants signedattributes in order to simplify creation of
the signature element by security tokens in such a way that the
signedattributes are inserted automatically by the token device.
That way they have the security associated with the security and
tamper resistance of the token device, and don't depend on the
host systems security or on the integrity of the signer herself.
[Milt wasn't there for the second day, where we moved to removing
special attribute blocks, so Milt should weigh in on David's
latest proposal -- Reagle.]
Fifth Slide -- signedobjectdata
* Boyer: does this support enveloped? Response: signedobjectdata
always refers to an object, but the object may be within the scope
of the signature element. There is always indirection.
* References to signed objects can be to an object within signature,
to an object within the same document, or to an object in another
document.
* Transformations include c14n and encoding. It may also include
compression.
* Change signedobjectdata to signedobjectreference?
* May use a default c14n and hashing algorithm or inherit the ones
from the computation over signedinfo.
Sixth Slide -- algorithms
* Currently there is no definition of the Identity c14n. This is not
c14n plus fixing up CRLF and charset.
* Null and Identity c14n are specific to digsig and are for the
point to point application. The case of unique production of a
canonicalized output of the DOM is in the "more extensive" c14n
algorithm, as is the Syntax WG's proposal based on InfoSet.
* Question about whether hash and signature algorithm should be
combined and whether the dual signature should be combined in a
single type. The parties would need to have the combined hash/sig
algorithms and the combination of signing capabilities. When a
combination of signatures is used, then the signaturevalue is sent
to the appropriate combined algorithm. It simplifies processing to
not have the discrete combinations of algorithms visible at the
core syntax level.
Seventh Slide -- keyinfo types
* Hayes: multiple keys are required for multiple signatures. Then we
have multiple instances of certs in keyinfo.
Eighth Slide -- Eye test and example
Ninth Slide -- Open Issues
* Do we always go forward with signedobjectdata being a reference?
Advantage is that signature can always be calculated over
signedinfo and doesn't matter whether the object is inline or
outside. Canonicalization of singed info may have to take into
account that the reference may be a URI or an ID depending on
whether the referenced object is external or internal.
* Is there only one or more than one instance of signedobjectdata in
signedinfo?
* attributedata and keyinfodata are candidates for promotion to the
next level and the corresponding wrappers might be eliminated.?
* Long discussion regarding whether it was necessary for the
signature core to chase down and verify the hash of the object
referenced?
* Is it possible to have a manifest where the URIs are not signed,
therefore allowing to move the referenced objects.
[Reagle's addition summary of this discussion.]
* solo: the benefit of the indirection is:
1. switching: could refer (depending on how you reference it) an
object that is external or internal, and signature wouldn't
break. reagle: I dispute this, if they have different URIs
they are different things, unless there is a statement of
identity.
2. transformations: keeping it external means one can have one
single c14n over the signedinfo, that are indistinct of the
content transformations (no nesting/multiple-c14n)
* Fox: will XML content be too small sometimes (particularly if
signature is also over siginfo, pretty static information) in
order to permit a dictionary attack, do we need padding and salt?
Solo: jokes XML is never small. Should investigate.
[Reagle summary of Open Issues from Syntax:]
[The resolution to many of these issues will be reflected in the
[15]next draft Solo will send since we went back and forth on some of
this stuff quite a lot.]
1. signature attributes: if we have signature semantics and include
it in <signature-attributes> they must be relevant to the
cryptographic signature, nothing about the signed object itself.
Semantics about the object should be in maninest attributes (or
reagle argues in a new signed object see [16]tomorrow's discussion
where both types of attributes are removed.)
2. signed object ref (data), should we limit it to one? Go with one
with caveats that it must make sense in a DLG (can someone else
sign your signature attributes?).
3. algorithms (crypto/hash): mandatory, recommended, optional
4. c14n, syntax WG, null and simple/minimal c14n
5. exclusion/xptr. the dsig:exclude declaration, which signature does
it belong to?
1. <X dsig:exclude> ...</X> everything is hashed and signed, now
someone adds a
2. <Y dsig:exclude> ...</Y> it will get rendered differently,
but not break the signature because other applications won't
know the dsig:exclude semantic.
John, in XFDL had something that did it differently, but not any
easier. consensus that we should bite the bullet and use XPtr in a
limited way as possible. Need to check if XPtr returns the whole
resource and a view, or a different resource (check the DOM that
is returned.) Are we better off use XML with XPtr to select or XML
with XSLT? Boyer: they are supposed to be converging with XSLT ->
XPtr -> XPath as ordered in terms of complexity.
Consensus. The reference from SignedInfo will just be a URI. This
can then point to a manifest or package which can use
Xlink/Xptr/Xpath as appropriate. This means you don't have to
worry about Xptr in the core signature syntax.
Question: Are things like c14n, encoding, XSLT, etc., ordered or
non-ordered? <transformations> is an ordered list.
6. Which crypto algorithms do we choose and mandatory to implements
and defaults? Also need to include security requirement such as
avoiding Phillip's downgrade attack mentioned on the list.
Need to references specs, define algorithm, take from Brown.
hash: SHA-1 (mandatory), MD5 (recommended) AES-H (keep an eye out)
MAC: HMAC-SHA1 (recommended), HMAC-MD5 (optional)
PK Signature: DSS=DSA with SHA-1 (mandatory); RSA with SHA-1
(recommended); RSA with MD-5 (optional); ECDSA (coming along)
Key Agreement: DH (optional) as defined/specified in the keyinfo
block.
7. Do you do combined signature types, or have two different
signatures? reagle: if they are two different signatures, can make
statements about each. Solo: could do it either way. Discussion:
why you might choose one or the other. Solo: it'll be clearer when
we go to implement.
8. Definition: encoding is arbitrary ways to represent a set of
characters; c14n is one particular representation of multiple
permissible representations.
1. Null (mandatory)
2. Minimal (mandatory) CR/LF, encoding, UTFF-8,
3. Minimal': white space handling?
4. DOM (optional)
5. SyntaxC14N (optional)
Boyer: we use the "<?" at the beginning of the document to
determine the encoding, but what if we only have a part of an XML
document? Reagle: good question!
Action item: Ed Simon, find someone to do minimal c14n. Milt will
propose whitespace handling.
Action item: Don poke on a specification of DOM-c14n (right now it
is wrapped in DOM-HASH. (Boyer, would DOM-c14n do attribute sorts
and white space handling?)
Tuesday, August 31
Regrets: Barb Fox, Milt Anderson,
900-1015 Wrap Up of Syntax
* Peter Lipp's object location proposal on the list is accepted.
1030-11 Requirements
1. add security requirements.
2. Don and ? has a few comments will send to list.
1100-1200 Signature Semantics (Notes: Reagle)
Rohit: point of clarity: a signature on a manifest may very well
validate, while the manifest (assertions) do not -- these are
distinct things.
Manifest is a collection of things, you need not validate.
Package is a collection of things, plus assertion of identity between
them.
Manifest and Package. Do we define attributes given a reference
stating the references should be fetched and validated? Or is it part
of the definition?
Reagle: argues against permitting external semantics to be introduced
into our definition through ambiguous manifest-attributes (Whether
those references are confirmed is up to the application.) Others can
define their own threshold XML application
<someoneelse:threshold>...</threshold> or make a statement about the
dsig:manifest using something like RDF.
First, a non-dsig application isn't going to know what the
relationship between manifest and man-attributes is, have to read the
spec.
<dsig:manifest id="1">
<signed objectref/>
<signed object/>
<man-attributes/>
</dsig:manifest>
However, if man-attributes is merely a signed-object with defined
policy assertions that reference "1", relationships are much more
exlplicit.
Second, lets avoid things like:
<dsig:attribute type="CDATA" and value="CDATA"/>
Make people introduce a new qualified namespace element with clearly
defined semantics, or make a statement about an existing resource.
Solo and consensus.: reconsideration on signedattributes,
signedattributes are merely a signedobject, referenced by the
signedobject reference. the signedobjectreference has a t ype
describing if its a manifest, package, signedattributes. Same with
manifest attributes but at a lower level.
Todd: we need a good way of binding the XML, style sheets, schemas,
and DTDs. Group members may work on a paper addressing the legal
issues of this and potential package requirements but not critical
path.
1030-1100 Scheduling and Allocating future documents and con calls
Calls now on Thursday on Noon.
CP (critical path), ST (standards track)
* Requirements (Reagle). CP
* Core Syntax (Fox, Solo, Brown). CP, ST
* Manifest & Package Application Defn. (Vincent). ST to be
integrated into other docs.
* Algorithm Definitions. (Bartel) CP, ST
* Scenarios (Boyer) to be integrated into other docs.
* Implementation (Simon) CP. will start playing with implementations
as soon as feasible, might propose how to do interop.
1300-1400 Marketing and Promotion
Once we have something we are comfortable with, we need to get on XML
sites and get people talking on XML-dev. Might have a marketing plan.
References
1. http://www.ietf.org/
2. http://www.w3.org/
3. http://www.w3.org/Signature/Overview.html
4.
http://cgi.w3.org/cgi-bin/html2txt?url=http://www.w3.org/Signature/Overview.h
tml
5. mailto:reagle@w3.org
6. http://www.w3.org/Signature/Drafts/xmldsig-scenarios-990818.html
7. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#one
8. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#EnvelopedDirect
9.
http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#UnenvelopedIndirect
10.
http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#UnenvelopedDirect
11. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#three
12. http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#Four
13. http://www.w3.org/Signature/Drafts/xml-dsig-datamodel-990823.html
14.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/thread.html#1
46
15.
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0244.html
16.
http://www.w3.org/Signature/Minutes/Irvine-Minutes.html#Signature_Semantics
_________________________________________________________
Joseph Reagle Jr.
Policy Analyst mailto:reagle@w3.org
XML-Signature Co-Chair http://w3.org/People/Reagle/
Received on Wednesday, 1 September 1999 15:19:33 UTC