W3C home > Mailing lists > Public > xml-encryption@w3.org > March 2002


From: merlin <merlin@baltimore.ie>
Date: Mon, 18 Mar 2002 21:56:44 +0000
To: reagle@w3.org
Cc: xml-encryption@w3.org, duerst@w3.org
Message-Id: <20020318215644.5F63A4422C@yog-sothoth.ie.baltimore.com>
>On Thursday 14 March 2002 17:24, merlin wrote:
>> If xmldsig (by virtual of c14n) requires that NFC conversion be
>> done by the application's XML processor, it seems appropriate
>> that xmlenc place the requirement at the same place. Otherwise,
>> use of the two specs together isn't completely consistent.
>I think you are correct about symmetry... XMLDSIG says that it RECOMMENDS 
>all serializations use NFC and states that the two that it specificies DO:
>Various canonicalization algorithms transcode from a non-Unicode encoding 
>to Unicode. The two algorithms below perform text normalization during 
>transcoding [NFC, NFC-Corrigendum]. We RECOMMEND that externally specified 
>canonicalization algorithms do the same.

In practice, they don't actually *perform* NFC; c14n mandates that
"the XML processor used to prepare the XPath data model input is
REQUIRED to use Unicode Normalization Form C". So c14n doesn't
perform the normalization; it requires that it be done already.

>All documents operated upon and generated by signature applications MUST be 
>in [NFC, NFC-Corrigendum] (otherwise intermediate processors might 
>unintentionally break the signature) 
>> I wonder could we rephrase XML encryption similarly to c14n:
>> 1.   If the data is an 'element' [XML, section 3] or element
>>      'content' [XML, section 3.1], obtain the octets by serializing the
>>      data in UTF-8 as specified in [XML]. Serialization MAY be done by
>>      the encryptor. If the encryptor does not serialize, then the
>>      application MUST perform the serialization. The XML processor used
>> to prepare the XML data is REQUIRED to use Unicode Normalization Form C
>> [NFC, NFC-Corrigendum] when converting an XML document to the UCS
>> character domain from any encoding that is not UCS-based (currently,
>> UCS-based encodings include UTF-8, UTF-16, UTF-16BE, and UTF-16LE, UCS-2,
>> and UCS-4).
>However, I'm not sure what is meant by this... What do you mean by "XML 
>processor." We've defined an application and encryptor. Either the 
>*application* or the *encryptor* serialize the data, if they do so, they 
>would have to use NFC right, particularly if it's signed?

I was trying to mirror text from c14n. I'm trying to say that we should
require that the XML input to encryption already be in NFC, as dsig and
c14n do, so it is not the responsibility of the encryptor to normalize
it. I'm not sure how else to express this..


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 by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Received on Monday, 18 March 2002 16:56:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC