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

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