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


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]