From: 22406680@people.or.jp
Real-Date: 18 Aug 95 23:19:16 JST
Subject: [infotalk,05343] EC PROJECT
Message-Id: <3034A164.4E61.004@people.or.jp>
通産省が、電子取引全般に関して、アイデアを募集しています。
全体で、１００億円の補正予算をつけるそうです。その内々
のアイデア募集が、行われます。でもなんと締め切りが２１日
月曜日、我はと思われる人は参加しましょう。
通産省の人に問い合わせたところ、一太郎の文書を、UUENCODE
して送ってきました。とりあえず、nettalk 34 にそれを登録して
おきました。テキストに変換したものは、nettalk 35 として、
土曜日のうちには登録しておきます。
文書の入手方法は、majordomo@iijnet.or.jp に
本文で、get nettalk 34 と書いてメールを送ると、その34
番がおくられててきます。
We are Information Volunteers! Let's Learn & Share!
*nettalk producer* Tadashi Nagao
From: yoshioka@well.com (Hiro Yoshioka)
Real-Date: Thu, 17 Aug 1995 22:45:40 -0700
Subject: [infotalk,05342] Re: Netscape SSL Key broken - a report from
Message-Id: <199508180543.WAA11787@well.com>
At 1:37 PM 95.8.18 +0900, MATSUMOTO Yutaka - Sun JTC wrote:
>San Jose Mercury の front page (8/17) だったそうですね。:-p
でした．
ただし今回やぶられたのは４０ビットのやつで米国内で利用可能な
１２８ビットの鍵の版は安全だという立場みたいですね．
よ
http://home.netscape.com/newsref/std/key_challenge.html
>
> KEY CHALLENGE
>
> --------------------------------------------------------------------
>
> Late Tuesday evening a person from France posted a news article to
> the hacker community claiming success at decrypting a single
> encrypted message that had been posted as a challenge on the
> Internet sometime on or before July 14, 1994. His response to
> questions about his posting has also been placed on the Internet.
>
> What this person did is decrypt one message that was encrypted using
> the RC4 algorithm and a 40-bit key. He used 120 workstations and two
> parallel supercomputers at three major research centers for 8 days
> to do so. As many have documented, including Netscape, a single RC4
> 40-bit encrypted message takes 64 MIPS-years of processing power to
> break, and this roughly corresponds to the amount of computing power
> that was used to decrypt the message.
>
> Important points to understand:
>
> 1. He broke a single encrypted message. For him to break another
> message (even from the same client to the same server seconds
> later) would require *another* 8 days of 120 workstations and
> two parallel supercomputers. The work that goes into breaking a
> single message can't be leveraged against other messages. Every
> message uses a different encryption key.
>
> 2. The standard way to judge the level of security of any
> encryption scheme is to compare the cost of breaking it versus
> the value of the information that can be gained. In this case
> he had to use at least $10,000 worth of computing power
> (ballpark figure for having access to 120 workstations and two
> parallel supercomputers for 8 days) to break a single message.
> Assuming the message is protecting something of less value than
> $10,000, then this information can be protected with only RC4
> 40-bit security. For information of greater value, currently
> available RC4 128-bit security should be used.
>
> 3. Inside the US, software can support a range of stronger
> encryption options, including RC4 128-bit, which is 2^88 times
> harder to decrypt. Meaning that the compute power required to
> decrypt such a message would be more than 1,000,000,000,000
> (trillion) times greater than that which was used to decrypt
> the RC4 40-bit message. This means that with foreseeable
> computer technology it would be practically impossible.
>
> In conclusion, we think RC4 40-bit is strong enough to protect
> consumer-level credit-card transactions -- since the cost of
> decrypting the message is sufficiently high to make it not worth the
> computer time required to do so -- and that our customers should use
> higher levels of security, particularly RC4 128-bit, whenever
> possible. This level of security has been available in the U.S.
> versions of our products since last April. Because of export
> controls it has not been available outside the U.S. We would
> appreciate your support in lobbying the U.S. government to lift the
> export controls on encryption. If you'd like to help us lobby the
> government send email to export@netscape.com.
>
> Finally, we'd like to reiterate that all this person has done is
> decrypt one single RC4 40-bit message. RC4 the algorithm and
> products which use the algorithm remain as secure as always. If you
> would like more detailed information about this event or a more
> thorough technical understanding of the issues involved continue
> here.
--
Hiro Yoshioka
http://www.st.rim.or.jp/~hirotaka
email:yoshioka@well.com
From: yoshioka@well.com (Hiro Yoshioka)
Real-Date: Thu, 17 Aug 1995 22:29:10 -0700
Subject: [infotalk,05341] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508180527.WAA05638@well.com>
よしおかです．
At 8:58 AM 95.8.18 +0900, Noritoshi Demizu (出水法俊 ) wrote:
>draft-ietf-html-i18n-00.txt ですが、ようやっと先ほど目を通しました。
>というわけで困ったことに、document character set として UCS-2 を使うよと
>言っているようです。UCS-2 って良く知らないのですが UNICODE なんですよね？
>ということは jisx0208 上では異なる文字でも、UNICODE 上同じ文字なら、同
>じ文字として扱わねばならないということかな。。
あ，違います．Ｘ０２０８で独立な文字はＵＣＳ２でも独立です．
ｕｎｉｆｉｃａｔｉｏｎとかいう言葉が一人歩きしちゃったわけですが
日中韓の漢字をｕｎｉｆｉｃａｔｉｏｎしたわけなので
ｉｓｏ２０２２ｊｐを使っている限り全然こまりません．
> * 4.2. Date, time, measures and monetary amounts
> ・Latiin-1 の文字を全部 entity 定義してる。
> ・日付、時刻、長さ、お金の表記も国によって違うのを吸収する。
ここらへんも吸収しようというのがまああれですね．
>というわけで、document character set として UCS-2 を明確に定義されるの
>を防いで ISO-2022 でも困らないようにするためには、思うに、UNICODE をも
>包含した、UNICODE に代わる便利な code set を提案すれば良いのではないか
>と思ったりしております。例えば、X11R5 の Xwchar みたいなの (曖昧な記憶
>を元に書いているので、例として不適切ならごめんなさい)。
ここでよくわからないのはｉｓｏ２０２２を利用するとどんな問題を
どのように解決するのでしょうか？
もちろん電子メールで利用しているという答えはその材料としては
弱いですよね．
いわゆるｊｕｎｅｔで利用されていたコードｉｓｏ−２０２２−ｊｐは
その当時，ａｓｃｉｉと漢字を７ビット環境化で使うために開発された
わけですよね．８ビット環境ではすでにＥＵＣとかＳＪＩＳが開発され
ていたわけですけど電子メールでは７ビットという制約があったから
利用していたと．
さてそのような制約のないＨＴＭＬの世界にｉｓｏ２０２２を持ち込む
としたらどのような問題を解決するのでしょうか？
よ
--
Hiro Yoshioka
http://www.st.rim.or.jp/~hirotaka
email:yoshioka@well.com
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Fri, 18 Aug 1995 14:05:42 +0900
Subject: [infotalk,05340] an SGML book list
Message-Id: <199508180505.OAA00184@coo.wg.omron.co.jp>
> (質問3) これから書き方を勉強するとしたら例えば何を読めばよい？
私の手元にある本を紹介します。
(1) 日本語の入門書のお勧め
編著者: 麻布メディア研究会
書名: SGML の書き方
発行所: (株)麻布プロデュース
ISBN 4-900710-01-6 定価1480円
コメント: いきなりの漫画でださい本かとだまされそうになりますが、
SGML 文書の書き方、DTD、SGML 宣言と必要なことがちゃんと
書いてあります。「絵説き本は深い」の実例のひとつです。
(2) 英語の学習書?
著者: Eric van Herwijnen
書名: Practical SGML Second Edition
発行所: Kluwer Academic Publishers
ISBN 0-7923-9934-8 価格: $40-$50くらいだったかな。。
コメント: ボストンの Quantum Books という本屋にビニ本になって
置かれていたので売れている可能性がある。www.ebt.com
でもお勧めの本として紹介されていた。きっと良い本なん
だけどまだ読めてないのであまりコメントできない。
(3) ハンドブック
著者: Charles F. Goldfarb (IBM Almaden Research Center)
書名: The SGML Handbook
発行所: Oxford University Press
ISBN 0-19-853737-9 価格: $95.00
コメント: SGML を定義している ISO 8879 が注釈付で掲載されてい
ます。SGML を深く理解するには必要かも。しかし、普通
は深く理解する必要はないと思います。:)
以上です。
出水法俊
From: Yutaka.Matsumoto@sun.co.jp (MATSUMOTO Yutaka - Sun JTC)
Real-Date: Fri, 18 Aug 95 13:36:44 JST
Subject: [infotalk,05339] Netscape SSL Key broken - a report from
Message-Id: <9508180436.AA07878@katsu.Japan.Sun.COM>
> ]40bit RC4 だから破られて当然じゃないですか？ 所詮 "exportable" だし。
> ]メールに署名するときでさえ 1024bit の鍵を使う時代ですからね。。。
>
>まったくその通り。ここにSSLの話を転載したのは、単に破られたという事実
>を示したかったからに過ぎません。理論的に弱いというだけでは、なかなか信
>じてもらえないのも事実だから。
San Jose Mercury の front page (8/17) だったそうですね。:-p
-- taka@Japan.Sun.COM
From: Tatsurou Sekiguchi <cocoa@is.s.u-tokyo.ac.jp>
Real-Date: Fri, 18 Aug 1995 11:33:29 +0900
Subject: [infotalk,05338] Re: draft-ietf-html-i18n-00.txt
Message-Id: <9508180233.AA27163@madonna.is.s.u-tokyo.ac.jp>
> (質問1) 2022-basedのような状態遷移を含む形態を記述することは、そも
> そもSGMLの枠組みで可能なのか？ そんなDTDは書けるのか？
> (質問2) もし書けるとしたら、どうやって書けばよい？
short reference mapping を使えばできるような気がします。
From: saty@ossi.com (Mr. Tsuchiya)
Real-Date: Thu, 17 Aug 1995 19:16:01 +0800
Subject: [infotalk,05337] draft-ietf-html-i18n-00.txt
Message-Id: <9508180216.AA05180@skuld.ossi.com>
すいません。書きたいことはあるのですが、ちょうど仕事が山場なもので、簡
単に。
> というわけで困ったことに、document character set として UCS-2 を使うよと
> 言っているようです。UCS-2 って良く知らないのですが UNICODE なんですよね？
> ということは jisx0208 上では異なる文字でも、UNICODE 上同じ文字なら、同
> じ文字として扱わねばならないということかな。。
Unicodeと ISO10646のすり合わせが行われたときに source code separation
という原則が提案されて、10646の文字の元となる集合(source code)である
JIS X0208、JIS X0212などの文字同士をunification しないことになって
いると思います。(私の理解では。) つまり、現実には jisx0208上で
異なる文字で Unicode上で同じである文字はないはずです。
> 図にすると、こんな感じです。(文章で書くとわけわかめだなぁ _O_)
> ファイルやネットワークで使われている文字表現
> ↓
> ↓(モデル上は内部処理のために変換)
> ↓
> document character set (内部表現の wchar_t みたいなもの)
> ↑
> ↑(descsetで対応関係を定義)
> ↑
> baseset (一般には標準の文字集合)
例えば、0から127番目までは ISO646 IRVで、128から 255までは iso 8859-1
という既存の*文字集合*を借りてきてひとつの document character setを作
ることができる、ということだと思っています。ギリシャとか東欧の人は後半
の部分を 自分のところの文字集合 iso8859のなんとかに置き換えて自分の言
葉用の document character setを宣言することができる。
> HTML が SGML の application である(SGMLで定義されている)限り、BASESET,
> DESCSET も宣言しなくちゃいけないようです。そうなると、BASESET や
> document character set に UNICODE を使いたくなるんでしょうね。
一般に誤解されやすいのは、ファイルやネットワークで使用されている文字表
現までUnicodeにしなければならないと思われてしまう点で、draft-i18n.txt
に出てくるように entity managerという魔法のモジュールが*想定*されてい
るので、基本的には外部コードに制限はありません。つまり、document char
setはパーサが解析する場合に意味を判断するための基準となるもので、制御
文字なのか図形文字なのか、図形文字ならば スペースやタブなのか印字イメー
ジがあるのか、名前として使用できるのか数字なのかといった意味を判定する
ためのテーブルである、というのが基本的な考え方です。
--
---------------------------------------------------------------------------
TSUCHIYA Satoshi | tsuchiya@sysrap.cs.fujitsu.co.jp | NIFTY-ID:GDC02435
土 屋 哲 (狼疾の人) | 富士通マルチメディアプロジェクト推進本部 企画部
From: shimono@well.com (Takao SHIMONO)
Real-Date: Thu, 17 Aug 1995 19:05:34 -0700
Subject: [infotalk,05336] Michael Jackson Simulchat
Message-Id: <199508180204.TAA24752@well.com>
あやしい者です。
これからMichael JacksonがAmerica OnlineのMTV Onlineのchatに登場するそ
うです。InternetのIRCもあるらしいので暇な人は探してみてはいかがでせう。
Takao SHIMONO
shimono@well.com
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Fri, 18 Aug 1995 09:29:37 +0900
Subject: [infotalk,05335] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508180029.JAA01045@coo.wg.omron.co.jp>
いま会社がネットワーク工事中なのでメールが届かなくなっています。
infotalk ML archive で見つけたので遅くなりましたがお返事書きます。
> ざっと目を通しただけですが、要は、
> 1) 文字集合としてISO 10646 UCS-2を使った場合のHTMLを定義した(DTD付)。
> 2) で、HTTPの"charset"パラメタで"ISO-10646-UCS-2"が指定されている場
> 合は、この形式に基づくHTMLとして処理すべし、と言っている。
> 3) 但しHTML 2.0そのものとしては、ISO 8859-1をat leastでサポートして
> いればよい(本当は8859-1＋αだけど詳細は略)、とも言っている。
> てなとこでしょうか。
うむむ、私とは感触がずいぶん違いますね:-)。私、寝てて読み間違えたかなぁ。。
少なくとも、さっきのメールの日本語は発散してて読みにくいことと思います。(_O_)
> で、(と勝手に話を飛ばしてますが)、そのためには2022-basedなHTMLの仕
> 様をちゃんと提出しないといけない訳です。もし仮に2022-basedなHTMLの
> 仕様を記述するとしたら、DTDはどうやって書けば良いのでしょうか。
DTD の方は気にしなくても良いと思います。それよか SGML 宣言中の
BASESET, DESCSET が問題だと思います。
さっきのメールに書いたように、SGML には document character set,
baseset, descset という概念があります。2022-based HTML を HTML の規格
に取り込むためには、ISO-2022 で表現できる文字すべてを含んだ文字の集合
をひとつ定義しなくてはいけないと思います。それが UCS-2 の upper set に
なっていれば、ISO-8859-1 を愛している人も、UCS-2 を愛している人も、
ISO-2022 を愛している人も幸せになれるのではないかと思います。
例えばここで定義する文字の集合を infotalk-wchar と呼んでみましょう。
これを次のように定義することで、簡単に ISO-8859-1, UCS-2 の上位互換に
なると思います。
* infotalk-wchar は 32bits とする。
* ISO-8859-1 は次のように表現する。ただし ISO-8859-1 のコードを XX とする。
00 00 00 XX
* UCS-2 は次のように表現する。ただし UCS-2 のコードを XX とする。
00 00 XX XX
* その他の文字集合で UCS-2 にすっぽり収まっているものがあればそれを使う。
00 00 YY XX
* その他の文字集合で UCS-2 にはすっぽりとは収まっていないものは、
AA BB CC XX 94文字集合 or 96文字集合
AA BB XX XX 94x94文字集合 or 96x96文字集合
これをきっちり定義して RFC にした上で、draft-ietf-html-i18n-00.txt の
SGML 宣言の BASESET, DESCSET を次みたいに書き換えれば終りかな。
BASESET "IETF//CHARSET RFCxxxx//ESC ?? ?? ??"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 4294967295 160
う〜む、いい加減ですが、こんなんでできたりして。:-)
# BASESET の書き方は超いい加減です。4294967295 = 2^32-1 です。
> (質問3) これから書き方を勉強するとしたら例えば何を読めばよい？
ちなみにいま私は次の本を見ています。
Eric van Herwijnen,
``Practical SGML Second Edition''
Kluwer Academic Publishers
ISBN 0-7923-9434-8
もう２冊おうちにあるので、後で書きます。
出水法俊
ps. draft-ietf-html-i18n-00.txt の参考文献に高田さんの論文がありますね。
ps2. 当たり前だけど、cii 使ってると cut&paste できないのね(;_;)
From: Noritoshi Demizu (出水法俊) <demizu@nff.ncl.omron.co.jp>
Real-Date: Fri, 18 Aug 1995 08:54:20 +0900
Subject: [infotalk,05334] Re: draft-ietf-html-i18n-00.txt
Message-Id: <199508172354.IAA00954@coo.wg.omron.co.jp>
draft-ietf-html-i18n-00.txt ですが、ようやっと先ほど目を通しました。
重要っぽい節だけをリストしてみました。注目は 2.1, 2.2 かな。
* 1.1 Scope
・これは HTML 2.x を定める。
(`x' の数字をどの時点で決めるか知らないけど、今なら 2.1 かな。)
・Internet Media Type として "text/html; version=2.x" を定める。
* 1.2.2. User agents
・ユーザエージェントは少なくとも ISO-8859-1 をサポートしてない
といけない。
・Ӓ と書く時、ISO-8859-1 の範囲以外であったとしても、
UCS-2 の範囲なら正しく *解析* できないといけない。
* 2.1. Reference processing model
・ファイルやネットワークで使われている文字の表現方法については
関知しない。HTTP や MIME の Content-Type フィールドの charset
パラメータ使って好きなのを使ってくれぃ。
・外部表現が何であれ気にせず、内部処理する前に(モデル上は) 2.2節
で定義する `document character set' ってのに変換しちゃうぞ。
・entityマネージャも、パーサも、アプリケーションも、文字のセマ
ンティクス(?)に関係する時には必ず HTML 2.x document character
set だけを使うのよ。これで Ӓ が一意に決まるわ。
* 2.2. The HTML 2.x document character set
・HTML 2.x document character set は UCS-2、つまり
Basic Multilingual Plane of ISO 10646:1993 [ISO-10646] である。
* 4.2. Date, time, measures and monetary amounts
・Latiin-1 の文字を全部 entity 定義してる。
・日付、時刻、長さ、お金の表記も国によって違うのを吸収する。
* 5.2. Form submission
・"application/x-www-form-urlencoded" では charset は扱えない。
・"multipart/form-data" がいいよ。
* 6. Miscellaneous
・Content-Type に charset paramter がないのが多い。
・<A ..> か <LINK ..> に CHARSET attribute を加えてはどうか。
・ドキュメントの頭に次のように書くのはどうか。
<META HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-2022-JP">
* 7. HTML Public Text
・HTML 2.x の DTD, SGML 宣言, Entity宣言が定義されている。
というわけで困ったことに、document character set として UCS-2 を使うよと
言っているようです。UCS-2 って良く知らないのですが UNICODE なんですよね？
ということは jisx0208 上では異なる文字でも、UNICODE 上同じ文字なら、同
じ文字として扱わねばならないということかな。。
* * *
さて、draft-ietf-html-i18n-00.txt と `Practical SGML' という本からの知
識によると、SGML では文字を次のように考えているようです。
・ドキュメント中で使うことのできる文字の集合を `document character set'
と言う。`document character set' に含まれるひとつひとつの文字には
一意な番号が割り当てられている。このとき、各文字がシステム上で具体
的にどのように表現されているかには関知しない。
・`document character set' の各番号が実際にはどの文字を表現している
かを示すために、`baseset' と `descset' を SGML 宣言部で宣言しなけ
ればならない。
・`baseset' は、多くの場合標準として定義されている文字集合を用いる。
・`descset' は、`baseset' と `document character set' の対応表である。
簡単のためか、`document character set' と `baseset' は同じものが
用いられることがよくあるようだ。
・ファイルやネットワークで使われている文字の集合を `system character
set' と言うらしい。
図にすると、こんな感じです。(文章で書くとわけわかめだなぁ _O_)
ファイルやネットワークで使われている文字表現
↓
↓(モデル上は内部処理のために変換)
↓
document character set (内部表現の wchar_t みたいなもの)
↑
↑(descsetで対応関係を定義)
↑
baseset (一般には標準の文字集合)
というわけで、SGML の文書の文字は、モデル上は固定長文字集合みたいです。
HTML が SGML の application である(SGMLで定義されている)限り、BASESET,
DESCSET も宣言しなくちゃいけないようです。そうなると、BASESET や
document character set に UNICODE を使いたくなるんでしょうね。
* * *
というわけで、document character set として UCS-2 を明確に定義されるの
を防いで ISO-2022 でも困らないようにするためには、思うに、UNICODE をも
包含した、UNICODE に代わる便利な code set を提案すれば良いのではないか
と思ったりしております。例えば、X11R5 の Xwchar みたいなの (曖昧な記憶
を元に書いているので、例として不適切ならごめんなさい)。
出水法俊