RE: [wss] Proposed text on C14N

[Peter Dapkus <pdapkus@bea.com>]

I think the example I used was that if you add attribute from a
previously undeclared namespace to one of the parents of the
to-be-signed element, it changes the namespace context.  In the
inclusive case, this will invalidate the signature, because the new
namespace from the attribute will be included in the inclusive c14n
output.  

the xsi:type example was the interop problem we saw; it's a common
source of trouble for exclusive c14n:   xsi:type is an attribute that
has a QName value.   xsi:type is used whenever your schema calls for a
specific type, and you use a subtype of that type in stead; in that
case, you must make the sender aware the content is the subtype so that
it can be properly parsed/validated.    the namespace referenced by the
QName value of xsi:type falls in the category of *not* visibly used --
to work properly with exclusive c14n, you need to include it as a
parameter (via InclusiveNamespaces) to exc c14n.


cheers,
-Pete

On Fri, 2003-08-29 at 13:07, Hal Lockhart wrote:
> What Peter Dapkus pointed out to me (and I believe this was actually seen
> during the Interop) was that if Inclusive is used, the signature can be
> invalidated by completely unrelated and seemingly innocent changes in the
> surrounding context.
> 
> Suppose for example, you have a signed chunk of XML in the body which is
> nested a couple three levels deep. Suppose some intermediary makes a
> seemingly unrelated change elsewhere in the body, but in a outer (enclosing)
> level.
> 
> Suppose they (perhaps without even realizing it) introduce a value which is
> a subtype of a type defined in the schema for the given element or
> attribute. This can cause the XML processing tool (e.g. DOM library) to emit
> an xml:type declaration. If this has not appeared before, it will be added
> to the c14n output text and the signature will break.
> 
> In other words, Inclusive can break even when the signed content is not
> moved from one document to another.
> 
> Hal
> 
> > -----Original Message-----
> > From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> > Sent: Thursday, August 28, 2003 10:33 AM
> > To: hlockhar@bea.com; wss@lists.oasis-open.org
> > Subject: RE: [wss] Proposed text on C14N
> >
> >
> > Rephrase that: "Thus inclusive canonicalization is safer when
> > used in cases where the signed content is moved from one XML
> > context to another and the application knows inappropriate
> > namespace declaration inheritance is not an issue. Inclusive
> > canonicalization is also recommended when the XML context is not
> > to be changed, reducing risks with inappropriate context changes
> > (e.g. changed QNAME namespaces)"
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia Mobile Phones
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ext [mailto:Frederick.Hirsch@nokia.com]
> > > Sent: Thursday, August 28, 2003 10:14 AM
> > > To: hlockhar@bea.com; wss@lists.oasis-open.org
> > > Subject: RE: [wss] Proposed text on C14N
> > >
> > >
> > > I am trying to understand the summary of the C14N thread. Is
> > > this correct:
> > >
> > > Exclusive canonicalization is generally necessary when a
> > > portion of XML is to be removed from one context and put into
> > > a different XML context. The reason is that inclusive
> > > canonicalization would typically copy one set of "extra"
> > > namespace declarations from ancestor nodes in the first
> > > context and another from the second, causing the signature
> > > verification to fail.
> > >
> > > Exclusive canonicalization is not appropriate in all cases,
> > > however, since it increases the risk that not all
> > > declarations will be included explicitly in the signed XML.
> > > Examples are namespace declarations associated with
> > > non-visible prefixes, such as QNAMES in element content or
> > > attribute values, as well as xml: attribute declarations. A
> > > mechanism to explicitly add declarations would require
> > > knowledge not typically available to the security code. Thus
> > > inclusive canonicalization is safer when used in an
> > > environment where removal of XML content is not expected.
> > >
> > > To summarize, inclusive canonicalization may include too much
> > > in the XML to be signed and exclusive canonicalization may
> > > include too little. Thus application decision is required as
> > > to which mechanism to use, given processing expectations and
> > > knowledge of schema (e.g. are QNAMEs used).
> > >
> > > (Is it possible to extend exclusive canonicalization to
> > > recognize QNAMES and pull in the declarations as needed?)
> > >
> > >
> > > regards, Frederick
> > >
> > > Frederick Hirsch
> > > Nokia Mobile Phones
> > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from
> > > the roster of the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_wor
> kgroup.php.
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
-- 
Peter Dapkus <pdapkus@bea.com>