Re: ACTION -169: Update draft - Transform Note

Responses inline...


On Mon, 2009-02-02 at 17:57 -0500, Frederick Hirsch wrote:
> Isn't it the case that you *need* to know which came first encryption  
> or signing when these operations are interleaved on subsets of  
> content, and that this cannot be pushed out to xproc because the need  
> to know is at the security level?

Yes.

> Is what is bad not the decryption transform per se, but the use case  
> of interleaving partial signing and encryption operations?

I'm not sure that I would call the use case "bad". Am I missing the
intent here?

Here's another use case (off the top of my head so if I'm off base, let
me know). One has data one wants to sign and encrypt for different
people. Your preference is to sign the original data, rather than the
encrypted. No interleaving but is that not a scenario where the
Decryption Transform would make sense? (Assuming one might
encrypt/obfuscate the signature/hash to ensure that it did not reveal
anything.)

> If this transform were disallowed, what would be the impacts on that  
> sort of use case?
> 
> Can someone please take an action to walk us through this? (seems like  
> we have a list of issues with the decryption transform but now need to  
> understand the alternative if it were not defined. It seems to me  
> there was a clear need for it if this use case is to be supported.)
> 

I'd like a little more time to think about this but we could try an
initial discussion tomorrow -- the starting question could be "do we
need to maintain the Decryption Transform?".

> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Feb 2, 2009, at 4:40 PM, ext Pratik Datta wrote:
> 
> > Decryption Transforms is bad from the performance point of view too.
> > Decryption is an expensive operation, and it is also followed by  
> > parsing and canonicalization.,  and all this needs again to be  
> > repeated because the all operations in the transform chain are  
> > temporary.  I.e. if somebody is using decryption transform - it  
> > usually means they are decrypting and parsing twice.
> >
> > If the receiver already has the decryption key (which they need for  
> > the decryption transform), it makes no sense to not decrypt first.
> >
> > Pratik
> >
> > Ed Simon wrote:
> >>
> >> I'm agreeable to the workflow and "sign what you see" concerns,  
> >> however,
> >> to play the devil's advocate, I'd like to delve into the  
> >> "resolution to
> >> the decryption/verification ordering issue".
> >>
> >> I would agree for the process-oriented scenario described by David  
> >> Solo
> >> in the Decryption Transform, that workflow (XProc) may now be a more
> >> appropriate alternative. On the other hand, signature and  
> >> encryption are
> >> often done together by the same software module and I can see why one
> >> might want to be explicit about how to validate/decrypt a
> >> cryptographically-protected blob within the blob itself.
> >>
> >> Thoughts? Do we know of any use cases where validation of a
> >> */encrypt/sign/encrypt/* blob is best served by a Decryption  
> >> Transform?
> >>
> >> Ed
> >>
> >>
> >> On Mon, 2009-02-02 at 11:20 -0800, Brad Hill wrote:
> >>
> >>> The specification (http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020304 
> >>> ) explicitly describes the use case for the transform as being  
> >>> driven by "workflow", "Sign What You See" and as a "resolution to  
> >>> the decryption/verification ordering issue".
> >>>
> >>> I think that the decryption transform is even more far afield in  
> >>> workflow-space than the XSLT transform, which is at least present  
> >>> at signature creation time and both specified and executed by the  
> >>> signer.
> >>>
> >>> The decryption transform says that a signer must presciently  
> >>> specify the possibility that a later third-party may make breaking  
> >>> changes to the signature and gives implicit permission, sight- 
> >>> unseen, for that third-party to provide instructions which the  
> >>> verifier (who only needs this transform if she has the capability  
> >>> to perform the decryption but is otherwise unaware of the presence  
> >>> and order-of-application of encryption!?) must execute in the  
> >>> context of authenticating the first-party data.
> >>>
> >>> It's madness from a cryptographic, security and workflow  
> >>> perspective, all.
> >>>
> >>> Brad
> >>>
> >>> -----Original Message-----
> >>> From: Ed Simon [mailto:edsimon@xmlsec.com]
> >>> Sent: Monday, February 02, 2009 10:41 AM
> >>> To: Brad Hill
> >>> Cc: Graf, Kenneth M; Pratik Datta; XMLSec WG Public List
> >>> Subject: RE: ACTION -169: Update draft - Transform Note
> >>>
> >>> Shouldn't an XML Signature instance include all the information  
> >>> needed
> >>> for a signature validator to validate the signature? This, to me,  
> >>> does
> >>> not put the Decryption Transform in the same category as the "Sign  
> >>> What
> >>> is Seen" issue.
> >>>
> >>> Ed
> >>>
> >>>
> >>> On Mon, 2009-02-02 at 10:02 -0800, Brad Hill wrote:
> >>>
> >>>> Agreed.  I would add that I am opposed to perpetuating all  
> >>>> "workflow" functionality, generally.  This would also include the  
> >>>> decryption transform.
> >>>>
> >>>> The problems of workflow and composition of XML processes got  
> >>>> crammed into signature for want of a better place.  Today, the  
> >>>> place for such use cases is XProc.
> >>>>
> >>>> Brad Hill
> >>>>
> >>>> -----Original Message-----
> >>>> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org 
> >>>> ] On Behalf Of Graf, Kenneth M
> >>>> Sent: Monday, February 02, 2009 7:43 AM
> >>>> To: Pratik Datta; XMLSec WG Public List
> >>>> Subject: RE: ACTION -169: Update draft - Transform Note
> >>>>
> >>>>
> >>>> I am against perpetuating the "sign what is seen" use case.  The  
> >>>> potential exposures to validators when XSLT is introduced are  
> >>>> very serious, and I do not see how this achieves the stated goal.
> >>>>
> >>>> If XSLT are limited to trusted XSLT then the following call  
> >>>> sequences yield the same result. "viewerTransform" could be  
> >>>> whatever fun things the browser and its plugins do so the user  
> >>>> actually sees something.
> >>>>
> >>>> whatIsSeen = viewerTransform( sign( htmlXsltTransform( rawData )))
> >>>> whatIsSeen = viewerTransform( htmlXsltTransform( sign( rawData )))
> >>>>
> >>>> I prefer the later; In XMLdsig we do not control nor guarantee  
> >>>> the proper operation of the viewerTransform, I do not see how  
> >>>> including the htmlXsltTransform in the signing operation allows  
> >>>> to achieve the "sign what you see" goal.
> >>>>
> >>>> Thanks, Ken.
> >>>>
> >>>> -----Original Message-----
> >>>> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org 
> >>>> ] On Behalf Of Pratik Datta
> >>>> Sent: Monday, February 02, 2009 1:31 AM
> >>>> To: XMLSec WG Public List
> >>>> Subject: Re: ACTION -169: Update draft - Transform Note
> >>>>
> >>>>
> >>>> Here is a list of changes that I made
> >>>>
> >>>> Changes that we had not discussed, or just alluded to.
> >>>> ---------------
> >>>> 1) Added details about the "sign what is seen" requirement. i.e.  
> >>>> the
> >>>> requirement to convert the xml to a html using XSLT and decrypt  
> >>>> transform
> >>>>   a)  Section 2 bullet 4
> >>>>   b) Added a new <Transforms> element in between <Selection> and
> >>>> <Canonicalization>
> >>>>   c) section 4.3
> >>>>
> >>>>
> >>>> 2) Clarified the requirements in section 3 - there are 4 bullets,  
> >>>> and
> >>>> each is expanded out
> >>>>   in detail in section 3.1 (determine what is signed), 3.2
> >>>> (performance), 3.3 (security) and 3.4 (canonicalization)
> >>>> Section 3.1.1.  and 3.1.2 is new material - talks about problems in
> >>>> determining what is signed
> >>>> Section 3.2.1 and 3.2.3 are also new - talks about performance  
> >>>> problems.
> >>>> Section 3.3 is also new - security- it is basically all the DoS  
> >>>> problems
> >>>> listed in the best requirements doc. the requirement is to solve  
> >>>> them
> >>>>
> >>>>
> >>>> 3) Removed Section 4, as that was overlapping with requirements and
> >>>> design.  Problems in old spec is now part of requirements.
> >>>>
> >>>> 4) Added some more properties to Section 4.4 canonicalization
> >>>>  serialization="EXI/XML" , sortAttributes="true/false",
> >>>> preserverPrefixes="true/false"
> >>>>
> >>>>
> >>>>
> >>>> Changes that were discussed
> >>>> -------------
> >>>> 1) added me as an Author
> >>>> 2) incorporated both of Frederick's emails
> >>>> 3) incorporated introductory text from Scott
> >>>> 4) incorporated , no entity expansion in C14N from Brad
> >>>> 5) Section 3.4 is canonicalization - it has been removed from the
> >>>> requirements document, and placed here
> >>>>     It split up into 3.4.1 historical requirements, and 3.4.2 :  
> >>>> modified
> >>>> requirements. Modified requiremens is what we discussed in F2F
> >>>>
> >>>> 6) Split up the deisgn into a section by element
> >>>>   4.2 <Selection>  4.3 <Transforms>  4.4 <Canonicalization>
> >>>>
> >>>>
> >>>> Pratik Datta wrote:
> >>>>
> >>>>> I have updated the transform notes with all the discussions that  
> >>>>> we
> >>>>> had during the Redwood City F2F.
> >>>>>
> >>>>> http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html
> >>>>>
> >>>>> This closes ACTION-169
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> 
> 
>

Received on Tuesday, 3 February 2009 00:44:28 UTC