W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2001

RE: Question about EncryptedType

From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
Date: Thu, 1 Nov 2001 13:37:05 -0500
Message-ID: <1DE737930E15D511B64400D0B76FE26201A5BBF0@ma07exm01.corp.isg.mot.com>
To: "'reagle@w3.org'" <reagle@w3.org>, Takeshi Imamura <IMAMU@jp.ibm.com>, bdournaee@rsasecurity.com
Cc: xml-encryption@w3.org, Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, dee3@torque.pothole.com
It seems to me that it is a historic accident of our early ignorance and lack of experience that inclusive canonicalization is recommended for xmldsig. It makes signatures brittle for protocol applications. I would recommend exclusive canonicaliztion for most xmldsig applications at this point and certainly for any where the XML context of signed/digested XML (including SignedInfo) could change.

For encryption, if encrypted XML is going to be decrypted into a different XML context and you don't want its meaning to change, you should use inclusive canonicalization (the W3C C14N Recommendation) to include much of its original context. If you want the XML to be subject to changes in its context (i.e., for namespace prefixes in it to possibly be bound to different namespaces), then you can use exclusive canonicalization or some non-canonical serialization.

Whether or not comments are includes is somewhat of an orthogonal consideration which is usually of no consequence.


-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org]
Sent: Wednesday, October 31, 2001 6:04 PM
To: Takeshi Imamura; bdournaee@rsasecurity.com
Cc: xml-encryption@w3.org; Donald Eastlake; dee3@torque.pothole.com
Subject: Re: Question about EncryptedType

On Thursday 25 October 2001 23:04, Takeshi Imamura wrote:
> >Technically speaking, I'd argue they are *not* in conflict. 4.1 says to
> >serialize, and 5.9 says one of those ways to serialize is c14n. However,
> > I do agree with you that it makes one wonder when one should use c14n.
> > I don't think anything in xenc requires c14n. If you need to c14n, it
> > would relate to integration with xmldsig. Based on my email [1] with
> > Takeshi regarding the Decryption Transform, it might not even be needed
> > there.
> >
> >So Takeshi, where does one use c14n when used with xmldsig, and should
> > we say it is recommended at all?
> The c14n is useful in a case, for example, where the outer context of the
> fragment which was signed and then encrypted may be changed.  Otherwise
> the validation of the signature over the fragment may fail because c14n
> may include unnecessary namespaces into the fragment.  In this case, the
> decryption transform does not help.  So I think that c14n should be
> recommended.

As Blake points out, c14n makes sense when xenc is used with xmldsig, but 
if one is not concerned with signatures, is c14n then recommended for xenc? 
(If so, in what capacity?) (Blake, the keywords are OPTIONAL, recommended 
is informative with respect to xmldsig.)

*Then*, when used with xmldsig, I'd like to see better text than the 
present, "serialization method where the outer context of a fragment which 
was signed and then encrypted may change. Otherwise the validation of the 
signature over the fragment may fail because the canonicalization by 
signature validation may include unnecessary namespaces into the fragment."

Even if you use c14n, if the outer context changed while the fragment was 
encrypted, when you validated (and &c14n; it) the signature might break 
because its serialization might include new namespaces.

If you're worried about context changing, one should use c14n-exc. Perhaps 
someone could present a rational of the benefits of the problem c14n, 
c14n-withComments, and c14n-exc each provide in the xenc+xmldsig scenario?


* I will be in France from 3-9 November for the W3C AC Meeting.

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/
Received on Thursday, 1 November 2001 13:37:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:05 UTC