RE: [wss] Proposed text on C14N

["Hal Lockhart" <hlockhar@bea.com>]

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.