Internet Engineering Task Force (IETF) J. Kelsey
Request for Comments: 5848 NIST
Category: Standards Track J. Callas
ISSN: 2070-1721 PGP Corporation
A. Clemm
Cisco Systems
May 2010
Signed Syslog Messages
Abstract
抽象
This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol".
この文書では、発信元の認証、メッセージの整合性、リプレイ抵抗、メッセージシーケンシング、および送信syslogメッセージにメッセージを欠けの検出を追加するためのメカニズムについて説明します。この仕様はRFC 5424で定義された作品、「Syslogの議定書」と併せて使用することを意図しています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、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/rfc5848.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5848で取得することができます。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Syslog Message Format . . . . . . . . . . . . . . . . . . . . 5
4. Signature Blocks . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Syslog Messages Containing a Signature Block . . . . . . . 7
4.2. Signature Block Format and Fields . . . . . . . . . . . . 7
4.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Reboot Session ID . . . . . . . . . . . . . . . . . . 10
4.2.3. Signature Group and Signature Priority . . . . . . . . 10
4.2.4. Global Block Counter . . . . . . . . . . . . . . . . . 13
4.2.5. First Message Number . . . . . . . . . . . . . . . . . 13
4.2.6. Count . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.7. Hash Block . . . . . . . . . . . . . . . . . . . . . . 14
4.2.8. Signature . . . . . . . . . . . . . . . . . . . . . . 14
4.2.9. Example . . . . . . . . . . . . . . . . . . . . . . . 15
5. Payload and Certificate Blocks . . . . . . . . . . . . . . . . 15
5.1. Preliminaries: Key Management and Distribution Issues . . 15
5.2. Payload Block . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Block Format and Fields . . . . . . . . . . . . . . . 16
5.2.2. Signer Authentication and Authorization . . . . . . . 18
5.3. Certificate Block . . . . . . . . . . . . . . . . . . . . 19
5.3.1. Syslog Messages Containing a Certificate Block . . . . 19
5.3.2. Certificate Block Format and Fields . . . . . . . . . 20
6. Redundancy and Flexibility . . . . . . . . . . . . . . . . . . 24
6.1. Configuration Parameters . . . . . . . . . . . . . . . . . 24
6.1.1. Configuration Parameters for Certificate Blocks . . . 24
6.1.2. Configuration Parameters for Signature Blocks . . . . 26
6.2. Overlapping Signature Blocks . . . . . . . . . . . . . . . 27
7. Efficient Verification of Logs . . . . . . . . . . . . . . . . 27
7.1. Offline Review of Logs . . . . . . . . . . . . . . . . . . 28
7.2. Online Review of Logs . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8.1. Cryptographic Constraints . . . . . . . . . . . . . . . . 32
8.2. Packet Parameters . . . . . . . . . . . . . . . . . . . . 33
8.3. Message Authenticity . . . . . . . . . . . . . . . . . . . 33
8.4. Replaying . . . . . . . . . . . . . . . . . . . . . . . . 33
8.5. Reliable Delivery . . . . . . . . . . . . . . . . . . . . 34
8.6. Sequenced Delivery . . . . . . . . . . . . . . . . . . . . 34
8.7. Message Integrity . . . . . . . . . . . . . . . . . . . . 34
8.8. Message Observation . . . . . . . . . . . . . . . . . . . 34
8.9. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 34
8.10. Denial of Service . . . . . . . . . . . . . . . . . . . . 35
8.11. Covert Channels . . . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9.1. Structured Data and Syslog Messages . . . . . . . . . . . 35
9.2. Version Field . . . . . . . . . . . . . . . . . . . . . . 36
9.3. SG Field . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4. Key Blob Type . . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
This document describes a mechanism, called syslog-sign in this document, that adds origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to syslog. Essentially, this is accomplished by sending a special syslog message. The content of this syslog message is called a Signature Block. Each Signature Block contains, in effect, a detached signature on some number of previously sent messages. It is cryptographically signed and contains the hashes of previously sent syslog messages. The originator of syslog-sign messages is simply referred to as a "signer". The signer can be the same originator as the originator whose messages it signs, or it can be a separate originator.
この文書では、発信元の認証、メッセージの整合性、リプレイ抵抗、メッセージシーケンシング、およびsyslogにメッセージを欠けの検出を追加し、この文書ではsyslog-記号と呼ばれるメカニズムを、説明しています。基本的に、これは特別なSyslogメッセージを送信することによって達成されます。このSyslogメッセージの内容は、署名ブロックと呼ばれています。各署名ブロックは、実際には、以前に送信されたメッセージのいくつかの数の分離署名を含んでいます。これは、暗号署名され、以前に送信されるsyslogメッセージのハッシュを含んでいます。 syslogのサインメッセージの発信元は、単に「署名者」と呼ばれています。署名者は、メッセージが署名、またはそれは別個発信することができる発信元と同じ発信元とすることができます。
While most implementations of syslog involve only a single originator and a single collector of each message, provisions need to be made to cover situations in which messages are sent to multiple collectors. This concerns, in particular, situations in which different messages from the same originator are sent to different collectors, which means that some messages are sent to some collectors but not to others. The required differentiation of messages is generally performed based on the Priority value of the individual messages. For example, messages from any Facility with a Severity value of 3, 2, 1, or 0 may be sent to one collector while all messages of Facilities 4, 10, 13, and 14 may be sent to another collector. Appropriate syslog-sign messages must be kept with their proper syslog messages. To address this, syslog-sign uses a Signature Group. A Signature Group identifies a group of messages that are all kept together for signing purposes by the signer. A Signature Block always belongs to exactly one Signature Group and always signs messages belonging only to that Signature Group.
syslogのほとんどの実装は、単一の創始者と各メッセージの単一コレクタを含むが、規定は、メッセージを複数のコレクタに送信される状況をカバーするためになされる必要があります。この懸念は、特に、状況がするのと同じ発信元と異なるメッセージがいくつかのメッセージがいくつかのコレクターにではなく、他の人に送信されることを意味し、別のコレクタに送信されます。メッセージの必要な分化は、一般的に個々のメッセージの優先順位値に基づいて行われます。設備4、10、13、及びすべてのメッセージ14は、別のコレクタに送信することができるが、例えば、3、2、1、または0の重大度値を有する任意のファシリティからのメッセージは、一のコレクタに送信することができます。適切なsyslogのサイン・メッセージは、その適切なsyslogメッセージと一緒に保管しなければなりません。これに対処するには、syslogの記号は、署名のグループを使用しています。署名のグループは、すべての署名者の目的に署名するために一緒に保持されているメッセージのグループを識別します。署名ブロックは、常に1つのシグネチャグループに属し、常にそれだけで署名グループに属するメッセージに署名します。
Additionally, a signer sends Certificate Blocks to provide key management information between the signer and the collector. A Certificate Block has a field to denote the type of key material which may be such things as a Public Key Infrastructure using X.509 (PKIX) certificate, an OpenPGP (Pretty Good Privacy) certificate, or even an indication that a key had been pre-distributed. In the cases of certificates being sent, the certificates may have to be split across multiple Certificate Blocks carried in separate messages.
さらに、署名者は、署名者とコレクタ間の鍵管理情報を提供するために、証明書のブロックを送信します。証明書ブロックは、X.509（PKIX）証明書、OpenPGPの（プリティグッドプライバシー）証明書、またはキーがされていたことも、表示を使用して公開鍵インフラストラクチャのようなものである可能性がある主要な材料の種類を示すためのフィールドを持っています事前配布。送信された証明書の例では、証明書は別々のメッセージで運ばれた複数の証明書をブロックにまたがって分割する必要があります。
It is possible that the same host contains multiple signers that each use their own keys to sign syslog messages. In this case, each signer sends its own Certificate Block and Signature Blocks. Furthermore, each signer defines its own Signature Groups. Each signer on a given host needs to use a distinct combination of APP-NAME, and PROCID for its Signature Block and Certificate Block message. (This implies that the combination of HOSTNAME, APP-NAME, and PROCID uniquely distinguishes originators of syslog-sign messages across hosts, provided that the signers use a unique HOSTNAME.)
同じホストが各syslogメッセージに署名するために、独自のキーを使用して、複数の署名者が含まれている可能性があります。この場合、各署名者は、独自の証明書をブロックし、署名ブロックを送信します。また、各署名者は、独自のシグネチャグループを定義します。特定のホスト上の各署名者はその署名ブロックおよび証明書ブロックメッセージのAPP-NAME、およびPROCIDの異なる組み合わせを使用する必要があります。 （これは、署名者は、一意のホスト名を使用することを提供ホスト名の組み合わせは、APP-NAME、およびPROCIDが一意のホスト間のsyslog-SIGNメッセージの発信者を区別することを意味しています。）
The collector may verify that the hash of each received message matches the signed hash contained in the corresponding Signature Block. A collector may process these Signature Blocks as they arrive, building an authenticated log file. Alternatively, it may store all the log messages in the order they were received. This allows a network operator to authenticate the log file at the time the logs are reviewed.
コレクタは、各受信したメッセージのハッシュが対応する署名ブロックに含まれる署名されたハッシュと一致することを検証することができます。彼らが到着すると、コレクタは、認証されたログファイルを構築し、これらの署名ブロックを処理することができます。また、それは彼らが受信されたために、すべてのログメッセージを保存することができます。これは、ネットワークオペレータは、ログが見直される時にログファイルを認証することができます。
The process of signing works as long as the collector accepts the syslog messages, the Certificate Blocks and the Signature Blocks. Once that is done, the process is complete. After that, anyone can go back, find the key material, and validate the received messages using the information in the Signature Blocks. Finding the key material is very easily done with Key Blob Types C, P, and K (see Section 4.2) since the public key is in the Payload Block. If Key Blob Types N or U are used, some poking around may be required to find the key material. The only way to have a vendor-specific implementation is through N or U; however, also in that case, the key material will have to be available in some form which could be used by implementations of other vendors.
署名のプロセスは、コレクタはsyslogメッセージ、証明書ブロックと署名ブロックを受け入れている限り動作します。それが完了すると、プロセスは完了です。その後、誰もが、戻ってキーマテリアルを見つけて、署名ブロック内の情報を使用して、受信したメッセージを検証することができます。公開鍵は、ペイロードブロック内にあるため、主要な材料を見つけることは非常に簡単に（4.2節を参照）の鍵BlobタイプC、P、およびKで行われます。キーBLOB型NまたはUを使用する場合は、周りのいくつか突っついは、鍵材料を見つけることが必要になることがあります。ベンダ固有の実装を持っている唯一の方法は、NまたはUを介してです。しかしながら、その場合には、鍵材料は、他のベンダーの実装で使用することができる何らかの形で利用できるようにしなければなりません。
Because the mechanism that is described in this specification uses the concept of STRUCTURED-DATA elements defined in [RFC5424], compliant implementations of this specification MUST also implement [RFC5424]. It is conceivable that the concepts underlying this
本明細書に記載されているメカニズムは[RFC5424]で定義された構造化データ要素の概念を使用するため、この仕様の準拠実装はまた、[RFC5424]を実装しなければなりません。概念がこれを基礎となると考えられます
specification could also be used in conjunction with other message-delivery mechanisms. Designers of other efforts to define event notification mechanisms are therefore encouraged to consider this specification in their designs.
仕様は、他のメッセージ配信メカニズムと組み合わせて使用することができます。イベント通知メカニズムを定義するための他の努力の設計者は、したがって、彼らのデザインで、この仕様を検討することをお勧めします。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This specification is intended to be used in conjunction with the syslog protocol as defined in [RFC5424]. The syslog protocol therefore MUST be supported by implementations of this specification.
この仕様は、[RFC5424]で定義されるようにsyslogプロトコルと組み合わせて使用されることが意図されます。 syslogプロトコルは、したがって、本明細書の実装によってサポートされなければなりません。
Because the originator generating the Signature Block message, also simply referred to as "signer", signs each message in its entirety, the messages MUST NOT be changed in transit. By the same token, the syslog-sign messages MUST NOT be changed in transit. One of the effects of such behavior, including message alteration by relays, would be to render any signing invalid and hence make the mechanism useless. Likewise, any truncation of messages that occurs between sending and receiving renders the mechanism useless. For this reason, syslog signer and collector implementations implementing this specification MUST support messages of up to and including 2048 octets in length, in order to minimize the chance of truncation. While syslog signer and collector implementations MAY support messages with a length longer than 2048 octets, implementers need to be aware that any message truncations that occur render the mechanism useless. In such cases, it is up to the operator to ensure that the syslog messages can be received properly and can be validated.
また、単に「署名者」と呼ばれる署名ブロックメッセージを生成する発信者が、その全体が各メッセージに署名するため、メッセージが転送中に変更してはなりません。同じトークンでは、syslog-サインメッセージが途中で変更してはなりません。リレーによるメッセージの変更を含め、このような行動の効果の一つは、無効な任意の署名をレンダリングするので、メカニズムが無用にするだろう。同様に、送信と受信との間で発生するメッセージの任意の切り捨ては無用機構をレンダリングします。このため、この仕様を実装するsyslogの署名者とコレクタの実装は切り捨ての可能性を最小限にするために、最大長さが2048オクテットを含むのメッセージをサポートしなければなりません。 syslogの署名者とコレクタの実装が2048オクテットよりも長い長さのメッセージをサポートするかもしれないが、実装者が発生したすべてのメッセージの短縮機構は無用ということを認識する必要があります。このような場合には、Syslogメッセージが適切に受信することができ、検証できることを保証するためにオペレータに任されています。
[RFC5426] recommends using the Transport Layer Security (TLS) transport and deliberately constrains the use of UDP. UDP is NOT RECOMMENDED for use with signed syslog because its recommended payload size of 480 octets is too restrictive for the purposes of syslog-sign. A 480-octet Signature Block could sign only 9 normal messages, meaning that at a significant proportion of messages would be Signature Block messages. The 480-octet limitation is primarily geared towards small embedded systems with significant resource constraints that, because of those constraints, would not implement syslog-sign in the first place. In addition, the use of UDP is geared towards syslog messages that are primarily intended for troubleshooting, a very different purpose from the application targeted by syslog-sign. Where syslog UDP transport is used, it is the responsibility of operators to ensure that network paths are configured in a way that messages of sufficient length (up to and including 2048 octets) can be properly delivered.
[RFC5426]トランスポート層セキュリティ（TLS）トランスポートを使用することをお勧めしますし、故意にUDPの使用を制約します。 480オクテットのその推奨ペイロードサイズからsyslog-SIGNの目的のためにあまりにも制限的であるため、UDPは、署名のsyslogの使用は推奨されません。 480オクテットの署名ブロックは、メッセージのかなりの割合で署名ブロックメッセージであろうことを意味し、わずか9通常のメッセージに署名することができます。 480オクテットの制限が主な理由は、これらの制約のため、最初の場所でのsyslog-記号を実装していないだろう、重要なリソースに制約のある小型の組み込みシステムを対象としています。また、UDPの使用は、主にトラブルシューティングのために意図されているSyslogメッセージは、Syslog-記号によってターゲットアプリケーションから非常に異なる目的を目指しています。シスログUDPトランスポートが使用される場合、そのネットワークパスが十分な長さのメッセージ（最大2048オクテットを含む）を適切に送達することができるような方法で構成されていることを確認するためのオペレータの責任です。
This specification uses the syslog message format described in [RFC5424]. Along with other fields, that document describes the concept of Structured Data (SD). Structured Data is defined in terms of SD ELEMENTS (SDEs). An SDE consists of a name and a set of parameter name-value pairs. The SDE name is referred to as SD-ID. The name-value pairs are referred to as SD-PARAM, or SD Parameters, with the name constituting the SD-PARAM-NAME, and the value constituting the SD-PARAM-VALUE.
この仕様は、[RFC5424]に記載されたsyslogメッセージフォーマットを使用します。他の分野に加えて、その文書には、構造化データ（SD）の概念を説明しています。構造化データは、SD ELEMENTS（のSDE）で定義されています。 SDEは、名前とパラメータの名前と値のペアのセットで構成されます。 SDE名はSD-IDと呼ばれています。名前と値のペアは、名前がSD-PARAM-NAMEを構成し、その値がSD-PARAM-VALUEを構成すると、SD-PARAM、又はSDパラメータと呼ばれます。
The syslog messages defined in this document carry the data that is associated with Signature Blocks and Certificate Blocks as Structured Data. For this purpose, the special syslog messages defined in this document include definitions of SDEs to convey parameters that relate to the signing of syslog messages. The MSG part of the syslog messages defined in this document SHOULD simply be empty -- the content of the messages is not intended for interpretation by humans but by applications that use those messages to build an authenticated log.
この文書で定義されたsyslogメッセージは、構造化データとして署名ブロックおよび証明書のブロックに関連付けられているデータを運びます。このために、このドキュメントで定義された特別なsyslogメッセージはsyslogメッセージの署名に関連するパラメータを伝えるためのSDEの定義が含まれています。この文書で定義されたsyslogメッセージのMSG部分は、単純に空である必要があります - メッセージの内容は、人間ではなく、認証されたログを構築するためにそれらのメッセージを使用するアプリケーションによって解釈のためのものではありません。
Because the syslog messages defined in this document adhere to the format described in [RFC5424], they identify the machine that originates the syslog message in the HOSTNAME field. Therefore, the Signature Block and Certificate Block data do not need to include any additional parameter to identify the machine that originates the message.
この文書で定義されたsyslogメッセージは、[RFC5424]で説明したフォーマットに準拠しているので、彼らはHOSTNAMEフィールドにSyslogメッセージを発信機を特定します。そのため、署名ブロックおよび証明書をブロックデータは、メッセージを発信機を識別するための任意の追加のパラメータを含める必要はありません。
In addition, several signers MAY sign messages on a single host independently of each other, each using their own Signature Groups. In that case, each unique signer is distinguished by the combination of APP-NAME and PROCID. (By the same token, the same message might be signed by multiple signers.) Each unique signer MUST have a unique APP-NAME and PROCID on each host. (This implies that the combination of HOSTNAME, APP-NAME and PROCID uniquely distinguishes the originator of syslog-sign messages, provided that the signers use a unique HOSTNAME.) A Signature Block message MUST use the same combination of HOSTNAME, APP-NAME, and PROC-ID that was used to send the corresponding Certificate Block messages containing the Payload Block.
また、いくつかの署名者は、それぞれ独自のシグネチャグループを使用して、互いに独立して単一のホスト上でのメッセージに署名することができます。その場合、各固有の署名者は、APP-NAMEとPROCIDの組み合わせによって区別されます。 （同様に、同一のメッセージが複数の署名者により署名されるかもしれない。）各固有の署名者は、各ホストに固有のAPP-NAMEとPROCIDがなければなりません。 （これは、ホスト名の組み合わせは、APP-NAMEとPROCID一意のsyslog-SIGNメッセージの発信者を区別し、署名者は、一意のホスト名を使用することを条件とすることを意味する。）署名ブロックメッセージ、ホスト名の同じ組み合わせ、APP-名を使用する必要があり、ペイロードブロックを含む対応する証明書をブロックメッセージを送信するために使用されたとPROC-ID。
This section describes the format of the Signature Block and the fields used within the Signature Block, as well as the syslog messages used to carry the Signature Block.
このセクションでは、署名ブロックおよび署名ブロック内で使用されるフィールドのフォーマット、ならびに署名ブロックを運ぶために使用されるsyslogメッセージを記載しています。
There is a need to distinguish the Signature Block itself from the syslog message that is used to carry a Signature Block. Signature Blocks MUST be encompassed within completely formed syslog messages. Syslog messages that contain a Signature Block are also referred to as Signature Block messages.
署名ブロックを運ぶために使用されるSyslogメッセージから署名ブロック自体を区別する必要があります。署名ブロックが完全に形成されたsyslogメッセージ内に包含されなければなりません。署名ブロックが含まれているSyslogメッセージも署名ブロックメッセージと呼ばれています。
A Signature Block message is identified by the presence of an SD ELEMENT with an SD-ID with the value "ssign". In addition, a Signature Block message MUST contain valid APP-NAME, PROCID, and MSGID fields to be compliant with [RFC5424]. This specification does not mandate particular values for these fields; however, for consistency, a signer MUST use the same values for APP-NAME, PROCID, and MSGID fields for every Signature Block message that is sent, whichever values are chosen. It MUST also use the same value for its HOSTNAME field. To allow for the possibility of multiple signers per host, the combination of APP-NAME and PROCID MUST be unique for each such signer on any given host. If a signer daemon is restarted, it MAY use a new PROCID for what is otherwise the same signer but MUST continue to use the same APP-NAME. If it uses a new PROCID, it MUST send a new Payload Block using Certificate Block messages that use the same new PROCID (and the same APP-NAME). It is RECOMMENDED (but not required) to use 110 as value for the PRI field, corresponding to facility 13 (log audit) and severity 6 (informational). The Signature Block is carried as Structured Data within the Signature Block message, per the definitions that follow in the next section. A Signature Block message MAY carry other Structured Data besides the Structured Data of the Signature Block itself. The MSG part of a Signature Block message SHOULD be empty.
署名ブロックメッセージは「SSIGN」値とSD-IDを持つSD要素の存在によって同定されます。また、署名ブロックメッセージは、[RFC5424]に準拠するために有効なAPP-NAME、PROCID、およびMSGIDフィールドを含まなければなりません。この仕様は、これらのフィールドの特定の値を強制しません。しかし、一貫性のために、署名者は値が選択されるいずれか送信されるすべての署名ブロックメッセージ用のAPP-NAME、PROCID、およびMSGIDフィールドの同じ値を使用しなければなりません。また、そのHOSTNAMEフィールドに同じ値を使用しなければなりません。ホストごとに複数の署名者の可能性を可能にするために、APP-NAMEとPROCIDの組み合わせは、任意のホスト上のそのような各署名者に対して一意でなければなりません。署名者デーモンが再起動された場合、それはそうと同じ署名者である何のための新しいPROCIDを使用してもよいが、同じAPP-NAMEを使用し続ける必要があります。それは新しいPROCIDを使用している場合、それは同じ新PROCID（と同じAPP-NAME）を使用する証明書をブロックメッセージを使用して、新しいペイロードブロックを送らなければなりません。施設13（監査ログ）および重症度6（情報）に対応し、PRIフィールドの値として110を使用することをお勧めします（必須ではない）されています。署名ブロックは、次のセクションで続く定義あたり、署名ブロックメッセージ内の構造化データとして行われます。署名ブロックメッセージは、署名ブロック自体の構造化データ以外の他の構造化されたデータを搬送することができます。署名ブロックメッセージのMSG部分は空であるべきです。
The syslog messages defined as part of syslog-sign themselves (Signature Block messages and Certificate Block messages) MUST NOT be signed by a Signature Block. Collectors that implement syslog-sign know to distinguish syslog messages that are associated with syslog-sign from those that are subjected to signing and process them differently. The intent of syslog-sign is to sign a stream of syslog messages, not to alter it.
syslogの-サイン自身（署名ブロックメッセージと証明書ブロックメッセージ）の一部として定義されたSyslogメッセージは、署名ブロックによって署名されてはなりません。 syslogのサインを実装するコレクターは、署名の対象とは異なるそれらを処理しているものからのsyslog-記号に関連付けられているsyslogメッセージを区別するために知っています。 syslogのサインの意図は、それを変更するのではなく、syslogメッセージの流れに署名することです。
The content of a Signature Block message is the Signature Block itself. The Signature Block MUST be encoded as an SD ELEMENT, as defined in [RFC5424].
署名ブロックメッセージの内容は、署名ブロック自体です。 [RFC5424]で定義されるように署名ブロックは、SD要素として符号化されなければなりません。
The SD-ID MUST have the value of "ssign".
SD-IDは、「記号」の値を持つ必要があります。
The SDE contains the fields of the Signature Block encoded as SD Parameters, as specified in the following. The Signature Block is composed of the following fields. The value of each field MUST be printable ASCII, and any binary values MUST be base64 encoded, as defined in [RFC4648].
SDEは、以下に指定されるように、SDパラメータとして符号化された署名ブロックのフィールドを含んでいます。署名ブロックは、以下のフィールドから構成されています。各フィールドの値は、印刷可能なASCII文字でなければなりません、そして、[RFC4648]で定義されるような任意のバイナリ値は、base64エンコードされなければなりません。
Field SD-PARAM-NAME Size in octets
----- ------------- ---- -- ------
Version VER 4
バージョンVIEW 4
Reboot Session ID RSID 1-10
セッションID RSID 1-10を再起動します
Signature Group SG 1
署名グループSG 1
Signature Priority SPRI 1-3
コード優先STOP 1-H
Global Block Counter GBC 1-10
グローバルブロックカウンターGBC 1-10
First Message Number FMN 1-10
最初のメッセージ数FMN 1-10
Count CNT 1-2
CNT 1-2カウント
Hash Block HB variable, size of hash times the number of hashes (base64 encoded binary)
ブロックHB変数をハッシュ、ハッシュ倍のサイズハッシュの数（BASE64符号化されたバイナリ）
Signature SIGN variable (base64 encoded binary)
署名SIGN変数（BASE64符号化されたバイナリ）
The fields MUST be provided in the order listed. Each SD parameter MUST occur once and only once in the Signature Block. New SD parameters MUST NOT be added unless a new Version of the protocol is defined. (Implementations that wish to add proprietary extensions will need to define a separate SD ELEMENT.) A Signature Block is accordingly encoded as follows, where xxx denotes a placeholder for the particular values:
フィールドがリストされている順に提供しなければなりません。各SDパラメータは、署名ブロックに一度だけ発生する必要があります。プロトコルの新しいバージョンが定義されていない限り、新しいSDパラメータが追加されてはなりません。 （独自の拡張を追加したい実装別SD要素を定義する必要があります。）次のように署名ブロックはそれに応じて符号化され、xxxは特定の値のためのプレースホルダを表します。
[ssign VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" GBC="xxx" FMN="xxx" CNT="xxx" HB="xxx" SIGN="xxx"]
【SSIGN VER = "XXX" RSID = "XXX" SG = "XXX" SPRI = "XXX" GBC = "XXX" FMN = "XXX" CNT = "XXX" HB = "XXX" SIGN = "XXX"]
Values of the fields constitute SD parameter values and are hence enclosed in quotes, per [RFC5424]. The fields are separated by single spaces and are described in the subsequent subsections.
フィールドの値は、SDパラメータ値を構成し、したがって、[RFC5424]あたり、引用符で囲まれています。フィールドは、単一のスペースで分離され、後続のサブセクションに記載されています。
The Version field is an alphanumeric value that has a length of 4 octets, which may include leading zeroes. The first 2 octets and the last octet contain a decimal character in the range of "0" to "9", whereas the third octet contains an alphanumeric character in the range of "0" to "9", "a" to "z", or "A" to "Z". The value in this field specifies the version of the syslog-sign protocol. This is extensible to allow for different hash algorithms and signature schemes to be used in the future. The value of this field is the grouping of the protocol version (2 octets), the hash algorithm (1 octet), and the signature scheme (1 octet).
バージョンフィールドは、先行ゼロを含んでいてもよい4つのオクテットの長さを有している英数字の値です。第2オクテットと最後のオクテットは、「0」〜「9」、第三のオクテットが「0」〜「9」の範囲内に英数字を含んでいるのに対し、「」から「Zの範囲内の小数点文字を含みます」、または "Z" から "A"。このフィールドの値は、syslog-SIGNプロトコルのバージョンを指定します。これは、将来的に使用されるハッシュアルゴリズム及び署名方式異なる可能にするために拡張可能です。このフィールドの値は、プロトコルバージョン（2つのオクテット）、ハッシュアルゴリズム（1つのオクテット）、および署名スキーム（1つのオクテット）のグループです。
Protocol Version - 2 octets, with "01" as the value for the protocol version that is described in this document.
プロトコルバージョン - この文書に記載されているプロトコルバージョンの値として「01」の2つのオクテット。
Hash Algorithm - 1 octet, where, in conjunction with Protocol Version 01, a value of "1" denotes SHA1 and a value of "2" denotes SHA256, as defined in [FIPS.180-2.2002]. (This is the octet that can have a value of not just "0" to "9" but also "a" to "z" and "A" to "Z".)
ハッシュアルゴリズム - [FIPS.180-2.2002]で定義されるように、プロトコルバージョン01と関連して、「1」の値はSHA1と「2」の値を示す1オクテットは、SHA256を意味します。 （これだけではなく、「0」〜「9」の値を持っているだけでなく、「」「Z」と「A」から「Z」にすることができるオクテットです。）
Signature Scheme - 1 octet, where, in conjunction with Protocol Version 01, a value of "1" denotes OpenPGP DSA, defined in [RFC4880] and [FIPS.186-2.2000].
署名スキーム - 1つのオクテット、プロトコルバージョン01に関連して、 "1" の値は[FIPS.186-2.2000]と[RFC4880]で定義され、OpenPGPのDSAを表します。
The version, hash algorithm, and signature scheme defined in this document would accordingly be represented as "0111" (if SHA1 is used as Hash Algorithm) and "0121" (if SHA256 is used as Hash Algorithm), respectively (without the quotation marks).
引用符（それぞれ、（SHA256のハッシュアルゴリズムとして使用される場合）は、この文書で定義されたバージョン、ハッシュアルゴリズム、及び署名方式は、それに応じて（SHA1のハッシュアルゴリズムとして使用される場合）、「0111」と「0121」のように表現されます）。
The values of the Hash Algorithm and Signature Scheme are defined relative to the Protocol Version. If the single-octet representation of the values for Hash Algorithm and Signature Scheme were to ever represent a limitation, this limitation could be overcome by defining a new Protocol Version with additional Hash Algorithms and/or Signature Schemes, and having implementations support both Protocol Versions concurrently.
ハッシュアルゴリズム及び署名方式の値は、プロトコルバージョンに対して定義されます。ハッシュアルゴリズム及び署名方式の値の単一オクテット表現はこれまで制限を表現した場合、この制限は、追加のハッシュアルゴリズムおよび/または署名スキームを使用して新しいプロトコルバージョンを定義することによって克服することができ、かつ有する実装は、両方のプロトコルバージョンをサポート同時に。
As long as the sender and receiver are both adhering to [RFC5424], the prerequisites are in place so that signed messages can be received by the receiver and validated with a Signature Block. To ensure immediate validation of received messages, all implementations MUST support SHA1, and SHA256 SHOULD be supported.
署名されたメッセージは、受信機によって受信され、署名ブロックで検証することができるようであれば、送信側と受信側の両方が[RFC5424]に付着されるように、前提条件が整っています。受信したメッセージの即時検証を確実にするために、すべての実装はSHA1をサポートしなければならない、とSHA256がサポートされるべきです。
The Reboot Session ID is a decimal value that has a length between 1 and 10 octets. The acceptable values for this are between 0 and 9999999999. Leading zeroes MUST be omitted.
リブートセッションIDは1と10オクテットの長さを有する小数値です。これの許容値は、先頭のゼロを省略しなければならない0〜9999999999.あります。
A Reboot Session ID is expected to strictly monotonically increase (i.e., to never repeat or decrease) whenever a signer reboots in order to allow collectors to distinguish messages and message signatures across reboots. There are several ways in which this may be accomplished. In one way, the Reboot Session ID may increase by 1, starting with a value of 1. Note that in this case, a signer is required to retain the previous Reboot Session ID across reboots. In another way, a value of the Unix time (number of seconds since 1 January 1970) may be used. Implementers of this method need to beware of the possibility of multiple reboots occurring within a single second. Implementers need to also beware of the year 2038 problem, which will cause the 32-bit representation of Unix time to wrap in the year 2038. In yet another way, implementations where the Simple Network Management Protocol (SNMP) engine and the signer always reboot at the same time might consider using the snmpEngineBoots value as a source for this counter as defined in [RFC3414].
リブートセッションIDを厳密に単調に増加すると予想される（すなわち、繰り返さない、または低下ないため）、署名者は、コレクタがリブートメッセージとメッセージ署名を区別することを可能にするためにリブートするたび。これを達成することができる、いくつかの方法があります。一つの方法では、再起動セッションIDは、この場合には、署名者がリブート前リブートセッションIDを保持することが必要であることに留意されたいの値から開始して、1だけ増加してもよいです。別の方法で、UNIX時刻（1970年1月1日からの秒数）の値を使用することができます。この方法の実装は、単一の第2内で発生する複数の再起動の可能性に注意する必要があります。実装者はまた、Unixの時間の32ビット表現は、まだ別の方法では2038年にラップするようになります2038年問題、実装が簡易ネットワーク管理プロトコル（SNMP）エンジンと署名者は常に、再起動に注意する必要があります[RFC3414]で定義されると同時に、このカウンタのソースとしてsnmpEngineBoots値を使用して検討するかもしれません。
In cases where a signer is not able to guarantee that the Reboot Session ID is always increased after a reboot, the Reboot Session ID MUST always be set to a value of 0. If the value can no longer be increased (e.g., because it reaches 9999999999), it SHOULD be reset to a value of 1. Implementations SHOULD ensure that such a reset does not go undetected, for example, by requesting operator acknowledgment when a reset is performed upon reboot. (Operator acknowledgment may not be possible in all situations, e.g., in the case of embedded devices.)
それが到達したため、値はもはや、例えば（増加できない場合は、署名者が再起動し、セッションIDは常に再起動後に増加していることを保証することができない場合には、再起動のセッションIDは、常に0の値に設定しなければなりません。 9999999999）、このようなリセットは、リセットが再起動時に実行されたときにオペレータ承認を要求することによって、例えば、検出されないていないことを保証しなければならない1実施の値にリセットされるべき。 （オペレータ応答は、組み込み機器の場合には、例えば、すべての状況で可能ではないかもしれません。）
If a reboot of a signer takes place, Signature Block messages MAY use a new PROCID. However, Signature Block messages of the same signer MUST continue to use the same HOSTNAME, APP-NAME, and MSGID.
署名者の再起動が行われた場合は、署名ブロックメッセージは、新しいPROCIDを使用するかもしれません。しかし、同じ署名者の署名ブロックのメッセージが同じホスト名、APP-NAME、およびMSGIDを使用し続ける必要があります。
The SG parameter may take any value from 0-3 inclusive. The SPRI parameter may take any value from 0-191 inclusive. These fields taken together allow network administrators to associate groupings of syslog messages with appropriate Signature Blocks and Certificate Blocks. Groupings of syslog messages that are signed together are also called Signature Groups. A Signature Block contains only hashes of those syslog messages that are part of the same Signature Group.
SGパラメータは、包括的な0-3から任意の値をとることがあります。 SPRIパラメータは、包括的な0から191までの任意の値をとることがあります。一緒にこれらのフィールドは、ネットワーク管理者は、適切な署名ブロックと証明書ブロックとsyslogメッセージのグループを関連付けることができます。一緒に署名されたsyslogメッセージのグループ化は、シグネチャグループと呼ばれています。署名ブロックは、同じシグネチャグループの一部であるこれらのsyslogメッセージのハッシュのみが含まれています。
For example, in some cases, network administrators might have originators send syslog messages of Facilities 0 through 15 to one collector and those with Facilities 16 through 23 to another. In such cases, associated Signature Blocks should likely be sent to the corresponding collectors as well, signing the syslog messages that are intended for each collector separately. This way, each collector receives Signature Blocks for all syslog messages that it receives, and only for those. The ability to associate different categories of syslog messages with different Signature Groups, signed in separate Signature Blocks, provides administrators with flexibility in this regard.
例えば、いくつかのケースでは、ネットワーク管理者は、オリジネーターが1つのコレクタと施設別に〜23 16としたものに施設0〜15のsyslogメッセージを送信する場合があります。このような場合には、関連する署名ブロックは、おそらく別々に各コレクタのために意図されているsyslogメッセージを署名、ならびに対応するコレクタに送られるべきです。このように、各コレクタは、受信するすべてのsyslogメッセージのための署名ブロックを受け取り、唯一のそれらのため。別署名ブロックに署名された異なるシグネチャ基でsyslogメッセージの異なるカテゴリを関連付ける能力は、この点での柔軟性を管理者に提供します。
Syslog-sign provides four options for handling Signature Groups, linking them with PRI values so they may be routed to the destination commensurate with the corresponding syslog messages. In all cases, no more than 192 distinct Signature Groups (0-191) are permitted.
Syslogのサインは、彼らが対応するSyslogメッセージに見合った宛先にルーティングすることができるので、PRI値とそれらを結ぶ、シグネチャグループを処理するための4つのオプションを提供します。全ての場合において、せいぜい192個の異なるシグネチャグループ（0から191）が許可されていません。
The Signature Group to which a Signature Block pertains is indicated by the Signature Priority (SPRI) field. The Signature Group (SG) field indicates how to interpret the Signature Priority field. (Note that the SG field does not indicate the Signature Group itself, as its name might suggest.) The SG field can have one of the following values:
署名ブロックの属するシグネチャグループは、署名優先度（SPRI）フィールドによって示されます。シグネチャグループ（SG）フィールドが署名Priorityフィールドをどのように解釈するかを示します。 SGのフィールドには、次のいずれかの値を持つことができます（。その名前が示唆するようSGフィールドは、シグネチャグループそのものを示すものではありませんので注意してください）：
a. "0" -- There is only one Signature Group. In this case, the administrators want all Signature Blocks to be sent to a single destination; in all likelihood, all of the syslog messages will also be going to that same destination. Signature Blocks contain signatures for all messages regardless of their PRI value. This means that, in effect, the Signature Block's SPRI value can be ignored. However, it is RECOMMENDED that a single SPRI value be used for all Signature Blocks. Furthermore, it is RECOMMENDED to set that value to the same value as the PRI field of the Signature Block message. This way, the PRI of the Signature Block message matches the SPRI of the Signature Block that it contains.
A。 「0」 - 唯一のシグネチャーグループがあります。この場合、管理者は、すべての署名ブロックが単一の宛先に送信されるようにします。すべての可能性では、syslogメッセージの全てはまた、同じ目的地に行くことになります。署名ブロックは関係なく、PRI値のすべてのメッセージのための署名が含まれています。これは、実際には、署名ブロックのSPRI値が無視できることを意味しています。しかし、単一SPRI値が全て署名ブロックに対して使用することを推奨されています。更に、署名ブロックメッセージのPRIフィールドと同じ値にその値を設定することをお勧めします。このように、署名ブロックメッセージのPRIは、それが含まれている署名ブロックのSPRIと一致します。
b. "1" -- Each PRI value is associated with its own Signature Group. Signature Blocks for a given Signature Group have SPRI = PRI for that Signature Group. In other words, the SPRI of the Signature Block matches the PRI value of the syslog messages that are part of the Signature Group and hence signed by the Signature Block. An SG value of 1 can, for example, be used when the administrator of a signer does not know where any of the syslog messages will ultimately go but anticipates that messages with different PRI values will be collected and processed separately. Having a Signature Group per PRI value provides administrators with a large degree of flexibility with regard to how to divide up the processing of syslog messages and their signatures after they are received, at the same time allowing Signature Blocks to follow the corresponding syslog messages to their eventual destination.
B。 「1」 - 各PRI値は、独自のシグネチャグループに関連付けられています。与えられた署名のグループのための署名ブロックは、その署名のグループのためにSPRI = PRIを持っています。換言すれば、署名ブロックのSPRIは、シグネチャグループの一部、従って署名ブロックによって署名されたsyslogメッセージのPRI値と一致します。 1のSG値は、例えば、Syslogメッセージのいずれかが最終的に行くが、別のPRI値を持つメッセージを収集し、別々に処理されることを予想していますどこ署名者の管理者が把握していないときに使用することができます。 PRI値ごと署名基を有する署名ブロックは、それらに対応するsyslogメッセージを追従することを可能にすると同時に、それらが受信された後、syslogメッセージとその署名の処理を分割する方法に関して柔軟性の大きな程度を管理者に提供します最終的な目的地。
c. "2" -- Each Signature Group contains a range of PRI values. Signature Groups are assigned sequentially. A Signature Block for a given Signature Group has its own SPRI value denoting the highest PRI value of syslog messages in that Signature Group. The lowest PRI value of syslog messages in that Signature Group will be 1 larger than the SPRI value of the previous Signature Group or "0" in case there is no other Signature Group with a lower SPRI value. The specific Signature Groups and ranges they are associated with are subject to configuration by a system administrator.
C。 「2」 - 各シグネチャグループは、PRI値の範囲が含まれています。シグネチャグループが順次割り当てられます。与えられた署名のグループのための署名ブロックは、その署名のグループでsyslogメッセージの最高のPRI値を示す独自のSPRI値を持っています。そのシグネチャグループ内のsyslogメッセージの最小PRI値が低いSPRI値を有する他のシグネチャグループが存在しない場合には1前シグネチャグループのSPRI値より大きいか「0」であろう。それらが関連付けられている特定のシグネチャグループおよび範囲は、システム管理者による設定の対象となっています。
d. "3" -- Signature Groups are not assigned with any of the above relationships to PRI values of the syslog messages they sign. Instead, another scheme is used, which is outside the scope of this specification. There has to be some predefined arrangement between the originator and the intended collectors as to which syslog messages are to be included in which Signature Group, requiring configuration by a system administrator. This also provides administrators with the flexibility to group syslog messages into Signature Groups according to criteria that are not tied to the PRI value. Note that this option is not intended for deployments that lack such an arrangement, as in those cases a collector could misinterpret the intended meaning of the Signature Group. A collector that receives Signature Block messages of a Signature Group of whose scheme it is not aware SHOULD bring this fact to the attention of the system administrator. The particular mechanism used for that is implementation-specific and outside the scope of this specification.
D。 「3」 - 署名のグループは、彼らが署名するsyslogメッセージのPRI値に上記の関係のいずれにも割り当てられていません。代わりに、別のスキームは、本明細書の範囲外であり、使用されています。これにsyslogメッセージは、システム管理者が構成を必要とするどのシグネチャグループに含まれるべきであるように発信者と意図コレクターの間にいくつかの事前定義された配列が存在しなければなりません。また、これはPRI値に縛られない基準に従って署名のグループにグループのsyslogメッセージに柔軟性を管理者に提供します。このオプションは、これらの例にコレクタが署名グループの意図する意味を誤解可能性があるので、このような配置に欠ける展開のために意図されていないことに注意してください。スキーム、システム管理者の注意にこの事実を持参してください、それは認識していないのシグネチャグループの署名ブロックメッセージを受信コレクター。そのために使用される特定の機構は、実装固有の、本明細書の範囲外です。
One reasonable way to configure some installations is to have only one Signature Group, indicated with SG=0, and have the signer send a copy of each Signature Block to each collector. In that case, collectors that are not configured to receive every syslog message will still receive signatures for every message, even ones they are not supposed to receive. While the collector will not be able to detect gaps in the messages (because the presence of a signature of a message that is missing does not tell the collector whether or not the corresponding message would be of the collector's concern), it does allow all messages that do arrive at each collector to be put into the right order and to be verified. It also allows each collector to detect duplicates. Likewise, configuring only one
いくつかの設備を構成する一つの合理的な方法は一つだけシグネチャグループを持つことで、SG = 0で示され、署名者は、各コレクタにそれぞれ署名ブロックのコピーを送っています。その場合には、すべてのSyslogメッセージを受信するように設定されていないのコレクターはまだ、すべてのメッセージのために、彼らが受け取ることになっていなくてもものを署名を受け取ります。 （不足しているメッセージの署名の存在は、対応するメッセージは、コレクターの懸念があるであろうか否かのコレクターを教えてくれないので）コレクタはメッセージのギャップを検出することはできませんが、それはすべてのメッセージを許可しませんそれは、右の順に入れなければ、検証するために、各コレクタに到着します。また、各コレクタは重複を検出することができます。同様に、一つだけを設定します
Signature Group can be a reasonable way to configure installations that involve relay chains, where one or more interim relays may or may not relay all messages to the same destination.
シグネチャグループは、一個の以上の中間リレーが、同じ宛先へのすべてのメッセージを中継しない場合があり、リレー鎖を伴うインストールを設定するには、合理的な方法にすることができます。
The Global Block Counter is a decimal value representing the number of Signature Blocks sent by syslog-sign before the current one, in this reboot session. This takes at least 1 octet and at most 10 octets displayed as a decimal counter. The acceptable values for this are between 0 and 9999999999, starting with 0. Leading zeroes MUST be omitted. If the value of the Global Block Counter has reached 9999999999 and the Reboot Session ID has a value other than 0 (indicating the fact that persistence of the Reboot Session ID is supported), then the Reboot Session ID MUST be incremented by 1 and the Global Block Counter resumes at 0. When the Reboot Session ID is 0 (i.e., persistent Reboot Session IDs are not supported) and the Global Block Counter reaches its maximum value, then the Global Block Counter is reset to 0 and the Reboot Session ID MUST remain at 0.
グローバルブロックカウンタは、この再起動セッション中に現在の前のsyslog-SIGNによって送信されたオリジナルブロックの数を表す値（10進数）です。これは、少なくとも1つのオクテットと進カウンタとして表示され、最大で10個のオクテットをとります。これの許容値を省略しなければならない0リーディングゼロで始まり、0から9999999999の間です。グローバルブロックカウンタの値が9999999999に達し、再起動セッションIDが（再起動セッションIDの永続性がサポートされていることを示す）0以外の値を持っている場合、再起動セッションIDは1とグローバルインクリメントしなければなりませんリブートセッションIDが0である（すなわち、永続的な再起動セッションIDがサポートされていない）とグローバルブロックカウンタがその最大値に達し、その後、グローバルブロックカウンタが0にリセットされ、再起動セッションIDが残っている必要がある場合、ブロックカウンタが0で再開します0で。
Note that the Global Block Counter crosses Signature Groups; it allows one to roughly synchronize when two messages were sent, even though they went to different collectors and are part of different Signature Groups.
グローバルブロックカウンタシグネチャグループを横切ることに留意されたいです。それは彼らが別のコレクターに行って、異なるシグネチャグループの一部であっても、二つのメッセージが送信されたとき、1が大体同期することができます。
Because a reboot results in the start of a new reboot session, the signer MUST reset the Global Block Counter to 0 after a reboot occurs. Applications need to take into account the possibility that a reboot occurred when authenticating a log, and situations in which reboots occur frequently may result in losing the ability to verify the proper sequence in which messages were sent, hence jeopardizing the integrity of the log.
再起動が発生した後、新たな再起動セッションの開始でリブートした結果なので、署名者は、0にグローバルブロックカウンタをリセットしなければなりません。アプリケーションは、アカウントにログインを認証するときに、再起動が発生している可能性を取る必要があり、かつ頻繁に発生リブートされる状況は、メッセージが故にログの整合性を危うくする、送信された中で適切な順序を検証する能力を失うことになることがあります。
This is a decimal value between 1 and 10 octets, with leading zeroes omitted. It contains the unique message number within this Signature Group of the first message whose hash appears in this block. The very first message of the reboot session is numbered "1". This implies that when the Reboot Session ID increases, the message number is reset to 1.
先行ゼロを省略して、これは、1と10オクテットの間の10進値です。これは、ハッシュ、このブロックに表示される最初のメッセージのこのシグネチャグループ内で一意のメッセージ番号が含まれています。リブートセッションの非常に最初のメッセージは、「1」番号が付けられています。これは、再起動セッションIDが増加した場合、メッセージ番号が1にリセットされることを意味します。
For example, if this Signature Group has processed 1000 messages so far and message number 1001 is the first message whose hash appears in this Signature Block, then this field contains 1001. The message number is relative to the Signature Group to which it belongs; hence, a message number does not identify a message beyond its Signature Group.
このシグネチャグループは、これまでに1000年のメッセージを処理したとメッセージ番号1001は、そのハッシュこの署名ブロックに表示される最初のメッセージである場合、例えば、このフィールドは、1001メッセージ番号は、それが属するシグネチャグループに対するものである含み、したがって、メッセージ番号は、その署名のグループを超えたメッセージを識別しません。
Should the message number reach 9999999999 within the same reboot session and Signature Group, the message number subsequently restarts at 1. In such an event, the Global Block Counter will be vastly different between two occurrences of the same message number.
メッセージ番号が同一のリブートセッションと署名グループ内9999999999に達する必要があり、メッセージの数は、その後、このようなイベントでは1で再起動し、グローバルブロックカウンターは、同一のメッセージ番号の2つの出現の間で大きく異なるだろう。
The count is a 1- or 2-octet field that indicates the number of message hashes to follow. The valid values for this field are 1 through 99. The number of hashes included in the Signature Block MUST be chosen such that the length of the resulting syslog message does not exceed the maximum permissible syslog message length.
カウントは、メッセージの数が追従するハッシュ示し1-または2-オクテットフィールドです。 1 99を介してハッシュの数は、署名ブロックに含まれるこのフィールドの有効な値が得られたシスログメッセージの長さが最大許容シスログメッセージの長さを超えないように選択されなければなりません。
The hash block is a block of hashes, each separately encoded in base64. Each hash in the hash block is the hash of the entire syslog message represented by the hash, independent of the underlying transport. Hashes are ordered from left to right in the order of occurrence of the syslog messages that they represent. The space character is used to separate the hashes. Note, the hash block constitutes a single SD-PARAM; a Signature Block message MUST include all its hashes in a single hash block and MUST NOT spread its hashes across several hash blocks.
ハッシュブロックは、ハッシュ、別々にBASE64でエンコードされた各々のブロックです。ハッシュブロックの各ハッシュは、基礎となるトランスポートの独立したハッシュで表される全体シスログメッセージのハッシュです。ハッシュは、それらが表すsyslogメッセージの発生順に左から右に並べられます。空白文字は、ハッシュを分離するために使用されます。ハッシュブロックは、単一のSD-PARAMを構成し、注意してください。署名ブロックメッセージは、単一のハッシュブロック内のすべてのハッシュを含まなければならないし、いくつかのハッシュブロックにわたってそのハッシュを広めてはなりません。
The "entire syslog message" refers to what is described as the syslog message excluding transport parts that are described in [RFC5425] and [RFC5426], and excluding other parts that may be defined in future transports. The hash value will be the result of the hashing algorithm run across the syslog message, starting with the "<" of the PRI portion of the header part of the message. The hash algorithm used and indicated by the Version field determines the size of each hash, but the size MUST NOT be shorter than 160 bits without the use of padding. It is base64 encoded as per [RFC4648].
「全体のsyslogメッセージは、」シスログメッセージ[RFC5425]及び[RFC5426]に記載されて搬送部を除いて、将来のトランスポートで定義されてもよい他の部分を除くように記載されているものを指します。ハッシュ値は、メッセージのヘッダ部分のPRI部のシスログメッセージ、「<」で始まる横切るハッシュアルゴリズムの結果であろう。バージョンフィールドによって使用され、示されたハッシュアルゴリズムは、各ハッシュのサイズを決定するが、サイズは、パディングを使用することなく、160ビットよりも短くてはいけません。これは[RFC4648]に従ってbase64エンコードです。
The number of hashes in a hash block SHOULD be chosen such that the resulting Signature Block message does not exceed a length of 2048 octets in order to avoid the possibility that truncation occurs. When more hashes need to be sent than fit inside a Signature Block message, it is advisable to start a new Signature Block.
ハッシュブロックのハッシュの数は切り捨てが発生する可能性を回避するために、得られた署名ブロックメッセージは、2048オクテットの長さを超えないように選択されるべきです。より多くのハッシュが署名ブロックメッセージ内に収まるよりも送信する必要がある場合、新しい署名ブロックを開始することをお勧めします。
This is a digital signature, encoded in base64 per [RFC4648]. The signature is calculated over the completely formatted Signature Block message (starting from the first octet of PRI and continuing to the last octet of MSG, or STRUCTURED-DATA if MSG is not present), before the SIGN parameter (SD Parameter Name and the space before it
これは[RFC4648]あたりのBASE64でエンコードされたデジタル署名です。 （MSGが存在しない場合PRIの最初のオクテットから始まるとMSGの最後のオクテットに継続、または構造-DATA）署名はSIGNパラメータ（SDパラメータ名とスペース前に、完全にフォーマットされた署名ブロックメッセージにわたって計算されますその前に
[" SIGN"], "=", and the corresponding value) is added. (In other words, the digital signature is calculated over the whole message, with the "SIGN=value" portion removed.) For the OpenPGP DSA signature scheme, the value of the signature field contains the DSA values r and s, encoded as two multiprecision integers (see [RFC4880], Sections 5.2.2 and 3.2), concatenated, and then encoded in base64 [RFC4648].
[ "SIGN"]、 "="、および対応する値）が加算されます。 （換言すれば、デジタル署名が削除「SIGN =値」の部分と、メッセージ全体にわたって計算される。）のOpenPGP DSA署名方式は、署名フィールドの値は、2つとして符号化、DSA値RおよびSを含有します次いで、多倍精度整数（セクション5.2.2および3.2、[RFC4880]を参照）、連結、およびBASE64でエンコードされた[RFC4648]。
An example of a Signature Block message is depicted below, broken into lines to fit publication rules. There is a space at the end of each line, with the exception of the last line, which ends with "]".
署名ブロックメッセージの例は、パブリケーションルールに適合するように行に分割、以下に示されています。 「]」で終わる最後の行を除いて、それぞれの行の末尾にスペースがあります。
<110>1 2009-05-03T14:00:39.529966+02:00 host.example.org syslogd 2138 - [ssign VER="0111" RSID="1" SG="0" SPRI="0" GBC="2" FMN="1" CNT="7" HB="K6wzcombEvKJ+UTMcn9bPryAeaU= zrkDcIeaDluypaPCY8WWzwHpPok= zgrWOdpx16ADc7UmckyIFY53icE= XfopJ+S8/hODapiBBCgVQaLqBKg= J67gKMFl/OauTC20ibbydwIlJC8= M5GziVgB6KPY3ERU1HXdSi2vtdw= Wxd/lU7uG/ipEYT9xeqnsfohyH0=" SIGN="AKBbX4J7QkrwuwdbV7Taujk2lvOf8gCgC62We1QYfnrNHz7FzAvdySuMyfM="]
<110> 1 2009-05-03T14：00：39.529966 + 02：00 host.example.orgは2138 syslogdを - [SSIGN VER = "0111" RSID = "1" SG = "0" SPRI = "0" GBC =」 2" FMN = "1" CNT = "7" HB = "K6wzcombEvKJ + UTMcn9bPryAeaU = zrkDcIeaDluypaPCY8WWzwHpPok = zgrWOdpx16ADc7UmckyIFY53icE = XfopJ + S8 / hODapiBBCgVQaLqBKg = J67gKMFl / OauTC20ibbydwIlJC8 = M5GziVgB6KPY3ERU1HXdSi2vtdw = Wxd / lU7uG / ipEYT9xeqnsfohyH0 =" SIGN = "AKBbX4J7QkrwuwdbV7Taujk2lvOf8gCgC62We1QYfnrNHz7FzAvdySuMyfM ="]
The message is of syslog-sign protocol version "01". It uses SHA1 as hash algorithm and an OpenPGP DSA signature scheme. Its reboot session ID is 1. Its Signature Group is 0, which means that all syslog messages go to the same destination; its Signature Priority (which can effectively be ignored because all syslog messages will be signed regardless of their PRI value) is 0. Its Global Block Counter is 2. The first message number is 1; the message contains 7 message hashes.
メッセージは、syslog-サインプロトコルバージョン「01」です。これは、ハッシュアルゴリズムとOpenPGPのDSA署名方式としてSHA1を使用します。その再起動セッションIDは、その署名のグループは、すべてのsyslogメッセージは、同じ目的地に行くことを意味し、0 1です。 （すべてのsyslogメッセージに関係なく、それらのPRI値の署名されるので、効果的に無視することができる）、その署名優先度0のグローバルブロックカウンタは、最初のメッセージの数が1である2です。メッセージは、7つのメッセージのハッシュが含まれています。
Certificate Blocks and Payload Blocks provide key management for syslog-sign. Their purpose is to support key management that uses public key cryptosystems.
証明書ブロックとペイロードブロックは、syslog-記号のための鍵管理を提供します。彼らの目的は、公開鍵暗号方式を使用してキー管理をサポートすることです。
A Payload Block contains public-key-certificate information that is to be conveyed to the collector. A Payload Block is sent at the beginning of a new reboot session, carrying public key information in effect for the reboot session. However, a Payload Block is not sent directly, but in (one or more) fragments. Those fragments are termed Certificate Blocks. Therefore, signers send at least one Certificate Block at the beginning of a new reboot session.
ペイロードブロックは、コレクタに搬送される公開鍵証明書情報を含みます。ペイロードブロックは、再起動のセッションで有効に公開鍵情報を運ぶ、新しいリブートセッションの開始時に送信されます。しかし、ペイロードブロックは、しかし、（1以上）の断片に直接送信されません。これらの断片は、証明書のブロックと呼ばれます。そのため、署名者は、新たな再起動セッションの開始時に少なくとも一つの証明書ブロックを送信します。
There are three key points to understand about Certificate Blocks:
証明書ブロックについて理解するには、3つの重要なポイントがあります。
a. They handle a variable-sized payload, fragmenting it if necessary and transmitting the fragments as legal syslog messages. This payload is built (as described below) at the beginning of a reboot session and is transmitted in pieces with each Certificate Block carrying a piece. There is exactly one Payload Block per reboot session.
A。彼らは、必要であれば、それを断片化し、法律上のsyslogメッセージの断片を送信する、可変サイズのペイロードを処理します。このペイロードは、（後述のように）再起動セッションの開始時に構築され、各証明書ブロック片を担持するとバラバラに送信されます。再起動のセッションごとに1つのペイロードブロックがあります。
b. The Certificate Blocks are digitally signed. The signer does not sign the Payload Block, but the signatures on the Certificate Blocks ensure its authenticity. Note that it may not even be possible to verify the signature on the Certificate Blocks without the information in the Payload Block; in this case, the Payload Block is reconstructed, the key is extracted, and then the Certificate Blocks are verified. (This is necessary even when the Payload Block carries a certificate, because some other fields of the Payload Block are not otherwise verified.) In practice, most installations keep the same public key over long periods of time, so that most of the time, it is easy to verify the signatures on the Certificate Blocks, and use the Payload Block to provide other useful per-session information.
B。証明書ブロックはデジタル署名されています。署名者は、ペイロードブロックに署名しませんが、証明書ブロックの署名は、その信憑性を保証します。それもペイロードブロック内の情報なしで証明書ブロックに署名を検証することは可能ではないかもしれないことに留意されたいです。この場合、ペイロードブロックは、キーが抽出され、再構成され、そしてその後、証明書ブロックが検証されます。 （これは、ペイロードブロックのいくつかの他のフィールドは、そうでない場合は検証されませんので、ペイロードブロックは、証明書を運ぶ場合にも必要です。）実際にはほとんどの時間ように、ほとんどのインストールは、長期間にわたって同じ公開鍵を保持し、証明書のブロックに署名を検証し、その他の有用なセッションごとの情報を提供するために、ペイロードブロックを使用するのは簡単です。
c. The kind of Payload Block that is expected is determined by what kind of key material is on the collector that receives it. The signer and collector (or offline log viewer) both have some key material (such as a root public key or pre-distributed public key) and an acceptable value for the Key Blob Type in the Payload Block, below. The collector or offline log viewer MUST NOT accept a Payload Block of the wrong type.
C。主要材料の種類によって決定されると予想されるペイロードブロックの種類は、それを受けコレクタにあります。署名者及びコレクタ（またはオフラインログビューア）の両方が以下（例えば、ルート公開鍵または事前配布公開鍵のような）いくつかの重要な材料とペイロードブロック内鍵blobを入力するための許容値を有します。コレクタまたはオフラインログビューアは、間違ったタイプのペイロードのブロックを受け入れてはいけません。
The Payload Block is built when a new reboot session is started. There is a one-to-one correspondence between reboot sessions and Payload Blocks. A signer creates a new Payload Block after each reboot. The Payload Block is used until the next reboot.
新しいリブートセッションが開始されると、ペイロードブロックが構築されています。リブートセッションとペイロードブロックの間に1対1で対応しています。署名者は、各再起動後に新しいペイロードブロックを作成します。ペイロードブロックは、次の再起動まで使用されています。
A Payload Block MUST have the following fields:
ペイロードブロックは、次のフィールドを持っている必要があります。
a. Full local timestamp for the signer at the time the reboot session started. This must be in the timestamp format specified in [RFC5424] (essentially, timestamp format per [RFC3339] with some further restrictions).
A。再起動セッションが開始時点での署名者のための完全なローカルタイムスタンプ。これは[RFC5424]で指定されたタイムスタンプ形式である必要があり（本質的に、いくつかのさらなる制限が[RFC3339]あたりのタイムスタンプ形式）。
b. Key Blob Type, a one-octet field containing one of five values:
B。キーBLOB型、5つの値の1つを含む1オクテットフィールド：
2. 'P' -- an OpenPGP KeyID and OpenPGP certificate (a Transferable Public Key as defined in [RFC4880], Section 11.1). The first 8 octets of the key blob field contain the OpenPGP KeyID (identifying which key or subkey inside the OpenPGP certificate is used), followed by the OpenPGP certificate itself.
2. 'P' - （[RFC4880]で定義されるように譲渡公開鍵、セクション11.1）のOpenPGP KeyIDをとOpenPGPの証明書。鍵ブロブフィールドの最初の8つのオクテットのOpenPGP証明書自体に続いて、（使用されるのOpenPGP証明書内のどのキーまたはサブキー識別）のOpenPGP鍵IDを含みます。
3. 'K' -- the public key whose corresponding private key is being used to sign these messages. For the OpenPGP DSA signature scheme, the key blob field contains the DSA prime p, DSA group order q, DSA group generator g, and DSA public-key value y, encoded as 4 multiprecision integers (see [RFC4880], Sections 5.5.2 and 3.2).
3.「K」 - その対応する秘密鍵これらのメッセージに署名するために使用されている公開鍵。 OpenPGPのDSA署名方式のため、鍵BLOBフィールドは4つの多倍精度整数（[RFC4880]を参照して、セクション5.5.2として符号化DSA素数pを、DSAグループ次数q、DSAグループジェネレータg、およびDSA公開鍵の値yを、含まおよび3.2）。
c. The key blob, if any, base64 encoded per [RFC4648] and consisting of the raw key data.
C。鍵blobは、もしあれば、base64では[RFC4648]あたりの符号化された生鍵データからなります。
The fields are separated by single space characters. Because a Payload Block is not carried in a syslog message directly, only the corresponding Certificate Blocks, it does not need to be encoded as an SD ELEMENT. The Payload Block does not contain a field that identifies the reboot session; instead, the reboot session can be inferred from the Reboot Session ID parameter of the Certificate Blocks that are used to carry the Payload Block.
フィールドは、単一の空白文字で区切られます。ペイロードブロックは、直接Syslogメッセージにのみ対応する証明書をブロックしておりませんので、SD要素としてエンコードする必要はありません。ペイロードブロックが再起動セッションを識別するフィールドが含まれていません。代わりに、再起動セッションは、ペイロードブロックを運ぶために使用されている証明書ブロックの再起動のセッションIDパラメータから推測することができます。
To ensure that the sender and receiver have at least one common Key Blob Type, for immediate validation of received messages, all implementations MUST support Key Blob Type "C" (PKIX certificate). When a PKIX certificate is used ("C" Key Blob Type), it is the certificate specified in [RFC5280]. Per [RFC5425], syslog messages may be transported over the TLS protocol, even where there is no PKI. If that transport is used, then the device will already have a PKIX certificate, and it MAY use the private key associated with that certificate to sign messages. In the case where there is no PKI, the chain of trust of a PKIX certificate must still be established to meet conventional security requirements. The methods for doing this are described in [RFC5425].
送信者と受信者が少なくとも一つの共通鍵BLOB型を持っていることを保証するために、受信したメッセージの即時検証のために、すべての実装は、キーBLOB型「C」（PKIX証明書）をサポートしなければなりません。 PKIX証明書は（「C」鍵ブロブ・タイプ）が使用される場合、それは[RFC5280]で指定された証明書です。 [RFC5425]あたり、syslogメッセージにはPKIがない場合でも、TLSプロトコルを介して輸送することができます。そのトランスポートを使用する場合、デバイスはすでにPKIX証明書を持って、それがメッセージに署名し、その証明書に関連付けられた秘密鍵を使用するかもしれません。何のPKIが存在しない場合には、PKIX証明書の信頼の連鎖は、依然として従来のセキュリティ要件を満たすために設立されなければなりません。これを行うための方法は、[RFC5425]で説明されています。
When the collector receives a Payload Block, it needs to determine whether the signatures are to be trusted. The following methods are in scope of this specification:
コレクタは、ペイロード・ブロックを受信すると、署名が信頼されるべきかどうかを決定する必要があります。次のメソッドは、この仕様の範囲内にあります。
a. X.509 certification path validation: The collector is configured with one or more trust anchors (typically root Certification Authority (CA) certificates), which allow it to verify a binding between the subject name and the public key. Certification path validation is performed as specified in [RFC5280].
A。 X.509認証パスの検証：コレクタは、それが主題名と公開鍵の間の結合を確認することを可能にする1つのまたは複数のトラストアンカー（通常はルート証明機関（CA）証明書）で構成されています。 [RFC5280]で指定されるように認証パスの検証が行われます。
If the HOSTNAME contains a Fully-Qualified Domain Name (FQDN) or
an IP address, it is then compared against the certificate as
described in [RFC5425], Section 5.2. Comparing other forms of
HOSTNAMEs is beyond the scope of this specification.
Collectors SHOULD support this method. Note that due to message size restrictions, syslog-sign sends only the end-entity certificate in the Payload Block. Depending on the PKI deployment, the collector may need to obtain intermediate certificates by other means (for example, from a directory).
コレクターは、このメソッドをサポートする必要があります。メッセージサイズの制限があるため、syslogの記号がペイロードブロックで唯一のエンドエンティティ証明書を送信することに注意してください。 PKIの展開に応じて、コレクタが（例えば、ディレクトリからの）他の手段によって、中間証明書を取得する必要があるかもしれません。
b. X.509 end-entity certificate matching: The collector is configured with information necessary to identify the valid end-entity certificates of its valid peers, and for each peer, the HOSTNAME(s) it is authorized to use.
B。 X.509エンドエンティティ証明書のマッチング：コレクタは、その有効なピアの有効なエンドエンティティ証明書を識別するのに必要な情報で構成され、各ピアのホスト名（複数可）が使用を許可されています。
To ensure interoperability, collectors MUST support fingerprints
of X.509 certificates as described below. Other methods MAY be
supported.
Collectors MUST support Key Blob Type 'C', and configuring the list of valid peers using certificate fingerprints. The fingerprint is calculated and formatted as specified in [RFC5425], Section 4.2.2.
コレクターは、キーのBlobタイプ「C」をサポートし、証明書のフィンガープリントを使用して、有効なピアのリストを設定しなければなりません。 [RFC5425]、セクション4.2.2で指定された指紋が計算され、フォーマットされます。
For each peer, the collector MUST support configuring a list of HOSTNAMEs that this peer is allowed to use either as FQDNs or IP addresses. Other forms of HOSTNAMEs are beyond the scope of this specification.
各ピアについて、コレクタは、このピアがのFQDNまたはIPアドレスのいずれかとして使用することが許可されたホスト名のリストを設定サポートしなければなりません。ホスト名の他の形態は、この仕様の範囲を超えています。
If the locally configured FQDN is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons as specified in Section 7 of [RFC5280]. An exact case-insensitive string match MUST be supported, but the implementation MAY also support wildcards of any type ("*", regular expressions, etc.) in locally configured names.
ローカルに設定FQDNは国際化ドメイン名である場合、適合実装は、[RFC5280]のセクション7で指定されるように比較を行うためのASCIIコンパチブルエンコーディング（ACE）形式に変換しなければなりません。正確な大文字と小文字を区別しない文字列の一致をサポートしなければなりませんが、実装はまた、ローカルに設定された名前のいずれかのタイプ（「*」、正規表現など）のワイルドカードをサポートするかもしれません。
Signer implementations MUST provide a means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism, and MUST make the certificate fingerprint available through a management interface.
署名者実装は鍵ペアおよび証明書が別の機構を介して利用可能でない場合にキーのペアと自己署名証明書を生成するための手段を提供しなければなりません、管理インタフェースを介して証明書のフィンガープリントを利用できるようにしなければなりません。
c. OpenPGP V4 fingerprints: Like X.509 fingerprints, except Key Blob Type 'P' is used, and the fingerprint is calculated as specified in [RFC4880], Section 12.2. When the fingerprint value is displayed or configured, each byte is represented in hexadecimal (using two uppercase ASCII characters), and space is added after every second byte. For example: "0830 2A52 2CD1 D712 6E76 6EEC 32A5 CAE1 03C8 4F6E".
C。 OpenPGP V4指紋：鍵blobタイプ「P」以外同様X.509フィンガープリントが使用され、そして[RFC4880]、セクション12.2で指定された指紋が計算されます。フィンガープリントの値を表示または設定されている場合、各バイトは、（二大文字のASCII文字を使用して）進数で表現され、そしてスペースが毎秒バイトの後に添加されます。例： "0830 2A52 2CD1 D712 6E76 6EEC 32A5 CAE1 03C8 4F6E"。
Signers and collectors MAY support this method.
署名者やコレクターがこのメソッドをサポートするかもしれません。
Other methods, such as "web of trust", are beyond the scope of this document.
そのような「信頼のウェブ」のような他の方法は、このドキュメントの範囲を超えています。
This section describes the format of the Certificate Block and the fields used within the Certificate Block, as well as the syslog messages used to carry Certificate Blocks.
このセクションでは、証明書をブロックし、証明書ブロック内で使用されるフィールドの形式と同様に、証明書ブロックを運ぶために使用されるsyslogメッセージを説明します。
Certificate Blocks are used to get the Payload Block to the collector. As with a Signature Block, each Certificate Block is carried in its own syslog message, called a Certificate Block message. In case separate collectors are associated with different Signature Groups, Certificate Block messages need to be sent to each collector.
証明書のブロックは、コレクタにペイロードブロックを取得するために使用されています。署名ブロックと同様に、各証明書ブロックは、独自のsyslogメッセージで運ばれ、証明書をブロックメッセージと呼ばれます。場合に別コレクタは異なるシグネチャグループに関連付けられている、証明書ブロックメッセージは、各コレクタに送信する必要があります。
Because certificates can legitimately be much longer than 2048 octets, the Payload Block can be split up into several pieces, with each Certificate Block carrying a piece of the Payload Block. Note that the signer MAY make the Certificate Blocks of any legal length (that is, any length that keeps the entire Certificate Block message within 2048 octets) that holds all the required fields. Software that processes Certificate Blocks MUST deal correctly with blocks of any legal length. The length of the fragment of the Payload Block that a Certificate Block carries MUST be at least one octet. The length SHOULD be chosen such that the length of the Certificate Block message does not exceed 2048 octets.
証明書は、合法的に2048オクテットよりもはるかに長くなる可能性があるため、ペイロードブロックは、各証明書のブロックは、ペイロードブロックの作品を運んで、いくつかの部分に分割することができます。署名者は法的な長さの証明書ブロックを行うことができることに注意してください（つまり、2048オクテット内全体の証明書をブロックメッセージを保持し、任意の長さ）、必要なすべてのフィールドを保持しています。証明書ブロックを処理するソフトウェアは、任意の有効な長さのブロックに正しく対処しなければなりません。証明書ブロックは、少なくとも1つのオクテットでなければなりません運ぶペイロードブロックの断片の長さ。長さは、証明書ブロックメッセージの長さが2048オクテットを超えないように選択されるべきです。
A Certificate Block message is identified by the presence of an SD ELEMENT with an SD-ID with the value "ssign-cert". In addition, a Certificate Block message MUST contain valid APP-NAME, PROCID, and MSGID fields to be compliant with syslog protocol. Syslog-sign does not mandate particular values for these fields; however, for consistency, a signer MUST use the same value for APP-NAME, PROCID, and MSGID fields for every Certificate Block message, whichever values are chosen. It MUST also use the same value for its HOSTNAME field. To allow for the possibility of multiple signers per host, the combination of APP-NAME and PROCID MUST be unique for each such originator. If a signer daemon is restarted, it MAY use a new PROCID for what is otherwise the same signer. The combination of APP-NAME and PROCID MUST be the same that is used for Signature Block messages of the same signer; however, a different MSGID MAY be used for Signature Block and Certificate Block messages. It is RECOMMENDED to use 110 as the value for the PRI field, corresponding to facility 13 (log audit) and severity 6 (informational). The Certificate Block is carried as Structured Data within the Certificate Block message. A Certificate Block message MAY carry other Structured Data besides the Structured Data of the Certificate Block itself. The MSG part of a Certificate Block message SHOULD be empty.
証明書ブロックメッセージは、値「SSIGN-CERT」とSD-IDとSD要素の存在によって同定されます。また、証明書をブロックメッセージはsyslogプロトコルに準拠するために有効なAPP-NAME、PROCID、およびMSGIDフィールドを含まなければなりません。 Syslogの記号は、これらのフィールドの特定の値を強制しません。しかし、一貫性のために、署名者は、APP-NAME、PROCID、および値が選択されているいずれかのすべての証明書ブロックメッセージのMSGIDフィールドの同じ値を使用しなければなりません。また、そのHOSTNAMEフィールドに同じ値を使用しなければなりません。ホストごとに複数の署名者の可能性を可能にするために、APP-NAMEとPROCIDの組み合わせは、そのような各発信者に対して一意でなければなりません。署名者デーモンが再起動された場合、それはそうと同じ署名者である何のための新しいPROCIDを使用するかもしれません。 APP-NAMEとPROCIDの組み合わせは、同じ署名者の署名ブロックメッセージに使用されるのと同じでなければなりません。しかし、異なるMSGIDは、署名ブロックおよび証明書ブロックメッセージのために使用されるかもしれません。施設13（監査ログ）および重症度6（情報）に対応し、PRIフィールドの値として110を使用することが推奨されます。証明書ブロックは、証明書をブロックメッセージ内の構造化データとして行われます。証明書をブロックメッセージは、証明書ブロック自体の構造化データに加えて、他の構造化データを搬送することができます。証明書をブロックメッセージのMSG部分は空である必要があります。
The contents of a Certificate Block message is the Certificate Block itself. Like a Signature Block, the Certificate Block is encoded as an SD ELEMENT. The SD-ID of the Certificate Block is "ssign-cert". The Certificate Block is composed of the following fields, each of which is encoded as an SD Parameter with parameter name as indicated. Each field must be printable ASCII, and any binary values are base64 encoded per [RFC4648].
証明書をブロックメッセージの内容は、証明書をブロックそのものです。署名ブロックのように、証明書ブロックはSD要素として符号化されます。証明書ブロックのSD-IDは "SSIGN-CERT" です。証明書ブロックが示されているようにパラメータ名とSDパラメータとしてエンコードされ、それぞれが以下のフィールドから構成されています。各フィールドは、印刷可能なASCII文字でなければならず、任意のバイナリ値は、[RFC4648]あたりbase64エンコードされています。
Field SD-PARAM-NAME Size in octets
----- ------------- ---- -- ------
Version VER 4
バージョンVIEW 4
Reboot Session ID RSID 1-10
セッションID RSID 1-10を再起動します
Signature Group SG 1
署名グループSG 1
Signature Priority SPRI 1-3
コード優先STOP 1-H
Total Payload Block Length TPBL 1-8
総ペイロードブロック長TPBL 1-8
Index into Payload Block INDEX 1-8
ペイロードブロックインデックス1-8内のインデックス
Fragment Length FLEN 1-4
断片長FLEN 1-4
Payload Block Fragment FRAG variable (base64 encoded binary)
ペイロードブロックフラグメントFRAG変数（BASE64符号化されたバイナリ）
Signature SIGN variable (base64 encoded binary)
署名SIGN変数（BASE64符号化されたバイナリ）
The fields MUST be provided in the order listed. New SD parameters MUST NOT be added unless a new Version of the protocol is defined. (Implementations that wish to add proprietary extensions will need to define a separate SD ELEMENT.) A Certificate Block is accordingly encoded as follows, where xxx denotes a placeholder for the particular values:
フィールドがリストされている順に提供しなければなりません。プロトコルの新しいバージョンが定義されていない限り、新しいSDパラメータが追加されてはなりません。 （独自の拡張を追加する実装は別SD要素を定義する必要があります。）次のようにAの証明書ブロックは、それに応じて符号化され、xxxは特定の値のプレースホルダを表します。
[ssign-cert VER="xxx" RSID="xxx" SG="xxx" SPRI="xxx" TPBL="xxx" INDEX="xxx" FLEN="xxx" FRAG="xxx" SIGN="xxx"]
[SSIGN-CERT VER = "XXX" RSID = "XXX" SG = "XXX" SPRI = "XXX" TPBL = "XXX" INDEX = "XXX" FLEN = "XXX" FRAG = "XXX" SIGN = "XXX"]
Values of the fields constitute SD parameter values and are hence enclosed in quotes, per [RFC5424]. The fields are separated by single spaces and are described below. Each SD parameter MUST occur once and only once.
フィールドの値は、SDパラメータ値を構成し、したがって、[RFC5424]あたり、引用符で囲まれています。フィールドは、単一のスペースで分離され、以下に記載されています。各SDパラメータは一度だけ発生する必要があります。
The Version field is 4 octets in length. This field is identical in format and meaning to the Version field described in Section 4.2.1.
バージョンフィールドは、長さが4つのオクテットです。このフィールドは、セクション4.2.1で説明したバージョンフィールドに形式と意味は同じです。
The Reboot Session ID is identical in format and meaning to the RSID field described in Section 4.2.2.
再起動し、セッションIDは、4.2.2項で説明したRSIDフィールドに形式と意味は同じです。
The SIG field is identical in format and meaning to the SIG field described in Section 4.2.3. The SPRI field is identical in format and meaning to the SPRI field described there.
SIGフィールドは、4.2.3項で説明したSIGフィールドに形式と意味は同じです。 SPRIフィールドは、そこに記載SPRIフィールドに形式と意味は同じです。
A signer SHOULD send separate Certificate Block messages for each Signature Group. This ensures that each collector that is associated with a Signature Group will receive the necessary key material in the case that messages of different Signature Groups are sent to different collectors. Note that the signer needs to get the same Payload Block to each collector, as for any given signer there is a one-to-one relationship between Payload Block and Reboot Session across all Signature Groups. Deployments that wish to associate different key material (and hence different Payload Blocks) with different Signature Groups can use separate signers for that purpose, each distinguished by its own combination of HOSTNAME, APP-NAME, and PROCID.
署名者は、各署名のグループに別々の証明書をブロックメッセージを送るべきです。これは、シグネチャ・グループに関連付けられている各コレクタは異なるシグネチャグループのメッセージは、異なるコレクタに送信される場合に必要な鍵材料を受信することを保証します。署名者は、すべてのシグネチャグループ間でペイロードブロックと再起動セッションの間に一対一の関係が存在する任意の署名者と同様に、各コレクタに同じペイロード・ブロックを取得する必要があることに注意してください。異なるシグネチャグループで異なる鍵材料（したがって異なるペイロードブロック）を関連付ける展開は、各ホスト名、APP-NAME、およびPROCIDの独自の組み合わせによって区別、その目的のために別個の署名者を使用することができます。
The Total Payload Block Length is a value representing the total length of the Payload Block in octets, expressed as a decimal with 1 to 8 octets with leading zeroes omitted.
総ペイロードブロック長がオクテットペイロードブロックの合計長さを表す値であり、省略先行ゼロを有する1〜8オクテットと小数として表さ。
This is a decimal value between 1 and 8 octets, with leading zeroes omitted. It contains the number of octets into the Payload Block at which this fragment starts. The first octet of the first fragment is numbered "1". (Note, it is not numbered "0".)
先行ゼロを省略して、これは、1と8オクテットの小数値です。これは、このフラグメントが始まるペイロードブロックにオクテットの数が含まれています。最初のフラグメントの最初のオクテットは、「1」の番号されます。 （それが「0」番されていない、注意してください。）
The total length of this fragment expressed as a decimal integer with 1 to 4 octets with leading zeroes omitted. The fragment length must be at least 1.
この断片の全長は省略先行ゼロを有する1〜4オクテットの10進整数として表さ。断片の長さは、少なくとも1でなければなりません。
The Payload Block Fragment contains a fragment of the payload block. Its length must match the indicated fragment length.
ペイロードブロック断片は、ペイロード・ブロックのフラグメントを含みます。その長さは、指示された断片の長さと一致しなければなりません。
This is a digital signature, encoded in base64, as per [RFC4648]. The Version field effectively specifies the original encoding of the signature. The signature is calculated over the completely formatted
これは[RFC4648]に従って、BASE64でエンコードされ、デジタル署名です。バージョンフィールドは、効果的に、署名の元のエンコーディングを指定します。署名は、完全にフォーマットさにわたって計算されます
Certificate Block message, before the SIGN parameter is added (see Section 4.2.8). For the OpenPGP DSA signature scheme, the value of the signature field contains the DSA values r and s, encoded as 2 multiprecision integers (see [RFC4880], Sections 5.2.2 and 3.2), concatenated, and then encoded in base64 [RFC4648].
SIGNパラメータが追加される前に、証明書ブロックメッセージ、（セクション4.2.8を参照してください）。 OpenPGPのDSA署名方式は、署名フィールドの値が2つの多倍精度整数（セクション5.2.2および3.2、[RFC4880]を参照）、連結、およびBASE64でエンコードされた[RFC4648]としてエンコード、DSAは、RおよびS値含ま。
An example of a Certificate Block message is depicted below, broken into lines to fit publication rules. There are no spaces at the end of the lines that contain the key blob and the signature.
証明書ブロックメッセージの例は、パブリケーションルールに適合するように行に分割、以下に示されています。キーブロブと署名を含む行の末尾のスペースはありません。
<110>1 2009-05-03T14:00:39.519307+02:00 host.example.org syslogd 2138 - [ssign-cert VER="0111" RSID="1" SG="0" SPRI="0" TPBL="587" INDEX="1" FLEN="587" FRAG="2009-05-03T14:00:39.519005+02:00 K BACsLMZ NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD+2hEkt1z cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr AAenBweVMlBgV3ZA5IMA8xq8l+i8wCgkWJjCjfLar7s+0X3HVrRroyARv8EAIYoxofh9m N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry 5X6482fUxbm+gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt/E4dT+Hmod4omECLteLXxtScTM gDXyC+bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv/rEgC ssS9E1qARM+h19KovIUOhl4VzBw3rK7v8Dlw/CJyYDd5kwSvCwjhO21LiReeS90VPYuZF RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg==" SIGN="AKAQEUiQptgpd0lKcXbuggGXH/dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7+c="]
<110> 1 2009-05-03T14：00：39.519307 + 02：00 host.example.orgは2138 syslogdを - [SSIGN-CERT VER = "0111" RSID = "1" SG = "0" SPRI = "0" TPBL = "587" INDEX = "1" FLEN = "587" FRAG = "2009-05-03T14：00：39.519005 + 02：00 K BACsLMZ NCV2NUAwe4RAeAnSQuvv2KS51SnHFAaWJNU2XVDYvW1LjmJgg4vKvQPo3HEOD + 2hEkt1z cXADe03u5pmHoWy5FGiyCbglYxJkUJJrQqlTSS6vID9yhsmEnh07w3pOsxmb4qYo0uWQr AAenBweVMlBgV3ZA5IMA8xq8l + i8wCgkWJjCjfLar7s + 0X3HVrRroyARv8EAIYoxofh9m N8n821BTTuQnz5hp40d6Z3UudKePu2di5Mx3GFelwnV0Qh5mSs0YkuHJg0mcXyUAoeYry 5X6482fUxbm + gOHVmYSDtBmZEB8PTEt8Os8aedWgKEt / E4dT + Hmod4omECLteLXxtScTM gDXyC + bSBMjRRCaeWhHrYYdYBACCWMdTc12hRLJTn8LX99kv1I7qwgieyna8GCJv / REGC ssS9E1qARM + h19KovIUOhl4VzBw3rK7v8Dlw / CJyYDd5kwSvCwjhO21LiReeS90VPYuZF RC1B82Sub152zOqIcAWsgd4myCCiZbWBsuJ8P0gtarFIpleNacCc6OV3i2Rg ==」SIGN = "AKAQEUiQptgpd0lKcXbuggGXH / dCdQCgdysrTBLUlbeGAQ4vwrnLOqSL7 + C ="]
The message is of syslog-sign protocol version "01". It uses SHA1 as hash algorithm and an OpenPGP DSA signature scheme. Its reboot session ID is 1. Its Signature Group is 0; its Signature Priority is 0. The Total Payload Block Length is 587 octets. The index into the payload block is 1 (meaning this is the first fragment). The length of the fragment is 587 (meaning that the Certificate Block message contains the entire Payload Block). The Payload Block has the timestamp 2009-05-03T14:00:39.519005+02:00. The Key Blob Type is 'K', meaning that it contains a public key whose corresponding private key is being used to sign these messages.
メッセージは、syslog-サインプロトコルバージョン「01」です。これは、ハッシュアルゴリズムとOpenPGPのDSA署名方式としてSHA1を使用します。その再起動セッションIDは、その署名のグループが0である1です。総ペイロードブロック長が587個のオクテットで0その署名の優先順位があります。ペイロードブロックにインデックスが1（これが最初のフラグメントであることを意味する）です。断片の長さは587である（証明書ブロックメッセージはペイロード全体のブロックを含むことを意味します）。 00：00：39.519005 + 02ペイロードブロックは、タイムスタンプ2009-05-03T14を持っています。キーのBlob型は、その対応する秘密鍵これらのメッセージに署名するために使用されている公開鍵が含まれていることを意味し、「K」です。
Note that the Certificate Block message in this example has a timestamp that is very close to the timestamp in the Payload Block. The fact that the timestamps are so close implies that this is the first Certificate Block message sent in this reboot session; additional Certificate Block messages can be sent later with a later timestamp, which will carry the same Payload Block that will still contain the same timestamp.
この例では、証明書をブロックメッセージはペイロードブロックのタイムスタンプに非常に近いタイムスタンプを持っていることに注意してください。タイムスタンプがとても接近しているという事実は、これは、この再起動のセッションで送信された最初の証明書をブロックメッセージであることを意味します。追加の証明書をブロックメッセージはまだ同じタイムスタンプが含まれています同じペイロードブロックを運ぶ後にタイムスタンプ、と後で送信することができます。
As described in Section 8.5 of [RFC5424], a transport sender may discard syslog messages. Likewise, when syslog messages are sent over unreliable transport, they can be lost in transit. However, if a collector does not receive Signature and Certificate Blocks, many messages may not be able to be verified. The signer is allowed to send Signature and Certificate Blocks multiple times. Sending Signature and Certificate Blocks multiple times provides redundancy with the intent to ensure that the collector or relay does get the Signature Blocks and in particular the Payload Block at some point in time. In the meantime, any online review of logs as described in Section 7.2 is delayed until the needed blocks are received. The collector MUST ignore duplicates of Signature Blocks and Certificate Blocks that it has already received and authenticated. In principle, the signer can change its redundancy level for any reason, without communicating this fact to the collector.
[RFC5424]のセクション8.5に記載されているように、トランスポート送信者は、syslogメッセージを破棄してもよいです。 syslogメッセージの信頼性の低いトランスポートを介して送信されるとき同様に、彼らは輸送中に紛失することができます。コレクタが署名および証明書ブロックを受信しない場合は、多くのメッセージを確認することができない場合があります。署名者は、署名と証明書のブロックを複数回送信することが許可されています。送信署名と証明書ブロック複数回コレクタまたはリレーがある時点でペイロードブロックの署名ブロックを取得し、特にことを確実にするために意図して冗長性を提供します。一方、7.2節で説明したように、ログのいずれかのオンラインレビューが必要なブロックが受信されるまで延期されます。コレクタは、それが既に受信され認証されたことを署名ブロックおよび証明書ブロックの重複を無視しなければなりません。原則的には、署名者は、コレクタにこの事実を通信せず、何らかの理由でその冗長レベルを変更することができます。
A signer that is also the originator of messages that it signs does not need to queue up other messages while sending redundant Certificate Block and Signature Block messages. It MAY send redundant Certificate Block messages even after Signature Block messages and regular syslog messages have been sent. By the same token, it MAY send redundant Signature Block messages even after newer syslog messages that are signed by a subsequent Signature Block have been sent, or even after a subsequent Signature Block message.
また、それが署名したメッセージの発信元である署名者は冗長な証明書をブロックし、署名ブロックメッセージの送信中に他のメッセージをキューする必要はありません。これは、署名ブロックメッセージと通常のsyslogメッセージが送信された後でさえ冗長な証明書をブロックメッセージを送信することができます。同じトークンによって、それ以降の署名ブロックに署名された新しいsyslogメッセージが送信され、あるいはその後の署名ブロックメッセージの後にされた後も、冗長署名ブロックメッセージを送信することができます。
In addition, the signer has flexibility in how many hashes to include within a Signature Block. It is legitimate for an originator to send short Signature Blocks to allow the collector to verify messages with minimal delay.
また、署名者は、署名ブロック内に含める方法多くのハッシュで柔軟性を有します。発信者は、コレクタが最小遅延でメッセージを確認することを可能にする短いシグネチャーブロックを送信することが正当なものです。
Although the transport sender is not constrained in how it decides to send redundant Signature and Certificate Blocks, or even in whether it decides to send along multiple copies of normal syslog messages, we define some redundancy parameters below that may be useful in controlling redundant transmission from the transport sender to the transport receiver and that may be useful for administrators to configure.
トランスポート送信者が、それは冗長な署名と証明書ブロックを送信することを決定した方法で、あるいはそれは、通常のsyslogメッセージの複数のコピーに沿って送信することを決定するかどうかに拘束されていないが、我々はその下にいくつかの冗長パラメータはからの冗長伝送を制御するのに有用である可能性がある定義します輸送輸送受信機への送信者とそれを構成するには、管理者にとって有用である可能性があります。
Certificate Blocks are always sent at the beginning of a new reboot session. One technique to ensure reliable delivery (see Section 8.5) is to send multiple copies. This can be controlled by a "certInitialRepeat" parameter:
証明書のブロックは常に新しいリブートセッションの開始時に送信されます。信頼性の高い配信を確保するための一つの技術は、（セクション8.5を参照）複数のコピーを送信することです。これは、「certInitialRepeat」パラメータによって制御することができます。
certInitialRepeat = number of times each Certificate Block should be sent before the first message is sent.
certInitialRepeat =最初のメッセージが送信される前に、各証明書ブロックが送信されなければならない回数。
It is also useful to resend Certificate Blocks every now and then for long-lived reboot sessions. This can be controlled by the certResendDelay and certResendCount parameters:
長寿命、再起動セッションの今して、すべての証明書ブロックを再送信することも有用です。これはcertResendDelayとcertResendCountパラメータによって制御することができます。
certResendDelay = maximum time delay in seconds until resending the Certificate Block.
証明書ブロックを再送信するまでの秒でcertResendDelay =最大時間遅延。
certResendCount = maximum number of other syslog messages to send until resending the Certificate Block.
certResendCount =証明書ブロックを再送信するまで送信するために、他のsyslogメッセージの最大数。
In some cases, it may be desirable to allow for configuration of the transport sender such that Certificate Blocks are not sent at all after the first normal syslog message has been sent. This could be expressed by setting both certResendDelay and certResendCount to "0". However, configuring the transport sender to send redundant Certificate Blocks even after the first message, in particular when the UDP transport [RFC5426] is used, is RECOMMENDED.
いくつかのケースでは、最初に通常のsyslogメッセージが送信された後、証明書のブロックが全く送信されないようなトランスポート送信者の設定を可能にすることが望ましい場合があります。これが「0」にcertResendDelayとcertResendCountの両方を設定することで表現することができます。しかし、UDPトランスポート[RFC5426]を使用する場合、特に、も最初のメッセージの後の冗長証明書ブロックを送信するためにトランスポート送信機を構成する、推奨されています。
In one set of circumstances, the receiver may receive a Certificate Block, some group of syslog messages, and some corresponding Signature Blocks. If the receiver reboots after that, then the conditions of recovery will vary depending upon the transport. For UDP [RFC5426], the receiver SHOULD continue to use the cached Certificate Block, but MUST validate the RSID value to make sure that it has the most current one. If the receiver cannot validate that it has the most current Certificate Block, then it MUST wait for a retransmission of the Certificate Block, which may be controlled by the certResendDelay and certResendCount parameters. It is up to the operators to ensure that Certificate Blocks are sent frequently enough to meet this set of circumstances.
状況の一組では、受信機は、証明書ブロック、syslogメッセージのいくつかのグループ、およびいくつかの対応する署名ブロックを受信することができます。受信機はその後に再起動した場合は、回復の条件は、輸送に応じて変化するであろう。 UDP [RFC5426]のために、受信機は、キャッシュされた証明書ブロックを使用し続けなければならないが、それは最新のものを持っていることを確認するために、RSIDの値を検証する必要があります。受信機は、それが最新の証明書のブロックを持っていることを検証することができないなら、それはcertResendDelayとcertResendCountパラメータによって制御することができる証明書ブロックの再送信を待機しなければなりません。これは、証明書ブロックは状況のこのセットを満たすのに十分な頻度で送信されることを保証するために、事業者に任されています。
For TLS transport [RFC5425], the sender MUST send a fresh Certificate Block when a session is established. This will keep the sender and receiver synchronized with the most current Certificate Block.
セッションが確立されると、TLS輸送[RFC5425]のために、送信者は新鮮な証明書ブロックを送らなければなりません。これは、最新の証明書ブロックと同期して、送信者と受信者を維持します。
Implementations that support sending syslog messages of different Signature Groups to different collectors and which wish to offer very granular controls MAY allow the above parameters to be configured on a per Signature Group basis.
別のコレクタに異なるシグネチャグループのsyslogメッセージの送信をサポートし、実装は、上記のパラメータは、署名ごとにグループごとに設定されることを可能にする非常に粒状のコントロールを提供したいです。
The choice of reasonable values in a given deployment depends on several factors, including the acceptable delay that may be incurred from the receipt of a syslog message until the corresponding Signature Block is received, whether UDP or TLS transport is used, and the available management bandwidth. The following might be a reasonable choice for a deployment in which reliability of underlying transport and of collector implementation are of little concern:
所与の配備に妥当な値の選択は、UDPまたはTLSトランスポートが使用されているかどうか、対応する署名ブロックが受信されるまで、シスログメッセージの受信から発生することができる許容される遅延を含むいくつかの要因に依存し、使用可能な管理帯域幅。以下は基本的な輸送のとコレクタの実装の信頼性がやや懸念された展開のための合理的な選択かもしれません。
certInitialRepeat=1, certResendDelay=1800 seconds, certResendCount=10000
certInitialRepeat = 1、certResendDelay = 1800秒、certResendCount = 10000
The following might be a reasonable choice for a deployment in which reliability of transmission over UDP transport could be an issue:
以下は、UDPトランスポート上の伝送の信頼性が問題になる可能性がある中で、展開のための合理的な選択かもしれません。
certInitialRepeat=2, certResendDelay=300 seconds, certResendCount=1000
certInitialRepeat = 2、certResendDelay = 300秒、certResendCount = 1000
Verification of log messages involves a certain delay of time that is caused by the lag in time between the sending of the message itself and the corresponding Signature Block. The following configuration parameter can be useful to limit the time lag that will be incurred (note that the maximum message length may also force generating a Signature Block; see Sections 4.2.6 and 4.2.7):
ログメッセージの検証は、メッセージ自体と対応する署名ブロックの送信の間の時間の遅れに起因する一定の遅延を含みます。次の構成パラメータは、（メッセージの最大長はまた、署名ブロックを生成強制できることに注意し、セクション4.2.6および4.2.7を参照）に発生するタイムラグを制限するのに有用であり得ます。
sigMaxDelay = generate a new Signature Block if this many seconds have elapsed since the message with the First Message Number of the Signature Block was sent.
この秒数は、ブロックが送信された署名の最初のメッセージ番号のメッセージから経過した場合sigMaxDelay =新しい署名ブロックを生成します。
Retransmissions of Signature Blocks are not sent immediately after the original transmission, but slightly later. The following parameters control when those retransmissions are done:
署名ブロックの再送信がやや後、元の送信直後に送信され、しかしされません。これらの再送信が行われたときに、以下のパラメータを制御します：
sigNumberResends = number of times a Signature Block is resent. (It is recommended to select a value of greater than "0" in particular when the UDP transport [RFC5426] is used.)
sigNumberResends =回数ブロックが再送信される署名。 （UDPトランスポート[RFC5426]が使用される場合には、特に「0」より大きい値を選択することをお勧めします。）
sigResendDelay = send the next retransmission when this many seconds have elapsed since the previous sending of this Signature Block.
この秒数は、前のこの署名ブロックの送信から経過したときsigResendDelay =次の再送信を送ります。
sigResendCount = send the next retransmission when this many other syslog messages have been sent since the previous sending of this Signature Block.
この他の多くのsyslogメッセージは、以前、この署名ブロックの送信以来送信されてきたときsigResendCountは=次の再送信を送ります。
The choice of reasonable values in a given deployment depends on several factors, including the acceptable delay that may be incurred from the receipt of a syslog message until the corresponding Signature Block is received so that the syslog message can be verified, the reliability of the underlying transport, and the available management bandwidth. The following might be a reasonable choice for a deployment where reliability of transport and collector are of little concern and where there is a need to have syslog messages generally signed within 5 minutes:
所与の配備に妥当な値の選択は、対応する署名ブロックが受信されるまで、システムログメッセージを確認することができるように、システムログメッセージの受信から発生することができる許容される遅延、根底の信頼性を含むいくつかの要因に依存します輸送、および使用可能な管理帯域幅。以下は、輸送やコレクターの信頼性がやや懸念されると、一般的に5分以内に署名したSyslogメッセージを持っている必要がある場合、展開のための合理的な選択かもしれません。
sigMaxDelay=300 seconds, sigNumberResends=2, sigResendDelay=300 seconds, sigResendCount=500
sigMaxDelay = 300秒、sigNumberResends = 2、sigResendDelay = 300秒、sigResendCount = 500
The following would be a reasonable choice for a deployment that needs to validate syslog messages typically within 60 seconds, but no more than 3 minutes after receipt:
次は60秒以内に、通常のsyslogメッセージを検証する必要がある展開のための合理的な選択であるが、せいぜい3分のレシートの後になります。
sigMaxDelay=30 seconds, sigNumberResends=5, sigResendDelay=30 seconds, sigResendCount=100
sigMaxDelay = 30秒、sigNumberResends = 5、sigResendDelay = 30秒、sigResendCount = 100
Notwithstanding the fact that the signer is not constrained in whether it decides to send redundant Signature Block messages, Signature Blocks SHOULD NOT overlap. This facilitates their processing by the receiving collector. This means that an originator of Signature Block messages, after having sent a first message with some First Message Number and a Count, SHOULD NOT send a second message with the same First Message Number but a different Count. It also means that an originator of Signature Block messages SHOULD NOT send a second message whose First Message Number is greater than the First Message Number, but smaller than the First Message Number plus the Count indicated in the first message.
署名者は、それが冗長署名ブロックメッセージを送信することを決定したかどうかに拘束されていないという事実にもかかわらず、署名ブロックは重複しないようにしてください。これは、受信コレクタによってそれらの処理を容易にします。これは、署名ブロックメッセージの発信元は、いくつかの最初のメッセージ数とカウントして最初のメッセージを送信した後、同じ最初のメッセージ数が異なるカウントして第2のメッセージを送ってはならないことを意味します。また、署名ブロックメッセージの発信者がその最初のメッセージ番号の最初のメッセージ数よりも大きいが、第一のメッセージ数と、最初のメッセージに示されている数よりも小さい第2のメッセージを送信しないことを意味します。
That said, the possibility of Signature Blocks that overlap does provide additional flexibility with regard to redundancy; it provides an additional option that may be desirable in some deployments. Therefore, collectors MUST be designed in a way that they can cope with overlapping Signature Blocks when confronted with them. The collector MUST ignore hashes of messages that it has already received and validated.
すなわち、重複署名ブロックの可能性は、冗長性に関してさらなる柔軟性を提供し、前記しました。それはいくつかの展開でことが望ましいかもしれない追加のオプションを提供します。そのため、コレクタは彼らがそれらに直面したとき署名ブロックの重複に対応できるように設計されなければなりません。コレクターは、それが既に受信して検証したメッセージのハッシュを無視しなければなりません。
The logs secured with syslog-sign may be reviewed either online or offline. Online review is somewhat more complicated and computationally expensive, but not prohibitively so. This section outlines a method for online and a method for offline verification of logs that implementations MAY choose to implement to verify logs efficiently. Implementations MAY also choose to implement a different method; it is ultimately up to each implementation how to process the messages that it receives.
syslogの記号で固定ログは、オンラインまたはオフラインで検討することができます。オンラインレビューは、やや複雑で計算上高価ですが、法外そうではありません。このセクションでは、オンラインのための方法および実装は効率的にログを確認するために実装することを選ぶかもしれログのオフライン検証のための方法を概説します。また、実装は異なる方法を実装することを選ぶかもしれ。それが最終的にどのように受信したメッセージを処理するには、各実装に任されています。
When the collector stores logs to be reviewed later, they can be authenticated offline just before they are reviewed. Reviewing these logs offline is simple and relatively inexpensive in terms of resources used, so long as there is enough space available on the reviewing machine.
コレクタ店は、後に検討するためにログインするときに、彼らが検討される直前にオフラインで認証することができます。これらのログをオフラインで確認することは限り審査マシンで使用可能な十分なスペースがあるとして、使用リソースの面でシンプルかつ比較的安価です。
To do so, we first go through the stored log file. Each message in the log file is classified as a normal message, a Signature Block message, or a Certificate Block message. Signature Blocks and Certificate Blocks are then separated by signer (as identified by HOSTNAME, APP-NAME, PROCID), Reboot Session ID, and Signature Group, and stored in their own files. Normal messages are stored in a keyed file, indexed on their hash values. They are not separated by signer, as their (HOSTNAME, APP-NAME, PROCID) identifies the application that generated the message. The application that generated the message does not have to coincide with the signer.
そうするために、我々は最初に保存されたログファイルを経ます。ログファイル内の各メッセージは通常のメッセージ、署名ブロックメッセージ、または証明書ブロックメッセージとして分類されます。署名ブロックおよび証明書ブロックは、その後、再起動し、セッションID、および署名のグループ（HOSTNAME、APP-NAME、PROCIDによって識別される）署名者によって分離し、自分のファイルに格納されています。通常のメッセージは、そのハッシュ値にインデックスを付け、キー付きファイルに保存されます。彼らは、それらの（ホスト名、APP-NAME、PROCID）としてメッセージを生成したアプリケーションを識別し、署名者によって分離されていません。メッセージを生成したアプリケーションは、署名者と一致する必要はありません。
For each signer, Reboot Session ID, and Signature Group, we then:
各署名者、再起動し、セッションID、および署名のグループのために、私たち：
a. Sort the Certificate Block file by INDEX value, and check to see whether we have a set of Certificate Blocks that can reconstruct the Payload Block. If so, we reconstruct the Payload Block, verify any key-identifying information, and then use this to verify the signatures on the Certificate Blocks we have received. When this is done, we have verified the reboot session and key used for the rest of the process.
A。 INDEX値によって証明書のブロックファイルをソートし、我々はペイロードブロックを再構築することができます証明書ブロックのセットを持っているかどうかを確認します。もしそうなら、私たちは、ペイロードブロックを再構築し、任意のキー識別情報を検証し、その後、我々が受け取った証明書ブロックに署名を検証するために、これを使用しています。これが行われると、我々は、プロセスの残りのために使用さリブートセッションとキーを確認しました。
b. Sort the Signature Block file by First Message Number. We now create an authenticated log file, which consists of some header information and then a (sequence of message number, message text pairs). We next go through the Signature Block file. We initialize a cursor for the last message number processed with the number 0. For each Signature Block in the file, we do the following:
B。最初のメッセージ番号署名ブロックファイルを並べ替えます。現在、いくつかのヘッダ情報と、次いで（メッセージ番号、メッセージテキスト対の配列）から成る認証ログファイルを作成します。私たちは、次の署名ブロックファイルを経ます。私たちは、次の手順を実行し、ファイル内の各署名ブロックの数は0で処理された最後のメッセージ番号のカーソルを初期化します。
2. If the value of the First Message Number of the Signature Block is less than or equal to the last message number processed, skip the first (last message number processed minus First Message Number plus 1) hashes.
2.署名ブロックの最初のメッセージ数の値が処理された最後のメッセージ数以下である場合、ハッシュ最初（最初のメッセージの数プラス1マイナス処理された最後のメッセージ番号）をスキップします。
a. Look up the hash value in the keyed message file.
A。キー付きメッセージ・ファイル内のハッシュ値を検索します。
b. If the message is found, write (message number, message text) to the authenticated log file.
B。メッセージが見つかった場合、認証されたログファイルに（メッセージ番号、メッセージテキスト）を書き込みます。
4. Set the last message number processed to the value of the First Message Number plus the Count of the Signature Block minus 1.
4.最初のメッセージナンバープラス署名ブロックの数マイナス1の値に処理された最後のメッセージ番号を設定します。
5. Skip all other Signature Blocks with the same First Message Number unless one with a larger Count is encountered.
大きなカウントと1が検出されない限り、5と同じ最初のメッセージ番号を持つ他のすべての署名ブロックをスキップします。
The resulting authenticated log file contains all messages that have been authenticated. In addition, it implicitly indicates all gaps in the authenticated messages (specifically in the case when all messages of the same Signature Group are sent to the same collector), because their message numbers are missing.
結果として認証されたログファイルには、認証されたすべてのメッセージが含まれています。また、それは暗黙的にそのメッセージ番号が欠落しているため、（具体的に同一のシグネチャグループのすべてのメッセージが同一のコレクタに送信される場合）、認証メッセージ内のすべてのギャップを示しています。
One can see that, assuming sufficient space for building the keyed file, this whole process is linear in the number of messages (generally two seeks, one to write and the other to read, per normal message received), and O(N lg N) in the number of Signature Blocks. This estimate comes with two caveats: first, the Signature Blocks arrive very nearly in sorted order, and so can probably be sorted more cheaply on average than O(N lg N) steps. Second, the signature verification on each Signature Block almost certainly is more expensive than the sorting step in practice. We have not discussed error-recovery, which may be necessary for the Certificate Blocks. In practice, a simple error-recovery strategy is probably enough: if the Payload Block is not valid, then we can just try alternate instances of each Certificate Block, if such are available, until we get the Payload Block right.
一つは、キー付きファイルを構築するための十分な空間を想定し、それを見ることができ、この全体のプロセスは、メッセージの数に線形である（通常のメッセージを受信あたり一般に二つが、読み取りに書き込み、他に1を求めて）、およびO（N LG N ）署名ブロックの数です。まず、署名ブロックはソート順に非常に近い到着し、これはおそらくO（N LG N）の工程よりも安価に、平均して選別することができる。この推定は、二つの警告が付属しています。第二に、各署名ブロックに署名検証はほぼ確実に実際にソートするステップよりも高価です。私たちは、証明書をブロックするために必要かもしれエラー回復を、説明していません。実際には、簡単なエラー回復戦略は、おそらく十分です：ペイロードブロックが有効でない場合はそのようなものが用意されていた場合、我々は、ペイロードブロックが権利を取得するまで、私たちはただ、各証明書のブロックの代替インスタンスを試すことができます。
It is easy for an attacker to flood us with plausible-looking messages, Signature Blocks, and Certificate Blocks.
攻撃者はもっともらしい見た目メッセージ、署名ブロック、および証明書ブロックで私たちをあふれさせるのは簡単です。
Some collector implementations may need to monitor log messages in close to real time. This can be done with syslog-sign, though it is somewhat more complex than offline verification. This is done as follows:
一部のコレクターの実装は、リアルタイムに近いにログメッセージを監視する必要があるかもしれません。それはオフラインで検証よりも多少複雑ですがこれは、syslogの記号で行うことができます。これは以下のように行われます。
a. We have an authenticated message file, into which we write (message number, message text) pairs that have been authenticated. We will assume that we are handling only one signer, Signature Group, and Reboot Session ID at any given time. (For the concurrent support of multiple signers, Signature Groups, and Reboot Session IDs, the same procedure is applied analogously to each. Signature Block messages and Certificate
A。我々は、認証されています（メッセージ番号、メッセージテキスト）のペアを作成しその中に、認証されたメッセージファイルを持っています。我々は、任意の時点で唯一の署名者、署名のグループ、および再起動のセッションIDを処理していることを前提としています。 （複数の署名者は、署名グループ、および再起動セッションIDの同時サポートについては、同一の手順がそれぞれ同様に適用される。署名ブロックメッセージ及び証明書の
Block messages clearly indicate their respective signer,
Signature Group, and Reboot Session ID.)
b. We have two data structures: A "Waiting for Signature" queue in which (arrival sequence, hash of message) pairs are kept in sorted order, and a "Waiting for Message" queue in which (message number, hash of message) pairs are kept in sorted order. In addition, we have a hash table that stores (message text, count) pairs indexed by hash value. In the hash table, count may be any number greater than zero; when count is zero, the entry in the hash table is cleared.
B。ペアはソート順に保持されている（到着順、メッセージのハッシュ）に「署名を待っている」キュー、およびペアがである（メッセージ番号、メッセージのハッシュ）に「メッセージを待っている」キュー：我々は2つのデータ構造を持っていますソートされた順序で保管。また、当社は、店舗（メッセージ・テキストは、カウント）というハッシュテーブルのハッシュ値でインデックス化のペアを持っています。ハッシュテーブルでは、カウントがゼロよりも大きい任意の数であってもよいです。カウントがゼロの場合、ハッシュテーブルのエントリがクリアされます。
Note: The "Waiting for Signature" queue gets used in the normal
case, when the signature arrives after the message itself. It
holds messages that have been received but whose signature has
yet to arrive. The "Waiting for Message" queue gets used in the
case that messages are lost or misordered (either in the network
or in relays). It holds signatures that have been received but
whose corresponding messages have yet to arrive. Since a single
Signature Block can cover only a limited number of messages (due
to size restrictions), and massive reordering/delaying is rare,
it is expected that both queues would be relatively small.
c. We must receive all the Certificate Blocks before any other processing can really be done. (This is why they are sent first.) Once that is done, any additional Certificate Block message that arrives is discarded. Any syslog messages or Signature Block messages that arrive before all Certificate Blocks have been received need to be buffered. Once all Certificate Blocks have been received, the messages in the buffer can be retrieved and processed as if they were just arriving.
C。他の処理を実際に行うことができます前に、我々は、すべての証明書ブロックを受けなければなりません。 （それらが最初に送信された理由はここにあります。）これが行われると、到着した任意の追加の証明書をブロックメッセージは破棄されます。任意のsyslogメッセージまたはすべての証明書をブロックする前に到着した署名ブロックメッセージをバッファリングすることの必要性を受けてきました。すべての証明書ブロックが受信されると、バッファ内のメッセージを検索することができ、彼らはちょうど到着したかのように処理されます。
d. Whenever a normal message arrives, we first check if its hash value is found in the "Waiting for Message" queue. If it is, we write the message number (from the "Waiting for Message" queue) and the message into the authenticated message file and remove the entry from the queue.
D。通常のメッセージが到着するたびにそのハッシュ値は、「メッセージを待っている」キューに発見された場合、我々は最初に確認してください。もしそうであれば、我々は、認証されたメッセージファイルに（「メッセージを待っている」キューから）メッセージ番号とメッセージを書き込み、キューからエントリを削除します。
Otherwise, we add (arrival sequence, hash of message) to the
"Waiting for Signature" queue. If our hash table already has an
entry for the message's hash value, we increment its count by
one; otherwise, we create a new entry with Count = 1.
If the "Waiting for Signature" message queue is full, we remove the oldest message from the queue. That message could not be validated close enough to real time. In order to update the hash table accordingly, we use that entry's hash to index the hash table. If that entry has count 1, we delete the entry from the hash table; otherwise, we decrement its count. By removing the message from the "Waiting for Signature" message queue without having actually received the message's signature, we make it impossible to authenticate the message should its signature arrive later. Implementers therefore need to ensure that queues are dimensioned sufficiently large to not expose the collector against Denial-of-Service (DoS) attacks that attempt to flood the collector with unsigned messages.
「署名のために待機中」のメッセージ・キューがいっぱいの場合、我々は、キューから最も古いメッセージを削除します。そのメッセージはリアルタイムに十分近くに検証することができませんでした。それに応じて、ハッシュテーブルを更新するために、我々は、インデックスへのエントリのハッシュハッシュテーブルを使用します。そのエントリが1カウントされている場合、我々はハッシュテーブルからエントリを削除します。そうでない場合は、我々はそのカウントをデクリメントします。メッセージの署名を受け、実際になくても、「署名のために待機中」のメッセージ・キューからメッセージを除去することにより、我々はそれが不可能その署名が後で到着すべきメッセージを認証するために作ります。実装者は、したがって、キューはサービス拒否（DoS）に対してコレクタを公開しないように十分に大きい寸法になっていることを確認する必要があり、符号なしのメッセージとコレクタをフラッディングすること試みを攻撃します。
e. Whenever a Signature Block message arrives, we check its originator, (i.e., the signer) by way of HOSTNAME, APP-NAME, and PROCID, as well as its Signature Group and Reboot Session ID to ensure it matches our Certificate Blocks. We then check to see whether the First Message Number value is too old to still be of interest, or if another Signature Block with that First Message Number and the same Count or a greater Count has already been received. If so, we discard the Signature Block. We then check the signature. Again, we discard the Signature Block if the signature is not valid.
電子。署名ブロックメッセージが到着するたびに、我々はそれが私達の証明書のブロックと一致することを確認するためにHOSTNAME、APP-NAME、およびPROCIDの方法だけでなく、そのシグネチャグループと再起動のセッションIDによって、その創始者、（すなわち、署名者）を確認してください。私たちは、最初のメッセージ数の値は、まだ関心があると古すぎるかどうかを確認し、またはその最初のメッセージの数と同じ回数以上カウントを持つ別の署名ブロックは、既に受信されている場合。もしそうなら、私たちは署名ブロックを捨てます。私たちは、署名を確認してください。署名が有効でない場合は、もう一度、我々は署名ブロックを捨てます。
Otherwise, we proceed with processing the hashes in the Signature
Block. A Signature Block contains a sequence of hashes, each of
which is associated with a message number, starting with the
First Message Number for the first hash and incrementing by one
for each subsequent hash. For each hash, we first check to see
whether the message hash is in the hash table. If this is the
case, it means that we have received the signature for a message
that was received earlier, and we do the following:
1. We check if a message with the same message number is already in the authenticated message file. If that is the case, the signed hash is a duplicate and we discard it.
同じメッセージ番号のメッセージは、認証されたメッセージ・ファイルにすでにある場合1.私たちは、ご確認ください。その場合は、署名したハッシュが重複していると我々はそれを捨てます。
2. Otherwise (the signed hash is not a duplicate), we write the (message number, message text) into the authenticated message file. We also update the hash table accordingly, using that entry's hash to index the hash table. If that entry has Count 1, we delete the entry from the hash table; otherwise, we decrement its count.
2.そうでない場合（署名ハッシュが重複していない）、我々は、認証されたメッセージ・ファイルに（メッセージ番号、メッセージテキスト）を書き込みます。また、インデックスにハッシュテーブルをそのエントリのハッシュを使用して、それに応じてハッシュテーブルを更新します。そのエントリが1カウントされている場合、我々はハッシュテーブルからエントリを削除します。そうでない場合は、我々はそのカウントをデクリメントします。
Otherwise (the message hash is not in the hash table), we write the (message number, message hash) to the "Waiting for Message" queue.
そうでない場合（メッセージハッシュがハッシュテーブルにない）、私たちは、「メッセージを待っている」キューに（メッセージ番号、メッセージのハッシュ）を書き込みます。
If the "Waiting for Message" queue is full, we remove the oldest entry. In that case, a message that was signed by the signer could not be validated by the receiver, either because the message was lost or because the signature arrived way ahead of the actual message. By removing the entry from the "Waiting for Message" queue without having actually received the message, we make it impossible to authenticate the a legitimate message should that message still arrive later. Implementers need to ensure queues are dimensioned sufficiently large so that the chances of such a scenario actually occurring is minimized.
「メッセージを待っている」キューがいっぱいになると、私たちは最も古いエントリを削除します。その場合には、署名者により署名されたメッセージは、受信側で検証することができなかった、いずれかのシグネチャはずっと先実際のメッセージの到着したため、メッセージが失われたりしたためです。実際にメッセージを受信しなくても、「メッセージを待っている」キューからエントリーを除去することにより、我々はそれが不可能認証するために作る正当なメッセージは、そのメッセージはまだ後に到着しなければなりません。実装者は、このようなシナリオが実際に発生する可能性が最小化されるようにキューが十分に大きい寸法にされていることを確認する必要があります。
f. The result of this is a sequence of messages in the authenticated message file. Each message in the message file has been authenticated. The sequence is labeled with numbers showing the order in which the messages were originally transmitted.
F。この結果は、認証されたメッセージ・ファイル内のメッセージの順序です。メッセージ・ファイル内の各メッセージには、認証されています。シーケンスは、メッセージが最初に送信された順序を示す番号で標識されます。
One can see that this whole process is roughly linear in the number of messages, and also in the number of Signature Blocks received. The process is susceptible to flooding attacks; an attacker can send enough normal messages that the messages roll off their queue before their Signature Blocks can be processed.
一つは、このプロセス全体が概ねメッセージの数において線形、また、受信した署名ブロックの数であることを見ることができます。プロセスは、フラッド攻撃を受けやすいです。攻撃者は、自分の署名ブロックが処理される前に、メッセージがそのキューをロールオフに十分な通常のメッセージを送ることができます。
Normal syslog event messages are unsigned and have most of the security attributes described in Section 8 of [RFC5424]. This document also describes Certificate Blocks and Signature Blocks, which are signed syslog messages. The Signature Blocks contain signature information for previously sent syslog event messages. All of this information can be used to authenticate syslog messages and to minimize or obviate many of the security concerns described in [RFC5424].
通常のsyslogイベントメッセージは、符号なしであり、[RFC5424]のセクション8に記載されたセキュリティ属性のほとんどを持っています。また、このドキュメントでは、syslogメッセージに署名している証明書をブロックし、署名ブロックを、説明しています。署名ブロックは、以前に送信されるsyslogイベントメッセージのための署名情報が含まれています。この情報のすべては、syslogメッセージを認証すると、[RFC5424]で説明したセキュリティ上の問題の多くを最小化または回避するために使用することができます。
The model for syslog-sign is a direct trust system where the certificate transferred is its own trust anchor. If a transport sender sends a stream of syslog messages that is signed using a certificate, the operator or application will transfer to the transport receiver the certificate that was used when signing. There is no need for a certificate chain.
syslogのサインのためのモデルは、転送証明書は、独自のトラストアンカーで直接信頼のシステムです。トランスポート送信者が証明書を使用して署名されたsyslogメッセージのストリームを送信する場合、オペレータ又はアプリケーションは、トランスポート受信機に署名する際に使用された証明書を転送します。証明書チェーンのための必要はありません。
As with any technology involving cryptography, it is advisable to check the current literature to determine whether any algorithms used here have been found to be vulnerable to attack.
暗号化を含む任意の技術と同様に、ここで使用される任意のアルゴリズムが攻撃に対して脆弱であることが判明しているかどうかを判断するために、現在の文学をチェックすることをお勧めします。
This specification uses Public Key Cryptography technologies. The proper party or parties have to control the private key portion of a public-private key pair. Any party that controls a private key can sign anything it pleases.
この仕様は、公開鍵暗号技術を使用しています。適切な当事者は、公開鍵と秘密鍵のペアの秘密鍵部分を制御しなければなりません。秘密鍵をコントロール当事者は、それが喜ば何かを署名することができます。
Certain operations in this specification involve the use of random numbers. An appropriate entropy source SHOULD be used to generate these numbers. See [RFC4086] and [NIST800.90].
本明細書における特定の操作は、乱数の使用を含みます。適切なエントロピー源は、これらの数字を生成するために使用されるべきです。 [RFC4086]と[NIST800.90]を参照してください。
As a signer, it is advisable to avoid message lengths exceeding 2048 octets. Various problems might result if a signer were to send messages with a length greater than 2048 octets, because relays MAY truncate messages with lengths greater than 2048 octets, which would make it impossible for collectors to validate a hash of the packet. To increase the chance of interoperability, it tends to be best to be conservative with what you send but liberal in what you are able to receive.
署名者として、2048オクテットを超える長さのメッセージを回避することをお勧めします。署名者は、リレーが、それは不可能コレクターは、パケットのハッシュを検証するために作るでしょう2048オクテットよりも大きい長さを持つメッセージを切り捨てる可能性があるため、2048オクテット以上の長さのメッセージを送信した場合、様々な問題が発生する可能性があります。相互運用性の可能性を高めるために、それはあなたが受け取ることができます何であなたが送る何と保守が、リベラルであることを最善になる傾向があります。
Signers need to rigidly adhere to the RFC 5424 format when sending messages. If a collector receives a message that is not formatted properly, then it might drop it, or it may modify it while receiving it. (See Appendix A.2 of [RFC5424].) If that were to happen, the hash of the sent message would not match the hash of the received message.
署名者は、メッセージを送信するときに厳格にRFC 5424形式に準拠する必要があります。コレクターが適切にフォーマットされていないメッセージを受信した場合、それは、それをドロップする可能性がある、またはそれを受信しながら、それを修正することができます。 （[RFC5424]の付録A.2を参照してください。）それが起こるした場合、送信されたメッセージのハッシュは、受信したメッセージのハッシュが一致しません。
Collectors are not to malfunction in the case that they receive malformed syslog messages or messages containing characters other than those specified in this document. In other words, they are to ignore such messages and continue working.
コレクターは、彼らが、この文書で指定されたもの以外の文字を含む不正な形式のsyslogメッセージまたはメッセージを受信する場合には誤動作することはありません。言い換えれば、彼らはそのようなメッセージを無視して作業を継続することです。
Syslog does not strongly associate the message with the message originator. That association is established by the collector upon verification of the Signature Block. Before a Signature Block is used to ascertain the authenticity of an event message, it might be received, stored, and reviewed by a person or automated parser. It is advisable not to assume a message is authentic until after a message has been validated by checking the contents of the Signature Block.
syslogは強く、メッセージ発信とメッセージを関連付けることはありません。その関連付けは、署名ブロックの検証時にコレクタによって確立されます。署名ブロックは、イベント・メッセージの信憑性を確認するために使用される前に、それは、受信格納され、人や自動化されたパーサによって検討される可能性があります。メッセージの後に署名ブロックの内容を確認することによって検証されるまではメッセージが本物であると仮定しないことをお勧めします。
With the Signature Block checking, an attacker may only forge messages if he or she can compromise the private key of the true originator.
彼または彼女は真の発信者の秘密鍵を損なう可能性があれば署名ブロック・チェックを使用すると、攻撃者はメッセージのみを偽造します。
Event messages might be recorded and replayed by an attacker. Using the information contained in the Signature Blocks, a reviewer can determine whether the received messages are the ones originally sent by an originator. The reviewer can also identify messages that have been replayed. Using a method for the verification of logs such as the one outlined in Section 7, a replayed message can be detected by checking prior to writing a message to the authenticated log file whether the message is already contained in it.
イベントメッセージは、攻撃者によって記録され、再生される場合があります。署名ブロックに含まれる情報を使用して、レビューアは、受信したメッセージが当初発信者によって送信されたものであるかどうかを判定することができます。レビューアはまた、再生されたメッセージを識別することができます。このような第7章に概説一つとしてログの検証のための方法を用いて、再生メッセージは、メッセージが既にその中に含まれているかどうかを認証ログファイルにメッセージを書き込む前にチェックすることによって検出することができます。
Event messages sent over UDP might be lost in transit. [RFC5425] can be used for the reliable delivery of syslog messages; however, it does not protect against loss of syslog messages at the application layer, for example, if the TCP connection or TLS session has been closed by the transport receiver for some reason. A reviewer can identify any messages sent by the originator but not received by the collector by reviewing the Signature Block information. In addition, the information in subsequent Signature Blocks allows a reviewer to determine whether any Signature Block messages were lost in transit.
UDP経由で送信されるイベントメッセージは、輸送中に失われる可能性があります。 [RFC5425]は、syslogメッセージの信頼できる配信のために使用することができます。 TCP接続またはTLSセッションが何らかの理由で、トランスポート受信機によって閉鎖されている場合しかし、それは、例えば、アプリケーション層でのsyslogメッセージの損失を防ぐことはできません。レビューアは署名ブロック情報を確認することにより、コレクタによって受信された任意の発信元から送信されたメッセージではないと識別することができます。また、後続の署名ブロックの情報は、投稿がどの署名ブロックメッセージが転送中に失われたかどうかを決定することを可能にします。
Syslog messages delivered over UDP might not only be lost, but also arrive out of sequence. A reviewer can determine the original order of syslog messages and identify which messages were delivered out of order by examining the information in the Signature Block along with any timestamp information in the message.
UDPを介して配信Syslogメッセージは失われることなく、順序が狂って到着しない場合があります。レビューは、syslogメッセージの元の順序を決定し、メッセージ内の任意のタイムスタンプ情報と共に署名ブロック内の情報を調べることにより、順不同で配信されたメッセージを識別することができます。
Syslog messages might be damaged in transit. A review of the information in the Signature Block determines whether the received message was the intended message sent by the originator. A damaged Signature Block or Certificate Block is evident because the collector will not be able to validate that it was signed by the signer.
Syslogメッセージは、輸送中に破損することがあります。署名ブロック内の情報のレビューは、受信したメッセージが発信者によって送信された意図されたメッセージであったか否かを判断します。コレクタは、それが署名者によって署名されたことを確認することができないので、損傷を受けた署名ブロックまたは証明書ブロックは明白です。
Unless TLS is used as a secure transport [RFC5425], event messages, Certificate Blocks, and Signature Blocks are all sent in plaintext. This allows network administrators to read the message when sniffing the wire. However, this also allows an attacker to see the contents of event messages and perhaps to use that information for malicious purposes.
TLSは、セキュアなトランスポートとして使用されていない限り、[RFC5425]、イベントメッセージ、証明書ブロック、および署名ブロックはすべて平文で送信されます。これは、ワイヤを盗聴する場合、ネットワーク管理者がメッセージを読み取ることができます。しかし、これはまた、イベントメッセージの内容を確認するために、おそらく悪意のある目的のためにその情報を使用する攻撃者がすることができます。
It is conceivable that an attacker might intercept Certificate Block messages and insert its own Certificate information. In that case, the attacker would be able to receive event messages from the actual originator and then relay modified messages, insert new messages, or delete messages. It would then be able to construct a Signature Block and sign it with its own private key. Network administrators need to verify that the key contained in the Payload Block is indeed the key being used on the actual signer. If that is the case, then this MITM attack will not succeed. Methods for establishing a chain of trust are also described in [RFC5425].
攻撃者は、証明書のブロックメッセージを傍受し、独自の証明書情報を挿入する可能性があることが考えられます。その場合、攻撃者は、実際の発信元からのイベントメッセージを受信し、変更されたメッセージを中継し、新しいメッセージを挿入、またはメッセージを削除することができるだろう。その後、署名ブロックを構築し、独自の秘密鍵で署名することができるだろう。ネットワーク管理者は、ペイロードブロックに含まれるキーは、実際の署名者に使用されているキーが確かであることを確認する必要があります。その場合は、このMITM攻撃は成功しません。信頼の連鎖を確立するための方法もまた、[RFC5425]で説明されています。
An attacker might send invalid Signature Block messages to overwhelm the collector's processing capability and consume all available resources. For this reason, it can be appropriate to simply receive the Signature Block messages and process them only as time permits.
攻撃者は、コレクタの処理能力を圧倒し、利用可能なすべてのリソースを消費するために、無効な署名ブロックメッセージを送信することがあります。このような理由から、単に署名ブロックメッセージを受信すると、時間が許す限りだけそれらを処理するために適切なことができます。
An attacker might also just overwhelm a collector by sending more messages to it than it can handle. Implementers are advised to consider features that minimize this threat, such as only accepting syslog messages from known IP addresses.
攻撃者はちょうどそれが処理できるよりも、それに複数のメッセージを送信することにより、コレクタを圧倒することがあります。実装者は、このような知られている唯一のIPアドレスからのsyslogメッセージを受け入れるように、この脅威を最小限に抑える機能を、検討することをお勧めします。
Nothing in this protocol attempts to eliminate covert channels. In fact, just about every aspect of syslog messages lends itself to the conveyance of covert signals. For example, a collusionist could send odd and even PRI values to indicate Morse Code dashes and dots.
このプロトコルでは何も隠れチャネルを排除しようとしません。実際には、syslogメッセージのちょうど約あらゆる面では隠密信号の搬送に適しています。例えば、collusionistは、モールスコードのダッシュやドットを示すために、奇数と偶数のPRI値を送信することができます。
With regard to [RFC5424], IANA has added the following values (with each parameter listed as mandatory) to the registry titled "syslog Structured Data ID Values":
[RFC5424]に関しては、IANAは、「syslogの構造化データID値」というタイトルのレジストリに（必須としてリストされた各パラメータを持つ）は、次の値を追加しました。
Structured Data ID Structured Data Parameter
------------------ -------------------------
ssign
VER
RSID
SG
SPRI
GBC
FMN
CNT
HB
SIGN
ssign-cert VER RSID SG SPRI TPBL INDEX FLEN FRAG SIGN
SSIGN-CC VER CONCEPT SG SPRI TPBL INDEX FLENのFRAGのSIGN
In addition, several fields are controlled by the IANA in both the Signature Block and the Certificate Block, as outlined in the following sections.
以下のセクションで概説されるように加えて、いくつかのフィールドは、署名ブロックおよび証明書ブロックの両方でIANAによって制御されます。
IANA has created three registries, each associated with a different subfield of the Version field of Signature Blocks and Certificate Blocks, described in Sections 4.2.1 and 5.3.2.1, respectively.
IANAは、三のレジストリ、セクションそれぞれ4.2.1および5.3.2.1に記載の署名ブロックおよび証明書ブロックのバージョンフィールドの異なるサブフィールドに関連付けられたそれぞれを作成しました。
The first registry that IANA has created is titled "syslog-sign Protocol Version Values". It is for the values of the Protocol Version subfield. The Protocol Version subfield constitutes the first two octets in the Version field. New values shall be assigned by the IANA using the "IETF Review" policy defined in [RFC5226]. Assigned numbers are to be increased by 1, up to a maximum value of "50". Protocol Version numbers of "51" through "99" are vendor specific; values in this range are not to be assigned by the IANA.
IANAが作成した最初のレジストリは、「syslogの記号プロトコルのバージョン値」と題されています。これは、プロトコルバージョンのサブフィールドの値です。プロトコルバージョンのサブフィールドは、バージョンフィールドの最初の2つのオクテットを構成しています。新しい値は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用してIANAによって割り当てされなければなりません。割り当てられた番号が「50」の最大値まで、1だけ増加されます。 「99」から「51」のプロトコルバージョン番号は、ベンダー固有のものです。この範囲の値は、IANAによって割り当てられてはなりません。
IANA has registered the Protocol Version values shown below.
IANAは、以下に示すプロトコルバージョン値が登録されています。
Value Protocol Version
----- ----------------
00 Reserved
01 Defined in RFC 5848
The second registry that IANA has created is titled "syslog-sign Hash Algorithm Values". It is for the values of the Hash Algorithm subfield. The Hash Algorithm subfield constitutes the third octet in the Version field Signature Blocks and Certificate Blocks. New values shall be assigned by the IANA using the "IETF Review" policy defined in [RFC5226]. Assigned values are to be increased sequentially, first up to a maximum value of "9", then from "a" to "z", then from "A" to "Z". The values are registered relative to the Protocol Version. This means that the same Hash Algorithm value can be reserved for different Protocol Versions, possibly referring to a different hash algorithm each time. This makes it possible to deal with future scenarios in which the single octet representation becomes a limitation, as more Hash Algorithms can be supported by defining additional Protocol Versions that implementations might support concurrently.
IANAが作成した第2レジストリは、「syslogの記号ハッシュアルゴリズムの値」と題されています。これは、ハッシュアルゴリズムのサブフィールドの値です。ハッシュアルゴリズムサブフィールドは、バージョンフィールド署名ブロックおよび証明書ブロックにおける第三のオクテットを構成しています。新しい値は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用してIANAによって割り当てされなければなりません。割り当てられた値は、「A」から「Z」から、「」から「Z」から、次に、最初の「9」の最大値まで順次増加されます。値は、プロトコルバージョンに対して登録されています。これは、同じハッシュアルゴリズム値がおそらく異なるハッシュアルゴリズムに毎回参照すると、異なるプロトコルバージョンのために確保することができることを意味します。これは、より多くのハッシュアルゴリズムは、実装が同時にサポートするかもしれない追加のプロトコルバージョンを定義することによって支持することができるように、単一のオクテット表現は、制限となるような将来のシナリオに対処することができます。
IANA has registered the Hash Algorithm values shown below.
IANAは、以下に示すハッシュアルゴリズム値が登録されています。
Value Protocol Version Hash Algorithm
----- ---------------- --------------
0 01 Reserved
1 01 SHA1
2 01 SHA256
The third registry that IANA has created is titled "syslog-sign Signature Scheme Values". It is for the values of the Signature Scheme subfield. The Signature Scheme subfield constitutes the fourth octet in the Version field of Signature Blocks and Certificate Blocks. New values shall be assigned by the IANA using the "IETF Review" policy defined in [RFC5226]. Assigned values are to be increased by 1, up to a maximum value of "9". This means that the same Signature Scheme value can be reserved for different Protocol Versions, possibly in each case referring to a different Signature Scheme each time. This makes it possible to deal with future scenarios in which the single octet representation becomes a limitation, as more Signature Schemes can be supported by defining additional Protocol Versions that implementations might support concurrently.
IANAが作成した第三レジストリは、「syslogのサイン署名方式の値」と題されています。これは、署名方式のサブフィールドの値です。署名方式のサブフィールドは、署名ブロックおよび証明書ブロックのバージョン]フィールドに4番目のオクテットを構成しています。新しい値は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用してIANAによって割り当てされなければなりません。割り当てられた値は「9」の最大値まで、1だけ増加されます。これは、同じ署名方式の値はおそらく異なる署名方式に毎回参照し、それぞれの場合において、異なるプロトコル・バージョンのために確保することができることを意味します。これは、より多くの署名スキームが実装が同時にサポートするかもしれない追加のプロトコルバージョンを定義することによって支持することができるように、単一のオクテット表現は、制限となるような将来のシナリオに対処することができます。
IANA has registered the Signature Scheme values shown below.
IANAは、以下に示す署名方式値を登録しました。
Value Protocol Version Signature Scheme
----- ---------------- ----------------
0 01 Reserved
1 01 OpenPGP DSA
IANA has created a registry titled "syslog-sign SG Field Values". It is for values of the SG Field as defined in Section 4.2.3. New values shall be assigned by the IANA using the "IETF Review" policy defined in [RFC5226]. Assigned values are to be incremented by 1, up to a maximum value of "7". Values "8" and "9" shall be left as vendor specific and shall not be assigned by the IANA.
IANAは、「syslogの記号SGのフィールド値」というタイトルのレジストリを作成しました。セクション4.2.3で定義されたように、それはSGフィールドの値用です。新しい値は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用してIANAによって割り当てされなければなりません。割り当てられた値は「7」の最大値まで、1ずつインクリメントされます。値「8」と「9」は、特定のベンダーとして残されるものとし、IANAによって割り当てられてはなりません。
IANA has registered the SG Field values shown below.
IANAは、以下に示すSGフィールド値を登録しています。
Value Meaning
----- -------
0 There is only one Signature Group.
1 Each PRI value is associated with its own Signature
Group.
2 Each Signature Group contains a range of PRI
values.
3 Signature Groups are not assigned with any of the
above relationships to PRI values of the syslog
messages they sign.
IANA has created a registry titled "syslog-sign Key Blob Type Values". It is to register one-character identifiers for the Key Blob Type, per Section 5.2. New values shall be assigned by the IANA using the "IETF Review" policy defined in [RFC5226]. Uppercase letters may be assigned as values. Lowercase letters are left as vendor specific and shall not be assigned by the IANA.
IANAは、「syslogの記号キーBLOB型の値」というタイトルのレジストリを作成しました。これは、5.2節ごとに、鍵Blobタイプのための1文字の識別子を登録することです。新しい値は、[RFC5226]で定義された「IETFレビュー」ポリシーを使用してIANAによって割り当てされなければなりません。大文字の値として割り当てられてもよいです。小文字は、特定のベンダーとして残されており、IANAによって割り当てられてはなりません。
IANA has registered the Key Blob Type values shown below.
IANAは、以下に示すキーBLOB型の値を登録しています。
Value Key Blob Type
----- -------------
C a PKIX certificate
P an OpenPGP certificate
K the public key whose corresponding private key is
used to sign the messages
N no key information sent, key is pre-distributed
U installation-specific key exchange information
The authors wish to thank the current Chairs of the Syslog Working Group, David Harrington and Chris Lonvick, and the other members of the Working Group, in particular Alex Brown, Chris Calabrese, Steve Chang, Pasi Eronen, Carson Gaspar, Rainer Gerhards, Drew Gross, Albert Mietus, Darrin New, Marshall Rose, Andrew Ross, Martin Schuette, Holt Sorenson, Rodney Thayer, and the many Counterpane Internet Security engineering and operations people who commented on various versions of this proposal.
著者は、特定のアレックス・ブラウン、クリス・カラブレーゼ、スティーブ・チャン、パシEronen、カーソンガスパル、レイナー・ガーハーズ、ドリューには、Syslogのワーキンググループ、デヴィッド・ハリントンとクリスLonvick、およびワーキンググループの他のメンバーの現在の議長に感謝したいですグロス、アルバートMietus、ダリン新しい、マーシャルローズ、アンドリュー・ロス、マーティンSchuette、ホルトソレンソン、ロドニーセイヤー、この提案のさまざまなバージョンについてコメントし、多くのCounterpane Internet Securityのエンジニアリングおよびオペレーションの人々。
[FIPS.186-2.2000] National Institute of Standards and Technology, "Digital Signature Standard", FIPS PUB 186-2, January 2000, <http://csrc.nist.gov/publications/ fips/archive/fips186-2/fips186-2.pdf>.
[FIPS.186-2.2000]アメリカ国立標準技術研究所、 "デジタル署名標準"、FIPS PUB 186-2の、2000年1月、<http://csrc.nist.gov/publications/ FIPS /アーカイブ/ FIPS186-2 / fips186-2.pdf>。
[FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/publications/ fips/fips180-2/fips180-2.pdf>.
[FIPS.180-2.2002]アメリカ国立標準技術研究所、 "セキュアハッシュ標準"、FIPS PUB 180-2の、2002年8月、<http://csrc.nist.gov/publications/ FIPS / fips180-2 / fips180- 2.pdf>。
[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月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]カラス、J.、Donnerhacke、L.、フィニー、H.、ショー、D.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 4880、2007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards氏、R.、 "syslogプロトコル"、RFC 5424、2009年3月。
[RFC5425] Miao, F., Yuzhi, M., and J. Salowey, "TLS Transport Mapping for syslog", RFC 5425, March 2009.
[RFC5425]ミャオ族、F.、Yuzhi、M.、およびJ. Salowey、 "syslogのためのTLSトランスポート・マッピング"、RFC 5425、2009年3月。
[RFC5426] Okmianski, A., "Transmission of syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426] Okmianski、A.、 "UDP上のsyslogメッセージの送信"、RFC 5426、2009年3月。
[NIST800.90] National Institute of Standards and Technology, "NIST Special Publication 800-90: Recommendation for Random Number Generation using Deterministic Random Bit Generators", June 2006, <http:// csrc.nist.gov/publications/nistpubs/800-90/ SP800-90revised_March2007.pdf>.
[NIST800.90]米国国立標準技術研究所、「は、NIST Special Publication 800-90：乱数生成のための勧告決定的ランダムビットジェネレータを使用して」、2006年6月、<のhttp：// csrc.nist.gov/publications/nistpubs/ 800-90 / SP800-90revised_March2007.pdf>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne、G.とC.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002.
、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Recommendations for Security", RFC 4086, June 2005.
[RFC4086]イーストレイク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
John Kelsey NIST
ジョン・ケルシーNIST
EMail: john.kelsey@nist.gov
メールアドレス：john.kelsey@nist.gov
Jon Callas PGP Corporation
ジョン・カラスPGPコーポレーション
EMail: jon@callas.org
メールアドレス：jon@callas.org
Alexander Clemm Cisco Systems
アレクサンダーClemmシスコシステムズ
EMail: alex@cisco.com
メールアドレス：alex@cisco.com