[Bug 4746] clarify SMLIF section 2 signature requirements

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4746


kumarp@microsoft.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Keywords|needsAgreement              |hasProposal




------- Comment #3 from kumarp@microsoft.com  2007-11-07 18:03 -------
Proposal:
Remove all references to XML canonicalization from the specification.

Reasons / More Info:
--------------------
I investigated XML signature related issues to propose answers to the following
questions:
1.      Should the SML-IF spec define whether a producer must perform XML
canonicalization before writing an SML-IF document?
2.      If documents are already signed, what should an SML-IF producer do to
the signatures if the producer wants to sign the entire document as well? That
is, should the producer strip the existing signature(s) before adding documents
to SML-IF?

[1]
The XML signature spec defines a customizable and extensible method for signing
XML and non-XML content. A digital signature can be embedded in the signed
document (there are 2 sub-flavors: enveloped / enveloping) or it can be
detached from the signed document. The Signature element contains a single
signature over one or more data objects. Each data object to be signed is
represented using a single Reference element (this should not be confused with
SML reference element). Each Reference element allows zero or more
transformations over original data before the digital signature is computed.
The XML canonicalization is just one such possible transform. A transform may
omit parts of the original data or add new one. There is no restriction on the
type or number of transforms that an application may use. One canonicalization
algorithm removes comments. One other form preserves comments. Each application
must be free to use the transforms that best fit its needs. The SML WG cannot
predict specific requirements for all applications based on SML therefore we
must not impose any restriction involving specific transformation. Note that
this does not harm interop. Regardless of the number and type of
transformations used, both producer and consumer apply them identically and
thus arrive at the same message digest (if there is no tampering).

[2]
The XML signature is encoded using XML elements. Even if a document already has
an XML signature, it can be safely packaged inside an SML-IF document. Since
the SML-IF doc is itself an XML doc, it can be signed like a regular XML doc. A
producer does not need to remove existing signatures. Moreover, if it is
desired that existing signatures should not be included in signature
calculation of the SML-IF document, a producer can logically remove the
signatures (by defining appropriate transforms) without having to physically
remove the signatures. An application must be free to use either method. 


Some references with relevant info:
1.      http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2.      http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
3.     
http://www.w3.org/Signature/Drafts/PROP-xmldsig-faq-20000218/Overview.html
4.      http://msdn.microsoft.com/msdnmag/issues/04/11/XMLSignatures/

Received on Wednesday, 7 November 2007 18:03:45 UTC