Re: NFC

I missed that. I'm creating non-NFC documents for testing
using DOM, which obviously isn't right.

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).

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.

Merlin

r/reagle@w3.org/2002.03.14/17:00:18
>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?
>
>http://www.w3.org/TR/2001/REC-xml-c14n-20010315
>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).
>
>
>[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0046.html
>>> > - 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.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>


-----------------------------------------------------------------------------
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.
   http://www.baltimore.com

Received on Thursday, 14 March 2002 17:24:31 UTC