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