On Thursday 14 March 2002 13:41, merlin wrote:
> What is the origin of our requirement that NFC be applied to XML content
> that is serialized from a "legacy encoding"?
> I'm just not clear why an encryptor should be concerned with this.
> Should it not be the responsibility of the application to do NFC if it
> cares about it?

It was added and agreed to given a last call comment form Martin [1].

> The current problem I have is that if I apply NFC to XML data that are
> covered by a signature, then verification of the decrypted data fails
> if NFC actually does anything.

If what you are signing has been c14nizezd and it the original was not from 
a UCS character domain, wouldn't the ressult be in NFC?
However, the XML processor used to prepare the XPath data model input 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).

>> > - This does not yet say anything about NFC when something being
>> >    encoded is serialized in UTF-8. In that case, it should say
>> >    that NFC MUST be applied when this involves conversion from
>> >    a legacy (i.e. non-Unicode) encoding.
>>Ok, in 4.1 step 3.1 (Encrypt the Data) now says just that:
>>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]. ([NFC] MUST be applied when this involves conversion
>>from a legacy (i.e. non-Unicode) encoding.) Serialization MAY be done by
>>the encryptor. If the encryptor does not serialize, then the application
>>MUST perform the serialization.
>This looks good to me.


Joseph Reagle Jr.       
W3C Policy Analyst      
IETF/W3C XML-Signature Co-Chair
W3C XML Encryption Chair

Received on Thursday, 14 March 2002 17:00:23 UTC