RE: [Bug 4746] clarify SMLIF section 2 signature requirements

These are very good questions.

A producer program cannot determine, without some human input, whether a change to a document will invalidate its signature. This is because a program cannot understand the semantics of an arbitrary transform. Thus the answer to the first question is: "it depends".

Whether to-be-packaged documents are pre-signed or whether it is important to preserve signatures on them really depends on the requirements & scenarios of each specific application. Further, whether a change actually invalidates a signature will depend on the specific transforms defined in the signature. These issues belong in the application domain. Our group cannot design a solution that will fit all situations. The best we could do is to recommend certain things to improve interop. However, we probably should not require any of it when generating SML-IF document. This way an application developer will be able to choose the right solution for the specific needs of that application.

This is why the proposal recommends that we should not require any specific transform (such as a specific form of canonicalization).

I have not seen questions or disagreement on the proposal from other team members. Please voice your concerns, if any, soon so that we can reach consensus on the next conf call.


From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On Behalf Of Sandy Gao
Sent: Wednesday, November 07, 2007 12:26 PM
To: public-sml@w3.org
Subject: Fw: [Bug 4746] clarify SMLIF section 2 signature requirements


Kumar,

> A producer does not need to remove existing signatures.

Are these signatures still valid?

For example, if my model documents are signed using C14N, but the documents have to be changed (e.g. to add sml:ref attributes) to be packaged in an IF document, wouldn't my signatures all become invalid?

If it's not because of adding sml:ref attributes (the only case we know that we have to change packaged documents), I would say packaged documents must be C14N-equivalent to the original document. Or if we take the base64 approach for the DTD issue, we could even say it must be identical to the original document, so that all signature algorithms (not only C14N) would work.

It's not clear to me which one is less an evil:
- Require IF producers to modify model documents to add defaulted sml:ref attribute, and possibly break signatures
- Forbid IF producers from modifying model documents, and live with potential inter-op between processors who do or do not use schema to help locate sml references.
- Forbid IF producers from modifying model documents, and require consumers *not* to use schema to help locate sml references.

Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG<http://www.w3.org/XML/Schema/>
Member, W3C SML WG<http://www.w3.org/XML/SML/>
(1-905) 413-3255 T/L 313-3255

----- Forwarded by Sandy Gao/Toronto/IBM on 2007-11-07 03:01 PM -----
bugzilla@wiggum.w3.org

2007-11-07 01:03 PM

To

Sandy Gao/Toronto/IBM@IBMCA

cc

Subject

[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/