Re: How secure is Infopath? Was RE: How secure is XForms?

John:

Thank you for your confirmation of my tentative suggestions. I greatly respect your opinions and work.

Were the tests with InfoPath conducted solely with client side PKI signatures?

To the extent that servers can sign data on behalf of signers either via an XKMS type of architecture, or a single key for a group of users, could either InfoPath or Xforms use of security for XML forms be facilitated by such an architecture? Are they compatible with such an architecture?

Are such server based signatures compatible with PureEdge's proprietary solution? (Cf the DSS TC of OASIS).

Best regards.

---------- Original Message ----------------------------------
From: "John Boyer" <JBoyer@PureEdge.com>
Date:  Fri, 10 Oct 2003 17:45:41 -0700

>Hi Andrew,
> 
>Yes, I would be happy to follow up on my points.
> 
>It is accurate to conclude XForms implementations do not support any of the 
>'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.
> 
>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 
>open a small door in case someone figures out an extremely bizarre way of doing this, 
>but I can find no reasonable way to sign anything but the data.  My conclusion is that 
>in the current release, InfoPath digital signatures have no value in and of themselves.
> 
>To put a fine point on this claim, we used the 'Applicant Rating' demo form and 
>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 
>'applicant number'.  Finally, we double-clicked our signed data file.  Up came the 
>InfoPath filler.  The processing instruction in the data file caused InfoPath to retrieve our 
>bogus UI, but the signature in the data file does not cover the UI, so it validated.  InfoPath 
>claimed that we signed our own prisoner registration form when this is not at all what we 
>signed.  It is a very compelling demo!
> 
>In the InfoPath design experience, there is very little to be done to add signature, 
>but this also means that there is very little power to set up good signatures.  One 
>simply clicks a checkbox to enable signing in the form.  Then, in fill-out mode, anyone 
>who gets access to the form can add their signature. Here are the problems:
> 
>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 
>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 
>a nice option for the form author.
> 
>2) The InfoPath filler has hard coded the particular transformations that sign the entire 
>data (less the signatures block).  So, two signers can sign the entire form, but two signers 
>cannot sign different parts of the same form.  It also does not appear possible to allow an 
>'office use only' section of a form to be filled out after the form has been signed.
> 
>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 
>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.
> 
>This last point means that InfoPath signatures are a significant disservice to any 
>enterprise hoping to secure their transactions with InfoPath because it is so easy for the 
>malicious signer to repudiate a transaction by simply showing that it is hard to conclusively 
>prove what the signer really agreed to.  After all, what you see is what you sign!
> 
>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 
>thought I would see myself use such a turn of phrase).  We added a DSig signature 
>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.
> 
>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 
>'recommended' to implement feature of DSig (recommended means that it is virtually
>ubiquitous since an implementer cannot claim to be spec compliant unless they 
>provide the feature or provide a compelling reason why it isn't there).  I wanted to test 
>whether the Microsoft code even supported XPath filtering, but the system does not
>seem to allow me to set up my own signature references.
> 
>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 
>template containing, among other things, the .xsl that generates the user interface).  
>Then, I would add a third reference that contained a transform to bind the URI in the 
>second reference above to the value of the href in the mso-infoPathSolution processing 
>instruction.  This is necessary to help ensure that the user interface being secured by 
>the signature is equal to the URI that is actually used to obtain the form template.  
>Maybe this is a hard transform to write, but if the design environment is writing it, then it 
>is not so hard on the form author.
> 
>Of course, we cannot do these things with InfoPath, but if we could, then the system 
>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 
>*compressed* file, so it is opaque to DSig transforms.
> 
>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 
>the form author set up signature filters.  I would be relieved and pleased to see a post that 
>shows how I can get InfoPath to let me set my own signature filters.  Otherwise, I will be 
>disappointed in InfoPath given the strong presence that Microsoft had on the XML DSig 
>working group.
> 
>Best regards,
>John Boyer, Ph.D.
>Senior Product Architect and Research Scientist
>PureEdge Solutions Inc.
> 
> 
> 
>
>-----Original Message-----
>From: AndrewWatt2001@aol.com [mailto:AndrewWatt2001@aol.com]
>Sent: Friday, October 10, 2003 11:00 AM
>To: John Boyer
>Cc: jmessing@law-on-line.com; www-forms@w3.org; XForms@yahoogroups.com
>Subject: Re: How secure is XForms?
>
>
>In a message dated 10/10/2003 17:59:48 GMT Daylight Time, JBoyer@PureEdge.com writes:
>
>
>
>Hi John and Andrew,
>
><snip/>
>
>As to Andrew's point about Microsoft InfoPath, you may with 
>significant effort be able to create a basic signature for a 
>form that meets the requirements described in our WWW8 paper
>from 1999, but this is 2003 and you will need XFDL to handle 
>many of signing scenarios that arise in practice and that are 
>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? 
>
>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
>
>
>
>
>
>

Received on Friday, 10 October 2003 20:58:55 UTC