この仕様では、アーカイブファイルのフォーマットを指定しません。階層パスをサポートするすべてのフォーマットが受入可能です。この仕様でアーカイブに追加されたファイルは、アーカイブ内の普通のファイルとしてディレクトリに置かれます。
manifest ファイルのすべての URL 識別子は RFC 1738、"Uniform Resource Locators" に記述されている URL 構文に従います。加えて、manifest の階層パスは RFC 1738 の URL 構文との一貫性のために '/' (フォーワードスラッシュ) を区切り文字として使用します。
アーカイブはパスツリーの上位レベルに "META-INF/" ディレクトリを作成することによって、署名されます。他のパス名が先行の "/" を含む場合、先行する "/" は受入可能です(すなわち、"/META-INF/")。
アーカイブ内に次のパス名を持った manifest ファイルは確実に 1 つあります。
META-INF/MANIFEST.MF
署名ファイルは次の形式のパス名を持ちます。
META-INF/x.SF文字列 x は文字 A-Z 0-9 およびダッシュまたはアンダースコアだけを含みます。x は 8 文字を超えてはいけません。
ファイル名内の非 ASCII 文字のエンコーディング (サポートされていれば) は、この仕様ではなくアーカイブフォーマットまたは他の規則によって定義されます。しかし、META-INF ディレクトリのファイル名は上記に制限されます。
名前 "META-INF"、"MANIFEST.MF" およびファイルタイプ ".SF" は、大文字で生成されますが 、大文字小文字どちらでも認識はされます。
ほとんどのケースで、manifest ファイルまたは署名ファイルに含まれる情報は、RFC822 で規定されるいわゆる「名前: 値」ペアとして表されます。
名前-値ペアのグループを「セクション」と呼びます。セクションは他のセクションと空白行で区分されます。
すべての形式のバイナリデータはベース 64 として表されます。行の長さが 72 バイ トを超えるようなバイナリデータについては継続が必要です。バイナリデータの例はダイジェストおよび署名です。
実装によって、65535 バイトまでのヘッダ値がサポートされます。
section: *header +newline
nonempty-section: +header +newline
newline: CR LF
| LF
| CR (not followed by LF)
; That 'not followed by LF' probably requires some minor
; ugliness in the parser. Sorry.
header: alphanum *headerchar ":" SPACE *otherchar newline
*continuation
continuation: SPACE *otherchar newline
; RFC822 has +(SPACE | TAB), but this way continuation lines
; never get mangled.
alphanum: {"A"-"Z"} | {"a"-"z"} | {"0"-"9"}
headerchar: alphanum | "-" | "_"
otherchar: any Unicode character except NUL, CR and LF
; Also: To prevent mangling of files sent via straight e-mail, no
; header will start with the four letters "From".
; When version numbering is used:
number: {"0"-"9"}+
; The number needn't be, e.g. 1.11 is considered to be later
; than 1.9. Both major and minor versions must be 3 digits or less.
最低でも次のような標準のバージョン番号を含む予備のセクションが、ファイルの上部に表示されます。
Manifest-Version: 1.0オプションで、使用に必要とされるバージョンを指定できます:
Required-Version: 1.0もし、Version: が Required-Version より大きい場合、拡張を使用します。
manifest ファイルはアーカイブ内の様々なファイルのエントリであるセクションからなります。
ヘッダ自身の多くはこの使用で規定されていません。必要なものは次のとおりです:
Name: dirpath/whatever.class Digest-Algorithms: (list of algorithms) (algorithm)-Digest: (base-64 representation of digest)"Name:" ヘッダはアーカイブ内で署名されているファイルへの相対パス、もしくは、アーカイブ外の絶対 URL 参照データを含みます。
Manifest-Version: 1.0 Name: common/class1.class Digest-Algorithms: MD5 MD5-Digest: (base64 representation of MD5 digest) Name: common/class2.class Digest-Algorithms: MD5, SHA MD5-Digest: (base64 representation of MD5 digest) SHA-Digest: (base64 representation of SHA digest)
manifest-file: "Manifest-Version: 1.0" newline
manifest-start
*manifest-entry
manifest-start: section
; Optional header is
; Required-Version: number "." number
;
; Required-Version indicates that only tools of the given version
; or later can be used to manipulate the file.
; The value of Digest-Algorithms is a comma-separated-list:
comma-separated-list: +headerchar "," *whitespace comma-separated-list
| +headerchar
各署名者は署名ファイルによって表示されます。
最低でも次のような標準のバージョン番号を含む予備のセクションが、ファイルの上部に表示されます。
Signature-Version: 1.0署名者が供給する情報で特定のパス名に固有のものでない情報は、この予備ヘッダに入っている必要があります。
このファイルの主要な部分は manifest ファイルと同様な形式です。この目的は、"policy" をヘッダに埋め込むことができるようにすることです。このヘッダは manifest 所有者 (通常アーカイブを生成する人) より署名者が供給します。
署名ファイルは、基本的には名前のリストであるセクションからなります。この名前はすべて manifest ファイルに存在する必要があります。余分なヘッダをここに入れることができます。ダイジェストもまた存在しますが、これは manifest ファイル内のエントリのダイジェストです。
manifest ファイルに表示されるが署名ファイルには表示されないパスまたは URL は計算に使用されません。これによってアーカイブのサブセットに署名できます。
Name: だけが必須です。
manifest が最初に分解されるとき、署名が最初に検証されます。この検証を効率のために覚えておくことができます。これは実際のアーカイブファイルでなく署名方向自身を有効化するだけです。
ファイルを有効化するためには、署名ファイルのダイジェストの値を manifest ファイルの対応するエントリに対して計算したダイジェストと比較します。次に、manifest ファイルのダイジェストの値 を "Name:" ヘッダ内で参照される実際のデータに対して計算されるダイジェストと比較します--相対パスまたは URL。
署名ファイルの例: Signature-Version: 1.0 Name: common/class1.class Digest-Algorithms: MD5 MD5-Digest: (base64 representation of MD5 digest) Name: common/class2.class Digest-Algorithms: MD5 MD5-Digest: (base64 representation of MD5 digest)
signature-file: "Signature-Version: 1.0" newline
signature-start
*signature-entry
signature-end
signature-start: section
; Optional header is
; Required-Version: number "." number
; This has the same meaning as in manifest-start.
; The only required header is Name. Its format is the same
; as in a manifest-entry.
与えられた manifest エントリ上で署名を有効化するための別の要件は、そのエントリの manifest エントリ内の Magic キーペア値の値を検証者が理解することです。
Magic キーはオプションですが、分解者はそのエントリの署名を検証する場合、エントリの Magic キーの値を理解する必要があります。
キー Magic の値はコンマで区切られたコンテキスト固有の文字列セットです。コンマの前後の空白は無視されます。大文字小文字も無視されます。magic キーワードの正確な意味はアプリケーション固有なものです。これらのキーワードには、manifest エントリに含まれるハッシュ値の計算法方が入っており、そのため署名の正しい検証には欠くことのできないものです。このキーワードは動的または埋め込みコンテンツ、多国語ドキュメント用の複数ハッシュなどに使用します。
次に、Magic の可能性のある使用例を 2 つ示します:
Name: http://www.scripts.com/index#script1 Digest-Algorithms: SHA SHA-Digest: (base64 representation of SHA hash) Magic: JavaScript, Dynamic
Name: http://www.tourist.com/guide.html Digest-Algorithms: SHA SHA-Digest: (base64 representation of SHA hash) SHA-Digest-French: (base64 representation of SHA hash) SHA-Digest-German: (base64 representation of SHA hash) Magic: Multilingual
最初の例では、これら Magic の値は http 問い合わせの結果がドキュ
メント自身に対立するようにドキュメントに埋め込まれたスクリプトであり、またそのスクリプトが動的に生成されるということを指摘します。この 2 つの情報は、Manifest のハッシュ値と比較しそして有効な署名と比較するハッシュ値の計算方法を指摘します。
第 2 の例では、Magic 値は取得したドキュメントが固有の言語用にネゴシエートされたコンテントであり、検証するハッシュは取得したドキュメントがどの言語で書かれているかに依存するということを指摘します。
デジタル署名ファイルは .SF ファイルと同じファイル名を持ちますが、異なる拡張子を持っています。拡張子はデジタル署名の型によって変化します。
.RSA (PKCS7 signature, MD5 + RSA) .DSA (PKCS7 signature, DSA) .PGP (Pretty Good Privacy Signature)外部署名データをサポートしないこれらのフォーマットについては、ファイルは .SF ファイルの署名済みコピーからなります。こうして、あるデータは重複する可能性があり、検証者は 2 つのファイルを比較する必要があります。
外部データをサポートするフォーマットは、".SF" ファイルを参照するか、暗示的な参照によって計算を実行します。
各 .SF ファイルは複数のデジタル署名を持つ可能性がありますが、これらの署名は同じ正当なエンティティによって生成される必要があります。
ファイルタイプは 1つから 3つの「英数字」文字です。認識できないファイルタイプは明確に無視する必要があります。
Thomas Dell (tdell@netscape.com) Netscape Corporation David Hopwood (david.hopwood@lady-margaret-hall.oxford.ac.uk) Oxford University Dave Brown (brown@eng.sun.com) Benjamin Renaud (br@eng.sun.com) David Connelly (dac@eng.sun.com) Sun Microsystems, Inc.