>On Monday 18 March 2002 16:56, merlin wrote:
>> >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..
>The text in question is, "([NFC] MUST be applied when this involves 
>conversion from a legacy (i.e. non-Unicode) encoding.)"
>The problem is that we might be encrypting element with an XML character 
>datum for a composed charcter ("a"+"^"). It's NFC should be "". We don't 
>want to encrypt and hand another application "dirty" (non-NFC) characters 
>upon decryption.

I agree with this principle.

>We could, state that the Element and Content must be in NFC form. Otherwise 
>whomever is serializing (the encryptor or application) MUST throw an error. 
>Is this acceptable?

However, I don't really like the MUST throw an error part. C14n doesn't
have this requirement, and there is no real difference between checking
for NFC and actually performing NFC. I'd prefer merely:

  Element and Content MUST be in NFC form.

This serves the same end, using exactly the same mechanism as dsig and
c14n: Whoever is handing us the data MUST be working in NFC.


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 Tuesday, 19 March 2002 18:06:31 UTC