How secure is Infopath? Was RE: How secure is XForms?
"John Boyer" <[email protected]> Fri, 10 Oct 2003 17:45:41 -0700
| Newsgroups | gmane.comp.web.xforms,gmane.ietf.xmldsig |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C38F90.FF15F886 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andrew, =20 Yes, I would be happy to follow up on my points. =20 It is accurate to conclude XForms implementations do not support any of = the=20 'what you see is what you sign' conceptualization presented in my paper = because XForms has not yet taken on interoperation with XML DSig. Moreover, = some implementations have added XML DSig as custom extensions, but they are uniformly signing data only because it is difficult or impossible to get = access to the presentation layer. =20 It is not accurate to conclude that InfoPath supports a 'what you see is = what you sign' conceptualization, such as is described in my 1999 paper. My prior = comments left=20 open a small door in case someone figures out an extremely bizarre way = of doing this,=20 but I can find no reasonable way to sign anything but the data. My = conclusion is that=20 in the current release, InfoPath digital signatures have no value in and = of themselves. =20 To put a fine point on this claim, we used the 'Applicant Rating' demo = form and=20 enabled signatures. We then filled out the form, signed it, and saved the data (which included the new signature). Then, we went into the = form template and changed the user interface to say ridiculous things like 'prisoner = number' instead of=20 'applicant number'. Finally, we double-clicked our signed data file. = Up came the=20 InfoPath filler. The processing instruction in the data file caused = InfoPath to retrieve our=20 bogus UI, but the signature in the data file does not cover the UI, so = it validated. InfoPath=20 claimed that we signed our own prisoner registration form when this is = not at all what we=20 signed. It is a very compelling demo! =20 In the InfoPath design experience, there is very little to be done to = add signature,=20 but this also means that there is very little power to set up good = signatures. One=20 simply clicks a checkbox to enable signing in the form. Then, in = fill-out mode, anyone=20 who gets access to the form can add their signature. Here are the = problems: =20 1) The form author has no control over whether particular individuals = (or individuals with certain roles) should be allowed to sign, which violates ABA guidelines = for what a signature=20 means (message authentication, signer authentication, **and signer = authorization**). At a minimum, having the ability to restrict the form to only taking one = signature would be=20 a nice option for the form author. =20 2) The InfoPath filler has hard coded the particular transformations = that sign the entire=20 data (less the signatures block). So, two signers can sign the entire = form, but two signers=20 cannot sign different parts of the same form. It also does not appear = possible to allow an=20 'office use only' section of a form to be filled out after the form has = been signed. =20 3) Since InfoPath signs the data only, it is extremely easy to add = things to the user interface after the user has signed, like fine print obligating the user = to terms and=20 conditions to which the signer did not originally agree. Indeed, as we = showed in the demo I described above, it was easy to change the entire context of what = was signed. =20 This last point means that InfoPath signatures are a significant = disservice to any=20 enterprise hoping to secure their transactions with InfoPath because it = is so easy for the=20 malicious signer to repudiate a transaction by simply showing that it is = hard to conclusively=20 prove what the signer really agreed to. After all, what you see is what = you sign! =20 Because this is such a problem, I should note that we tried things that = were outside of the normal InfoPath design experience to see if we could 'jury-rig' a good = signature (I never=20 thought I would see myself use such a turn of phrase). We added a DSig = signature=20 element that had our own <reference> elements in it so that both the = data and presentation could be signed. When we did this, the InfoPath filler promptly = informed us that there was an invalid digital signature in the form. We tried to add a = signature anyway, but InfoPath forced us to remove the invalid signature before allowing us to = add a new signature, which it dutifully hard-coded to sign only the data. =20 A secondary problem is that the InfoPath signatures are created with = XSLT transforms, which are 'optional' according to the XML signature recommendation. = This means that not all XML DSig engines will validate the signatures. Moreover, the = particular task they are trying to perform is easily accomplished with an XPath filter, which = is a=20 'recommended' to implement feature of DSig (recommended means that it is = virtually ubiquitous since an implementer cannot claim to be spec compliant unless = they=20 provide the feature or provide a compelling reason why it isn't there). = I wanted to test=20 whether the Microsoft code even supported XPath filtering, but the = system does not seem to allow me to set up my own signature references. =20 If I were designing the InfoPath signature solution, I would first = change the data filter to be based on XPath filtering, not XSLT. I would also get rid = of the enveloped transform as it seems to be redundant with what the XSLT (and hence the = XPath) is already trying to do. Then I would add a second reference to the .XSN = file (the form=20 template containing, among other things, the .xsl that generates the = user interface). =20 Then, I would add a third reference that contained a transform to bind = the URI in the=20 second reference above to the value of the href in the = mso-infoPathSolution processing=20 instruction. This is necessary to help ensure that the user interface = being secured by=20 the signature is equal to the URI that is actually used to obtain the = form template. =20 Maybe this is a hard transform to write, but if the design environment = is writing it, then it=20 is not so hard on the form author. =20 Of course, we cannot do these things with InfoPath, but if we could, = then the system=20 design still seems completely incapable of being extended to partial = document signing scenarios. The main problem is that the .XSN file containing the form = template is a=20 *compressed* file, so it is opaque to DSig transforms. =20 Hopefully, this is enough information to start with. It does not even = begin to touch on the issues in PureEdge's more current research because InfoPath does not = seem to let=20 the form author set up signature filters. I would be relieved and = pleased to see a post that=20 shows how I can get InfoPath to let me set my own signature filters. = Otherwise, I will be=20 disappointed in InfoPath given the strong presence that Microsoft had on = the XML DSig=20 working group. =20 Best regards, John Boyer, Ph.D. Senior Product Architect and Research Scientist PureEdge Solutions Inc. =20 =20 =20 -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Friday, October 10, 2003 11:00 AM To: John Boyer Cc: [email protected]; [email protected]; [email protected] Subject: Re: How secure is XForms? In a message dated 10/10/2003 17:59:48 GMT Daylight Time, = [email protected] writes: Hi John and Andrew, <snip/> As to Andrew's point about Microsoft InfoPath, you may with=20 significant effort be able to create a basic signature for a=20 form that meets the requirements described in our WWW8 paper from 1999, but this is 2003 and you will need XFDL to handle=20 many of signing scenarios that arise in practice and that are=20 of greater interest to the security communities at RSA and the ACM. John, I would like to follow up on some other points you made but don't have = time to do that at the moment. Hopefully I will over the weekend. Can I attempt to distill your final paragraph into a take home message? Is it accurate to conclude that InfoPath currently implements some of = your 1999 suggestions and that XForms implements none of them?=20 Is that an accurate statement of the position today? I appreciate that you have hopes of better things for the future but = that is one of the issues I would like to explore further later. Secondly, can you state which non-basic signing scenarios you have = tested in InfoPath 2003 which work and which signing scenarios you have = tested in InfoPath 2003 which don't work? Alternatively, were your = comments about creating a "basic signature" in InfoPath ... and the = hints of difficulty and/or inadequacy ... more by way of a general = comment than specific testing? Can you clarify what you mean in that = context by a "basic signature"? I am trying to lead you to firm up comments which are capable of more = than one interpretation. Thanks Andrew Watt ------_=_NextPart_001_01C38F90.FF15F886 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Hi=20 Andrew,</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Yes, I=20 would be happy to follow up on my points.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>It is=20 accurate to conclude XForms implementations do not support any of the=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>'what=20 you see is what you sign' conceptualization presented in my paper=20 because</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>XForms=20 has not yet taken on interoperation with XML DSig. Moreover,=20 some</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>implementations have added XML DSig as custom extensions, but = they=20 are</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>uniformly signing data only because it is difficult or = impossible to get=20 access</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>to the=20 presentation layer.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>It is=20 not accurate to conclude that InfoPath supports a 'what you see is what = you=20 sign'</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>conceptualization, such as is described in my 1999 paper. = My prior=20 comments left </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>open a=20 small door in case someone </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>figures out an extremely bizarre = way of doing=20 this, </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>but I=20 can find no reasonable way </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>to sign anything but the = data. =20 My conclusion is that </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>in the=20 current </FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>release, InfoPath digital signatures = have=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>no value in and of themselves.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>To put=20 a fine point on this claim, we used the 'Applicant Rating' demo form and = </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>enabled signatures. We then filled out the form, signed = it,=20 and saved</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>the=20 data (which included the new signature). Then, we went into the = form=20 template</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>and changed the user interface to say ridiculous things = like=20 'prisoner </FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>number' instead of </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>'applicant number'. Finally, we double-clicked our signed = data=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>file. Up came the </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>InfoPath filler. The processing instruction in the data = file=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>caused InfoPath to retrieve our </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>bogus=20 UI, but the signature in the data file does </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>not cover the UI,=20 so it validated. InfoPath </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>claimed that we signed our own </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>prisoner=20 registration form when this is not at all what we </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>signed. It is a very </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>compelling=20 demo!</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>In the=20 InfoPath design experience, there is very little to be done to add=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>signature, </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>but=20 this also means that there is very little power to set up = </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>good=20 signatures. One </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>simply=20 clicks a checkbox to enable signing in </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>the form. =20 Then, in fill-out mode, </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>anyone </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>who=20 gets access to the form can add </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>their=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>signature. Here are the problems:</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>1) The=20 form author has no control over whether particular individuals (or = individuals=20 with</FONT></SPAN></DIV> <DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D620451123-10102003>certain roles) </SPAN><SPAN=20 class=3D620451123-10102003>should be allowed </SPAN><SPAN=20 class=3D620451123-10102003>to </SPAN></FONT></FONT></FONT><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>sign, which=20 violates ABA guidelines for what </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff size=3D2>a = signature=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>means=20 (message authentication, </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>signer authentication, = </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>**and signer=20 authorization**).</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>At a=20 minimum, having the ability to restrict the form to only taking one=20 signature would be </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>a nice=20 option for the form author.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>2) The=20 InfoPath filler has hard coded the particular transformations=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>that sign the entire </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>data=20 (less the signatures block)</FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>. So, two = </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>signers can sign=20 the entire form, but two signers </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>cannot=20 sign </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>different parts of the same form. It also does not appear = possible=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>to allow an </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>'office use only' section of a form to be filled out after=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>the form has been signed.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>3)=20 Since InfoPath signs the data only, it is extremely easy to add things = to the=20 user</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>interface after the user has signed, like fine print obligating = the user=20 to terms and </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>conditions to which the signer did not originally agree. = Indeed, as=20 we showed in the</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>demo I=20 described above, it was easy to change the entire context of what was=20 signed</FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial=20 color=3D#0000ff size=3D2>.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>This=20 last point means that InfoPath signatures are a significant disservice = to any=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>enterprise hoping to secure their </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>transactions with=20 InfoPath b</FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>ecause it is so easy for the = </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>malicious signer to repudiate </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff size=3D2>a = transaction by=20 simply </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff size=3D2>showing that it is hard to conclusively=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>prove=20 what the signer </FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>really agreed to. After all, = </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>what you see is=20 what you sign!</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Because this is such a problem, </FONT></SPAN></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff size=3D2>I = should note=20 that we tried things that were outside of the</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>normal=20 InfoPath design </FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>experience to see </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>if we could=20 'jury-rig' a good signature (I never </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>thought I would </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>see myself use such a turn of=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>phrase). We added a DSig signature </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>element that had our own <reference> elements = </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>in it so that=20 both the data and presentation</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>could=20 be signed. When we did this, the InfoPath filler promptly informed = us that=20 there</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>was an=20 invalid digital signature in the form. We tried to add a signature = anyway,=20 but</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>InfoPath forced us to remove the invalid signature before = allowing us to=20 add a</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>new=20 signature, which it dutifully hard-coded to sign only the=20 data.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>A=20 secondary problem is that the InfoPath signatures are created with XSLT=20 transforms,</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>which=20 are 'optional' according to the XML signature recommendation. This = means=20 that</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>not=20 all XML DSig engines will validate the signatures. Moreover, the=20 particular task they</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>are=20 trying to perform is easily accomplished with an XPath filter, which is = a=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>'recommended' to implement feature of DSig (recommended means = that it is=20 virtually</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>ubiquitous since an implementer cannot claim to be spec = compliant unless=20 they </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>provide the feature or provide a compelling reason why it isn't = there). I wanted to test </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>whether the </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT face=3DArial=20 color=3D#0000ff size=3D2>Microsoft code even supported XPath filtering, = but the=20 system does not</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>seem=20 to allow me to set up my own signature references.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>If I=20 were designing the InfoPath signature solution, I would first change the = data</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>filter=20 to be based on XPath filtering, not XSLT. I would also get rid of = the=20 enveloped</FONT></SPAN></DIV> <DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D620451123-10102003>transform as it seems to be redundant with = what the=20 XSLT (and hence the XPath)</SPAN></FONT></FONT></FONT></DIV> <DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20 class=3D620451123-10102003>is already trying to do. </SPAN><SPAN=20 class=3D620451123-10102003><FONT>Then I would add a second reference=20 </FONT></SPAN></FONT></FONT></FONT><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>to the .XSN file (the form = </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>template containing, among other things, the .xsl that=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>generates the user interface). </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Then,=20 I would add a third reference that contained </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff size=3D2>a = transform to=20 bind the URI in the </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>second=20 reference above to the value of the href </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>in the=20 mso-infoPathSolution processing </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>instruction. This is necessary to help = </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>ensure that the=20 user interface being secured by </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>the=20 signature is equal to the URI </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>that is actually used to obtain = the form=20 template. </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Maybe=20 this is a hard transform </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>to write, but if the design = environment is=20 writing it, then it </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>is not=20 so hard on the </FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>form author.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Of=20 course, we cannot do these things with InfoPath, but if we could, then = the=20 system </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>design=20 still seems completely incapable of being extended to partial document=20 signing</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>scenarios</FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>. The main problem is that the .XSN file=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>containing the form template is a </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>*compressed* file, so it is opaque to DSig=20 transforms.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Hopefully, this is enough information to start with. It = does not=20 even begin to touch on</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>the=20 issues in PureEdge's more current research because InfoPath does = not seem=20 to let </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>the=20 form author set </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>up signature filters. I = would be=20 relieved and pleased to see a post </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>that=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>shows=20 </FONT></SPAN><SPAN class=3D620451123-10102003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>how I can get InfoPath </FONT></SPAN><SPAN = class=3D620451123-10102003><FONT=20 face=3DArial color=3D#0000ff size=3D2>to let me set my own signature = filters. =20 Otherwise, </FONT></SPAN><SPAN class=3D620451123-10102003><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I will be </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>disappointed in InfoPath given </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>the strong=20 presence that Microsoft had on the </FONT></SPAN><SPAN=20 class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>XML DSig=20 </FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>working group.</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2>Best=20 regards,</FONT></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003> <DIV> <DIV><SPAN class=3D796002122-22042003><FONT face=3DArial size=3D2>John = Boyer,=20 Ph.D.</FONT></SPAN></DIV> <DIV><SPAN class=3D796002122-22042003><FONT face=3DArial size=3D2>Senior = Product=20 Architect and Research Scientist</FONT></SPAN></DIV> <DIV><SPAN class=3D796002122-22042003><FONT face=3DArial = size=3D2>PureEdge Solutions=20 Inc.</FONT></SPAN></DIV></DIV></SPAN></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV></DIV> <DIV><SPAN class=3D620451123-10102003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <BLOCKQUOTE> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> = [email protected]=20 [mailto:[email protected]]<BR><B>Sent:</B> Friday, October 10, = 2003 11:00=20 AM<BR><B>To:</B> John Boyer<BR><B>Cc:</B> [email protected];=20 [email protected]; [email protected]<BR><B>Subject:</B> Re: How = secure is=20 XForms?<BR><BR></FONT></DIV><FONT face=3Darial,helvetica><FONT = lang=3D0 face=3DArial=20 size=3D2 FAMILY=3D"SANSSERIF">In a message dated 10/10/2003 17:59:48 = GMT Daylight=20 Time, [email protected] writes:<BR><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"=20 TYPE=3D"CITE">Hi John and Andrew,<BR><BR><snip/><BR><BR>As to = Andrew's=20 point about Microsoft InfoPath, you may with <BR>significant effort = be able=20 to create a basic signature for a <BR>form that meets the = requirements=20 described in our WWW8 paper<BR>from 1999, but this is 2003 and you = will need=20 XFDL to handle <BR>many of signing scenarios that arise in practice = and that=20 are <BR>of greater interest to the security communities at RSA and = the=20 ACM.</BLOCKQUOTE><BR><BR>John,<BR><BR>I would like to follow up on = some other=20 points you made but don't have time to do that at the moment. = Hopefully I will=20 over the weekend.<BR><BR>Can I attempt to distill your final paragraph = into a=20 take home message?<BR><BR>Is it accurate to conclude that InfoPath = currently=20 implements some of your 1999 suggestions and that XForms implements = none of=20 them? <BR><BR>Is that an accurate statement of the position = today?<BR><BR>I=20 appreciate that you have hopes of better things for the future but = that is one=20 of the issues I would like to explore further later.<BR><BR>Secondly, = can you=20 state which non-basic signing scenarios you have tested in InfoPath = 2003 which=20 work and which signing scenarios you have tested in InfoPath 2003 = which don't=20 work? Alternatively, were your comments about creating a "basic = signature" in=20 InfoPath ... and the hints of difficulty and/or inadequacy ... more by = way of=20 a general comment than specific testing? Can you clarify what you mean = in that=20 context by a "basic signature"?<BR><BR>I am trying to lead you to firm = up=20 comments which are capable of more than one=20 interpretation.<BR><BR>Thanks<BR><BR>Andrew=20 Watt<BR><BR><BR></BLOCKQUOTE></FONT></FONT></BODY></HTML> ------_=_NextPart_001_01C38F90.FF15F886--