Editor: Joseph Reagle email@example.com
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 bold are ones that should still be investigated.
The following emails from WG members express comments/corrections on the
meeting minutes that have been reflected in these minutes.
|Daniel W. Woycke
Monday, August 30
, John Boyer (Notes: Reagle)
Enveloped Internal Content
Signature element is the root element. Doesn't need to be supported directly,
more elegant ways to do things.
Everyone's syntax does this, no worries mate.
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
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
Signing External Resources (Detached Signatures)
Signing Partial XML Documents
Boyer shows and argues that July XPointers (or more specifically XPath) seemingly
offers the filter/select/exclude/extract 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? URI's
aren't sufficient for selection in the manifest, but perhaps they are in
the core signature. (Also, the WG seems happy with calling "exclude" "extract"
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 also asserts this adds security problems in that it requires modifications
to the signed document. (see
Boyer raises a 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
1015-1030 Data Model,
Joseph Reagle (Notes: Daniel Woycke)
Benefit of Data Model is to view how the assertions, elements and structures
Manifest is a series of assertions about the existence and "trust" of information
referenced by manifest
Package asserts all references are to the same information whether coded
into a URI or inline, etc.
Is verification of all assertions necessary? This is not part of the working
By looking at the data model once can view the relationships and bound the
The WG is to deal with the signature and its relation to its elements and
objects and reference
The data model needs to be updated to match the current spec.
Reviews his proposed data model, explains:
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.
C14n will be dealt with this afternoon.
Notes for David Solo ---
Don plus discussion -- Distinguish between three levels.
Core signature syntax -- the syntax for creating a signature over a set of
bytes within the scope of the signature
Signed objects syntax -- how you sign referred to and signed objects.
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
Where does the signedobjectdata refer to an object that has been already
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:
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.
transformations: keeping it external means one can have one single c14n over
the signedinfo, that are indistinct of the content transformations (no
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
[Reagle summary of Open Issues from Syntax:]
[The resolution to many of these issues will be reflected in the
draft Solo will send since we went back and forth on some of this stuff
quite a lot.]
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 tomorrow's discussion where
both types of attributes are removed.)
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
algorithms (crypto/hash): mandatory, recommended, optional
c14n, syntax WG, null and simple/minimal c14n
exclusion/xptr. the dsig:exclude declaration, which signature does it belong
<X dsig:exclude> ...</X> everything is hashed and signed, now
someone adds a
<Y dsig:exclude> ...</Y> it will get rendered differently, but
not break the signature because other applications won't know the dsig:exclude
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 (without fragmentID
1990902:1.) 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.
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.
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.
Definition: encoding is arbitrary ways to represent a set of characters;
c14n is one particular representation of multiple permissible representations.
Minimal (mandatory) CR/LF, encoding, UTFF-8,
Minimal': white space handling?
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:
Action item: Ed Simon, find someone to do minimal c14n. Milt will propose
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.
add security requirements.
Don and ? has a few comments will send to list.
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.
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
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.