Re: Security hole

["Brian M. Thomas" <bt0008@xxxxxxxxxxxxxxx>]

> As I see it there is a very simple solution to the problem:
> Let the digital signature standard also include the character
> set coding (e.g. MIME-type) in the message that is signed.

I think we're talking about two different issues here: character sets
and fonts.  The character set and its interpretation are one thing, and
their interpretation is a matter of standard.  The font issue is another,
however, and unless a signature covered the font data completely, the
defense that your signature covered something different from what you
saw is without support.

Alternatively, you could use software that insisted on fonts that displayed
the character sets as you understood them, supported by a trusted signature
on the fonts as you download them.  I would lean in this direction, since
the issue of where to get all the stuff and canonicalize it for signing
seems, on the surface, a difficult one, and the subject of years of standards
committee work that we don't have time for.  A font is, effectively, code,
and must be part of your TCB if you are going to trust it.
 
> This obviously doesn't solve the problem with malicous SW that
> would display the characters wrongly but I don't think that we
> can adress that issue within this forum.
> 
> Ragards,
> /Lars Johansson
> Sweden Post

As I think I made clear above, this really is about malicious code, in
the fonts that are downloaded with the form to be signed.  It's
probably a very good idea to specify the entire content of a form, as
displayed, that you fill out and sign, just as when you sign a paper
document "as displayed", since proof of material modification of the
document after your signature can void it.


Brian Thomas - Distributed Systems Architect  bt0008@entropy.sbc.com
Southwestern Bell                             bthomas@primary.net
One Bell Center,  Room 34G3                   Tel: 314 235 3141
St. Louis, MO 63101                           Fax: 314 235 0162