↓ ↑ページトップへ
表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
0/400
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
12/16

登録

 扉が開いた。


 利用者が出てくる。


 リゼットは見送り、机へ戻った。


 記録を開く。


 実施した方式。


 必要な確認事項。


 成立。


 抜けがないことを確認して、署名した。


 最初の一件だった。


 隣の受付では、次の利用者の確認が終わっている。


 リゼットは勤務表を見た。


 自分で対応できる方式だった。


 記録を閉じる。


 名前を呼んだ。


     *


 再編纂稿の修正は、認証器の節から始めた。


 古い原稿を左に置き、これまで作った対照表を右に置く。


 古代の Authenticator。


 利用者本人の確認を内部で行い、資格情報の秘密鍵を保持し、必要な処理を行う認証器。


 現行制度の門番。


 利用者本人を確認し、認証境界で認証業務を行う資格職。


 古い原稿には、両者が一つの系譜として並んでいた。


 門番制度は古代認証器の機能を復元したもの。


 その記述自体は、成立期の資料と矛盾しない。


 原構造を再現できない場合、判明した機能を当時利用可能な技術や制度で実現する。


 復興事業の方針も、すでに確認している。


 ただし、古代の認証器そのものが門番へ変わったわけではない。


 そこを一文直した。


 古代側の説明に、秘密鍵と署名を加える。


 現行制度側には、本人確認機能が既存の門番へ配置された成立経路を記す。


 参照史料を二つに分けた。


 読み返す。


 これならいい。


 次の節へ進んだ。


     *


 公開鍵の節は、少し長くなった。


 古代の公開鍵は、認証器が保持する秘密鍵と対になる。


 認証時には、認証器が資格情報の秘密鍵を用いて署名し、接続先が登録済みの公開鍵で検証する。


 現在の公開鍵は、入口で認証済みであることを後段で確認するための証票だった。


 名称は同じでも、技術的に同じものではない。


 それも、調査済みだった。


 古い原稿から、直接の技術継承を示す一文を外した。


 代わりに、制度成立時の参照関係を加える。


 古代資料から読み取られた、秘匿される側と、検証に利用される側。


 それが、すでに検討されていた認証済票の運用へ重ねられた。


 ここも書ける。


 ただ、古い原稿にあった、


 ――認証器による本人確認の結果を、公開鍵によって後段へ伝達する。


 という一文は残せなかった。


 古代側で検証されるのは認証器が生成した署名で、現在側で後段へ渡るのは認証済票だった。


 機能を大きくまとめれば似ている。


 処理を追えば違う。


 一文を削り、参照先を分けた。


 もう一度、認証器の節へ戻る。


 そちらの末尾も少し直した。


     *


 昼前には、修正履歴がずいぶん増えていた。


 物理鍵。


 古代では、利用者が所持する物理的な認証器。


 現行制度では、資格を持つ王族による高位区画の直接認証。


 王族による直接確認は、古代認証技術の復興事業より前から存在する。


 後に、古代の物理的認証手段と機能上の対応を持つ制度として整理された。


 ここも、同じものではない。


 無関係でもない。


 成立経路は書ける。


 技術的対応は確認できない。


 注記を加えた。


 初期認証。


 候補者が教育と資格判定を終え、王族による初期認証を受ける。


 業務権限が委任される。


 仮登録後、指導下実務へ入る。


 単独配置判定を経て、正式登録される。


 古代側には Registration がある。


 以前の対照表を開いた。


 すでに欄は分けてある。


 古代 Registration:資格情報の生成・登録。


 門番初期認証:認証資格の登録・業務権限の委任。


 ここで新しく確認することはなかった。


 問題は、これを原稿へ戻したときだった。


     *


 古代の登録手順に関する節を開く。


 認証を行う前に、資格情報を登録する。


 そこだけなら、現在の制度と同じ言葉で書ける。


 古い原稿も、そこを対応関係の中心に置いていた。


 登録されたものが、後の認証を成立させる。


 研究者は、現在の対照表を横へ置いた。


 古代では、認証器が資格情報の鍵対を生成する。


 秘密鍵は認証器が保持する。


 接続先へ返されるのは公開鍵と資格情報を識別する情報などで、接続先はそれを利用者の記録へ登録する。


 後の認証では、接続先が新しい challenge を出し、認証器が保持する秘密鍵で署名した結果を返す。


 接続先は、登録済みの公開鍵でそれを検証する。


 現在の門番登録では、登録されるのは認証業務を行う者と、その者に委任された業務範囲だった。


 登録された門番が、後に利用者を認証する。


 事前の登録が、後の認証を可能にする。


 そこまでは似ている。


 誰を登録するのか。


 何を保持するのか。


 誰が認証時の処理を行うのか。


 誰が何を検証するのか。


 並べると、同じ手順とは書けなかった。


 古い原稿の一文を見る。


 ――古代の Registration は、復興期に認証担当者の登録制度として復元され、現在の初期認証制度へ継承された。


 削除した。


 代わりの文を書き始める。


 復興期には、認証に先立って必要なものを登録するという古代認証技術の――


 そこで止めた。


 それだけでは、何が継承されたのか分からない。


 機能か。


 考え方か。


 名称か。


 制度上の配置か。


 成立期の資料では、それぞれを別に追える。


 一本の文へ戻すと、また同じものとして読める。


 文を消した。


 注記だけ残した。


 直接的な技術継承としては記述しない。成立経路を別記。


     *


 午後、保護の節まで進んだ。


 こちらはもっと単純だった。


 古代認証技術にも、security、protection、privacy に関する記述はある。


 資格情報。


 認証器。


 利用者本人の確認。


 資格情報を利用できる条件。


 現在の保護技能とは、保護する対象が違う。


 現行制度の保護技能は、門番制度が普及した後、安全上の必要から開発され、教育と資格の中へ組み込まれた。


 古代仕様の直接的な復元ではない。


 そのように直した。


 代理口の節も確認する。


 古代側に直接対応する仕様は確認できない。


 通常認証を利用できない者への免除や個別許可が先にあり、運用上の問題から代替の本人認証が制度化された。


 これも成立史は書ける。


 古代から同じ方式が続いているとは書けない。


 修正した箇所を上から見直した。


 認証器。


 公開鍵。


 物理鍵。


 初期認証。


 登録。


 代理口。


 保護。


 それぞれの修正には根拠がある。


 個別に読めば、特に問題はなかった。


 続けて読むと、別の問題があった。


     *


 再編纂稿の目次を開いた。


 第一部、古代認証技術。


 第二部、復元。


 第三部、現代認証制度。


 見出しだけなら分かれている。


 だが、第二部の中身は、古代側の項目を順に現在側へ渡す構成になっていた。


 生体認証。


 認証器。


 公開鍵。


 物理鍵。


 登録。


 古代側で説明したものが、復元の節を通り、現在制度側の同名または対応する制度へ続く。


 その構成だから、これまでは一つの系譜として読めた。


 いま加えた注記を一覧にする。


 技術的対応、確認できず。


 制度上の成立経路、確認。


 機能上の対応。


 直接的な技術継承としては記述しない。


 門番制度成立後に開発。


 古代典拠、確認できず。


 同じ種類の注記が、別々の章に現れていた。


 材料が足りないわけではない。


 認証器については、古代側も復興期も現行制度側も資料がある。


 公開鍵もある。


 物理鍵もある。


 初期認証も、代理口も、保護も成立過程を追えている。


 それでも、古代の項目を一つずつ現在へ渡す章立てに戻すと、どこかで技術的な継承を補わなければならなくなる。


 逆に、対応関係をすべて外せば、復興期の記録に残っている参照や命名まで消える。


 古代の認証技術と、現在の認証制度は無関係ではない。


 同じものでもない。


 研究者は目次の第二部を開いたまま、しばらく修正履歴を見た。


 本文を直すのをやめた。


     *


 これまで確認した復興期の資料を、別の一覧へ移した。


 認証器の機能復興。


 王城警備への試行。


 本人確認機能の門番への配置。


 認証済票。


 王族による直接確認。


 門番資格制度。


 初期認証。


 代理口。


 保護技能。


 どれも、初めて見る資料ではなかった。


 これまでは、それぞれの項目の成立経路を確認するために読んだ。


 年代を付ける。


 参照先を付ける。


 並べ替える。


 途中で、空欄がいくつかできた。


 制度が存在しなかった空白ではない。


 個別の調査では、そこをつなぐ必要がなかった。


 どの検討が先だったのか。


 どの運用が、別の制度改定へ影響したのか。


 復興事業側の判断が、いつ認証行政側の規程へ入ったのか。


 後から標準化されたものを、成立時からあったものとして扱っていないか。


 個々の制度史では足りていた記述を、一つの形成史として並べるには確認が必要だった。


 復興事業の実施要領を思い出す。


 原構造を再現できない場合、判明した機能を当時利用可能な技術や制度で実現する。


 これまでも何度も参照した方針だった。


 認証器の試行では、門番へ本人確認機能を置いた。


 物理鍵では、既存の王族直接確認と対応づけた。


 その後には、運用上の必要から生まれた代理口や保護技能がある。


 個別には追えている。


 全体では、まだ並べていない。


 これまで確認した資料は、一か所にまとまっているわけではなかった。


 復元事業そのものの記録は研究院側。


 初期運用規程や認証制度改定の記録は行政側。


 王城警備への試行や王族による直接確認は、王城側の記録を参照していた。


 これまでは、必要な項目ごとにそれぞれを見ていた。


 資料請求票を出した。


 復興事業記録。


 初期運用規程。


 認証制度改定記録。


 王城側の会議記録。


 すでに閲覧したものも含めた。


 今度は項目別ではなく、年代を揃えて読む。


     *


 夕方、再編纂稿の目次を複製した。


 元の目次は消さずに残す。


 複製した方で、第二部の見出しを外した。


 古代認証技術。


 その下にあった復元項目を、いったん脇へ移す。


 現代認証制度。


 こちらもそのまま残した。


 二つの間に空きを作る。


 何と書くか少し迷った。


 復元。


 それでは、今までと同じだった。


 制度形成。


 まだ、そこまで確定していない。


 結局、もっと広い言葉にした。


 復興期。


 見出しの下に、今日並べた資料番号を移した。


 本文は書かなかった。


 書けないわけではない。


 同じ構成のままでは、書かない方がよかった。


 資料請求票をその横へ置いた。


 明日は、年代順に読む。


 本文は、まだなかった。


評価をするにはログインしてください。
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
このエピソードに感想はまだ書かれていません。
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。