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


From: Joseph Reagle <reagle@w3.org>
Date: Tue, 19 Mar 2002 17:38:52 -0500
Message-Id: <200203192238.RAA11907@tux.w3.org>
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org, duerst@w3.org
On Monday 18 March 2002 16:56, merlin wrote:
> >http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-c14nAlg
> >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.

That's true... It's not part of the canonicalization process itself, but it 
*is* a required characteristic of the output that is done by constraining 
the input. "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".

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

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?
Received on Tuesday, 19 March 2002 17:38:56 UTC

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