W3C home > Mailing lists > Public > www-forms@w3.org > March 2001

Re: One more possible hole in UI?

From: <nimrod@jacada.com>
Date: Thu, 29 Mar 2001 18:41:32 +0200
To: Berin Loritsch <bloritsch@apache.org>, XForms Mailing List <www-forms@w3.org>
Message-ID: <42256A1E.005C04FB.00@jacada.com>

> My oppinion is that if data is sensitive, then encrypt
> it.  I think that encryption is a completely separate
> concern than what the XForms proposal is trying to
> enable.  I wouldn't want a partially encrypted form.
> The complexity involved doesn't provide the payoff
> for an all or nothing approach.  To me, weak encryption
> is no better than no encryption.
> If I have some sensitive information on a form, and
> the rest is not sensitive, I would tend to take the
> brute force method of making it all encrypted.

This approach, however appealing it may be, lacks in
two key areas.

The first is plain security.  If you encrypt the whole
form, then you make yourself vulnerable to known-
plaintext attacks.  Since parts of the form are known
(e.g. tag names), they can be used to break the
encryption if it's vulnerable to known-plaintext
attacks.  Encrypting just the sensitive information
gives an attacker less to play with.

[note: there are other,potentially conflicting, aspects.
e.g. if the context is in the clear, then it may give
clues to the contents of the sensitive info]

The other area is usability of the form.  It may well
be that you don't need the whole form in order to
start processing it.  You might, for example, route it
to different back-end systems based on data that isn't
sensitive (e.g. an employee's name isn't sensitive,
but that employee's salary may well be - but using the
name you can forward the form to the correct branch
without knowledge of the salary).


> I really don't think that transport issues such as encryption
> should be an embeddable part of the XForms spec.

So encryption, eventually, is not necessarily a
transport issue.

Received on Thursday, 29 March 2001 11:47:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:04 UTC