Independent Submission A. Keromytis
Request for Comments: 5708 Columbia University
Category: Informational January 2010
ISSN: 2070-1721
X.509 Key and Signature Encoding for the
KeyNote Trust Management System
Abstract
抽象
This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.
このメモは基調信頼管理システム（RFC 2704）のバージョン2のためのX.509キー識別子と署名エンコーディングを記述する。 X.509証明書（RFC 5280）は、直接、既に認証用のX.509証明書を使用するプロトコルとの容易な統合を可能にし、基調アサーションでオーソまたはライセンシーフィールド（または両方のフィールドに）で使用することができます。
In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792).
また、ドキュメントは、（RFC 2792で定義されているMD5及びSHA1ハッシュ関数を越えて）他のハッシュ関数を使用して、追加の署名タイプを定義します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5708.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5708で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントの発行日に有効な：（trustee.ietf.org/license-info HTTP）この文書では、BCP 78とIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
KeyNote is a simple and flexible trust-management system designed to work well for a variety of large- and small-scale, Internet-based applications. It provides a single, unified language for both local policies and credentials. KeyNote policies and credentials, called 'assertions', contain predicates that describe the trusted actions permitted by the holders of specific public keys. KeyNote assertions are essentially small, highly structured programs. A signed assertion, which can be sent over an untrusted network, is also called a 'credential assertion'. Credential assertions, which also serve the role of certificates, have the same syntax as policy assertions but are also signed by the principal delegating the trust. Note that only one principal may sign a credential assertion, but trust may be delegated to multiple principals. The credential assertion may delegate trust to each of these principals separately or to groups of principals required to act together. For more details on KeyNote, see [KEYNOTE]. This document assumes reader familiarity with the KeyNote system.
基調は大規模および小規模、インターネットベースのさまざまなアプリケーションのためにうまく動作するように設計されたシンプルで柔軟な信託管理システムです。これは、ローカルポリシーと資格情報の両方のために、単一の、統一された言語を提供します。 「アサーション」と呼ば基調ポリシーおよび資格情報は、特定の公開鍵の所有者によって許可され信頼されるアクションを記述する述語が含まれています。基調アサーションは、本質的に小さな、高度に構造化されたプログラムです。信頼できないネットワークを介して送信することができる署名されたアサーションは、また、「資格アサーション」と呼ばれます。また、証明書の役割を果たし資格アサーションは、ポリシーアサーションと同じ構文を持っているだけでなく、信頼を委任するプリンシパルによって署名されています。唯一の主体が資格アサーションに署名することができるが、信頼が複数の主体に委譲することができることに留意されたいです。資格アサーションは、個別にまたは一緒に行動するために必要なプリンシパルのグループにこれらのプリンシパルのそれぞれに信頼を委任することができます。基調の詳細については、[KEYNOTE]を参照してください。この文書では、基調システムを読者の知識があることを前提としています。
Cryptographic keys may be used in KeyNote to identify principals. To facilitate interoperation between different implementations and to allow for maximal flexibility, keys must be converted to a normalized canonical form (dependent on the public key algorithm used) for the purposes of any internal comparisons between keys. For example, an RSA key may be encoded in base64 [RFC4648] ASCII in one credential and in hexadecimal ASCII in another. A KeyNote implementation must internally convert the two encodings to a normalized form that allows for comparison between them. Furthermore, the internal structure of an encoded key must be known for an implementation to correctly decode it. [RFC2792] describes the RSA and DSA (Digital Signature Algorithm) key identifier and signature encodings for use in KeyNote assertions. This document specifies a new key identifier, allowing X.509 certificates [RFC5280] to be used as a key substitute wherever an RSA or DSA key may be used in KeyNote. Specifically, KeyNote will use the key associated with the subject of an X.509 certificate. In addition, this document defines a corresponding signature encoding, to be used in conjunction with X.509 key identifiers. Finally, this document defines new signature encodings that use new hash functions beyond the MD5 and SHA1 functions defined in RFC 2792, and which in recent years have been found to be vulnerable to attack.
暗号鍵は、プリンシパルを識別するために、基調に使用することができます。異なる実装の間での相互運用を容易にし、最大の柔軟性を可能にするために、キーは、キーの間に任意の内部比較の目的のために（使用される公開鍵アルゴリズムに依存して）正規化された標準形式に変換されなければなりません。例えば、RSA鍵は、一つ資格で、別の16進ASCIIでBASE64 [RFC4648] ASCIIで符号化されてもよいです。基調実装は、内部それらの間の比較を可能に正規化されたフォームに2つのエンコーディングを変換する必要があります。さらに、符号化されたキーの内部構造は、それを正しく復号する実装のために既知でなければなりません。 [RFC2792]は基調アサーションに使用するためのRSAやDSA（デジタル署名アルゴリズム）鍵識別子と署名エンコーディングを記述する。この文書では、RSA又はDSAキーを基調に使用することができるどこX.509証明書[RFC5280]キー代替として使用することを可能にする、新しい鍵の識別子を指定します。具体的には、基調講演X.509証明書のサブジェクトに関連付けられたキーを使用します。また、この文書は、X.509鍵識別子と組み合わせて使用することに対応する署名エンコーディングを定義します。最後に、この文書はRFC 2792で定義されたMD5とSHA1の機能を超えて、新たなハッシュ関数を使用して新しい署名のエンコーディングを定義し、近年の攻撃に対して脆弱であることが判明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
X.509 key identifiers in KeyNote are encoded as an ASN1 Distinguished Encoding Rules (DER) encoding of the whole X.509 certificate, as defined in Section 4 of [RFC5280].
[RFC5280]のセクション4で定義されるよう基調でX.509キー識別子は、全体のX.509証明書のASN1識別符号化規則（DER）符号化として符号化されます。
For use in KeyNote credentials, the ASN1 DER-encoded object is then ASCII-encoded (e.g., as a string of hex digits or base64 characters).
基調クレデンシャルで使用するために、ASN1 DER符号化されたオブジェクトは、ASCII符号化された（例えば、進数字またはBASE64文字の文字列）です。
X.509 keys encoded in this way in KeyNote must be identified by the "x509-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or "base64"). Other ASCII encoding schemes may be defined in the future.
アルゴリズム名XXXは、ASCIIコード化（「進」または「BASE64」）である：基調に、このように符号化されたX.509キーは、「X509-XXX」によって識別されなければなりません。その他のASCII符号化方式は、将来的に定義されてもよいです。
For comparison purposes, the Subject public key in X.509 certificates is used in the normalized form described in Section 2 of [RFC2792]. The resulting RSA or DSA key is then used for comparing, per [RFC2792]. All X.509 key comparisons in KeyNote occur between normalized forms. Note that this allows for comparison between a directly encoded RSA or DSA key (as specified in RFC 2792) and the same key when contained in an X.509 certificate.
比較目的のために、X.509証明書のサブジェクト公開鍵は、[RFC2792]のセクション2で説明した正規化された形態で使用されます。得られたRSA又はDSA鍵は、その後、[RFC2792]あたり、比較のために使用されます。基調のすべてのX.509キーの比較は正規化されたフォームの間に発生します。 X.509証明書に含まれている場合、これは（RFC 2792で指定されるように）そのまま符号化RSA又はDSAキーと同一のキーとの間の比較を可能にすることに留意されたいです。
X.509 key identifier signatures are defined for historical reasons. Implementers are encouraged to use the RSA- or DSA-based signature encodings instead.
X.509鍵識別子署名は歴史的な理由のために定義されています。実装者は、代わりにRSA-またはDSAベースの署名のエンコーディングを使用することをお勧めします。
X.509 key identifier signatures in KeyNote are identical to RSA- or DSA-based signatures [RFC2792]. The only difference is that the public key corresponding to the private key that generated the signatures is encoded in an X.509 certificate in the Authorizer field of the signed credential assertion. However, an RSA- or DSA-based signature encoding (depending on the Subject key contained in the X.509 certificate itself) may be used instead.
基調でX.509鍵識別子署名はRSA-またはDSAベースの署名[RFC2792]と同一です。唯一の違いは、署名を生成した秘密鍵に対応する公開鍵は、署名された信用証明書アサーションの授権者フィールドのX.509証明書に符号化されることです。しかし、（X.509証明書自体に含まれる被写体のキーに応じて）RSA-またはDSAベースの署名符号化を用いてもよいです。
X.509 key identifier signatures in KeyNote are computed over the assertion body (starting from the beginning of the first keyword, up to and including the newline character immediately before the "Signature:" keyword) and the signature algorithm name (including the trailing colon character, e.g., "sig-x509-sha512-base64:")
基調でX.509キー識別子の署名がアサーション本体にわたって計算される（まで、最初のキーワードの先頭から開始し、直前に改行文字を含む：キーワード「署名」）末尾結腸を含むと署名アルゴリズム名（文字、例えば、 "SIG-X509-SHA512-BASE64："）
X.509 key identifier signatures are encoded as an ASN1 OCTET STRING object, containing the signature value.
X.509鍵識別子署名は、署名値を含む、ASN1 OCTET文字列オブジェクトとして符号化されます。
For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII-encoded (as a string of hex digits or base64 characters).
基調クレデンシャルで使用するために、ASN1オクテット文字列は、その後、ASCII符号化された（16進数字またはBASE64文字の文字列）です。
X.509 key identifier signatures encoded in this way in KeyNote must be identified by the "sig-x509-XXX-YYY:" algorithm name, where XXX is a hash function name (see Section 5 and Section 7 of this document) and YYY is an ASCII encoding ("hex" or "base64").
基調に、このように符号化されたX.509鍵識別子署名は、「SIG-X509-XXX-YYY：」で識別されなければならないアルゴリズム名XXXは、ハッシュ関数名である（セクション5と、このドキュメントのセクション7）とYYY ASCIIエンコーディング（「進」または「BASE64」）です。
For historical reasons (backward compatibility), X.509 key identifier signatures SHOULD support SHA1 as the hash function, using the "sha1" keyword. In addition, SHA256, SHA512, and RIPEMD160 ([SHA256+], [SHA2-2], [RIPEMD-160]) signatures MUST be supported for use with X.509 key identifier signatures, by using the "sha256", "sha512", and "ripemd160" keywords, respectively (see Section 7).
歴史的な理由（下位互換性）のために、X.509鍵識別子署名は「SHA1」キーワードを使用して、ハッシュ関数としてSHA-1をサポートしなければなりません。また、SHA256、SHA512、およびRIPEMD160（[SHA256 +]、[SHA2-2]、[RIPEMD160]）シグネチャが "SHA256" を用いて、X.509鍵識別子署名で使用するためにサポートしなければなりません、 "SHA512" 、および "RIPEMD160" のキーワードは、それぞれ（セクション7を参照します）。
In addition, SHA256, SHA512, and RIPEMD160 signature identifiers are defined for RSA signatures, using the "sha256", "sha512", and "ripemd160" keywords, respectively (see Section 7).
また、SHA256は、SHA512、およびRIPEMD160署名識別子がそれぞれ "SHA256"、 "SHA512"、および "RIPEMD160" のキーワードを使用して、RSA署名のために定義されている（セクション7参照）。
This document discusses the format of X.509 keys and signatures as used in KeyNote. The security of KeyNote credentials utilizing such keys and credentials is directly dependent on the strength of the related public key algorithms. On the security of KeyNote itself, see [KEYNOTE]. Furthermore, it is the responsibility of the application developer to ensure that X.509 certificates are valid (signed by a trusted authority, not expired, and not revoked).
この文書では、基調で使用されるX.509鍵と署名の形式を論じています。基調ような鍵を利用した資格情報と資格情報のセキュリティは、関連する公開鍵アルゴリズムの強さに直接依存しています。基調自体のセキュリティには、[KEYNOTE]を参照してください。さらに、それはX.509証明書が有効であることを確実にするために、アプリケーション開発者の責任である（信頼できる認証局によって署名されたが、有効期限が切れていない、と失効していません）。
The use of SHA1 as part of signatures and key identifiers is discouraged, because of the various weaknesses in the algorithm that have been identified in recent years.
署名と鍵識別子の一部としてSHA1を使用することがあるため、近年では確認されているアルゴリズムでは、様々な弱点のため、お勧めできません。
Per [RFC2792], IANA has provided a registry of reserved algorithm identifiers. The following are reserved by this document as KeyNote public key format identifiers:
[RFC2792]あたりに、IANAは予約アルゴリズム識別子のレジストリを提供してきました。基調公開鍵フォーマット識別子として、このドキュメントによって予約されている次のとおりです。
- "x509-hex" - "x509-base64"
- "X509-進" - "X509-BASE64"
The following are reserved by this document as KeyNote signature algorithm identifiers:
基調署名アルゴリズム識別子としてこの文書によって予約されている以下：
- "sig-x509-sha1-hex" - "sig-x509-sha1-base64" - "sig-x509-sha256-hex" - "sig-x509-sha256-base64" - "sig-x509-sha512-hex" - "sig-x509-sha512-base64" - "sig-x509-ripemd160-hex" - "sig-x509-ripemd160-base64" - "sig-rsa-sha256-hex" - "sig-rsa-sha256-base64" - "sig-rsa-sha512-hex" - "sig-rsa-sha512-base64" - "sig-rsa-ripemd160-hex" - "sig-rsa-ripemd160-base64"
- "アウト-X509-SHA1-進" - "アウト-X509-SHA1-BASE64" - "アウト-X509のSHA256進" - "アウト-X509のSHA256-BASE64" - "アウト-X509のSHA512の六角" - "アウト-X509のSHA512-BASE64" - "アウト-X509 RIPEMD160-進" - "アウト-X509 RIPEMD160 - BASE64" - "アウト-RSA-SHA256進" - "アウト-RSA-SHA256-BASE64" - "アウト-RSA-SHA512進" - "アウト-RSA-SHA512-BASE64" - "アウト-RSA-RIPEMD160-進" - "アウト-RSA-RIPEMD160 - BASE64"
Note that the double quotes are not part of the algorithm identifiers.
二重引用符は、アルゴリズム識別子の一部ではないことに注意してください。
[SHA256+] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[SHA256 +]イーストレイク3日、D.とT.ハンセンは、RFC 4634、2006年7月、 "米国は、ハッシュアルゴリズム（SHAとHMAC-SHA）を固定します"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[KEYNOTE] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. Keromytis, "The KeyNote Trust-Management System Version 2", RFC 2704, September 1999.
【KEYNOTE]ブレイズ、M.、ファイゲンバウム、J.、Ioannidis、J.、およびA. Keromytis、 "基調信託管理システムバージョン2"、RFC 2704、1999年9月。
[RFC2792] Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System", RFC 2792, March 2000.
[RFC2792]ブレイズ、M.、Ioannidis、J.、およびA. Keromytis、 "基調トラスト・マネジメント・システムのためのDSAおよびRSA鍵と署名エンコーディング"、RFC 2792、2000年3月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RIPEMD-160] 3.ISO/IEC 10118-3:1998, "Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions," International Organization for Standardization, Geneva, Switzerland, 1998.
[RIPEMD-160] 3.ISO / IEC 10118-3：1998、 "情報技術 - セキュリティ技術 - ハッシュ関数 - 第3部：専用ハッシュ関数、" 国際標準化機構、ジュネーブ、スイス、1998。
[SHA2-2] NIST, "Descriptions of SHA-256, SHA-384, and SHA-512", May 2001, <http://csrc.nist.gov/publications/fips/ fips180-3/fips180-3_final.pdf>.
、2001年5月、<http://csrc.nist.gov/publications/fips/ fips180-3 / fips180-3_final [SHA2-2] NIST、 "SHA-256、SHA-384およびSHA-512の説明"。 PDF>。
The author would like to thank Jim Schaad for his review and comments on earlier versions of this document.
著者は彼のレビューと、このドキュメントの以前のバージョンへのコメントのためにジムSchaadに感謝したいと思います。
Author's Address
著者のアドレス
Angelos D. Keromytis Department of Computer Science Columbia University Mail Code 0401 1214 Amsterdam Avenue New York, New York 1007 USA
コンピュータサイエンスコロンビア大学メールコードのアンゲロス・D. Keromytis課0401 1214アムステルダムアベニューニューヨーク、ニューヨーク1007 USA
EMail: angelos@cs.columbia.edu
メールアドレス：angelos@cs.columbia.edu