Re: [wss] issue: including namsepaces for QName values in c14n output

[merlin <merlin@baltimore.ie>]

Hi Peter,

No, this doesn't introduce a new validation step - it has
always been the case that you must '"See" What is Signed'
(§8.1.3). A signature reference #foo over an element Foo could
use any number of transforms, so the recipient can make no
assumption that Foo is really signed. The most general and
safe solution is to re-parse the actual canonicalized/digested
bytes, and use the new document. In this way, you are safe
from most attacks - you will only ever utilize the actual
signed data with whatever context is inherited by the
canonicalization algorithm.

This is, of course, inefficient. If &c14n; is used, and
there are no other transforms, and the signed data makes no
use of inherited context other than that covered by &c14n;
(it covers namespaces and xml:* attributes), then you can
safely use the original XML structure.

Or, in the case of &exc-c14n; you must verify that the signed
data does not use inherited xml:* attribute information,
and that all non-visibly utilized namespace prefixes are
declared in the unsuppressed namespace prefix list of the
canonicalization algorithm used in the signature reference
covering the data.

Were I to codify this in language, it would be something
like this:

When constructing a same-document XML signature reference for
use in a wsse:Security header, the sender MUST ensure that an
appropriate canonicalization algorithm is used. The sender MAY
use exclusive c14n if, through first-hand knowledge of the data
being signed and the relevant schema, or through some other
mechanism, it can ensure that the canonicalization algorithm
is parameterized with all namespace prefixes utilized, albeit
non-visibly, by the signed data; or, less specifically but
no less securely, all namespace prefixes that are utilized
by the signed data, and if the signed data does not rely on
any other inherited context, such as the value of attributes
in the XML namespace. Otherwise the sender MUST use inclusive
c14n or an alternative canonicalization algorithm that meets
the security requirements of the signed data.

When validating a same-document XML signature reference in
a wsse:Security header, the recipient MUST ensure that an
appropriate canonicalization algorithm was used, and that no
unexpected transforms occur in the reference. If exclusive
c14n was used then the recipient MUST, through first-hand
knowledge of the signed data and the relevant schema, or
through some other mechanism, ensure that all namespace
prefixes utilized by the signed data are included in the
canonical form, and that the signed data relies on no other
inherited context. Otherwise, the recipient MUST ensure that
the canonicalization algorithm that was employed meets the
security requirements of the signed data. If unexpected
transforms are encountered, or if it is not possible to
validate the canonicalization algorithm, then the recipient
MUST NOT assert the validity of the identified portion of
the SOAP message under consideration. The recipient MAY
provide a qualified assertion, subject to the transforms and
canonicalization algorithm, in order that the application can
make an informed decision about the data, and it SHOULD permit
the application to re-parse the canonicalized, pre-digested
bytes, in order to obtain an XML document that accurately
reflects the data, and any inherited context, that were
actually signed.

[ sender, recipient, application are probably not the correct words ]

However, this is, in some sense, just generic XML signature
text.

In answer to your comment below about extensions and how
recipients must understand extensions used by the sender
in order to validate messages; as long as the recipient does
not process any unknown extensions, then it's reasonably
safe for it to ensure that just the namespace prefixes that
it knows about are signed; if other parts are unsigned then,
since it's not using them, it doesn't matter. However, as
soon as you extend this to signing an application-level
SOAP body, things get difficult; you can't say that the
body is 'signed' unless you know what namespace prefixes
it uses.

As I said earlier, I don't know why we're using &exc-c14n;
in the first place. Do we expect that our SOAP messages will
be relocated into other contexts? If not, maybe we should be
using &c14n; instead.

Merlin

r/pdapkus@bea.com/2003.07.29/14:43:23
>I reviewed draft 14 where issue 95 was addressed and couldn't find any
>text introduced to address the issue of namespaces that are non-visibly
>used (ie namespaces used in QName values).   The spec should at  least
>state the requirement to add non-visibly used namespaces.   Preferrably,
>it would provide some detail about how to identify namespaces that are
>non-visibly used.   
>
>I think there are a couple of questions to be answered in this regard:
>
>First, does this introduce an additional step to signature validation,
>where we validate that all non-visibly used namespaces were correctly
>included?  seems like it should.
>
>Second,  how (if at all) can we identify non-visibly used namespaces
>without awareness for the messageschema and any extending schemas? 
>
>Requiring awarness of message schema is a bad thing -- it tightens the
>coupling between web service implementations for the sender and receiver
>by requiring both to be in sync on the message schema and on any
>extensions to that schema.   This would be the only place that awareness
>of the message schema has so far been required for WS Security
>processing.
>
>If we don't require awareness of the message schema, then it seems like
>we ought to be very explicit about the algorithm by which we identify
>non-visibly used namespaces -- to be sure that we can always get
>agreement between the sender and the receiver about which namespaces
>should have been included (assuming we also validate the non-visibly
>used namespaces).
>
>If we *do* require awareness, then we should probably warn the reader
>against extending signed elements even when their schemas allow unless
>they're relatively certain that the receiver is aware of the extensions
>too.
>
>Finally, I am assuming that we include these namespaces via the
>InclusiveNamespaces child of Transform, defined in the Exclusive c14n
>spec, correct?
>
>It might also be nice to update the example to demonstrate the inclusion
>of the namespaces in the signature.
>
>On today's call, I think I mispoke -- I believe Merlin had agreed on a
>previous call to submit text because he had a clear idea for how this
>all should be done.  Still up for it, Merlin?
>
>
>cheers,
>
>-Pete
>
>-- 
>Peter Dapkus <pdapkus@bea.com>
>
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-o
>pen.org/apps/org/workgroup/wss/members/leave_workgroup.php
>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com