この仕様では、アーカイブファイルの形式を指定しません。階層パスをサポートするすべての形式が受入可能です。この仕様でアーカイブに追加されたファイルは、アーカイブ内の普通のファイルとしてディレクトリに置かれます。
マニフェストファイルのすべての URL 識別子は RFC 1738、Uniform Resource Locators に記述されている URL 構文に従います。加えて、マニフェストの階層パスは RFC 1738 の URL 構文との一貫性のために「/」(フォーワードスラッシュ) を区切り文字として使用します。
アーカイブはパスツリーの上位レベルに META-INF/ ディレクトリを作成することによって、署名されます。ほかのパス名が先行する「/」を含む場合、先行する「/」をとります(すなわち、/META-INF/)。
アーカイブ内に次のパス名を持ったマニフェストファイルが 1 つだけあります。
META-INF/MANIFEST.MF
署名ファイルは次の形式のパス名を持ちます。
META-INF/x.SF文字列 x は文字 A-Z 0-9 およびダッシュまたはアンダースコアだけを含みます。x は 8 文字を超えてはなりません。
ファイル名内の非 ASCII 文字のエンコーディング (サポートされていれば) は、この仕様ではなくアーカイブ形式またはほかの規則によって定義されます。しかし、META-INF ディレクトリのファイル名は上記に制限されます。
名前 META-INF、MANIFEST.MF およびファイルタイプ .SF は、大文字で生成されますが 、大文字と小文字どちらでも認識はされます。
ほとんどのケースで、マニフェストファイルまたは署名ファイルに含まれる情報は、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 より大きい場合、拡張を使用します。
マニフェストファイルはアーカイブ内の様々なファイルのエントリであるセクションからなります。
ヘッダ自身の多くはこの使用で規定されていません。必要なものは次のとおりです。
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署名者が供給する情報で特定のパス名に固有のものでない情報は、この予備ヘッダに入っている必要があります。
このファイルの主要な部分は、マニフェストファイルと同様な形式です。この目的は、マニフェストの所有者 (通常、このアーカイブの生成者) ではなく署名者の提供するヘッダへの埋め込みを許すことです。
署名ファイルは、基本的には名前のリストであるセクションからなります。この名前はすべてマニフェストファイルに存在する必要があります。余分なヘッダをここに入れることができます。ダイジェストもまた存在しますが、これはマニフェストファイル内のエントリのダイジェストです。
マニフェストファイルに表示されるが署名ファイルには表示されないパスまたは URL は、計算に使用されません。これによってアーカイブのサブセットに署名できます。
Name: だけが必須です。
マニフェストが最初に分析されるとき、署名が最初に検証されます。この検証結果を効率化のために記録できます。これは実際のアーカイブファイルでなく、署名自身を検証するだけです。
ファイルを検証するためには、署名ファイルのダイジェスト値をマニフェストファイルの対応するエントリから計算したダイジェスト値と比較します。次に、マニフェストファイルのダイジェストの値 を 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.
与えられたマニフェストエントリ上で署名を有効化するための別の要件は、そのエントリのマニフェストエントリ内の Magic キーペア値の値を検証者が理解することです。
Magic キーはオプションですが、分解者はそのエントリの署名を検証する場合、エントリの Magic キーの値を理解する必要があります。
キー Magic の値は、コンマで区切られたコンテキスト固有の文字列のセットです。コンマの前後の空白は無視されます。大文字小文字も無視されます。magic キーワードの正確な意味はアプリケーション固有なものです。これらのキーワードには、マニフェストエントリに含まれるハッシュ値の計算方法が入っており、そのため署名の正しい検証には欠くことのできないものです。このキーワードは、動的または埋め込みコンテンツ、多国語ドキュメント用の複数ハッシュなどに使用します。
次に、潜在的に 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 つの情報は、マニフェストのハッシュ値と比較し、有効な署名と比較するハッシュ値の計算方法を示します。
第 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.