minutes of 4 November 1999 telecon

XMLDSIG Teleconference Minutes, 4 November 1999

On call
     Barbara Fox, Microsoft
     John Boyer, UWI
     Donald Eastlake, IBM
     Ed Simon, Entrust
     Raghavan, Sun Microsystems,
     Mark Bartel, JetForm
     (Dave Solo, CitiCorp ? regrets)
     (Joseph Reagle, W3C ? regrets)

Notes by Donald Eastlake

Implementations, Code availabiity - < 10 minutes
Donals Eastlake ? have posted IBM canonicalization code on my home ftp
server as previously mentioned on mailing list.  This is from Hiroshi
Maruyama at the IBM Tokyo Research Laboratory.  The plan is to incorporate
this in the security suite up on IBM's alphaWorks site and also update the
XML digital signature stuff in the suite to  correspond to the current
working group draft core syntax and processing document.
Barb Fox ? It would be good to post sample correct XML digital signature
package output?.
Ed Simon ? May have some more reference code implementation next week?
Donald ? in the future there may be a private web site based on the IBM
code where you can cut and paste a signature and submit it and the web
server will tell you the results of trying to verify it.  Others are
welcome to set up such testing systems.

Signature Syntax & Processing draft questions:
     Securing Location/Transforms - < 10 minutes
       Levels of indirection, Manifests, References, ...
Discussion of recent suggestions that perhaps Location shouldn't be signed
and that the resulting ability to move data around might imply need for
different Transforms due to different encoding in different places, etc.
This can  be handled currently by having SignedInfo point to a Manifest
which points to a Manifest but that's kind of complex and depends on
applications behavior.
John Boyer - suggested accomplishing this by including optional Transforms
over SignedInfo in SignedInfo.  Such Transforms could, for example, cause
Location to be omitted from the digest.
This whole area needs further discussion and thought.

     Parameters - < 10 minutes
       Types a element names, attributes, ...
Several people spoke against having parameters be elements like Integer,
Real, Boolean, String, Binary, etc.  Not clear about the desirability if
these are qualified by a descriptive Namespace.  More descriptive element
names had not been suggested before by some due to fear of a need to
include them all in the DTD.
Ed Simon - specific elements  schema better that DTD and being worked on
with Joseph can be presented next week.
Donald ? This whole area needs further discussion.  Final syntax and
processing document should be careful to specify when elements / attributes
from other name spaces can be used for all parts of the syntax.

     Nonces - < 5 minutes
       Size, Entropy, Necessity ?
Barb Fox ? Feeling is that no nonce is required but moving the more
variable sub elements up near the beginning of enclosing signed elements to
make it less effective to try to pre-load digest functions is a probably a
good idea.
Donald ? specification should say it is designed for and only lists
signature algorithms not requiring a nonce.  Verbosity of XML makes it
likely that at least 512 bits will be feed to SHA-1 resulting is good
hashing.

Brief discussion of the idea of encoding a binary PKCS#7 signature in
SignatureValue.  Unanimous opinion of those on the call was that while this
mechanically fits into the syntax, it is not an XML digital signature and
would not be conformant to the standard.

     Canonicalization - < 10 minutes
Although more work is needed here to create a synthesis of different
comments on the mailing list, most of those on the call were of the opinion
that it will be very common for applications to use DOM to read SignedInfo.
As a result, some "canonicalization", i.e., a standard way of serializing
the DOM tree, will be essential to working XML digital signatures.
Some syntax constraints may also be needed to avoid problems due to
validating versus non-validating parsers.  For example, no entities,
pre-normalized attribute values?
XML data blocks that are signed are a bit different from SignedInfo and
might be treated as binary/text data requiring minimal or no
canonicalization.

     "SignatureProperties" - < 10 minutes
Discussion just confirmed WG consensus that SignatureProperties is the
place for, and only for, statements about the signature itself, such as
signing time.  Most actual use of CMS "signed attributes" seems to be that
sort of thing anyway.

     WG Meeting Agenda at IETF next week, see below
Ed Simon ? working on schema with Joseph Reagle.  Should have a slot 2nd
session after Canonicalization.  Time for implementations slot should be
longer.


Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668

Received on Friday, 5 November 1999 11:16:22 UTC