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
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“系统日志协议”中定义的工作结合使用。
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予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
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
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 sign，它向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
虽然syslog的大多数实现只涉及每条消息的一个发起者和一个收集器，但需要作出规定，以涵盖将消息发送到多个收集器的情况。这尤其涉及来自同一发起者的不同消息被发送到不同收集器的情况，这意味着某些消息被发送到某些收集器，而不是其他收集器。所需的消息区分通常基于单个消息的优先级值执行。例如，来自严重性值为3、2、1或0的任何设施的消息可以发送到一个收集器，而设施4、10、13和14的所有消息可以发送到另一个收集器。适当的系统日志签名消息必须与其适当的系统日志消息一起保存。为了解决这个问题，syslog sign使用了一个签名组。签名组标识一组完全相同的消息
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.
由签字人为签字目的保存在一起。签名块始终只属于一个签名组，并且始终对仅属于该签名组的消息进行签名。
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.)
同一主机可能包含多个签名者，每个签名者使用自己的密钥对系统日志消息进行签名。在这种情况下，每个签名者发送自己的证书块和签名块。此外，每个签名者定义自己的签名组。给定主机上的每个签名者都需要为其签名块和证书块消息使用APP-NAME和PROCID的不同组合。（这意味着主机名、APP-NAME和PROCID的组合可以唯一区分主机间syslog签名消息的发起人，前提是签名人使用唯一的主机名。）
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消息、证书块和签名块，签名过程就可以工作。完成后，流程即告完成。之后，任何人都可以返回，找到关键材料，并使用签名块中的信息验证收到的消息。使用类型为C、P和K的密钥块（见第4.2节）查找密钥材料非常容易，因为公钥位于有效负载块中。如果使用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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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协议。
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 signer和collector实现可能支持长度超过2048个八位字节的消息，但实现者需要知道，发生的任何消息截断都会导致该机制无效。在这种情况下，由操作员确保系统日志消息能够正确接收并进行验证。
[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
[RFC5426]建议使用传输层安全（TLS）传输，并有意限制UDP的使用。不建议将UDP与签名的syslog一起使用，因为其建议的有效负载大小480个八位字节对于syslog签名来说太严格了。480个八位组的签名块只能对9条普通消息进行签名，这意味着大部分消息都是签名块消息。480个八位组的限制主要针对具有重大资源约束的小型嵌入式系统，由于这些约束，这些系统首先无法实现syslog签名。此外，UDP的使用面向主要用于故障排除的syslog消息，这与syslog sign所针对的应用程序用途截然不同。在使用syslog UDP传输的情况下，运营商有责任确保网络路径正确
configured in a way that messages of sufficient length (up to and including 2048 octets) can be properly delivered.
以一种方式进行配置，可以正确传递足够长度的消息（最多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]中描述的系统日志消息格式。与其他领域一样，该文档描述了结构化数据（SD）的概念。结构化数据是根据SD元素（SDE）定义的。SDE由一个名称和一组参数名称-值对组成。SDE名称称为SD-ID。名称-值对称为SD-PARAM或SD参数，名称构成SD-PARAM-name，值构成SD-PARAM-value。
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消息将与签名块和证书块关联的数据作为结构化数据携带。为此，本文档中定义的特殊系统日志消息包括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.
由于本文档中定义的系统日志消息遵循[RFC5424]中所述的格式，因此它们在主机名字段中标识生成系统日志消息的机器。因此，签名块和证书块数据不需要包括任何附加参数来标识发起消息的机器。
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签名消息的发起人，前提是签名者使用唯一的主机名。）签名块消息必须使用相同的主机名、APP-NAME和PROCID组合，和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消息中。包含签名块的系统日志消息也称为签名块消息。
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元素来标识。此外，签名块消息必须包含有效的APP-NAME、PROCID和MSGID字段才能符合[RFC5424]。本规范未规定这些字段的特定值；但是，为了保持一致性，签名者必须为发送的每个签名块消息使用相同的APP-NAME、PROCID和MSGID字段值，以选择的值为准。它的主机名字段也必须使用相同的值。为了允许每个主机有多个签名者，APP-NAME和PROCID的组合对于任何给定主机上的每个此类签名者都必须是唯一的。如果重新启动了签名者守护程序，则它可能会使用新的PROCID作为相同的签名者，但必须继续使用相同的APP-NAME。如果它使用新的PROCID，则必须使用使用相同新PROCID（和相同的应用程序名称）的证书块消息发送新的有效负载块。建议（但不是必需的）使用110作为PRI字段的值，对应于设施13（日志审计）和严重程度6（信息性）。根据下一节中的定义，签名块作为结构化数据携带在签名块消息中。签名块消息可以携带除签名块本身的结构化数据之外的其他结构化数据。签名块消息的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 sign本身的一部分的syslog消息（签名块消息和证书块消息）不得由签名块签名。实现syslog sign的收集器知道如何区分与syslog sign关联的syslog消息和接受签名的syslog消息，并对其进行不同的处理。syslog sign的目的是对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的值必须为“ssign”。
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，并且任何二进制值必须是base64编码的，如[RFC4648]中所定义。
Field SD-PARAM-NAME Size in octets
----- ------------- ---- -- ------
Field SD-PARAM-NAME Size in octets
----- ------------- ---- -- ------
Version VER 4
版本4
Reboot Session ID RSID 1-10
重新启动会话ID RSID 1-10
Signature Group SG 1
签名组sg1
Signature Priority SPRI 1-3
签名优先级SPRI 1-3
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)
签名符号变量（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个八位字节，其中可能包括前导零。前两个八位字节和最后一个八位字节包含范围为“0”到“9”的十进制字符，而第三个八位字节包含范围为“0”到“9”、“a”到“z”或“a”到“z”的字母数字字符。此字段中的值指定syslog签名协议的版本。这是可扩展的，以允许将来使用不同的哈希算法和签名方案。此字段的值是协议版本（2个八位字节）、哈希算法（1个八位字节）和签名方案（1个八位字节）的分组。
Protocol Version - 2 octets, with "01" as the value for the protocol version that is described in this document.
协议版本-2个八位字节，其中“01”作为本文档中描述的协议版本的值。
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".)
哈希算法-1个八位字节，其中，与协议版本01一起，“1”表示SHA1，“2”表示SHA256，如[FIPS.180-2.2002]中所定义。（这是八位字节，其值不仅可以为“0”到“9”，还可以为“a”到“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”表示[RFC4880]和[FIPS.186-2.2000]中定义的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).
因此，本文件中定义的版本、哈希算法和签名方案将分别表示为“0111”（如果SHA1用作哈希算法）和“0121”（如果SHA256用作哈希算法）（不带引号）。
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和99999999之间。必须省略前导零。
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可能会增加1，从值1开始。请注意，在这种情况下，需要签名者在重新启动期间保留以前的重新启动会话ID。另一方面，可以使用Unix时间值（自1970年1月1日起的秒数）。此方法的实现者需要注意在一秒钟内发生多次重新启动的可能性。实现者还需要注意2038年的问题，这将导致Unix时间的32位表示在2038年结束。在另一种方式中，简单网络管理协议（SNMP）引擎和签名者总是同时重启的实现可能考虑使用SNMPDekStudio值作为该计数器的源（如在RCFC1414]中定义的。
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。如果该值不能再增加（例如，因为它达到99999999），则应将其重置为值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（含0-3）之间的任何值。SPRI参数可以采用0-191（含0-191）之间的任何值。这些字段合在一起允许网络管理员将系统日志消息分组与适当的签名块和证书块相关联。一起签名的系统日志消息分组也称为签名组。签名块只包含属于同一签名组的那些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.
例如，在某些情况下，网络管理员可能会让发起者将设施0到15的系统日志消息发送给一个收集器，将设施16到23的系统日志消息发送给另一个收集器。在这种情况下，相关的签名块也应该发送到相应的收集器，分别为每个收集器的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 sign为处理签名组提供了四个选项，将它们与PRI值链接，以便将它们路由到与相应Syslog消息相称的目标。在所有情况下，不允许超过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）字段指示如何解释签名优先级字段。（请注意，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”--只有一个签名组。在这种情况下，管理员希望将所有签名块发送到单个目的地；很有可能，所有系统日志消息也将发送到同一个目的地。签名块包含所有消息的签名，而不考虑其优先级值。这意味着，实际上可以忽略签名块的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
b. “1”--每个PRI值都与其自己的签名组相关联。给定签名组的签名块具有该签名组的SPRI=PRI。换句话说，签名块的SPRI与syslog消息的PRI值匹配，syslog消息是签名组的一部分，因此由签名块签名。例如，当签名者的管理员不知道任何syslog消息最终将去哪里，但预期将分别收集和处理具有不同PRI值的消息时，可以使用SG值1。每个PRI值有一个签名组，这为管理员提供了关于如何划分签名组的很大程度的灵活性
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.
接收到系统日志消息及其签名后的处理，同时允许签名块跟随相应的系统日志消息到达其最终目的地。
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值。签名组按顺序分配。给定签名组的签名块具有自己的SPRI值，表示该签名组中syslog消息的最高PRI值。该签名组中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”--签名组与它们所签名的系统日志消息的PRI值之间没有任何上述关系。相反，使用了另一种方案，这超出了本规范的范围。发起者和预期收集器之间必须有一些预定义的安排，以确定哪些系统日志消息将包含在哪个签名组中，这需要系统管理员进行配置。这还为管理员提供了根据与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在当前签名块之前发送的签名块数。这需要至少1个八位字节，最多10个八位字节显示为十进制计数器。可接受的值介于0和99999999之间，从0开始。必须省略前导零。如果全局块计数器的值已达到99999999，并且重新启动会话ID的值不是0（表示支持重新启动会话ID的持久性），则重新启动会话ID必须增加1，全局块计数器恢复为0。当重新启动会话ID为0（即，不支持持久重新启动会话ID）且全局块计数器达到其最大值时，全局块计数器将重置为0，并且重新启动会话ID必须保持为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.
注意，全局块计数器跨越签名组；它允许在发送两条消息时大致同步，即使它们发送到不同的收集器并且属于不同的签名组。
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个八位字节之间的十进制值，前导零被省略。它包含哈希出现在此块中的第一条消息的此签名组中的唯一消息编号。重新启动会话的第一条消息编号为“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处重新启动。在这种情况下，相同消息编号的两次出现之间的全局块计数器将大不相同。
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。必须选择签名块中包含的哈希数，以使生成的syslog消息的长度不超过允许的最大syslog消息长度。
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编码。散列块中的每个散列都是由散列表示的整个系统日志消息的散列，与底层传输无关。散列按照它们所表示的系统日志消息的出现顺序从左到右排序。空格字符用于分隔散列。注意，散列块构成单个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].
“整个系统日志消息”指的是系统日志消息，不包括[RFC5425]和[RFC5426]中描述的传输部分，也不包括将来传输中可能定义的其他部分。哈希值将是在syslog消息中运行哈希算法的结果，从消息头部分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编码。签名是在完全格式化的签名块消息上计算的（从PRI的第一个八位字节开始，一直到MSG的最后一个八位字节，如果MSG不存在，则是结构化数据），在签名参数（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=value”部分。）对于OpenPGP DSA签名方案，签名字段的值包含DSA值r和s，编码为两个多精度整数（参见[RFC4880]，第5.2.2和3.2节），串联，然后在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 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="]
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”。它使用SHA1作为哈希算法和OpenPGP DSA签名方案。其重新启动会话ID为1。它的签名组为0，这意味着所有syslog消息都指向同一个目标；它的签名优先级（可以有效地忽略，因为所有系统日志消息都将被签名，而不管它们的PRI值如何）为0。其全局块计数器为2。第一消息编号为1；该消息包含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.
有效负载块包含要传送到收集器的公钥证书信息。有效负载块在新的重新启动会话开始时发送，其中包含重新启动会话有效的公钥信息。然而，有效负载块不是直接发送的，而是以（一个或多个）片段的形式发送的。这些片段称为证书块。因此，签名者在新的重新启动会话开始时至少发送一个证书块。
There are three key points to understand about Certificate Blocks:
关于证书块，需要了解三个关键点：
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. 它们处理可变大小的负载，必要时对其进行分段，并将这些分段作为合法的系统日志消息进行传输。此有效负载在重新启动会话开始时构建（如下所述），并在每个证书块携带一个片段的情况下以片段的形式传输。每个重新启动会话只有一个有效负载块。
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.
有效负载块是在启动新的重新启动会话时生成的。重启会话和有效负载块之间存在一对一的对应关系。签名者在每次重新启动后创建一个新的有效负载块。有效负载块将一直使用，直到下次重新启动。
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. Key Blob类型，一个包含五个值之一的八位字段：
1. 'C' -- a PKIX certificate (per [RFC5280]).
1. “C”-PKIX证书（根据[RFC5280]）。
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”-OpenPGP密钥ID和OpenPGP证书（可转让公钥，定义见[RFC4880]第11.1节）。key blob字段的前8个八位字节包含OpenPGP KeyID（标识使用的是OpenPGP证书中的哪个密钥或子密钥），然后是OpenPGP证书本身。
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签名方案，key blob字段包含DSA prime p、DSA组顺序q、DSA组生成器g和DSA公钥值y，编码为4个多精度整数（请参见[RFC4880]，第5.5.2和3.2节）。
4. 'N' -- no key information sent; key is pre-distributed.
4. “N”-未发送关键信息；密钥是预先分发的。
5. 'U' -- installation-specific key exchange information.
5. “U”-特定于安装的密钥交换信息。
c. The key blob, if any, base64 encoded per [RFC4648] and consisting of the raw key data.
c. 密钥blob（如果有）是根据[RFC4648]编码的base64，由原始密钥数据组成。
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元素。有效负载块不包含标识重新启动会话的字段；相反，可以从用于承载有效负载块的证书块的reboot session 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”密钥Blob类型）时，它是[RFC5280]中指定的证书。根据[RFC5425]，系统日志消息可以通过TLS协议传输，即使在没有PKI的情况下也是如此。如果使用该传输，则设备将已经具有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证书路径验证：收集器配置有一个或多个信任锚（通常是根证书颁发机构（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.
如果主机名包含完全限定域名（FQDN）或IP地址，则将其与[RFC5425]第5.2节中所述的证书进行比较。比较其他形式的主机名超出了本规范的范围。
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 sign只发送有效负载块中的结束实体证书。根据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.
为确保互操作性，收集器必须支持X.509证书的指纹，如下所述。可能支持其他方法。
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.
对于每个对等机，收集器必须支持配置允许该对等机用作FQDNs或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
如果本地配置的FQDN是国际化域名，则一致性实现必须将其转换为ASCII兼容编码（ACE）格式，以便按照[RFC5280]第7节的规定进行比较。必须支持完全不区分大小写的字符串匹配，但也可能支持实现
support wildcards of any type ("*", regular expressions, etc.) in locally configured names.
在本地配置的名称中支持任何类型的通配符（“*”、正则表达式等）。
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指纹：与X.509指纹类似，但使用的是密钥Blob类型“P”，并且指纹是按照[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.
本节介绍证书块的格式、证书块中使用的字段，以及用于承载证书块的系统日志消息。
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.
证书块用于向收集器获取有效负载块。与签名块一样，每个证书块都包含在自己的系统日志消息中，称为证书块消息。如果单独的收集器与不同的签名组相关联，则需要向每个收集器发送证书块消息。
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个八位字节内的任何长度）的证书块，以保存所有必需字段。处理证书块的软件必须正确处理任何合法长度的块。证书块承载的有效负载块片段长度必须至少为一个八位字节。长度的选择应确保证书块消息的长度不超过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元素来标识。此外，证书块消息必须包含有效的APP-NAME、PROCID和MSGID字段，以符合syslog协议。Syslog sign不为这些字段指定特定值；但是，为了保持一致性，签名者必须为每个证书阻止消息的APP-NAME、PROCID和MSGID字段使用相同的值，以选择的值为准。它的主机名字段也必须使用相同的值。为了允许每个主机有多个签名者，APP-NAME和PROCID的组合对于每个此类发起人都必须是唯一的。如果重新启动了签名者守护程序，它可能会使用新的PROCID来处理同一个签名者。APP-NAME和PROCID的组合必须与用于同一签名者的签名阻止消息的组合相同；然而，不同的MSGID可用于签名块和证书块消息。建议使用110作为PRI字段的值，对应于设施13（日志审计）和严重程度6（信息性）。证书块作为结构化数据携带在证书块消息中。证书块消息可以携带除证书块本身的结构化数据之外的其他结构化数据。证书块消息的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
----- ------------- ---- -- ------
Field SD-PARAM-NAME Size in octets
----- ------------- ---- -- ------
Version VER 4
版本4
Reboot Session ID RSID 1-10
重新启动会话ID RSID 1-10
Signature Group SG 1
签名组sg1
Signature Priority SPRI 1-3
签名优先级SPRI 1-3
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)
签名符号变量（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元素。）证书块相应地编码如下，其中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个八位字节省略前导零。片段长度必须至少为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].
添加符号参数之前的证书阻止消息（见第4.2.8节）。对于OpenPGP DSA签名方案，签名字段的值包含DSA值r和s，编码为2个多精度整数（请参见[RFC4880]，第5.2.2和3.2节），串联，然后在base64[RFC4648]中编码。
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.
下面描述了证书阻止消息的一个示例，将其分成几行以符合发布规则。在包含密钥blob和签名的行末尾没有空格。
<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 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="]
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”。它使用SHA1作为哈希算法和OpenPGP DSA签名方案。其重新启动会话ID为1。其签名组为0；其签名优先级为0。总有效负载块长度为587个八位字节。有效负载块的索引为1（表示这是第一个片段）。片段的长度为587（意味着证书块消息包含整个有效负载块）。有效负载块的时间戳为2009-05-03T14:00:39.519005+02:00。密钥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节所述，传输发送方可以丢弃系统日志消息。同样，当系统日志消息通过不可靠的传输发送时，它们可能会在传输过程中丢失。但是，如果收集器未接收签名和证书块，则许多消息可能无法验证。允许签名者多次发送签名和证书块。多次发送签名和证书块提供冗余，目的是确保收集器或中继器在某个时间点获得签名块，特别是有效负载块。同时，第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消息之后，或者即使在后续签名块消息之后，它也可以发送冗余签名块消息。
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.
尽管传输发送方在决定如何发送冗余签名和证书块，甚至在决定是否发送多个正常系统日志消息副本时不受限制，我们在下面定义了一些冗余参数，这些参数可能有助于控制从传输发送方到传输接收方的冗余传输，也可能有助于管理员进行配置。
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节）是发送多份副本。这可由“CertificationRepeat”参数控制：
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=在重新发送证书块之前要发送的其他系统日志消息的最大数量。
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消息之后根本不发送证书块。这可以通过将certResendDelay和certResendCount都设置为“0”来表示。但是，建议将传输发送器配置为即使在第一条消息之后也发送冗余证书块，特别是在使用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.
在一组情况下，接收器可以接收证书块、一些系统日志消息组和一些相应的签名块。如果接收器在此之后重新启动，则恢复的条件将根据传输的不同而有所不同。对于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
给定部署中合理值的选择取决于几个因素，包括从接收syslog消息到接收到相应签名块可能产生的可接受延迟、是否使用UDP或TLS传输以及可用的管理带宽。下面可能是一个例子
reasonable choice for a deployment in which reliability of underlying transport and of collector implementation are of little concern:
对于部署的合理选择，基本传输和收集器实现的可靠性几乎不受关注：
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.
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
给定部署中合理值的选择取决于多个因素，包括从接收syslog消息到接收到相应的签名块（以便可以验证syslog消息）、基础传输的可靠性可能产生的可接受延迟，以及可用的管理带宽。对于传输和收集器可靠性较高的部署，以下可能是一个合理的选择
are of little concern and where there is a need to have syslog messages generally signed within 5 minutes:
不太重要，并且通常需要在5分钟内对系统日志消息进行签名：
sigMaxDelay=300 seconds, sigNumberResends=2, sigResendDelay=300
seconds, sigResendCount=500
sigMaxDelay=300 seconds, sigNumberResends=2, sigResendDelay=300
seconds, 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秒内验证系统日志消息（通常在收到消息后不超过3分钟）的部署，以下是合理的选择：
sigMaxDelay=30 seconds, sigNumberResends=5, sigResendDelay=30
seconds, sigResendCount=100
sigMaxDelay=30 seconds, sigNumberResends=5, sigResendDelay=30
seconds, 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.
尽管签名者在决定是否发送冗余签名块消息时不受限制，但签名块不应重叠。这便于接收采集器对其进行处理。这意味着，签名阻止消息的发起人在发送了具有某些第一消息编号和计数的第一消息后，不应发送具有相同第一消息编号但具有不同计数的第二消息。这还意味着签名阻止消息的发起人不应发送第二条消息，其第一条消息编号大于第一条消息编号，但小于第一条消息编号加上第一条消息中指示的计数。
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 sign保护的日志可以在线或离线查看。在线评论有点复杂，计算成本也很高，但并不令人望而却步。本节概述了一种用于在线和离线验证日志的方法，实现可以选择实现这种方法来有效地验证日志。实现也可以选择实现不同的方法；如何处理接收到的消息最终取决于每个实现。
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.
为此，我们首先检查存储的日志文件。日志文件中的每条消息都被分类为普通消息、签名块消息或证书块消息。签名块和证书块由签名者（由主机名、应用程序名、PROCID标识）、重新启动会话ID和签名组分隔，并存储在各自的文件中。普通消息存储在一个键控文件中，根据其散列值编制索引。它们不由签名者分隔，因为它们的（主机名、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. 按索引值对证书块文件进行排序，并检查是否有一组可以重建有效负载块的证书块。如果是这样，我们将重建有效负载块，验证任何密钥标识信息，然后使用该信息验证我们收到的证书块上的签名。完成此操作后，我们已经验证了用于其余过程的重新启动会话和密钥。
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处理的最后一个消息编号初始化一个游标。对于文件中的每个签名块，我们执行以下操作：
1. Verify the signature on the Signature Block.
1. 验证签名块上的签名。
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）散列。
3. For each remaining hashed message in the Signature Block:
3. 对于签名块中的每个剩余哈希消息：
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.
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.
可以看出，假设有足够的空间来构建密钥文件，整个过程在消息数量上是线性的（通常每个接收到的正常消息有两个寻道，一个用于写入，另一个用于读取），在签名块数量上是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 sign完成，尽管它比离线验证要复杂一些。具体做法如下：
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.)
阻止消息清楚地指示各自的签名者、签名组和重新启动会话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. 我们有两种数据结构：一种是“等待签名”队列，其中（到达序列、消息散列）对按排序顺序保存；另一种是“等待消息”队列，其中（消息编号、消息散列）对按排序顺序保存。此外，我们还有一个哈希表，它存储按哈希值索引的（消息文本、计数）对。在哈希表中，count可以是大于零的任何数字；当count为零时，哈希表中的条目将被清除。
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. 我们必须先接收所有证书块，然后才能真正执行任何其他处理。（这就是为什么先发送它们。）完成后，将丢弃到达的任何其他证书阻止消息。在接收到所有证书块之前到达的任何系统日志消息或签名块消息都需要缓冲。一旦接收到所有证书块，就可以检索和处理缓冲区中的消息，就像它们刚刚到达一样。
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.
否则，我们将（到达序列、消息散列）添加到“等待签名”队列中。如果我们的哈希表已经有一个消息哈希值的条目，我们将其计数增加一；否则，我们将创建一个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
如果“等待签名”消息队列已满，我们将从队列中删除最旧的消息。该消息无法在足够接近实时的情况下得到验证。为了相应地更新哈希表，我们使用该条目的哈希对哈希表进行索引。如果该条目的计数为1，则从
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.
哈希表；否则，我们将减少其计数。通过在没有实际收到消息签名的情况下从“等待签名”消息队列中删除消息，我们使得在消息签名稍后到达时无法对消息进行身份验证。因此，实现者需要确保队列的尺寸足够大，以避免收集器受到拒绝服务（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.
e. 每当签名块消息到达时，我们都会通过主机名、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.
实际的消息。通过在没有实际收到消息的情况下从“Waiting for Message”队列中删除条目，我们可以在消息稍后到达时对合法消息进行身份验证。实现者需要确保队列的尺寸足够大，以便将实际发生这种情况的可能性降至最低。
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].
正常的系统日志事件消息没有签名，并且具有[RFC5424]第8节中描述的大多数安全属性。本文档还描述了证书块和签名块，它们是经过签名的系统日志消息。签名块包含以前发送的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 sign的模型是一个直接信任系统，其中传输的证书是它自己的信任锚。如果传输发送方发送使用证书签名的系统日志消息流，则操作员或应用程序将向传输接收方传输签名时使用的证书。不需要证书链。
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 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 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.
系统日志消息可能在传输过程中损坏。对签名块中信息的审查可确定收到的消息是否是发端人发送的预期消息。损坏的签名块或证书块很明显，因为收集器将无法验证它是否由签名者签名。
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地址的SysLogo消息。
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消息的几乎每个方面都有助于传递隐蔽信号。例如，共谋者可以发送奇数和偶数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
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证书版本RSID SG SPRI TPBL索引FLEN FRAG标志
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签名协议版本值”。用于协议版本子字段的值。协议版本子字段构成版本字段中的前两个八位字节。IANA应使用[RFC5226]中定义的“IETF审查”政策分配新值。分配的编号将增加1，最大值为“50”。“51”至“99”的协议版本号是特定于供应商的；IANA不分配此范围内的值。
IANA has registered the Protocol Version values shown below.
IANA已注册协议版本值，如下所示。
Value Protocol Version
----- ----------------
00 Reserved
01 Defined in RFC 5848
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创建的第二个注册表名为“syslog符号哈希算法值”。它用于哈希算法子字段的值。哈希算法子字段构成版本字段签名块和证书块中的第三个八位字节。IANA应使用[RFC5226]中定义的“IETF审查”政策分配新值。分配值应按顺序增加，首先增加到最大值“9”，然后从“a”增加到“z”，然后从“a”增加到“z”。这些值是相对于协议版本注册的。这意味着可以为不同的协议版本保留相同的哈希算法值，每次可能引用不同的哈希算法。这使得我们有可能处理未来的场景，在这种场景中，单八位组表示成为一种限制，因为通过定义实现可能同时支持的其他协议版本，可以支持更多的散列算法。
IANA has registered the Hash Algorithm values shown below.
IANA已注册如下所示的哈希算法值。
Value Protocol Version Hash Algorithm
----- ---------------- --------------
0 01 Reserved
1 01 SHA1
2 01 SHA256
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签名方案值”。它用于签名方案子字段的值。签名方案子字段构成签名块和证书块版本字段中的第四个八位字节。IANA应使用[RFC5226]中定义的“IETF审查”政策分配新值。指定值将增加1，最大值为“9”。这意味着可以为不同的协议版本保留相同的签名方案值，可能在每种情况下每次引用不同的签名方案。这使得我们能够处理未来的场景，在这种场景中，单八位组表示成为一种限制，因为通过定义实现可能同时支持的其他协议版本，可以支持更多的签名方案。
IANA has registered the Signature Scheme values shown below.
IANA已注册如下所示的签名方案值。
Value Protocol Version Signature Scheme
----- ---------------- ----------------
0 01 Reserved
1 01 OpenPGP DSA
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 sign SG Field Values”的注册表。它适用于第4.2.3节中定义的SG字段值。IANA应使用[RFC5226]中定义的“IETF审查”政策分配新值。分配的值将增加1，最大值为“7”。值“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.
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 sign Key Blob Type Values”的注册表。根据第5.2节，为密钥Blob类型注册一个字符标识符。IANA应使用[RFC5226]中定义的“IETF审查”政策分配新值。大写字母可以指定为值。小写字母为供应商专用字母，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
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.
作者谨感谢Syslog工作组现任主席David Harrington和Chris Lonvick，以及工作组其他成员，特别是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）和许多反对互联网安全工程和运营的人士对该提案的不同版本发表了评论。
[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-22000年1月<http://csrc.nist.gov/publications/ fips/archive/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-22002年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]Bradner，S.，“RFC中用于表示需求水平的关键词”，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数据编码”，RFC4648，2006年10月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年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]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5424] Gerhards, R., "The syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5425] Miao, F., Yuzhi, M., and J. Salowey, "TLS Transport Mapping for syslog", RFC 5425, March 2009.
[RFC5425]Miao，F.，Yuzhi，M.，和J.Salowey，“系统日志的TLS传输映射”，RFC 54252009年3月。
[RFC5426] Okmianski, A., "Transmission of syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426]Okmianski，A.，“通过UDP传输系统日志消息”，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特别出版物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.Newman，“互联网上的日期和时间：时间戳”，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.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，RFC 34142002年12月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Recommendations for Security", RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全性的随机性建议”，RFC 40862005年6月。
Authors' Addresses
作者地址
John Kelsey NIST
约翰·凯尔西
EMail: john.kelsey@nist.gov
EMail: john.kelsey@nist.gov
Jon Callas PGP Corporation
乔恩卡拉斯PGP公司
EMail: jon@callas.org
EMail: jon@callas.org
Alexander Clemm Cisco Systems
亚历山大克莱姆思科系统公司
EMail: alex@cisco.com
EMail: alex@cisco.com