W3C home > Mailing lists > Public > www-international@w3.org > October to December 1996

Re: FW: Security hole

From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Date: Fri, 06 Dec 1996 16:43:26 +0000
Message-Id: <>
To: Borka Jerman-Blazic <borka@e5.ijs.si>, plipp <plipp@iaik.tu-graz.ac.at>
Cc: "Lamond, Keith" <keithl@reston.btna.com>, w3c-dsig@w3.org, ietf-pkix@tandem.com, www-international@w3.org
Borka & Peter,

Please remember to CC: me explicitly in any replies.

Borka, I'm afraid I don't deserve your God's blessings! As I don't
subscribe to any of the mailing lists I sent this to, I just wanted to
ensure the matter was raised but it's not my field - so I don't intend to
devote any time to sorting it out. 

I did get a response from Peter Lipp (attached at end), who is implying the
current solutions cover this problem and it is therefore not a problem?...

I have embedded a comment concerning his reply, within his reply below.


>Date: Fri, 6 Dec 1996 09:28:00 -0500
>From: "Lamond, Keith" <keithl@reston.btna.com>
>This note arrived through one of the mailing lists I monitor. It is about
>the security problem with downloadable fonts you sent out earlier.
> ----------
>From:  Borka Jerman-Blazic[SMTP:borka@e5.ijs.si]
>Sent:  Friday, December 06, 1996 8:31 AM
>To:  w3c-dsig
>Cc:  ietf-pkix; wg-i18n
>Subject:  Security hole
> ----------------------------------------------------
>From: Borka Jerman-Blazic <borka>
>Dear Bob,
>God bless you with your letter/discovery about
>security hole in digital signatures.
>I am telling the same story  everywhere I have a lecture about
>character sets, but no one listen.
>So, I deeply support what you have said and I am sking you
>for joint action. What should this be? IETF WG or EU project ??
>The IAB-Charcater sets report is on its way as RFC and there it is
>clearly stated that all RFC standards or protocols that have an
>issue with charcater sets must be revised. IAB is supporting
>Unicode and  UTF8 so maybe we should start for digital signature
>the use of Unicode. In the future this seems as the only solution,
>but migration approaches are also needed.
>Please go ahead with your comments.
>Borka Jerman-Blazic
> ------- End of Forwarded Message

>Date: Thu, 05 Dec 1996 15:34:11
>From: plipp <plipp@iaik.tu-graz.ac.at>
>To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>, w3c-dsig@w3.org,
>        ietf-pkix@tandem.com
>Cc: drummond@onramp.net
>Subject: Antw: Security hole: Digital Signing + Downloadable fonts
>>Solution would be to sign the aggregate of all the resources recursively
>>referenced. Whether this should be the default behaviour, I would say yes
>>(as to "display" them you have them all in memory anyway).
>We are allowing several resources within to be included one signature.
>the user, or better the signing application, needs to be fully aware which 
>resources are to be included in that list, such as the font in your example.
>What you consider the default behaviour is clearly application-dependent.

The reason I said signing *every* linked resource needs to be the default
is that a client app. won't necessarily be able to cater for every possible
way a document might be structured (bearing in mind here we are talking
about not what is expected behaviour for an application, but what might be
done by someone trying to break the security). However, I guess you are
right, in principal, that an app writer could be in a position where s/he
feels s/he knows every possible way there is to link other resources to the
signed resource and which ones are security risks. I wouldn't personally
feel secure with that attitude though, especially with the Web being so

>Our view of a signature is not limited to ordering etc.
>Peter Lipp, IAIK, University of Technology, Graz
>Institute for Applied Information Processing and Communications
>Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513
>Was nützt die beste Erziehung, die Kinder machen uns ja doch alles nach.

Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm
Received on Friday, 6 December 1996 11:43:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:16 UTC