OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] Proposed text on C14N



Maybe we should have a rule that says you can only use canonicalizations 
that don't depend on the context in which the signed content appears?

At 01:07 PM 8/29/2003, 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]