[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Proposed text on C14N
r/Frederick.Hirsch@nokia.com/2003.08.28/10:33:00 >Rephrase that: "Thus inclusive canonicalization is safer when used in cases wh >ere the signed content is moved from one XML context to another and the applic >ation knows inappropriate namespace declaration inheritance is not an issue. I >nclusive canonicalization is also recommended when the XML context is not to b >e changed, reducing risks with inappropriate context changes (e.g. changed QNA >ME namespaces)" s/inclusive/exclusive/ on line 1. I would, verbosely, express it thus: Inclusive c14n includes in the canonical form all inherited and local namespace declarations and xml: attributes, whether or not they are visibly utilized. As a result, if the signed data or signature are moved into a new context, or if new ancestor namespaces or xml: attributes are introduced into the document (e.g., by intermediary processing) then the signature will be rendered invalid. Exclusive c14n includes in the canonical form only those namespace declarations that are visibly utilized or explicitly parameterized, and only local xml: attributes. As a result, the signed data and signature are immune to irrelevant contextual changes. However, explicit application and/or schema support is required to accurately parameterize the algorithm with non-visibly utilized namespace prefixes of the signed data (e.g., QName prefixes). Otherwise, the signed data may be vulnerable to semantic changes that will not be detected by the signature. Consequently, inclusive c14n is the safer canonicalization algorithm from a security perspective: It requires no knowledge of the data that are to be secured in order to safely sign them. On the other hand, exclusive c14n is required in order to generate self-signed structures that support placement within different XML contexts. Inclusive c14n meets the needs of the common usage scenarios of WS-Security: SOAP messages are not typically moved from one XML context to another, and the semantics of the SOAP body are typically not known to the security module. Exclusive c14n meets the needs of, for example, SAML tokens: These are expressly designed to be self-signed structures that will be placed into different XML contexts. Further, the semantics of the SAML token will be explicitly known to the signer, so it can accurately parameterize the algorithm. Exclusive c14n does not solve the problems of encapsulating a signed SOAP message within another document: It cannot address ID attribute clashes between the encapsulated SOAP message and the encapsulating document, etc. For this reason, SOAP attachments or equivalent must be used in order to effect message encapsulation, allowing each encapsulated message to remain in a distinct document context. merlin >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_workgroup.php. > > >To unsubscribe from this mailing list (and be removed from the roster of the O >ASIS TC), go to http://www.oasis-open.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]