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

Please consider the inline comments and questions. They are submitted with both respect and best regards.

---------- Original Message ----------------------------------
From: "John Boyer" <JBoyer@PureEdge.com>
Date:  Tue, 14 Oct 2003 16:38:08 -0700

>
>Hi John,
>
>See inline comments below...
>
>-----Original Message-----
>From: jmessing [mailto:jmessing@law-on-line.com]
>Sent: Friday, October 10, 2003 5:51 PM
>To: AndrewWatt2001@aol.com; John Boyer
>Cc: jmessing@law-on-line.com; www-forms@w3.org; XForms@yahoogroups.com;
>w3c-ietf-xmldsig@w3.org
>Subject: 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.
>
><johnboyer>Thanks!</johnboyer>
>
>Were the tests with InfoPath conducted solely with client side PKI signatures?
>
><johnboyer>Yes.</johnboyer>
>
>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).
>
><johnboyer>
>Well, the InfoPath solution only seemed to allow you to set up 
>data-only client-side PKI signatures, and XForms 1.0 has not yet 
>addressed integration with digital signatures.
>
>As for server-side generation of signatures, let me begin by
>saying that signatures really tend to be more valuable to the
>verifier than the signer. 
></johnboyer>

<john messing>I would agree with the statement that a signature is primarily useful to a relying party: i.e., one who extends goods, services or credit in reliance upon the validity of the signature. If by "verifier" you mean "relying party", then I agree.

</john messing>

><johnboyer>
>This is because most systems are set
>up to be point of contact with individuals as signers and a company
>as the verifier.  Since the company/verifier is the one running the 
>server, it is too self-serving if the verifier has significant
>control over the signature generation process. 

></johnboyer>

<john messing> I guess the term "most systems" is a little confusing to me, as it could include a PKI as well as server-based system. 

If the relying party has no control over the signature generation process but it is in the hands of a trusted third party then wherever signing occurs, whether on the client or an independent server, this assumption no longer is valid. That is the case I am postulating and that proponents of server signatures generally agree is required.
</john messing> 

><johnboyer>
> This is why 
>companies tend to use a 3rd party as a certificate authority,
>for example.

></johnboyer>

<john messing> ... or a 3rd party server signature service?
</john messing> 

><johnboyer>
> The problem we are talking about now is another
>manifestation of this issue.  If a signature only signs data,
>then the verifier's hands are not clean, so to speak, because it 
>is possible to change what the user saw after the signature is
>generated.
>
></johnboyer>


<john messing> I am having trouble following this reasoning. If a structure and its style sheet are signed, how it is possible to change the presentation? For example, if XMLDSIG is used, and the transforms are applied before a keyed signature is generated, then what was signed is what was seen, regardless of whether a client or server affixed the signature.

If the signer is a trusted third party and the relying party has no control over either the signature generation process or the manner of signature validation, then blanket distrust of the server-based process seems unwarranted. This is the case I am referring to.
</john messing> 

><johnboyer>
>Regarding server-side signature generation, the verifier may use 
>3rd party software to create the server-side signature systems, but 
>if that software is doing the actual cryptographic calculations
>on the verifier's server, then the signer's private key will appear 
>in the clear in server memory at some point.  Unless special hardware 
>is installed to prevent this or unless the system calls out to a 3rd 
>party web service for signature generation, the verifier can still get 
>their hands on a signer's private key material. It is true that the 
>3rd party software tends to make it harder to do so because the signers' 
>private keys are not in the clear in the permanent storage, but it is 
>still easier to get the key material than it would be by integer 
>factorization.  As the value of the protected transactions increases, 
>the volume of such transactions decreases, which seems to make reliance 
>on laws pertaining to common practices of a business less tenable.
>
></johnboyer>

<john messing> Again, assuming an independent third party web service with a hardware security module, then these objections no longer seem applicable and the issue of factorization, assuming keys of sufficient length, is not a consideration specific to the server side signing; i.e., it applies equally to client side signing.
</john messing>

><johnboyer>
>I've said all of this mainly as a qualifying context for answering
>your final question.  Suppose you do have a 'good' system of 
>server-side signatures that somehow provides the verifier a level
>of plausible deniability regarding tampering (such a system is 
>feasible, so the supposition is not degenerate). Then, I see nothing
>to prevent that system from using the additional PureEdge
>methodologies to secure portions of a form and to prevent partial
>form signing from creating additional security risks. 
>
></johnboyer>

<john messing> The term "partial form signing" introduces a new concept. What do you mean by it?
</john messing>

><johnboyer>
>The main issue is that InfoPath is not architected to be extensible
>in this way.  Although the XForms working group has yet to formally
>consider signature integration, I believe XForms is more likely to be
>easily extended to allow a host language to apply the PureEdge
>methods.  Whether the methods are applied by server-side code or
>client-side code will likely be up to the implementation.  XForms
>typically does not distinguish where certain functionality gets
>implemented, so long as it has the specified behaviors (i.e. meets
>the defined requirements).
>
>The big problem for XForms is that it is designed to be hosted by
>another language, so if the host language has difficulty locking 
>down the attributes we want to secure with the PureEdge methods,
>then an XForm will be out of luck simply because of the language
>used in the host envelope.  We want to position XFDL as a secure
>host language for XForms because we think it will be much harder to 
>write securable XHTML, in part because of properties of the language 
>itself and in part because of expected flexibilities in the 
>rendering environment itself (a web browser).
>
></johnboyer>

<john messing>Is it a fair conclusion that the rendering environment is equally the same with regard to both client and server side signing solutions?
</john messing>

>Best regards,
>John Boyer, Ph.D.
>Senior Product Architect and Research Scientist
>PureEdge Solutions Inc.
></johnboyer>
>
>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 Tuesday, 14 October 2003 22:43:28 UTC