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

Hi John,

Best regards here too.  Just to make this an email that can be 
followed more easily, I'll try to pull your comments and questions
together from the stream of our conversation to date.

1) By 'verifier' I do mean relying party.

2) By 'most systems' I mean most applications of digital signatures.
Most of the time you have a many to one relationship, with signers 
being the many and the relying party being the one.  So, I think we
are still on common ground in our belief that the relying party has
more to lose if the digital signature technology used in their 
application is found to be faulty.

When I say digital signature technology, I mean things like PKI or
server-based.  Further, I really mean not just the identity management 
itself, but the whole framework.  How is the message to be signed
calculated? What does it mean in the application context? How is the
identity connected to the message? How is the message content prevented
from being tampered with? etc.

3) I agree that server-side systems are appropriate as long as
the proper precautions are taken.  I just wanted to make sure I put
in the statement about proper precautions before I went on to say
that such server-side systems could be augmented with our extra
techniques for helping to secure 'what the signer saw'.

There are two reasons for this.  One, this is a public list, so I 
wanted to avoid the email that would ask the question if I didn't
answer it first.  Second, I think it is appropriate to imply that 
any such augmentations must be treated with the same level of care
that is used to get the core cryptographic operations off of the
client machines in the first place.  See #5

4) Your fourth question was about partial document signing.  Well,
this is the domain of signature filters as well as the augmentations
which I will be presenting at the upcoming ACM Workshop on XML Security.
The idea is that, in practice, we regularly run into forms in which
additional work must be performed after a signature event.  Thus,
the full context of a signature is only part of a form.  Simple examples
would include the 'Office use only' section of a form (which is always
blank when you sign the form, then filled in later) and simple multiple
signer scenarios like signer/co-signer on a loan application.

However, this is really only the beginning.  We've deployed forms within
the U.S. military and various governments in which the requirements are
to have multiple form sections filled out by different parties, each of
whom may attach further supporting documents.  A good example was a 
military policy manual change form that had to be signed by dozens of 
people in a chain of command, each of whom could add further comments
in their own little section.  Each signature 'approved' all material that
came before it.

There are lots of similar examples, but I don't want to write a book here :-)
The main idea is that you create each signature to filter out the portion
of the document that must still change.  If the filter is exact enough, you
can maintain security because if any changes other than those anticipated by
the form designer are made, then the previously applied signatures break.

My current work addresses what happens when either the form developer has
not fully appreciated the rigor that needed to go into his filter or when
the resolution into the language semantics provided by the markup is too
coarse, thereby preventing a filter from accurately characterizing the 
pattern of data to be omitted.  In such cases, we still want to prevent
anything that has been omitted from obfuscating what has been signed.

5) I think your final question was whether it was fair to conclude that 
the rendering environment is equally the same with regard to both client 
and server side signing solutions.

The real answer is, not really.  For example, you can deliver a blob of
XHTML to the client web browser, but each user's machine may have 
different settings for how to interpret font sizes such that the 
appearance of the page is quite unpredictable.

So, regarding #3 above, it is generally hard unless you have tight control 
over the client rendering device to be able to implement a 'what you 
see is what you sign' concept with a server-based signing technology.  
The reason is that the server has to be able to exactly replicate what 
the signer saw *on the client machine*.

Best regards,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.


-----Original Message-----
From: jmessing [mailto:jmessing@law-on-line.com]
Sent: Tuesday, October 14, 2003 7:36 PM
To: jmessing@law-on-line.com; AndrewWatt2001@aol.com; John Boyer
Cc: www-forms@w3.org; XForms@yahoogroups.com; w3c-ietf-xmldsig@w3.org
Subject: 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 Thursday, 16 October 2003 19:33:15 UTC