Network Working Group E. Rescorla
Request for Comments: 2660 RTFM, Inc.
Category: Experimental A. Schiffman
Terisa Systems, Inc.
August 1999
Network Working Group E. Rescorla
Request for Comments: 2660 RTFM, Inc.
Category: Experimental A. Schiffman
Terisa Systems, Inc.
August 1999
The Secure HyperText Transfer Protocol
安全超文本传输协议
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.
本备忘录描述了用于保护使用超文本传输协议（HTTP）发送的消息的语法，HTTP是万维网的基础。安全HTTP（S-HTTP）为事务机密性、真实性/完整性和来源的不可否认性提供独立适用的安全服务。
The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.
该协议通过支持交易双方之间的选项协商，强调在选择密钥管理机制、安全策略和加密算法方面的最大灵活性。
Table of Contents
目录
1. Introduction .................................................. 3
1.1. Summary of Features ......................................... 3
1.2. Changes ..................................................... 4
1.3. Processing Model ............................................ 5
1.4. Modes of Operation .......................................... 6
1.5. Implementation Options ...................................... 7
2. Message Format ................................................ 7
2.1. Notational Conventions ...................................... 8
2.2. The Request Line ............................................ 8
2.3. The Status Line ............................................. 8
2.4. Secure HTTP Header Lines .................................... 8
2.5. Content .....................................................12
2.6. Encapsulation Format Options ................................13
1. Introduction .................................................. 3
1.1. Summary of Features ......................................... 3
1.2. Changes ..................................................... 4
1.3. Processing Model ............................................ 5
1.4. Modes of Operation .......................................... 6
1.5. Implementation Options ...................................... 7
2. Message Format ................................................ 7
2.1. Notational Conventions ...................................... 8
2.2. The Request Line ............................................ 8
2.3. The Status Line ............................................. 8
2.4. Secure HTTP Header Lines .................................... 8
2.5. Content .....................................................12
2.6. Encapsulation Format Options ................................13
2.6.1. Content-Privacy-Domain: CMS ...............................13
2.6.2. Content-Privacy-Domain: MOSS ..............................14
2.6.3. Permitted HTTP headers ....................................14
2.6.3.2. Host ....................................................15
2.6.3.3. Connection ..............................................15
3. Cryptographic Parameters ......................................15
3.1. Options Headers .............................................15
3.2. Negotiation Options .........................................16
3.2.1. Negotiation Overview ......................................16
3.2.2. Negotiation Option Format .................................16
3.2.3. Parametrization for Variable-length Key Ciphers ...........18
3.2.4. Negotiation Syntax ........................................18
3.3. Non-Negotiation Headers .....................................23
3.3.1. Encryption-Identity .......................................23
3.3.2. Certificate-Info ..........................................23
3.3.3. Key-Assign ................................................24
3.3.4. Nonces ....................................................25
3.4. Grouping Headers With SHTTP-Cryptopts .......................26
3.4.1. SHTTP-Cryptopts ...........................................26
4. New Header Lines for HTTP .....................................26
4.1. Security-Scheme .............................................26
5. (Retriable) Server Status Error Reports .......................27
5.1. Retry for Option (Re)Negotiation ............................27
5.2. Specific Retry Behavior .....................................28
5.3. Limitations On Automatic Retries ............................29
6. Other Issues ..................................................30
6.1. Compatibility of Servers with Old Clients ...................30
6.2. URL Protocol Type ...........................................30
6.3. Browser Presentation ........................................31
7. Implementation Notes ..........................................32
7.1. Preenhanced Data ............................................32
7.2. Note:Proxy Interaction ......................................34
7.2.1. Client-Proxy Authentication ...............................34
8. Implementation Recommendations and Requirements ...............34
9. Protocol Syntax Summary .......................................35
10. An Extended Example ..........................................36
Appendix: A Review of CMS ........................................40
Bibliography and References ......................................41
Security Considerations ..........................................43
Authors' Addresses ...............................................44
Full Copyright Statement..........................................45
2.6.1. Content-Privacy-Domain: CMS ...............................13
2.6.2. Content-Privacy-Domain: MOSS ..............................14
2.6.3. Permitted HTTP headers ....................................14
2.6.3.2. Host ....................................................15
2.6.3.3. Connection ..............................................15
3. Cryptographic Parameters ......................................15
3.1. Options Headers .............................................15
3.2. Negotiation Options .........................................16
3.2.1. Negotiation Overview ......................................16
3.2.2. Negotiation Option Format .................................16
3.2.3. Parametrization for Variable-length Key Ciphers ...........18
3.2.4. Negotiation Syntax ........................................18
3.3. Non-Negotiation Headers .....................................23
3.3.1. Encryption-Identity .......................................23
3.3.2. Certificate-Info ..........................................23
3.3.3. Key-Assign ................................................24
3.3.4. Nonces ....................................................25
3.4. Grouping Headers With SHTTP-Cryptopts .......................26
3.4.1. SHTTP-Cryptopts ...........................................26
4. New Header Lines for HTTP .....................................26
4.1. Security-Scheme .............................................26
5. (Retriable) Server Status Error Reports .......................27
5.1. Retry for Option (Re)Negotiation ............................27
5.2. Specific Retry Behavior .....................................28
5.3. Limitations On Automatic Retries ............................29
6. Other Issues ..................................................30
6.1. Compatibility of Servers with Old Clients ...................30
6.2. URL Protocol Type ...........................................30
6.3. Browser Presentation ........................................31
7. Implementation Notes ..........................................32
7.1. Preenhanced Data ............................................32
7.2. Note:Proxy Interaction ......................................34
7.2.1. Client-Proxy Authentication ...............................34
8. Implementation Recommendations and Requirements ...............34
9. Protocol Syntax Summary .......................................35
10. An Extended Example ..........................................36
Appendix: A Review of CMS ........................................40
Bibliography and References ......................................41
Security Considerations ..........................................43
Authors' Addresses ...............................................44
Full Copyright Statement..........................................45
The World Wide Web (WWW) is a distributed hypermedia system which has gained widespread acceptance among Internet users. Although WWW browsers support other, preexisting Internet application protocols, the native and primary protocol used between WWW clients and servers is the HyperText Transfer Protocol (HTTP) [RFC-2616]. The ease of use of the Web has prompted its widespread employment as a client/server architecture for many applications. Many such applications require the client and server to be able to authenticate each other and exchange sensitive information confidentially. The original HTTP specification had only modest support for the cryptographic mechanisms appropriate for such transactions.
万维网（WWW）是一种分布式超媒体系统，已被互联网用户广泛接受。尽管WWW浏览器支持其他现有的Internet应用程序协议，但WWW客户端和服务器之间使用的本机和主要协议是超文本传输协议（HTTP）[RFC-2616]。Web的易用性促使它作为许多应用程序的客户机/服务器体系结构得到广泛应用。许多这样的应用程序要求客户机和服务器能够相互验证，并机密地交换敏感信息。最初的HTTP规范只对适合于此类事务的加密机制提供了适度的支持。
Secure HTTP (S-HTTP) provides secure communication mechanisms between an HTTP client-server pair in order to enable spontaneous commercial transactions for a wide range of applications. Our design intent is to provide a flexible protocol that supports multiple orthogonal operation modes, key management mechanisms, trust models, cryptographic algorithms and encapsulation formats through option negotiation between parties for each transaction.
安全HTTP（S-HTTP）提供HTTP客户机-服务器对之间的安全通信机制，以便为广泛的应用程序启用自发的商业事务。我们的设计意图是提供一个灵活的协议，该协议支持多种正交操作模式、密钥管理机制、信任模型、加密算法和封装格式，通过各方之间针对每个事务的选项协商实现。
Secure HTTP is a secure message-oriented communications protocol designed for use in conjunction with HTTP. It is designed to coexist with HTTP's messaging model and to be easily integrated with HTTP applications.
安全HTTP是一种面向消息的安全通信协议，设计用于与HTTP结合使用。它被设计为与HTTP的消息传递模型共存，并易于与HTTP应用程序集成。
Secure HTTP provides a variety of security mechanisms to HTTP clients and servers, providing the security service options appropriate to the wide range of potential end uses possible for the World-Wide Web. The protocol provides symmetric capabilities to both client and server (in that equal treatment is given to both requests and replies, as well as for the preferences of both parties) while preserving the transaction model and implementation characteristics of HTTP.
安全HTTP为HTTP客户端和服务器提供了多种安全机制，提供了适合万维网各种潜在最终用途的安全服务选项。该协议为客户机和服务器提供了对称功能（即对请求和响应以及双方的首选项给予同等对待），同时保留了HTTP的事务模型和实现特征。
Several cryptographic message format standards may be incorporated into S-HTTP clients and servers, particularly, but in principle not limited to, [CMS] and [MOSS]. S-HTTP supports interoperation among a variety of implementations, and is compatible with HTTP. S-HTTP aware clients can communicate with S-HTTP oblivious servers and vice-versa, although such transactions obviously would not use S-HTTP security features.
一些加密消息格式标准可并入S-HTTP客户端和服务器，特别是但原则上不限于[CMS]和[MOSS]。S-HTTP支持多种实现之间的互操作，并且与HTTP兼容。支持S-HTTP的客户端可以与S-HTTP无关服务器通信，反之亦然，尽管此类事务显然不会使用S-HTTP安全功能。
S-HTTP does not require client-side public key certificates (or public keys), as it supports symmetric key-only operation modes.
S-HTTP不需要客户端公钥证书（或公钥），因为它只支持对称密钥操作模式。
This is significant because it means that spontaneous private transactions can occur without requiring individual users to have an established public key. While S-HTTP is able to take advantage of ubiquitous certification infrastructures, its deployment does not require it.
这一点很重要，因为这意味着可以在不要求单个用户拥有已建立的公钥的情况下进行自发的私有事务。虽然S-HTTP能够利用无处不在的认证基础设施，但其部署并不需要它。
S-HTTP supports end-to-end secure transactions, in contrast with the original HTTP authorization mechanisms which require the client to attempt access and be denied before the security mechanism is employed. Clients may be "primed" to initiate a secure transaction (typically using information supplied in message headers); this may be used to support encryption of fill-out forms, for example. With S-HTTP, no sensitive data need ever be sent over the network in the clear.
S-HTTP支持端到端安全事务，这与原始HTTP授权机制不同，原始HTTP授权机制要求客户端尝试访问并在使用安全机制之前被拒绝。客户机可以“启动”以启动安全事务（通常使用消息头中提供的信息）；例如，这可用于支持填写表单的加密。有了S-HTTP，任何敏感数据都不需要在网络上以明文形式发送。
S-HTTP provides full flexibility of cryptographic algorithms, modes and parameters. Option negotiation is used to allow clients and servers to agree on transaction modes (e.g., should the request be signed or encrypted or both -- similarly for the reply?); cryptographic algorithms (RSA vs. DSA for signing, DES vs. RC2 for encrypting, etc.); and certificate selection (please sign with your "Block-buster Video certificate").
S-HTTP提供了加密算法、模式和参数的充分灵活性。选项协商用于允许客户机和服务器就交易模式达成一致（例如，请求是否应该签名或加密，或者两者都应该签名或加密——回复也是如此）；加密算法（RSA与DSA用于签名，DES与RC2用于加密等）；和证书选择（请使用您的“BlockBuster视频证书”签名）。
S-HTTP attempts to avoid presuming a particular trust model, although its designers admit to a conscious effort to facilitate multiply-rooted hierarchical trust, and anticipate that principals may have many public key certificates.
S-HTTP试图避免假定特定的信任模型，尽管其设计者承认有意识地努力促进多根层次信任，并预期主体可能具有许多公钥证书。
S-HTTP differs from Digest-Authentication, described in [RFC-2617] in that it provides support for public key cryptography and consequently digital signature capability, as well as providing confidentiality.
S-HTTP不同于[RFC-2617]中描述的摘要认证，因为它支持公钥加密，从而支持数字签名功能，并提供机密性。
This document describes S-HTTP/1.4. It differs from the previous memo in that it differs from the previous memo in its support of the Cryptographic Message Syntax (CMS) [CMS], a successor to PKCS-7; and hence now supports the Diffie-Hellman and the (NIST) Digital Signature Standard cryptosystems. CMS used in RSA mode is bits on the wire compatible with PKCS-7.
本文档介绍S-HTTP/1.4。它与前一份备忘录的不同之处在于，它与前一份备忘录的不同之处在于，它支持PKCS-7的后续版本加密消息语法（CMS）[CMS]；因此现在支持Diffie-Hellman和（NIST）数字签名标准密码系统。RSA模式中使用的CMS是与PKCS-7兼容的线上位。
The creation of an S-HTTP message can be thought of as a a function with three inputs:
可以将S-HTTP消息的创建视为具有三个输入的函数：
1. The cleartext message. This is either an HTTP message or some other data object. Note that since the cleartext message is carried transparently, headers and all, any version of HTTP can be carried within an S-HTTP wrapper. 2. The receiver's cryptographic preferences and keying material. This is either explicitly specified by the receiver or subject to some default set of preferences. 3. The sender's cryptographic preferences and keying material. This input to the function can be thought of as implicit since it exists only in the memory of the sender.
1. 明文信息。这是HTTP消息或其他数据对象。请注意，由于明文消息是透明传输的，因此任何版本的HTTP都可以在S-HTTP包装器中传输。2.接收方的加密首选项和密钥设置材料。这要么由接收者明确指定，要么受制于某些默认的首选项集。3.发送方的加密首选项和密钥设置材料。该函数的输入可以被认为是隐式的，因为它只存在于发送方的内存中。
In order to create an S-HTTP message, then, the sender integrates the sender's preferences with the receiver's preferences. The result of this is a list of cryptographic enhancements to be applied and keying material to be used to apply them. This may require some user intervention. For instance, there might be multiple keys available to sign the message. (See Section 3.2.4.9.3 for more on this topic.) Using this data, the sender applies the enhancements to the message clear-text to create the S-HTTP message.
然后，为了创建S-HTTP消息，发送方将发送方的首选项与接收方的首选项集成在一起。其结果是要应用的加密增强和用于应用它们的键控材料的列表。这可能需要一些用户干预。例如，可能有多个密钥可用于对消息进行签名。（有关此主题的更多信息，请参阅第3.2.4.9.3节。）使用此数据，发送方将增强功能应用于消息明文以创建S-HTTP消息。
The processing steps required to transform the cleartext message into the S-HTTP message are described in Sections 2 and 3. The processing steps required to merge the sender's and receiver's preferences are described in Sections 3.2.
第2节和第3节描述了将明文消息转换为S-HTTP消息所需的处理步骤。第3.2节描述了合并发送方和接收方偏好所需的处理步骤。
The recovery of an S-HTTP message can be thought of as a function of four distinct inputs:
可以将S-HTTP消息的恢复视为四个不同输入的函数：
1. The S-HTTP message. 2. The receiver's stated cryptographic preferences and keying material. The receiver has the opportunity to remember what cryptographic preferences it provided in order for this document to be dereferenced. 3. The receiver's current cryptographic preferences and keying material. 4. The sender's previously stated cryptographic options. The sender may have stated that he would perform certain cryptographic operations in this message. (Again, see sections 4 and 5 for details on how to do this.)
1. S-HTTP消息。2.接收方声明的加密首选项和密钥材料。接收方有机会记住它提供了哪些加密首选项，以便解除对该文档的引用。3.接收方当前的加密首选项和密钥设置材料。4.发送方先前声明的加密选项。发件人可能已声明他将在此消息中执行某些加密操作。（同样，有关如何操作的详细信息，请参见第4节和第5节。）
In order to recover an S-HTTP message, the receiver needs to read the headers to discover which cryptographic transformations were performed on the message, then remove the transformations using some combination of the sender's and receiver's keying material, while taking note of which enhancements were applied.
为了恢复S-HTTP消息，接收方需要读取消息头以发现对消息执行了哪些加密转换，然后使用发送方和接收方的密钥材料的某种组合删除转换，同时注意应用了哪些增强。
The receiver may also choose to verify that the applied enhancements match both the enhancements that the sender said he would apply (input 4 above) and that the receiver requested (input 2 above) as well as the current preferences to see if the S-HTTP message was appropriately transformed. This process may require interaction with the user to verify that the enhancements are acceptable to the user. (See Section 6.4 for more on this topic.)
接收方还可以选择验证所应用的增强是否与发送方表示将应用的增强（上面的输入4）和接收方请求的增强（上面的输入2）以及当前首选项匹配，以查看S-HTTP消息是否被适当转换。此过程可能需要与用户交互，以验证增强功能是否为用户所接受。（有关此主题的更多信息，请参见第6.4节。）
Message protection may be provided on three orthogonal axes: signature, authentication, and encryption. Any message may be signed, authenticated, encrypted, or any combination of these (including no protection).
可以在三个正交轴上提供消息保护：签名、身份验证和加密。任何消息都可以经过签名、身份验证、加密，或这些信息的任意组合（不包括保护）。
Multiple key management mechanisms are supported, including password-style manually shared secrets and public-key key exchange. In particular, provision has been made for prearranged (in an earlier transaction or out of band) symmetric session keys in order to send confidential messages to those who have no public key pair.
支持多种密钥管理机制，包括密码式手动共享秘密和公钥交换。特别是，规定了预先安排（在早期交易或带外）的对称会话密钥，以便向没有公钥对的人发送机密消息。
Additionally, a challenge-response ("nonce") mechanism is provided to allow parties to assure themselves of transaction freshness.
此外，还提供了质询响应（“nonce”）机制，以允许各方确保自己的交易新鲜度。
If the digital signature enhancement is applied, an appropriate certificate may either be attached to the message (possibly along with a certificate chain) or the sender may expect the recipient to obtain the required certificate (chain) independently.
如果应用了数字签名增强，则可以将适当的证书附加到消息（可能与证书链一起），或者发送方可以期望接收方独立地获得所需的证书（链）。
In support of bulk encryption, S-HTTP defines two key transfer mechanisms, one using public-key enveloped key exchange and another with externally arranged keys.
为了支持批量加密，S-HTTP定义了两种密钥传输机制，一种使用公钥封装的密钥交换，另一种使用外部安排的密钥。
In the former case, the symmetric-key cryptosystem parameter is passed encrypted under the receiver's public key.
在前一种情况下，对称密钥密码系统参数在接收方的公钥下加密传递。
In the latter mode, we encrypt the content using a prearranged session key, with key identification information specified on one of the header lines.
在后一种模式中，我们使用预先安排的会话密钥加密内容，并在其中一个头行上指定密钥标识信息。
Secure HTTP provides a means to verify message integrity and sender authenticity for a message via the computation of a Message Authentication Code (MAC), computed as a keyed hash over the document using a shared secret -- which could potentially have been arranged in a number of ways, e.g.: manual arrangement or 'inband' key management. This technique requires neither the use of public key cryptography nor encryption.
安全HTTP提供了一种通过计算消息身份验证码（MAC）来验证消息完整性和消息发送方真实性的方法，MAC作为使用共享密钥的文档上的密钥散列进行计算，可能以多种方式排列，例如：手动排列或“带内”密钥管理。这种技术既不需要使用公钥加密，也不需要加密。
This mechanism is also useful for cases where it is appropriate to allow parties to identify each other reliably in a transaction without providing (third-party) non-repudiability for the transactions themselves. The provision of this mechanism is motivated by our bias that the action of "signing" a transaction should be explicit and conscious for the user, whereas many authentication needs (i.e., access control) can be met with a lighter-weight mechanism that retains the scalability advantages of public-key cryptography for key exchange.
该机制还适用于允许各方在交易中可靠地相互识别而不为交易本身提供（第三方）不可抵赖性的情况。提供这种机制是出于我们的偏见，即“签署”交易的行为对于用户来说应该是明确的和有意识的，而许多身份验证需求（即访问控制）可以通过一种重量较轻的机制来满足，该机制保留了公钥加密用于密钥交换的可伸缩性优势。
The protocol provides a simple challenge-response mechanism, allowing both parties to insure the freshness of transmissions. Additionally, the integrity protection provided to HTTP headers permits implementations to consider the Date: header allowable in HTTP messages as a freshness indicator, where appropriate (although this requires implementations to make allowances for maximum clock skew between parties, which we choose not to specify).
该协议提供了一个简单的质询-响应机制，允许双方确保传输的新鲜度。此外，提供给HTTP报头的完整性保护允许实现考虑日期：HTTP消息中允许的报头作为新鲜度指示器，在适当的情况下（虽然这需要实现允许双方之间的最大时钟偏移，这是我们选择不指定的）。
In order to encourage widespread adoption of secure documents for the World-Wide Web in the face of the broad scope of application requirements, variability of user sophistication, and disparate implementation constraints, Secure HTTP deliberately caters to a variety of implementation options. See Section 8 for implementation recommendations and requirements.
面对广泛的应用程序需求、用户复杂程度的变化和不同的实现约束，为了鼓励万维网广泛采用安全文档，安全HTTP故意迎合各种实现选项。有关实施建议和要求，请参见第8节。
Syntactically, Secure HTTP messages are the same as HTTP, consisting of a request or status line followed by headers and a body. However, the range of headers is different and the bodies are typically
从语法上讲，安全HTTP消息与HTTP相同，由请求或状态行，后跟头和正文组成。但是，标题的范围不同，主体通常是
cryptographically enhanced.
加密增强的。
This document uses the augmented BNF from HTTP [RFC-2616]. You should refer to that document for a description of the syntax.
本文档使用HTTP[RFC-2616]中的扩充BNF。有关语法的描述，请参阅该文档。
In order to differentiate S-HTTP messages from HTTP messages and allow for special processing, the request line should use the special Secure" method and use the protocol designator "Secure-HTTP/1.4". Consequently, Secure-HTTP and HTTP processing can be intermixed on the same TCP port, e.g. port 80. In order to prevent leakage of potentially sensitive information Request-URI should be "*". For example:
为了区分S-HTTP消息和HTTP消息，并允许进行特殊处理，请求行应使用“特殊安全”方法，并使用协议指示符“安全HTTP/1.4”。因此，安全HTTP和HTTP处理可以在同一TCP端口上混合使用，例如端口80。为了防止潜在敏感信息泄漏，请求URI应为“*”。例如：
Secure * Secure-HTTP/1.4
安全*安全HTTP/1.4
When communicating via a proxy, the Request-URI should be consist of the AbsoluteURI. Typically, the rel path section should be replaced by "*" to minimize the information passed to in the clear. (e.g. http://www.terisa.com/*); proxies should remove the appropriate amount of this information to minimize the threat of traffic analysis. See Section 7.2.2.1 for a situation where providing more information is appropriate.
当通过代理进行通信时，请求URI应该由绝对URI组成。通常，rel path部分应替换为“*”，以最小化在清除中传递给的信息。（例如。http://www.terisa.com/*); 代理应删除适当数量的此类信息，以将流量分析的威胁降至最低。有关提供更多信息的情况，请参见第7.2.2.1节。
S-HTTP responses should use the protocol designator "Secure-HTTP/1.4". For example:
S-HTTP响应应使用协议指示符“安全HTTP/1.4”。例如：
Secure-HTTP/1.4 200 OK
安全HTTP/1.4 200正常
Note that the status in the Secure HTTP response line does not indicate anything about the success or failure of the unwrapped HTTP request. Servers should always use 200 OK provided that the Secure HTTP processing is successful. This prevents analysis of success or failure for any request, which the correct recipient can determine from the encapsulated data. All case variations should be accepted.
请注意，安全HTTP响应行中的状态并不表示未包装HTTP请求的成功或失败。如果安全HTTP处理成功，服务器应始终使用200 OK。这会阻止对任何请求的成功或失败进行分析，而正确的接收者可以从封装的数据中确定这些请求。应接受所有案例变更。
The header lines described in this section go in the header of a Secure HTTP message. All except 'Content-Type' and 'Content-Privacy-Domain' are optional. The message body shall be separated from the header block by two successive CRLFs.
本节中描述的标题行位于安全HTTP消息的标题中。除“内容类型”和“内容隐私域”之外的所有内容都是可选的。消息体应通过两个连续的CRLF与标题块分开。
All data and fields in header lines should be treated as case insensitive unless otherwise specified. Linear whitespace [RFC-822] should be used only as a token separator unless otherwise quoted. Long header lines may be line folded in the style of [RFC-822].
除非另有规定，否则标题行中的所有数据和字段都应视为不区分大小写。除非另有说明，否则线性空白[RFC-822]只能用作标记分隔符。长标题行可采用[RFC-822]样式进行折线。
This document refers to the header block following the S-HTTP request/response line and preceding the successive CRLFs collectively as "S-HTTP headers".
本文档将S-HTTP请求/响应行之后、连续CRLF之前的头块统称为“S-HTTP头”。
The two values defined by this document are 'MOSS' and 'CMS'. CMS refers to the privacy enhancement specified in section 2.6.1. MOSS refers to the format defined in [RFC-1847] and [RFC-1848].
本文件定义的两个值为“MOSS”和“CMS”。CMS指第2.6.1节中规定的隐私增强。MOSS是指[RFC-1847]和[RFC-1848]中定义的格式。
Under normal conditions, the terminal encapsulated content (after all privacy enhancements have been removed) would be an HTTP message. In this case, there shall be a Content-Type line reading:
在正常情况下，终端封装的内容（在删除所有隐私增强功能后）将是HTTP消息。在这种情况下，应具有内容类型行读数：
Content-Type: message/http
Content-Type: message/http
The message/http content type is defined in RFC-2616.
消息/http内容类型在RFC-2616中定义。
If the inner message is an S-HTTP message, then the content type shall be 'application/s-http'. (See Appendix for the definition of this.)
如果内部消息是S-HTTP消息，则内容类型应为“应用程序/S-HTTP”。（有关此定义，请参见附录。）
It is intended that these types be registered with IANA as MIME content types.
打算将这些类型作为MIME内容类型向IANA注册。
The terminal content may be of some other type provided that the type is properly indicated by the use of an appropriate Content-Type header line. In this case, the header fields for the encapsulation of the terminal content apply to the terminal content (the 'final headers'). But in any case, final headers should themselves always be S-HTTP encapsulated, so that the applicable S-HTTP/HTTP headers are never passed unenhanced.
终端内容可以是某种其他类型，前提是通过使用适当的内容类型标题行正确指示该类型。在这种情况下，用于封装终端内容的标题字段应用于终端内容（“最终标题”）。但在任何情况下，最终的头本身都应该是S-HTTP封装的，这样适用的S-HTTP/HTTP头就永远不会被未增强地传递。
S-HTTP encapsulation of non-HTTP data is a useful mechanism for passing pre-enhanced data (especially presigned data) without requiring that the HTTP headers themselves be pre-enhanced.
非HTTP数据的S-HTTP封装是传递预增强数据（特别是预签名数据）的一种有用机制，无需预先增强HTTP头本身。
The Content-Type for MOSS shall be an acceptable MIME content type describing the cryptographic processing applied. (e.g. multipart/signed). The content type of the inner content is described in the content type line corresponding to that inner content, and for HTTP messages shall be 'message/http'.
MOSS的内容类型应为可接受的MIME内容类型，描述应用的加密处理。（例如，多部分/签名）。内部内容的内容类型在与该内部内容对应的内容类型行中描述，对于HTTP消息，应为“消息/HTTP”。
This header line is intended to convey information about a key which has been arranged outside of the internal cryptographic format. One use of this is to permit in-band communication of session keys for return encryption in the case where one of the parties does not have a key pair. However, this should also be useful in the event that the parties choose to use some other mechanism, for instance, a one-time key list.
此标题行旨在传达有关已安排在内部加密格式之外的密钥的信息。这种方法的一个用途是允许在其中一方没有密钥对的情况下进行会话密钥的带内通信以进行返回加密。然而，如果当事方选择使用某种其他机制，例如一次性钥匙清单，这也应该是有用的。
This specification defines two methods for exchanging named keys, Inband, Outband. Inband indicates that the session key was exchanged previously, using a Key-Assign header of the corresponding method. Outband arrangements imply that agents have external access to key materials corresponding to a given name, presumably via database access or perhaps supplied immediately by a user from keyboard input. The syntax for the header line is:
本规范定义了两种交换命名密钥的方法：带内和带外。Inband表示会话密钥是以前使用相应方法的密钥分配头交换的。带外安排意味着代理可以从外部访问与给定名称对应的关键材料，可能是通过数据库访问，也可能是由用户通过键盘输入立即提供。标题行的语法为：
Prearranged-Key-Info =
"Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID
CoverKey-ID = method ":" key-name
CoveredDEK = *HEX
method = "inband" | "outband"
Prearranged-Key-Info =
"Prearranged-Key-Info" ":" Hdr-Cipher "," CoveredDEK "," CoverKey-ID
CoverKey-ID = method ":" key-name
CoveredDEK = *HEX
method = "inband" | "outband"
While chaining ciphers require an Initialization Vector (IV) [FIPS-81] to start off the chaining, that information is not carried by this field. Rather, it should be passed internal to the cryptographic format being used. Likewise, the bulk cipher used is specified in this fashion.
虽然链式密码需要初始化向量（IV）[FIPS-81]来开始链式，但该字段不携带该信息。相反，它应该在内部传递给正在使用的加密格式。同样，使用的批量密码也是以这种方式指定的。
<Hdr-Cipher> should be the name of the block cipher used to encrypt the session key (see section 3.2.4.7)
<Hdr Cipher>应为用于加密会话密钥的分组密码的名称（见第3.2.4.7节）
<CoveredDEK> is the protected Data Encryption Key (a.k.a. transaction key) under which the encapsulated message was encrypted. It should be appropriately (randomly) generated by the sending agent, then encrypted under the cover of the negotiated key (a.k.a. session key) using the indicated header cipher, and then converted into hex.
<CoveredDEK>是受保护的数据加密密钥（也称为事务密钥），在该密钥下对封装的消息进行加密。它应该由发送代理适当（随机）生成，然后在协商密钥（也称为会话密钥）的掩护下使用指定的报头密码进行加密，然后转换为十六进制。
In order to avoid name collisions, cover key namespaces must be maintained separately by host and port.
为了避免名称冲突，必须按主机和端口分别维护覆盖密钥名称空间。
Note that some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS may have support for symmetric key management.
请注意，某些内容隐私域，特别是MOSS和CMS的未来版本可能支持对称密钥管理。
The Prearranged-Key-Info field need not be used in such circumstances. Rather, the native syntax is preferred. Keys exchanged with Key-Assign, however, may be used in this situation.
在这种情况下，不需要使用预先安排的密钥信息字段。相反，首选本机语法。但是，在这种情况下，可以使用与密钥分配交换的密钥。
This header is used to supply a Message Authenticity Check, providing both message authentication and integrity, computed from the message text, the time (optional -- to prevent replay attack), and a shared secret between client and server. The MAC should be computed over the encapsulated content of the S-HTTP message. S-HTTP/1.1 defined that MACs should be computed using the following algorithm ('||' means concatenation):
此报头用于提供消息真实性检查，提供消息身份验证和完整性，根据消息文本、时间（可选，以防止重播攻击）以及客户端和服务器之间的共享秘密计算。应通过S-HTTP消息的封装内容计算MAC。S-HTTP/1.1定义应使用以下算法计算MAC（“| |”表示串联）：
MAC = hex(H(Message||[<time>]||<shared key>))
MAC = hex(H(Message||[<time>]||<shared key>))
The time should be represented as an unsigned 32 bit quantity representing seconds since 00:00:00 GMT January 1, 1970 (the UNIX epoch), in network byte order. The shared key format is a local matter.
时间应表示为无符号32位量，表示自1970年1月1日格林尼治标准时间00:00:00（UNIX纪元）起的秒数，以网络字节顺序表示。共享密钥格式是本地事务。
Recent research [VANO95] has demonstrated some weaknesses in this approach, and this memo introduces a new construction, derived from [RFC-2104]. In the name of backwards compatibility, we retain the previous constructions with the same names as before. However, we also introduce a new series of names (See Section 3.2.4.8 for the names) that obey a different (hopefully stronger) construction. (^ means bitwise XOR)
最近的研究[VANO95]证明了这种方法的一些弱点，本备忘录介绍了一种新的结构，源自[RFC-2104]。在向后兼容性的名义下，我们保留了以前的结构与以前相同的名称。然而，我们还引入了一系列新的名称（名称见第3.2.4.8节），这些名称遵循不同（希望更强）的结构。（^表示按位异或）
HMAC = hex(H(K' ^ pad2 || H(K' ^ pad1 ||[<time>]|| Message)))
pad1 = the byte 0x36 repeated enough times to fill out a
hash input block. (I.e. 64 times for both MD5 and SHA-1)
pad2 = the byte 0x5c repeated enough times to fill out a
hash input block.
K' = H(<shared key>)
HMAC = hex(H(K' ^ pad2 || H(K' ^ pad1 ||[<time>]|| Message)))
pad1 = the byte 0x36 repeated enough times to fill out a
hash input block. (I.e. 64 times for both MD5 and SHA-1)
pad2 = the byte 0x5c repeated enough times to fill out a
hash input block.
K' = H(<shared key>)
The original HMAC construction is for the use of a key with length equal to the length of the hash output. Although it is considered safe to use a key of a different length (Note that strength cannot be increased past the length of the hash function itself, but can be reduced by using a shorter key.) [KRAW96b] we hash the original key
原始HMAC构造用于使用长度等于散列输出长度的密钥。尽管使用不同长度的密钥被认为是安全的（请注意，强度不能增加到超过哈希函数本身的长度，但可以通过使用较短的密钥来减少）。[KRAW96b]我们对原始密钥进行哈希运算
to permit the use of shared keys (e.g. passphrases) longer than the length of the hash. It is noteworthy (though obvious) that this technique does not increase the strength of short keys.
允许使用比散列长度更长的共享密钥（如密码短语）。值得注意的是（尽管很明显），这种技术不会增加短键的强度。
The format of the MAC-Info line is:
MAC信息行的格式为：
MAC-Info =
"MAC-Info" ":" [hex-time],
hash-alg, hex-hash-data, key-spec
hex-time = <unsigned seconds since Unix epoch represented as HEX>
hash-alg = <hash algorithms from section 3.2.4.8>
hex-hash-data = <computation as described above represented as HEX>
Key-Spec = "null" | "dek" | Key-ID
MAC-Info =
"MAC-Info" ":" [hex-time],
hash-alg, hex-hash-data, key-spec
hex-time = <unsigned seconds since Unix epoch represented as HEX>
hash-alg = <hash algorithms from section 3.2.4.8>
hex-hash-data = <computation as described above represented as HEX>
Key-Spec = "null" | "dek" | Key-ID
Key-Ids can refer either to keys bound using the Key-Assign header line or those bound in the same fashion as the Outband method described later. The use of a 'Null' key-spec implies that a zero length key was used, and therefore that the MAC merely represents a hash of the message text and (optionally) the time. The special key-spec 'DEK' refers to the Data Exchange Key used to encrypt the following message body (it is an error to use the DEK key-spec in situations where the following message body is unencrypted).
密钥ID可以引用使用密钥分配头行绑定的密钥，也可以引用以与后面描述的带外方法相同的方式绑定的密钥。“Null”密钥规范的使用意味着使用了零长度密钥，因此MAC仅表示消息文本和（可选）时间的散列。特殊密钥规范“DEK”是指用于加密以下消息体的数据交换密钥（在以下消息体未加密的情况下使用DEK密钥规范是错误的）。
If the time is omitted from the MAC-Info line, it should simply not be included in the hash.
如果MAC信息行中省略了时间，则不应将其包含在哈希中。
Note that this header line can be used to provide a more advanced equivalent of the original HTTP Basic authentication mode in that the user can be asked to provide a username and password. However, the password remains private and message integrity can be assured. Moreover, this can be accomplished without encryption of any kind.
请注意，此标题行可用于提供与原始HTTP基本身份验证模式更高级的等价物，即可以要求用户提供用户名和密码。但是，密码仍然是私有的，可以确保消息的完整性。此外，这可以在没有任何加密的情况下实现。
In addition, MAC-Info permits fast message integrity verification (at the loss of non-repudiability) for messages, provided that the participants share a key (possibly passed using Key-Assign in a previous message).
此外，MAC Info允许对消息进行快速消息完整性验证（在失去不可抵赖性的情况下），前提是参与者共享密钥（可能使用前一条消息中的密钥分配进行传递）。
Note that some Content-Privacy-Domains, notably likely future revisions of MOSS and CMS may have support for symmetric integrity protection The MAC-Info field need not be used in such circumstances. Rather, the native syntax is preferred. Keys exchanged with Key-Assign, however, may be used in this situation.
请注意，某些内容隐私域，特别是MOSS和CMS的未来版本可能支持对称完整性保护。在这种情况下，不需要使用MAC信息字段。相反，首选本机语法。但是，在这种情况下，可以使用与密钥分配交换的密钥。
The content of the message is largely dependent upon the values of the Content-Privacy-Domain and Content-Transfer-Encoding fields.
消息的内容在很大程度上取决于内容隐私域和内容传输编码字段的值。
For a CMS message, with '8BIT' Content-Transfer-Encoding, the content should simply be the CMS message itself.
对于CMS消息，使用“8位”内容传输编码，内容应该只是CMS消息本身。
If the Content-Privacy-Domain is MOSS, the content should consist of a MOSS Security Multipart as described in RFC1847.
如果内容隐私域是MOSS，则内容应包括RFC1847中所述的MOSS安全多部分。
It is expected that once the privacy enhancements have been removed, the resulting (possibly protected) contents will be a normal HTTP request. Alternately, the content may be another Secure-HTTP message, in which case privacy enhancements should be unwrapped until clear content is obtained or privacy enhancements can no longer be removed. (This permits embedding of enhancements, such as sequential Signed and Enveloped enhancements.) Provided that all enhancements can be removed, the final de-enhanced content should be a valid HTTP request (or response) unless otherwise specified by the Content-Type line.
预计一旦隐私增强功能被删除，生成的（可能受保护的）内容将是一个正常的HTTP请求。或者，该内容可以是另一个安全的HTTP消息，在这种情况下，隐私增强应该展开，直到获得清晰的内容或者隐私增强不能再被删除。（这允许嵌入增强功能，例如顺序签名和封装增强功能。）如果可以删除所有增强功能，则最终取消增强的内容应为有效的HTTP请求（或响应），除非内容类型行另有规定。
Note that this recursive encapsulation of messages potentially permits security enhancements to be applied (or removed) for the benefit of intermediaries who may be a party to the transaction between a client and server (e.g., a proxy requiring client authentication). How such intermediaries should indicate such processing is described in Section 7.2.1.
请注意，这种消息的递归封装可能允许应用（或删除）安全增强，以使作为客户机和服务器之间事务一方的中介（例如，需要客户机身份验证的代理）受益。第7.2.1节描述了此类中介机构应如何表明此类处理。
Content-Privacy-Domain 'CMS' follows the form of the CMS standard (see Appendix).
内容隐私域“CMS”遵循CMS标准的形式（见附录）。
Message protection may proceed on two orthogonal axes: signature and encryption. Any message may be either signed, encrypted, both, or neither. Note that the 'auth' protection mode of S-HTTP is provided independently of CMS coding via the MAC-Info header of section 2.3.6 since CMS does not support a 'KeyDigestedData' type, although it does support a 'DigestedData' type.
消息保护可以在两个正交轴上进行：签名和加密。任何消息都可以是签名的、加密的、两者都可以，或者两者都不能。请注意，S-HTTP的“身份验证”保护模式通过第2.3.6节的MAC信息头独立于CMS编码提供，因为CMS不支持“KeyDigestedData”类型，尽管它支持“DigestedData”类型。
This enhancement uses the 'SignedData' type of CMS. When digital signatures are used, an appropriate certificate may either be attached to the message (possibly along with a certificate chain) as specified in CMS or the sender may expect the recipient to obtain its certificate (and/or chain) independently. Note that an explicitly allowed instance of this is a certificate signed with the private component corresponding to the public component being attested to. This shall be referred to as a self-signed certificate. What, if any, weight to give to such a certificate is a purely local matter. In
此增强使用CMS的“SignedData”类型。当使用数字签名时，可以按照CMS中的规定将适当的证书附加到消息（可能与证书链一起），或者发送方可能期望接收方独立获得其证书（和/或链）。请注意，显式允许的实例是使用私有组件签名的证书，该私有组件对应于要验证的公共组件。这应称为自签名证书。这种证书的重要性（如果有的话）完全是本地问题。在里面
either case, a purely signed message is precisely CMS compliant.
无论哪种情况，纯签名消息都完全符合CMS。
This enhancement is performed precisely as enveloping (using either ' EnvelopedData' types) under CMS. A message encrypted in this fashion, signed or otherwise, is CMS compliant. To have a message which is both signed and encrypted, one simply creates the CMS SignedData production and encapsulates it in EnvelopedData as described in CMS.
此增强与CMS下的包络（使用“EnvelopedData”类型）完全相同。以这种方式加密、签名或其他方式的消息符合CMS。要使消息同时经过签名和加密，只需创建CMS SignedData产品并将其封装在信封数据中，如CMS中所述。
This uses the 'EncryptedData' type of CMS. In this mode, we encrypt the content using a DEK encrypted under cover of a prearranged session key (how this key may be exchanged is discussed later), with key identification information specified on one of the header lines. The IV is in the EncryptedContentInfo type of the EncryptedData element. To have a message which is both signed and encrypted, one simply creates the CMS SignedData production and encapsulates it in EncryptedData as described in CMS.
这使用CMS的“EncryptedData”类型。在这种模式下，我们使用在预先安排的会话密钥（稍后讨论如何交换该密钥）的掩护下加密的DEK对内容进行加密，其中一个头行上指定了密钥标识信息。IV是EncryptedData元素的EncryptedContentInfo类型。要使消息同时经过签名和加密，只需创建CMS SignedData产品并按照CMS中的描述将其封装在EncryptedData中。
The body of the message should be a MIME compliant message with content type that matches the Content-Type line in the S-HTTP headers. Encrypted messages should use multipart/encrypted. Signed messages should use multipart/signed. However, since multipart/signed does not convey keying material, is is acceptable to use multipart/mixed where the first part is application/mosskey-data and the second part is multipart/mixed in order to convey certificates for use in verifying the signature.
消息体应该是符合MIME的消息，其内容类型与S-HTTP头中的内容类型行相匹配。加密邮件应使用多部分/加密邮件。已签名消息应使用多部分/已签名。但是，由于多部分/签名不传递密钥材料，因此可以使用多部分/混合，其中第一部分是应用程序/密钥数据，第二部分是多部分/混合，以便传递用于验证签名的证书。
Implementation Note: When both encryption and signature are applied by the same agent, signature should in general be applied before encryption.
实施说明：当加密和签名都由同一个代理应用时，通常应在加密之前应用签名。
In general, HTTP [RFC-2616] headers should appear in the inner content (i.e. the message/http) of an S-HTTP message but should not appear in the S-HTTP message wrapper for security reasons. However, certain headers need to be visible to agents which do not have access to the encapsulated data. These headers may appear in the S-HTTP headers as well.
通常，HTTP[RFC-2616]头应出现在S-HTTP消息的内部内容（即消息/HTTP）中，但出于安全原因，不应出现在S-HTTP消息包装中。但是，某些标头需要对无权访问封装数据的代理可见。这些标头也可能出现在S-HTTP标头中。
Please note that although brief descriptions of the general purposes of these headers are provided for clarity, the definitive reference is [RFC-2616].
请注意，虽然为了清楚起见，提供了这些标题的一般用途的简要说明，但最终参考文献为[RFC-2616]。
The host header specificies the internet host and port number of the resource being requested. This header should be used to disambiguate among multiple potential security contexts within which this message could be interpreted. Note that the unwrapped HTTP message will have it's own Host field (assuming it's an HTTP/1.1 message). If these fields do not match, the server should respond with a 400 status code.
主机标头指定所请求资源的internet主机和端口号。此标头应用于在多个可能的安全上下文中消除歧义，在这些上下文中可以解释此消息。请注意，未包装的HTTP消息将有自己的主机字段（假设它是HTTP/1.1消息）。如果这些字段不匹配，服务器应以400状态代码响应。
The Connection field has precisely the same semantics in S-HTTP headers as it does in HTTP headers. This permits persistent connections to be used with S-HTTP.
连接字段在S-HTTP头中的语义与在HTTP头中的语义完全相同。这允许与S-HTTP一起使用持久连接。
As described in Section 1.3.2, every S-HTTP request is (at least conceptually) preconditioned by the negotiation options provided by the potential receiver. The two primary locations for these options are
如第1.3.2节所述，每个S-HTTP请求（至少在概念上）都由潜在接收方提供的协商选项进行预处理。这些选项的两个主要位置是
1. In the headers of an HTTP Request/Response. 2. In the HTML which contains the anchor being dereferenced.
1. 在HTTP请求/响应的标头中。2.在包含被取消引用的锚的HTML中。
There are two kinds of cryptographic options which may be provided: Negotiation options, as discussed in Section 3.2 convey a potential message recipient's cryptographic preferences. Keying options, as discussed in Section 3.3 provide keying material (or pointers to keying material) which may be of use to the sender when enhancing a message.
可以提供两种加密选项：协商选项，如第3.2节所述，传递潜在消息接收方的加密首选项。如第3.3节所述，键控选项提供键控材料（或指向键控材料的指针），在增强消息时，这些材料可能对发送者有用。
Binding cryptographic options to anchors using HTML extensions is the topic of the companion document [SHTML] and will not be treated here.
使用HTML扩展将加密选项绑定到锚点是附带文档[SHTML]的主题，这里不讨论。
Both parties are able to express their requirements and preferences regarding what cryptographic enhancements they will permit/require the other party to provide. The appropriate option choices depend on implementation capabilities and the requirements of particular applications.
双方都能够就允许/要求另一方提供的加密增强功能表达其要求和偏好。适当的选项选择取决于实现能力和特定应用程序的要求。
A negotiation header is a sequence of specifications each conforming to a four-part schema detailing:
协商标题是一系列规范，每个规范符合四部分模式，详细说明：
Property -- the option being negotiated, such as bulk encryption algorithm.
属性--正在协商的选项，例如批量加密算法。
Value -- the value being discussed for the property, such as DES-CBC
Value——正在讨论的属性值，例如DES-CBC
Direction -- the direction which is to be affected, namely: during reception or origination (from the perspective of the originator).
方向——受影响的方向，即：接收或发端期间（从发端人的角度）。
Strength -- strength of preference, namely: required, optional, refused
强度——偏好强度，即：必需、可选、拒绝
As an example, the header line:
例如，标题行：
SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC2
SHTTP对称内容算法：recv可选=DES-CBC，RC2
could be thought to say: "You are free to use DES-CBC or RC2 for bulk encryption for encrypting messages to me."
可以这样认为：“您可以自由地使用DES-CBC或RC2进行批量加密，以加密发送给我的消息。”
We define new headers (to be used in the encapsulated HTTP header, not in the S-HTTP header) to permit negotiation of these matters.
我们定义了新的头（将在封装的HTTP头中使用，而不是在S-HTTP头中使用），以允许协商这些问题。
The general format for negotiation options is:
谈判选项的一般格式为：
Option = Field ":" Key-val ";" *(Key-val)
Key-val = Key "=" Value *("," Value)
Key = Mode"-"Action ; This is represented as one
; token without whitespace
Mode = "orig" | "recv"
Action = "optional" | "required" | "refused"
Option = Field ":" Key-val ";" *(Key-val)
Key-val = Key "=" Value *("," Value)
Key = Mode"-"Action ; This is represented as one
; token without whitespace
Mode = "orig" | "recv"
Action = "optional" | "required" | "refused"
The <Mode> value indicates whether this <Key-val> refers to what the agent's actions are upon sending privacy enhanced messages as opposed to upon receiving them. For any given mode-action pair, the interpretation to be placed on the enhancements (<Value>s) listed is:
<Mode>值指示此<Key val>是否指代理在发送隐私增强消息时的操作，而不是在接收消息时的操作。对于任何给定的模式动作对，对所列增强（<Value>s）的解释如下：
'recv-optional:' The agent will process the enhancement if the other party uses it, but will also gladly process messages without the enhancement.
'recv optional:'如果另一方使用该增强功能，代理将处理该增强功能，但也很乐意在没有该增强功能的情况下处理消息。
'recv-required:' The agent will not process messages without this enhancement.
“recv required:”如果没有此增强功能，代理将不会处理消息。
'recv-refused:' The agent will not process messages with this enhancement.
'recv拒绝：'代理将不处理具有此增强功能的邮件。
'orig-optional:' When encountering an agent which refuses this enhancement, the agent will not provide it, and when encountering an agent which requires it, this agent will provide it.
'orig optional:'当遇到拒绝此增强的代理时，该代理将不提供此增强，而当遇到需要此增强的代理时，此代理将提供此增强。
'orig-required:' The agent will always generate the enhancement.
“orig required:”代理将始终生成增强。
'orig-refused:' The agent will never generate the enhancement.
orig拒绝了：“代理永远不会生成增强。
The behavior of agents which discover that they are communicating with an incompatible agent is at the discretion of the agents. It is inappropriate to blindly persist in a behavior that is known to be unacceptable to the other party. Plausible responses include simply terminating the connection, or, in the case of a server response, returning 'Not implemented 501'.
发现自己正在与不兼容的代理通信的代理的行为由代理自行决定。盲目坚持另一方不可接受的行为是不合适的。合理的响应包括简单地终止连接，或者在服务器响应的情况下，返回“未实现501”。
Optional values are considered to be listed in decreasing order of preference. Agents are free to choose any member of the intersection of the optional lists (or none) however.
可选值按优先顺序递减。但是，代理可以自由选择可选列表交叉点的任何成员（或无）。
If any <Key-Val> is left undefined, it should be assumed to be set to the default. Any key which is specified by an agent shall override any appearance of that key in any <Key-Val> in the default for that field.
如果未定义任何<Key Val>，则应假定将其设置为默认值。代理指定的任何密钥应覆盖该字段默认值中任何<key Val>中该密钥的任何外观。
For ciphers with variable key lengths, values may be parametrized
using the syntax <cipher>'['<length>']'
For ciphers with variable key lengths, values may be parametrized
using the syntax <cipher>'['<length>']'
For example, 'RSA[1024]' represents a 1024 bit key for RSA. Ranges may be represented as
例如，“RSA[1024]”表示RSA的1024位密钥。范围可以表示为
<cipher>'['<bound1>'-'<bound2>']'
<cipher>'['<bound1>'-'<bound2>']'
For purposes of preferences, this notation should be treated as if it read (assuming x and y are integers)
出于首选项的目的，应将此符号视为已读（假设x和y为整数）
<cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y)
<cipher>[x], <cipher>[x+1],...<cipher>[y] (if x<y)
and
和
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y)
<cipher>[x], <cipher>[x-1],...<cipher>[y] (if x>y)
The special value 'inf' may be used to denote infinite length.
特殊值“inf”可用于表示无限长。
Using simply <cipher> for such a cipher shall be read as the maximum range possible with the given cipher.
对此类密码使用简单的<cipher>，应被视为给定密码的最大可能范围。
This header refers to the Content-Privacy-Domain type of section 2.3.1. Acceptable values are as listed there. For instance,
此标题是指第2.3.1节的内容隐私域类型。可接受值如下所列。例如，
SHTTP-Privacy-Domains: orig-required=cms;
recv-optional=cms,MOSS
SHTTP-Privacy-Domains: orig-required=cms;
recv-optional=cms,MOSS
would indicate that the agent always generates CMS compliant messages, but can read CMS or MOSS (or, unenhanced messages).
表示代理始终生成符合CMS的消息，但可以读取CMS或MOSS（或未增强消息）。
This indicates what sort of Public Key certificates the agent will accept. Currently defined values are 'X.509' and 'X.509v3'.
这表示代理将接受哪种类型的公钥证书。当前定义的值为“X.509”和“X.509v3”。
This header indicates which algorithms may be used for key exchange. Defined values are 'DH', 'RSA', 'Outband' and 'Inband'. DH refers to Diffie-Hellman X9.42 style enveloping. [DH] RSA refers to RSA enveloping. Outband refers to some sort of external key agreement.
此标头指示可用于密钥交换的算法。定义的值为“DH”、“RSA”、“带外”和“带内”。DH指Diffie-Hellman X9.42风格的封套。[DH]RSA指RSA包络。Outband指某种外部密钥协议。
Inband refers to section 3.3.3.1.
带内参考第3.3.3.1节。
The expected common configuration of clients having no certificates and servers having certificates would look like this (in a message sent by the server):
没有证书的客户端和有证书的服务器的预期公共配置如下所示（在服务器发送的消息中）：
SHTTP-Key-Exchange-Algorithms: orig-optional=Inband, DH;
recv-required=DH
SHTTP-Key-Exchange-Algorithms: orig-optional=Inband, DH;
recv-required=DH
This header indicates what Digital Signature algorithms may be used. Defined values are 'RSA' [PKCS-1] and 'NIST-DSS' [FIPS-186] Since NIST-DSS and RSA use variable length moduli the parametrization syntax of section 3.2.3 should be used. Note that a key length specification may interact with the acceptability of a given certificate, since keys (and their lengths) are specified in public-key certificates.
此标题指示可使用的数字签名算法。定义值为“RSA”[PKCS-1]和“NIST-DSS”[FIPS-186]，因为NIST-DSS和RSA使用可变长度模，所以应使用第3.2.3节的参数化语法。请注意，密钥长度规范可能与给定证书的可接受性相互作用，因为密钥（及其长度）是在公钥证书中指定的。
This indicates what message digest algorithms may be used. Previously defined values are 'RSA-MD2' [RFC-1319], 'RSA-MD5' [RFC-1321], 'NIST-SHS' [FIPS-180].
这表明可以使用哪些消息摘要算法。先前定义的值为“RSA-MD2”[RFC-1319]、“RSA-MD5”[RFC-1321]、“NIST-SHS”[FIPS-180]。
This header specifies the symmetric-key bulk cipher used to encrypt message content. Defined values are:
此标头指定用于加密消息内容的对称密钥批量密码。定义值为：
DES-CBC -- DES in Cipher Block Chaining (CBC) mode [FIPS-81] DES-EDE-CBC -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in outer CBC mode DES-EDE3-CBC -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in outer CBC mode DESX-CBC -- RSA's DESX in CBC mode IDEA-CBC -- IDEA in CBC mode RC2-CBC -- RSA's RC2 in CBC mode CDMF-CBC -- IBM's CDMF (weakened key DES) [JOHN93] in CBC mode
DES-CBC——密码分组链（CBC）模式中的DES[FIPS-81]DES-EDE-CBC——使用加密-解密加密的2个密钥3在外部CBC模式中DES-EDE3-CBC——使用加密-解密加密的3个密钥3在外部CBC模式中DESX-CBC——RSA在CBC模式中的DESX IDEA-CBC——CBC模式中的IDEA RC2-CBC——RSA在CBC模式中的RC2 CDMF-CBC——IBM的CDMF（弱密钥DES）[JOHN93]在CBC模式下
Since RC2 keys are variable length, the syntax of section 3.2.3 should be used.
由于RC2键是可变长度的，因此应使用第3.2.3节的语法。
This header specifies the symmetric-key cipher used to encrypt message headers.
此标头指定用于加密消息标头的对称密钥密码。
DES-ECB -- DES in Electronic Codebook (ECB) mode [FIPS-81] DES-EDE-ECB -- 2 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode DES-EDE3-ECB -- 3 Key 3DES using Encrypt-Decrypt-Encrypt in ECB mode DESX-ECB -- RSA's DESX in ECB mode IDEA-ECB -- IDEA RC2-ECB -- RSA's RC2 in ECB mode CDMF-ECB -- IBM's CDMF in ECB mode
DES-ECB——电子码本（ECB）模式下的DES[FIPS-81]DES-EDE-ECB——ECB模式下使用加密-解密加密的2个密钥3DES DES-EDE3-ECB——ECB模式下使用加密-解密加密的3个密钥3DES DESX-ECB——ECB模式下RSA的DESX IDEA-ECB——IDEA RC2-ECB——ECB模式下RSA的RC2 CDMF-ECB——ECB模式下IBM的CDMF
Since RC2 is variable length, the syntax of section 3.2.3 should be used.
由于RC2是可变长度的，因此应使用第3.2.3节的语法。
This header indicates what algorithms are acceptable for use in providing a symmetric key MAC. 'RSA-MD2', 'RSA-MD5' and 'NIST-SHS' persist from S-HTTP/1.1 using the old MAC construction. The tokens ' RSA-MD2-HMAC', 'RSA-MD5-HMAC' and 'NIST-SHS-HMAC' indicate the new HMAC construction of 2.3.6 with the MD2, MD5, and SHA-1 algorithms respectively.
此标头指示可用于提供对称密钥MAC的算法。”RSA-MD2、“RSA-MD5”和“NIST-SHS”使用旧的MAC结构从S-HTTP/1.1中保留下来。标记“RSA-MD2-HMAC”、“RSA-MD5-HMAC”和“NIST-SHS-HMAC”分别表示使用MD2、MD5和SHA-1算法的2.3.6新HMAC结构。
This header indicates security enhancements to apply. Possible values are 'sign', 'encrypt' and 'auth' indicating whether messages are signed, encrypted, or authenticated (i.e., provided with a MAC), respectively.
此标题表示要应用的安全增强。可能的值为“sign”、“encrypt”和“auth”，分别指示消息是经过签名、加密还是经过身份验证（即，提供MAC）。
This is a generalized pattern match syntax to describe identifiers for a large number of types of keying material. The general syntax is:
这是一种通用的模式匹配语法，用于描述大量类型的键控材质的标识符。一般语法为：
Your-Key-Pattern =
"Your-Key-Pattern" ":" key-use "," pattern-info
key-use = "cover-key" | "auth-key" | "signing-key"
Your-Key-Pattern =
"Your-Key-Pattern" ":" key-use "," pattern-info
key-use = "cover-key" | "auth-key" | "signing-key"
This header specifies desired values for key names used for encryption of transaction keys using the Prearranged-Key-Info syntax of section 2.3.5. The pattern-info syntax consists of a series of comma separated regular expressions. Commas should be escaped with backslashes if they appear in the regexps. The first pattern should be assumed to be the most preferred.
此标题使用第2.3.5节的预安排密钥信息语法指定用于加密事务密钥的密钥名称的所需值。模式信息语法由一系列逗号分隔的正则表达式组成。如果逗号出现在正则表达式中，则应使用反斜杠转义。应假定第一种模式是最优选的。
Auth-key patterns specify name forms desired for use for MAC authenticators. The pattern-info syntax consists of a series of comma separated regular expressions. Commas should be escaped with backslashes if they appear in the regexps. The first pattern should be assumed to be the most preferred.
身份验证密钥模式指定MAC身份验证程序所需的名称形式。模式信息语法由一系列逗号分隔的正则表达式组成。如果逗号出现在正则表达式中，则应使用反斜杠转义。应假定第一种模式是最优选的。
This parameter describes a pattern or patterns for what keys are acceptable for signing for the digital signature enhancement. The pattern-info syntax for signing-key is:
此参数描述了数字签名增强可接受签名密钥的模式。签名密钥的模式信息语法为：
pattern-info = name-domain "," pattern-data
模式信息=名称域”，“模式数据”
The only currently defined name-domain is 'DN-1779'. This parameter specifies desired values for fields of Distinguished Names. DNs are considered to be represented as specified in RFC1779, the order of fields and whitespace between fields is not significant.
当前唯一定义的域名是“DN-1779”。此参数指定可分辨名称字段的所需值。DNs被认为是按照RFC1779中的规定表示的，字段的顺序和字段之间的空白并不重要。
All RFC1779 values should use ',' as a separator rather than ';', since ';' is used as a statement separator in S-HTTP.
所有RFC1779值都应使用“，”作为分隔符，而不是“；”，自“；”起在S-HTTP中用作语句分隔符。
Pattern-data is a modified RFC1779 string, with regular expressions permitted as field values. Pattern match is performed field-wise, unspecified fields match any value (and therefore leaving the DN-Pattern entirely unspecified allows for any DN). Certificate chains may be matched as well (to allow for certificates without name subordination). DN chains are considered to be ordered left-to-right with the issuer of a given certificate on its immediate right, although issuers need not be specified. A trailing '.' indicates that the sequence of DNs is absolute. I.e. that the one furthest to the right is a root.
模式数据是经过修改的RFC1779字符串，允许使用正则表达式作为字段值。模式匹配是按字段执行的，未指定的字段匹配任何值（因此完全未指定DN模式允许任何DN）。还可以匹配证书链（以允许证书没有名称从属关系）。DN链被认为是从左到右排序的，给定证书的颁发者位于其直接右侧，尽管不需要指定颁发者。尾随“.”表示DNs序列是绝对序列。也就是说，最右边的是根。
The syntax for the pattern values is,
模式值的语法为，
Value = DN-spec *("," Dn-spec)["."]
Dn-spec = "/" *(Field-spec) "/"
Field-spec := Attr = "Pattern"
Attr = "CN" | "L" | "ST" | "O" |
"OU" | "C" | <or as appropriate>
Pattern = <POSIX 1003.2 regular expressions>
Value = DN-spec *("," Dn-spec)["."]
Dn-spec = "/" *(Field-spec) "/"
Field-spec := Attr = "Pattern"
Attr = "CN" | "L" | "ST" | "O" |
"OU" | "C" | <or as appropriate>
Pattern = <POSIX 1003.2 regular expressions>
For example, to request that the other agent sign with a key certified by the RSA Persona CA (which uses name subordination) one could use the expression below. Note the use of RFC1779 quoting to protect the comma (an RFC1779 field separator) and the POSIX 1003.2 quoting to protect the dot (a regular expression metacharacter).
例如，要请求其他代理使用RSA Persona CA（使用名称从属）认证的密钥签名，可以使用下面的表达式。注意使用RFC1779引号保护逗号（RFC1779字段分隔符）和POSIX 1003.2引号保护点（正则表达式元字符）。
Your-Key-Pattern: signing-key, DN-1779,
/OU=Persona Certificate, O="RSA Data Security,
Inc\."/
Your-Key-Pattern: signing-key, DN-1779,
/OU=Persona Certificate, O="RSA Data Security,
Inc\."/
A representative header block for a server follows.
下面是服务器的代表性头块。
SHTTP-Privacy-Domains: recv-optional=MOSS, CMS;
orig-required=CMS
SHTTP-Certificate-Types: recv-optional=X.509;
orig-required=X.509
SHTTP-Key-Exchange-Algorithms: recv-required=DH;
orig-optional=Inband,DH
SHTTP-Signature-Algorithms: orig-required=NIST-DSS;
recv-required=NIST-DSS
SHTTP-Privacy-Enhancements: orig-required=sign;
orig-optional=encrypt
SHTTP-Privacy-Domains: recv-optional=MOSS, CMS;
orig-required=CMS
SHTTP-Certificate-Types: recv-optional=X.509;
orig-required=X.509
SHTTP-Key-Exchange-Algorithms: recv-required=DH;
orig-optional=Inband,DH
SHTTP-Signature-Algorithms: orig-required=NIST-DSS;
recv-required=NIST-DSS
SHTTP-Privacy-Enhancements: orig-required=sign;
orig-optional=encrypt
Explicit negotiation parameters take precedence over default values. For a given negotiation option type, defaults for a given mode-action pair (such as 'orig-required') are implicitly merged unless explicitly overridden.
显式协商参数优先于默认值。对于给定的协商选项类型，除非显式重写，否则将隐式合并给定模式操作对（例如“orig required”）的默认值。
The default values (these may be negotiated downward or upward) are:
默认值（可向下或向上协商）为：
SHTTP-Privacy-Domains: orig-optional=CMS;
recv-optional=CMS
SHTTP-Certificate-Types: orig-optional=X.509;
recv-optional=X.509
SHTTP-Key-Exchange-Algorithms: orig-optional=DH,Inband,Outband;
SHTTP-Privacy-Domains: orig-optional=CMS;
recv-optional=CMS
SHTTP-Certificate-Types: orig-optional=X.509;
recv-optional=X.509
SHTTP-Key-Exchange-Algorithms: orig-optional=DH,Inband,Outband;
recv-optional=DH,Inband,Outband
SHTTP-Signature-Algorithms: orig-optional=NIST-DSS;
recv-optional=NIST-DSS
SHTTP-Message-Digest-Algorithms: orig-optional=RSA-MD5;
recv-optional=RSA-MD5
SHTTP-Symmetric-Content-Algorithms: orig-optional=DES-CBC;
recv-optional=DES-CBC
SHTTP-Symmetric-Header-Algorithms: orig-optional=DES-ECB;
recv-optional=DES-ECB
SHTTP-Privacy-Enhancements: orig-optional=sign,encrypt, auth;
recv-required=encrypt;
recv-optional=sign, auth
3.3. Non-Negotiation Headers
recv-optional=DH,Inband,Outband
SHTTP-Signature-Algorithms: orig-optional=NIST-DSS;
recv-optional=NIST-DSS
SHTTP-Message-Digest-Algorithms: orig-optional=RSA-MD5;
recv-optional=RSA-MD5
SHTTP-Symmetric-Content-Algorithms: orig-optional=DES-CBC;
recv-optional=DES-CBC
SHTTP-Symmetric-Header-Algorithms: orig-optional=DES-ECB;
recv-optional=DES-ECB
SHTTP-Privacy-Enhancements: orig-optional=sign,encrypt, auth;
recv-required=encrypt;
recv-optional=sign, auth
3.3. Non-Negotiation Headers
There are a number of options that are used to communicate or identify the potential recipient's keying material.
有许多选项可用于传达或识别潜在收件人的键入材料。
This header identifies a potential principal for whom the message described by these options could be encrypted; Note that this explicitly permits return encryption under (say) public key without the other agent signing first (or under a different key than that of the signature). The syntax of the Encryption-Identity line is:
此标头标识了一个可能的主体，这些选项描述的消息可以对该主体进行加密；注意，这显式地允许在（比如）公钥下返回加密，而不需要其他代理先签名（或者使用与签名不同的密钥）。加密标识行的语法为：
Encryption-Identity = "Encryption Identity" ":" name-class,key-sel,name-arg name-class = "DN-1779" | MOSS name forms
Encryption Identity=“Encryption Identity”“：“名称类，密钥选择，名称arg name class=“DN-1779”| MOSS名称表单
The name-class is an ASCII string representing the domain within which the name is to be interpreted, in the spirit of MOSS. In addition to the MOSS name forms of RFC1848, we add the DN-1779 name form to represent a more convenient form of distinguished name.
name类是一个ASCII字符串，表示要在其中解释名称的域，符合MOSS的精神。除了RFC1848的MOSS名称形式外，我们还添加了DN-1779名称形式，以表示更方便的可分辨名称形式。
The argument is an RFC-1779 encoded DN.
参数是RFC-1779编码的DN。
In order to permit public key operations on DNs specified by Encryption-Identity headers without explicit certificate fetches by the receiver, the sender may include certification information in the Certificate-Info option. The format of this option is:
为了允许在加密标识头指定的DNs上进行公钥操作，而无需接收方显式获取证书，发送方可以在证书信息选项中包含证书信息。此选项的格式为：
Certificate-Info: <Cert-Fmt>','<Cert-Group>
Certificate-Info: <Cert-Fmt>','<Cert-Group>
<Cert-Fmt> should be the type of <Cert-Group> being presented.
<Cert Fmt>应为所呈现的<Cert Group>类型。
Defined values are 'PEM' and 'CMS'. CMS certificate groups are provided as a base-64 encoded CMS SignedData message containing sequences of certificates with or without the SignerInfo field. A PEM format certificate group is a list of comma-separated base64-encoded PEM certificates.
定义值为“PEM”和“CMS”。CMS证书组以base-64编码的CMS SignedData消息的形式提供，其中包含证书序列（带或不带SignerInfo字段）。PEM格式证书组是逗号分隔的base64编码PEM证书列表。
Multiple Certificate-Info lines may be defined.
可以定义多个证书信息行。
This option serves to indicate that the agent wishes to bind a key to a symbolic name for (presumably) later reference.
此选项用于指示代理希望将密钥绑定到符号名，以便（可能）以后引用。
The general syntax of the key-assign header is:
密钥分配头的一般语法为：
Key-Assign = "Key-Assign" ":" Method "," Key-Name "," Lifetime "," Ciphers ";" Method-args
Key Assign=“Key Assign”“：“方法”、“密钥名”、“生存期”、“密码”；“方法参数”
Key-name = string
Lifetime = "this" | "reply" | ""
Method ="inband"
Ciphers = "null" | Cipher+
Cipher" = <Header cipher from section 3.2.4.7>
kv = "4" | "5"
Key-name = string
Lifetime = "this" | "reply" | ""
Method ="inband"
Ciphers = "null" | Cipher+
Cipher" = <Header cipher from section 3.2.4.7>
kv = "4" | "5"
Key-Name is the symbolic name to which this key is to be bound. Ciphers is a list of ciphers for which this key is potentially applicable (see the list of header ciphers in section 3.2.4.7). The keyword 'null' should be used to indicate that it is inappropriate for use with ANY cipher. This is potentially useful for exchanging keys for MAC computation.
Key Name是此键要绑定到的符号名。密码是该密钥可能适用的密码列表（参见第3.2.4.7节中的标题密码列表）。关键字“null”应用于表示不适合与任何密码一起使用。这对于为MAC计算交换密钥可能很有用。
Lifetime is a representation of the longest period of time during which the recipient of this message can expect the sender to accept that key. 'this' indicates that it is likely to be valid only for reading this transmission. 'reply' indicates that it is useful for a reply to this message. If a Key-Assign with the reply lifetime appears in a CRYPTOPTS block, it indicates that it is good for at least one (but perhaps only one) dereference of this anchor. An unspecified lifetime implies that this key may be reused for an indefinite number of transactions.
“生存期表示此邮件的收件人期望发件人接受该密钥的最长时间。”这“表示它可能仅对读取此传输有效。”“回复”表示它对回复此邮件很有用。如果在CRYPTOPTS块中出现一个具有应答生存期的密钥分配，则表明该密钥分配对于该锚的至少一次（但可能仅一次）解引用是有效的。未指定的生存期意味着此密钥可用于无限数量的事务。
Method should be one of a number of key exchange methods. The only currently defined value is 'inband' referring to Inband keys (i.e., direct assignment).
方法应该是多个密钥交换方法之一。当前唯一定义的值是“带内键”，指带内键（即直接赋值）。
This header line may appear either in an unencapsulated header or in an encapsulated message, though when an uncovered key is being directly assigned, it may only appear in an encrypted encapsulated content. Assigning to a key that already exists causes that key to be overwritten.
此标题行可能出现在未封装的标题或封装的消息中，但当直接分配未覆盖的密钥时，它可能只出现在加密的封装内容中。分配给已存在的密钥会导致该密钥被覆盖。
Keys defined by this header are referred to elsewhere in this specification as Key-IDs, which have the syntax:
此标头定义的键在本规范的其他地方称为键ID，其语法如下：
Key-ID = method ":" key-name
密钥ID=方法“：”密钥名称
This refers to the direct assignment of an uncovered key to a symbolic name. Method-args should be just the desired session key encoded in hexidecimal as in:
这是指将未覆盖的密钥直接分配给符号名。方法args应该是以十六进制编码的所需会话密钥，如中所示：
Key-Assign: inband,akey,reply,DES-ECB;0123456789abcdef
密钥分配：带内、akey、应答、DES-ECB；0123456789abcdef
Short keys should be derived from long keys by reading bits from left to right.
短键应该通过从左到右读取位从长键派生而来。
Note that inband key assignment is especially important in order to permit confidential spontaneous communication between agents where one (but not both) of the agents have key pairs. However, this mechanism is also useful to permit key changes without public key computations. The key information is carried in this header line must be in the inner secured HTTP request, therefore use in unencrypted messages is not permitted.
请注意，带内密钥分配特别重要，以便允许在一个（但不是两个）代理具有密钥对的代理之间进行保密的自发通信。然而，这种机制也有助于允许在不进行公钥计算的情况下更改密钥。此头行中携带的密钥信息必须在内部安全HTTP请求中，因此不允许在未加密消息中使用。
Nonces are opaque, transient, session-oriented identifiers which may be used to provide demonstrations of freshness. Nonce values are a local matter, although they are might well be simply random numbers generated by the originator. The value is supplied simply to be returned by the recipient.
nonce是不透明的、暂时的、面向会话的标识符，可用于演示新鲜度。Nonce值是一个局部问题，尽管它们很可能只是发起者生成的随机数。提供该值只是为了让接收方返回。
This header is used by an originator to specify what value is to be returned in the reply. The field may be any value. Multiple nonces may be supplied, each to be echoed independently.
发起者使用此标题指定回复中要返回的值。该字段可以是任何值。可以提供多个nonce，每个nonce独立地被回声。
The Nonce should be returned in a Nonce-Echo header line. See section 4.1.1.
Nonce应在Nonce Echo头行中返回。见第4.1.1节。
In order for servers to bind a group of headers to an HTML anchor, it is possible to combine a number of headers on a single S-HTTP Cryptopts header line. The names of the anchors to which these headers apply is indicated with a 'scope' parameter.
为了让服务器将一组头绑定到HTML锚，可以在单个S-HTTP Cryptopts头行上组合多个头。这些头应用到的锚的名称用“scope”参数表示。
This option provides a set of cryptopts and a list of references to which it applies. (For HTML, these references would be named using the NAME tag). The names are provided in the scope attribute as a comma separated list and separated from the next header line by a semicolon. The format for the SHTTP-Cryptopts line is:
此选项提供一组CryptoPt及其应用的引用列表。（对于HTML，这些引用将使用NAME标记命名）。这些名称在scope属性中以逗号分隔的列表形式提供，并用分号与下一标题行分隔。SHTTP Cryptopts行的格式为：
SHTTP-Cryptopts =
"SHTTP-Cryptopts" ":" scope ";" cryptopt-list
scope = "scope="<tag-spec> ; This is all one token without whitespace
tag-spec = tag *("," tag) | ""
cryptopt-list = cryptopt *(";" cryptopt)
cryptopt = <S-HTTP cryptopt lines described below>
tag = <value used in HTML anchor NAME attribute>
SHTTP-Cryptopts =
"SHTTP-Cryptopts" ":" scope ";" cryptopt-list
scope = "scope="<tag-spec> ; This is all one token without whitespace
tag-spec = tag *("," tag) | ""
cryptopt-list = cryptopt *(";" cryptopt)
cryptopt = <S-HTTP cryptopt lines described below>
tag = <value used in HTML anchor NAME attribute>
For example:
例如：
SHTTP-Cryptopts: scope=tag1,tag2;
SHTTP-Privacy-Domains:
orig-required=cms; recv-optional=cms,MOSS
SHTTP-Cryptopts: scope=tag1,tag2;
SHTTP-Privacy-Domains:
orig-required=cms; recv-optional=cms,MOSS
If a message contains both S-HTTP negotiation headers and headers grouped on SHTTP-Cryptopts line(s), the other headers shall be taken to apply to all anchors not bound on the SHTTP-Cryptopts line(s). Note that this is an all-or-nothing proposition. That is, if a SHTTP-Cryptopts header binds options to a reference, then none of these global options apply, even if some of the options headers do not appear in the bound options. Rather, the S-HTTP defaults found in Section 3.2.4.11 apply.
如果消息同时包含S-HTTP协商头和分组在SHTTP Cryptopts线上的头，则其他头应适用于所有未绑定在SHTTP Cryptopts线上的锚。请注意，这是一个全有或全无的命题。也就是说，如果SHTTP Cryptopts头将选项绑定到引用，则这些全局选项都不适用，即使某些选项头没有出现在绑定的选项中。相反，第3.2.4.11节中的S-HTTP默认值适用。
Two non-negotiation header lines for HTTP are defined here.
这里定义了HTTP的两个非协商头行。
All S-HTTP compliant agents must generate the Security-Scheme header in the headers of all HTTP messages they generate. This header permits other agents to detect that they are communicating with an S-HTTP compliant agent and generate the appropriate cryptographic
所有符合S-HTTP的代理必须在其生成的所有HTTP消息的头中生成安全方案头。此标头允许其他代理检测到它们正在与符合S-HTTP的代理通信，并生成适当的密码
options headers.
选项标题。
For implementations compliant with this specification, the value must be 'S-HTTP/1.4'.
对于符合此规范的实现，值必须为“S-HTTP/1.4”。
The header is used to return the value provided in a previously received Nonce: field. This has to go in the encapsulated headers so that it an be cryptographically protected.
标头用于返回以前收到的Nonce:字段中提供的值。这必须放在封装的头文件中，以便对其进行加密保护。
We describe here the special processing appropriate for client retries in the face of servers returning an error status.
我们在这里描述了在服务器返回错误状态时适用于客户端重试的特殊处理。
A server may respond to a client request with an error code that indicates that the request has not completely failed but rather that the client may possibly achieve satisfaction through another request. HTTP already has this concept with the 3XX redirection codes.
服务器可以使用错误代码响应客户机请求，该错误代码指示该请求尚未完全失败，但客户机可能通过另一个请求获得满足。HTTP已经有了3XX重定向代码的概念。
In the case of S-HTTP, it is conceivable (and indeed likely) that the server expects the client to retry his request using another set of cryptographic options. E.g., the document which contains the anchor that the client is dereferencing is old and did not require digital signature for the request in question, but the server now has a policy requiring signature for dereferencing this URL. These options should be carried in the header of the encapsulated HTTP message, precisely as client options are carried.
在S-HTTP的情况下，服务器期望客户机使用另一组加密选项重试他的请求是可以想象的（而且确实很可能）。例如，包含客户端正在解引用的锚的文档是旧的，并且不需要对所讨论的请求进行数字签名，但是服务器现在有一个策略，要求对该URL进行解引用。这些选项应该在封装的HTTP消息的头中携带，就像携带客户端选项一样。
The general idea is that the client will perform the retry in the manner indicated by the combination of the original request and the precise nature of the error and the cryptographic enhancements depending on the options carried in the server response.
一般的想法是，客户端将以原始请求和错误的精确性质以及加密增强（取决于服务器响应中携带的选项）的组合所指示的方式执行重试。
The guiding principle in client response to these errors should be to provide the user with the same sort of informed choice with regard to dereference of these anchors as with normal anchor dereference. For instance, in the case above, it would be inappropriate for the client to sign the request without requesting permission for the action.
客户对这些错误的响应的指导原则应该是为用户提供与正常锚取消参考相同的关于这些锚取消参考的知情选择。例如，在上述情况下，客户端在未请求操作许可的情况下签署请求是不合适的。
The HTTP errors 'Unauthorized 401', 'PaymentRequired 402' represent failures of HTTP style authentication and payment schemes. While S-HTTP has no explicit support for these mechanisms, they can be performed under S-HTTP while taking advantage of the privacy services offered by S-HTTP. (There are other errors for S-HTTP specific authentication errors.)
HTTP错误“Unauthorized 401”、“PaymentRequired 402”表示HTTP样式的身份验证和支付方案失败。虽然S-HTTP对这些机制没有明确的支持，但它们可以在S-HTTP下执行，同时利用S-HTTP提供的隐私服务。（S-HTTP特定身份验证错误还有其他错误。）
This server status reply is provided so that the server may inform the client that although the current request is rejected, a retried request with different cryptographic enhancements is worth attempting. This header shall also be used in the case where an HTTP request has been made but an S-HTTP request should have been made. Obviously, this serves no useful purpose other than signalling an error if the original request should have been encrypted, but in other situations (e.g. access control) may be useful.
提供此服务器状态回复是为了让服务器可以通知客户端，尽管当前请求被拒绝，但具有不同加密增强功能的重试请求值得尝试。如果已发出HTTP请求，但应发出S-HTTP请求，则也应使用此标头。显然，如果原始请求应该被加密，那么除了发出错误信号外，这没有任何用处，但在其他情况下（例如访问控制）可能有用。
In the case of a request that was made as an SHTTP request, it indicates that for some reason the cryptographic enhancements applied to the request were unsatisfactory and that the request should be repeated with the options found in the response header. Note that this can be used as a way to force a new public key negotiation if the session key in use has expired or to supply a unique nonce for the purposes of ensuring request freshness.
对于作为SHTTP请求发出的请求，它表示出于某种原因，应用于该请求的加密增强不令人满意，应使用响应标头中的选项重复该请求。请注意，如果正在使用的会话密钥已过期，这可以作为强制新公钥协商的一种方式，或者为确保请求新鲜度而提供唯一的nonce。
If the 420 code is returned in response to an HTTP request, it indicates that the request should be retried using S-HTTP and the cryptographic options indicated in the response header.
如果返回420代码以响应HTTP请求，则表明应使用S-HTTP和响应头中指示的加密选项重试该请求。
This error code indicates that something about the S-HTTP request was bad. The error code is to be followed by an appropriate explanation, e.g.:
此错误代码表示S-HTTP请求有问题。错误代码后面应附有适当的解释，例如：
421 BogusHeader Content-Privacy-Domain must be specified
421必须指定Boguheader内容隐私域
This response is analagous to the 420 response except that the options in the message refer to enhancements that the client must perform in order to satisfy the proxy.
此响应与420响应类似，只是消息中的选项指的是客户端必须执行的增强，以满足代理的要求。
This response code is specifically for use with proxy-server interaction where the proxy has placed the If-Modified-Since header in the S-HTTP headers of its request. This response indicates that the following S-HTTP message contains sufficient keying material for the proxy to forward the cached document for the new requestor.
此响应代码专门用于代理服务器交互，其中代理已将If-Modified-Since头放在其请求的S-HTTP头中。此响应表示以下S-HTTP消息包含足够的密钥材料，以便代理将缓存文档转发给新请求者。
In general, this takes the form of an S-HTTP message where the actual enhanced content is missing, but all the headers and keying material are retained. (I.e. the optional content section of the CMS message has been removed.) So, if the original response was encrypted, the response contains the original DEK re-covered for the new recipient. (Notice that the server performs the same processing as it would have in the server side caching case of 7.1 except that the message body is elided.)
通常，这采用S-HTTP消息的形式，其中缺少实际的增强内容，但保留了所有标题和键控材料。（即CMS消息的可选内容部分已被删除。）因此，如果原始响应已加密，则响应包含为新收件人重新覆盖的原始DEK。（请注意，服务器执行与7.1的服务器端缓存情况相同的处理，只是省略了消息体。）
These headers are again internal to HTTP, but may contain S-HTTP negotiation options of significance to S-HTTP. The request should be redirected in the sense of HTTP, with appropriate cryptographic precautions being observed.
这些头也是HTTP内部的，但可能包含对S-HTTP具有重要意义的S-HTTP协商选项。请求应该在HTTP的意义上重定向，并遵守适当的加密预防措施。
Permitting automatic client retry in response to this sort of server response permits several forms of attack. Consider for the moment the simple credit card case:
允许自动客户端重试以响应此类服务器响应允许多种形式的攻击。暂时考虑一下信用卡的简单情况：
The user views a document which requires his credit card. The user verifies that the DN of the intended recipient is acceptable and that the request will be encrypted and dereferences the anchor. The attacker intercepts the server's reply and responds with a message encrypted under the client's public key containing the Moved 301 header. If the client were to automatically perform this redirect it would allow compromise of the user's credit card.
用户查看需要其信用卡的文档。用户验证预期收件人的DN是否可接受，请求是否将被加密并取消对锚的引用。攻击者截获服务器的回复，并使用包含Moved 301标头的客户端公钥下加密的消息进行响应。如果客户端自动执行此重定向，将允许泄露用户的信用卡。
This shows one possible danger of automatic retries -- potential compromise of encrypted information. While it is impossible to consider all possible cases, clients should never automatically reencrypt data unless the server requesting the retry proves that he already has the data. So, situations in which it would be acceptable to reencrypt would be if:
这显示了自动重试的一个可能危险——加密信息的潜在危害。虽然不可能考虑所有可能的情况，但客户端不应该自动重新加密数据，除非请求重试的服务器证明他已经拥有数据。因此，可以接受重新加密的情况是：
1. The retry response was returned encrypted under an inband key freshly generated for the original request. 2. The retry response was signed by the intended recipient of the original request. 3. The original request used an outband key and the response is encrypted under that key.
1. 重试响应是在为原始请求新生成的带内密钥下加密返回的。2.重试响应由原始请求的预期收件人签名。3.原始请求使用带外密钥，响应在该密钥下加密。
This is not an exhaustive list, however the browser author would be well advised to consider carefully before implementing automatic reencryption in other cases. Note that an appropriate behavior in cases where automatic reencryption is not appropriate is to query the user for permission.
这不是一个详尽的列表，但是在其他情况下，在实现自动重加密之前，最好仔细考虑浏览器作者。请注意，在不适合自动重新加密的情况下，适当的行为是查询用户的权限。
Since we discourage automatic (without user confirmation) signing in even the usual case, and given the dangers described above, it is prohibited to automatically retry signature enchancement.
由于我们不鼓励在通常情况下自动（无需用户确认）签名，并且考虑到上述危险，因此禁止自动重试签名增强。
Assuming that all the other conditions are followed, it is permissible to automatically retry MAC authentication.
假设遵循所有其他条件，则允许自动重试MAC身份验证。
Servers which receive requests in the clear which should be secured should return 'SecurityRetry 420' with header lines set to indicate the required privacy enhancements.
以明文形式接收请求的服务器应返回“SecurityRetry 420”，并设置标题行以指示所需的隐私增强功能。
We define a new URL protocol designator, 'shttp'. Use of this designator as part of an anchor URL implies that the target server is S-HTTP capable, and that a dereference of this URL should undergo S-HTTP processing.
我们定义了一个新的URL协议指示符“shttp”。将此指示符用作锚URL的一部分意味着目标服务器支持S-HTTP，并且此URL的解引用应经过S-HTTP处理。
Note that S-HTTP oblivious agents should not be willing to dereference a URL with an unknown protocol specifier, and hence sensitive data will not be accidentally sent in the clear by users of non-secure clients.
请注意，S-HTTP不经意的代理不应该愿意使用未知的协议说明符取消对URL的引用，因此非安全客户端的用户不会意外地以明文形式发送敏感数据。
While preparing a secure message, the browser should provide a visual indication of the security of the transaction, as well as an indication of the party who will be able to read the message. While reading a signed and/or enveloped message, the browser should indicate this and (if applicable) the identity of the signer. Self-signed certificates should be clearly differentiated from those validated by a certification hierarchy.
在准备安全消息时，浏览器应提供交易安全性的视觉指示，以及能够阅读消息的一方的指示。在阅读签名和/或信封信息时，浏览器应指明签名者的身份（如适用）。自签名证书应与通过证书层次结构验证的证书明确区分。
Failure to authenticate or decrypt an S-HTTP message should be presented differently from a failure to retrieve the document. Compliant clients may at their option display unverifiable documents but must clearly indicate that they were unverifiable in a way clearly distinct from the manner in which they display documents which possessed no digital signatures or documents with verifiable signatures.
验证或解密S-HTTP消息失败与检索文档失败的表现形式应不同。合规客户可自行选择显示不可验证的文件，但必须明确表明其不可验证的方式与他们显示不具有数字签名的文件或具有可验证签名的文件的方式明显不同。
Clients shall provide a method for determining that HTTP requests are to be signed and for determining which (assuming there are many) certificate is to be used for signature. It is suggested that users be presented with some sort of selection list from which they may choose a default. No signing should be performed without some sort of explicit user interface action, though such action may take the form of a persistent setting via a user preferences mechanism (although this is discouraged.)
客户端应提供一种方法，用于确定HTTP请求将被签名，以及确定将使用哪个（假设有多个）证书进行签名。建议向用户提供某种选择列表，用户可以从中选择默认值。如果没有某种明确的用户界面操作，则不应执行任何签名，尽管此类操作可能通过用户首选项机制采取持久设置的形式（尽管不鼓励这样做）
Clients shall provide a method to display the DN and certificate chain associated with a given anchor to be dereferenced so that users may determine for whom their data is being encrypted. This should be distinct from the method for displaying who has signed the document containing the anchor since these are orthogonal pieces of encryption information.
客户端应提供一种方法来显示与要取消引用的给定锚相关联的DN和证书链，以便用户可以确定为谁加密其数据。这应该与显示谁在包含锚的文档上签名的方法不同，因为这些是正交的加密信息。
While S-HTTP has always supported preenhanced documents, in previous versions it was never made clear how to actually implement them. This section describes two methods for doing so: preenhancing the HTTP request/response and preenhancing the underlying data.
虽然S-HTTP始终支持预先增强的文档，但在以前的版本中，从未明确说明如何实际实现它们。本节介绍两种方法：预先增强HTTP请求/响应和预先增强底层数据。
The two primary motivations for preenhanced documents are security and performance. These advantages primarily accrue to signing but may also under special circumstances apply to confidentiality or repudiable (MAC-based) authentication.
预增强文档的两个主要动机是安全性和性能。这些优势主要来自于签名，但在特殊情况下也可能适用于保密性或可重认性（基于MAC的）身份验证。
Consider the case of a server which repeatedly serves the same content to multiple clients. One such example would be a server which serves catalogs or price lists. Clearly, customers would like to be able to verify that these are actual prices. However, since the prices are typically the same to all comers, confidentiality is not an issue. (Note: see Section 7.1.5 below for how to deal with this case as well).
考虑服务器对多个客户端重复服务相同内容的情况。一个这样的例子是提供目录或价目表的服务器。显然，客户希望能够验证这些是实际价格。然而，由于价格通常对所有参与者都是相同的，因此保密性不是问题。（注：关于如何处理这种情况，请参见下文第7.1.5节）。
Consequently, the server might wish to sign the document once and simply send the cached signed document out when a client makes a new request, avoiding the overhead of a private key operation each time. Note that conceivably, the signed document might have been generated by a third party and placed in the server's cache. The server might not even have the signing key! This illustrates the security benefit of presigning: Untrusted servers can serve authenticated data without risk even if the server is compromised.
因此，服务器可能希望对文档进行一次签名，并在客户端发出新请求时将缓存的签名文档发送出去，从而避免每次私钥操作的开销。请注意，可以想象，已签名的文档可能由第三方生成并放置在服务器的缓存中。服务器甚至可能没有签名密钥！这说明了预签名的安全好处：即使服务器受到威胁，不受信任的服务器也可以提供经过身份验证的数据，而不会带来风险。
The obvious implementation is simply to take a single request/response, cache it, and send it out in situations where a new message would otherwise be generated.
显而易见的实现就是简单地获取单个请求/响应，缓存它，并在可能生成新消息的情况下将其发送出去。
It is also possible using S-HTTP to sign the underlying data and send it as an S-HTTP messsage. In order to do this, one would take the signed document (a CMS or MOSS message) and attach both S-HTTP headers (e.g. the S-HTTP request/response line, the Content-Privacy-Domain) and the necessary HTTP headers (including a Content-Type that reflects the inner content).
也可以使用S-HTTP对底层数据进行签名，并将其作为S-HTTP消息发送。为了做到这一点，可以获取已签名的文档（CMS或MOSS消息）并附加S-HTTP头（例如S-HTTP请求/响应行、内容隐私域）和必要的HTTP头（包括反映内部内容的内容类型）。
SECURE * Secure-HTTP/1.4
Content-Type: text/html
Content-Privacy-Domain: CMS
SECURE * Secure-HTTP/1.4
Content-Type: text/html
Content-Privacy-Domain: CMS
Random signed message here...
这里是随机签名的消息。。。
This message itself cannot be sent, but needs to be recursively encapsulated, as described in the next section.
此消息本身无法发送，但需要递归封装，如下一节所述。
As required by Section 7.3, the result above needs to be itself encapsulated to protect the HTTP headers. the obvious case [and the one illustrated here] is when confidentiality is required, but the auth enhancement or even the null transform might be applied instead. That is, the message shown above can be used as the inner content of a new S-HTTP message, like so:
根据第7.3节的要求，上面的结果本身需要封装以保护HTTP头。显而易见的情况[这里所示的情况]是当需要保密性时，但是可以应用身份验证增强甚至空转换。也就是说，上面显示的消息可以用作新S-HTTP消息的内部内容，如下所示：
SECURE * Secure-HTTP/1.4
Content-Type: application/s-http
Content-Privacy-Domain: CMS
SECURE * Secure-HTTP/1.4
Content-Type: application/s-http
Content-Privacy-Domain: CMS
Encrypted version of the message above...
上面邮件的加密版本。。。
To unfold this, the receiver would decode the outer S-HTTP message, reenter the (S-)HTTP parsing loop to process the new message, see that that too was S-HTTP, decode that, and recover the inner content.
要展开此过程，接收方将解码外部S-HTTP消息，重新进入（S-）HTTP解析循环以处理新消息，查看该消息也是S-HTTP，对其进行解码，然后恢复内部内容。
Note that this approach can also be used to provide freshness of server activity (though not of the document itself) while still providing nonrepudiation of the document data if a NONCE is included in the request.
请注意，这种方法还可以用于提供服务器活动的新鲜度（尽管不是文档本身），同时如果请求中包含NONCE，则仍然提供文档数据的不可否认性。
Although preenhancement works best with signature, it can also be used with encryption under certain conditions. Consider the situation where the same confidential document is to be sent out repeatedly. The time spent to encrypt can be saved by caching the ciphertext and simply generating a new key exchange block for each recipient. [Note that this is logically equivalent to a multi- recipient message as defined in both MOSS and CMS and so care must be taken to use proper PKCS-1 padding if RSA is being used since otherwise, one may be open to a low encryption exponent attack [HAST96].
虽然预增强最适用于签名，但在某些条件下也可以用于加密。考虑重复发送相同机密文件的情况。通过缓存密文并为每个收件人生成一个新的密钥交换块，可以节省加密所花费的时间。[请注意，这在逻辑上等同于MOSS和CMS中定义的多收件人邮件，因此如果使用RSA，则必须小心使用适当的PKCS-1填充，否则可能会受到低加密指数攻击[HAST96]。
The use of S-HTTP presents implementation issues to the use of HTTP proxies. While simply having the proxy blindly forward responses is straightforward, it would be preferable if S-HTTP aware proxies were still able to cache responses in at least some circumstances. In addition, S-HTTP services should be usable to protect client-proxy authentication. This section describes how to achieve those goals using the mechanisms described above.
S-HTTP的使用给HTTP代理的使用带来了实现问题。虽然简单地让代理盲目地转发响应是简单的，但如果S-HTTP感知代理至少在某些情况下仍然能够缓存响应，则更好。此外，S-HTTP服务应可用于保护客户端代理身份验证。本节介绍如何使用上述机制实现这些目标。
When an S-HTTP aware proxy receives a request (HTTP or S-HTTP) that (by whatever access control rules it uses) it requires to be S-HTTP authenticated (and if it isn't already so), it should return the 422 response code (5.7.4).
当支持S-HTTP的代理收到一个请求（HTTP或S-HTTP）时（根据其使用的任何访问控制规则），它需要进行S-HTTP身份验证（如果还没有），它应该返回422响应代码（5.7.4）。
When the client receives the 422 response code, it should read the cryptographic options that the proxy sent and determine whether or not it is willing to apply that enhancement to the message. If the client is willing to meet these requirements, it should recursively encapsulate the request it previously sent using the appropriate options. (Note that since the enhancement is recursively applied, even clients which are unwilling to send requests to servers in the clear may be willing to send the already encrypted message to the proxy without further encryption.) (See Section 7.1 for another example of a recursively encapsulated message)
当客户端收到422响应代码时，它应该读取代理发送的加密选项，并确定是否愿意将该增强应用于消息。如果客户机愿意满足这些要求，它应该使用适当的选项递归地封装它以前发送的请求。（注意，由于该增强是递归应用的，即使是不愿意向clear中的服务器发送请求的客户端也可能愿意将已加密的消息发送到代理，而无需进一步加密。）（递归封装消息的另一个示例见第7.1节）
When the proxy receives such a message, it should strip the outer encapsulation to recover the message which should be sent to the server.
当代理收到这样的消息时，它应该剥离外部封装以恢复应该发送到服务器的消息。
All S-HTTP agents must support the MD5 message digest and MAC authentication. As of S-HTTP/1.4, all agents must also support the RSA-MD5-HMAC construction.
所有S-HTTP代理必须支持MD5消息摘要和MAC身份验证。从S-HTTP/1.4开始，所有代理还必须支持RSA-MD5-HMAC构造。
All S-HTTP agents must support Outband, Inband, and DH key exchange.
所有S-HTTP代理必须支持带外、带内和DH密钥交换。
All agents must support encryption using DES-CBC.
所有代理必须支持使用DES-CBC进行加密。
Agents must support signature generation and verification using NIST-DSS.
代理商必须支持使用NIST-DSS生成和验证签名。
We present below a summary of the main syntactic features of S-HTTP/1.4, excluding message encapsulation proper.
下面我们总结了S-HTTP/1.4的主要语法特征，不包括消息封装本身。
Content-Privacy-Domain: ('CMS' | 'MOSS')
Prearranged-Key-Info: <Hdr-Cipher>,<Key>,<Key-ID>
Content-Type: 'message/http'
MAC-Info: [hex(timeofday)',']<hash-alg>','hex(<hash-data>)','
<key-spec>
Content-Privacy-Domain: ('CMS' | 'MOSS')
Prearranged-Key-Info: <Hdr-Cipher>,<Key>,<Key-ID>
Content-Type: 'message/http'
MAC-Info: [hex(timeofday)',']<hash-alg>','hex(<hash-data>)','
<key-spec>
Key-Assign: <Method>','<Key-Name>','<Lifetime>','
<Ciphers>';'<Method-args>
Encryption-Identity: <name-class>','<key-sel>','<name-args>
Certificate-Info: <Cert-Fmt>','<Cert-Group>
Nonce: <string>
Nonce-Echo: <string>
Key-Assign: <Method>','<Key-Name>','<Lifetime>','
<Ciphers>';'<Method-args>
Encryption-Identity: <name-class>','<key-sel>','<name-args>
Certificate-Info: <Cert-Fmt>','<Cert-Group>
Nonce: <string>
Nonce-Echo: <string>
SHTTP-Cryptopts: <scope>';'<string>(,<string>)*
SHTTP-Privacy-Domains: ('CMS' | 'MOSS')
SHTTP-Certificate-Types: ('X.509')
SHTTP-Key-Exchange-Algorithms: ('DH', 'RSA' | 'Inband' | 'Outband')
SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS')
SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS'
'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC')
SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' |
'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' |
'RC2-CBC' )
SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' |
'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' |
'RC2-ECB')
SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth')
Your-Key-Pattern: <key-use>','<pattern-info>
SHTTP-Cryptopts: <scope>';'<string>(,<string>)*
SHTTP-Privacy-Domains: ('CMS' | 'MOSS')
SHTTP-Certificate-Types: ('X.509')
SHTTP-Key-Exchange-Algorithms: ('DH', 'RSA' | 'Inband' | 'Outband')
SHTTP-Signature-Algorithms: ('RSA' | 'NIST-DSS')
SHTTP-Message-Digest-Algorithms: ('RSA-MD2' | 'RSA-MD5' | 'NIST-SHS'
'RSA-MD2-HMAC', 'RSA-MD5-HMAC', 'NIST-SHS-HMAC')
SHTTP-Symmetric-Content-Algorithms: ('DES-CBC' | 'DES-EDE-CBC' |
'DES-EDE3-CBC' | 'DESX-CBC' | 'CDMF-CBC' | 'IDEA-CBC' |
'RC2-CBC' )
SHTTP-Symmetric-Header-Algorithms: ('DES-ECB' | 'DES-EDE-ECB' |
'DES-EDE3-EBC' | 'DESX-ECB' | 'CDMF-ECB' | 'IDEA-ECB' |
'RC2-ECB')
SHTTP-Privacy-Enhancements: ('sign' | 'encrypt' | 'auth')
Your-Key-Pattern: <key-use>','<pattern-info>
Secure * Secure-HTTP/1.4
安全*安全HTTP/1.4
Secure-HTTP/1.4 200 OK SecurityRetry 420 BogusHeader 421 <reason>
安全HTTP/1.4 200 OK SecurityRetry 420 Boguheader 421<reason>
We provide here a contrived example of a series of S-HTTP requests and replies. Rows of equal signs are used to set off the narrative from sample message traces. Note that the actual encrypted or signed message bodies would normally be binary garbage. In an attempt to preserve readability while still using (mostly) genuine messages, the bodies of the requests have been base64 encoded. To regenerate actual S-HTTP messages, it is necessary to remove the base64 encoding from the message body.
我们在这里提供了一系列S-HTTP请求和响应的人为示例。等号行用于将叙述与示例消息跟踪隔开。请注意，实际加密或签名的消息体通常是二进制垃圾。为了在仍然使用（大部分）真实消息的同时保持可读性，请求的主体已经进行了base64编码。要重新生成实际的S-HTTP消息，必须从消息体中删除base64编码。
Alice, using an S-HTTP-capable client, begins by making an HTTP request which yields the following response page:
Alice使用支持S-HTTP的客户端，首先发出HTTP请求，生成以下响应页面：
============================================================
200 OK HTTP/1.0
Server-Name: Navaho-0.1.3.3alpha
Certificate-Info: CMS,MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh
kiG9w0BBwEAAKCAM
IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
AAAAA==
============================================================
200 OK HTTP/1.0
Server-Name: Navaho-0.1.3.3alpha
Certificate-Info: CMS,MIAGCSqGSIb3DQEHAqCAMIACAQExADCABgkqh
kiG9w0BBwEAAKCAM
IIBrTCCAUkCAgC2MA0GCSqGSIb3DQEBAgUAME0xCzAJBgNVBAYTAlVTMSAwH
gYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc
29uYSBDZXJ0aWZpY2F0ZTAeFw05NDA0MDkwMDUwMzdaFw05NDA4MDIxODM4N
TdaMGcxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0e
SwgSW5jLjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZTEYMBYGA1UEA
xMPU2V0ZWMgQXN0cm9ub215MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMy8Q
cW7RMrB4sTdQ8Nmb2DFmJmkWn+el+NdeamIDElX/qw9mIQu4xNj1FfepfJNx
zPvA0OtMKhy6+bkrlyMEU8CAwEAATANBgkqhkiG9w0BAQIFAANPAAYn7jDgi
rhiIL4wnP8nGzUisGSpsFsF4/7z2P2wqne6Qk8Cg/Dstu3RyaN78vAMGP8d8
2H5+Ndfhi2mRp4YHiGHz0HlK6VbPfnyvS2wdjCCAccwggFRAgUCQAAAFDANB
gkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhd
GEgU2VjdXJpdHksIEluYy4xLjAsBgNVBAsTJUxvdyBBc3N1cmFuY2UgQ2Vyd
GlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTQwMTA3MDAwMDAwWhcNOTYwMTA3M
jM1OTU5WjBNMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2Vjd
XJpdHksIEluYy4xHDAaBgNVBAsTE1BlcnNvbmEgQ2VydGlmaWNhdGUwaTANB
gkqhkiG9w0BAQEFAANYADBVAk4GqghQDa9Xi/2zAdYEqJVIcYhlLN1FpI9tX
Q1m6zZ39PYXK8Uhoj0Es7kWRv8hC04vqkOKwndWbzVtvoHQOmP8nOkkuBi+A
QvgFoRcgOUCAwEAATANBgkqhkiG9w0BAQIFAANhAD/5Uo7xDdp49oZm9GoNc
PhZcW1e+nojLvHXWAU/CBkwfcR+FSf4hQ5eFu1AjYv6Wqf430Xe9Et5+jgnM
Tiq4LnwgTdA8xQX4elJz9QzQobkE3XVOjVAtCFcmiin80RB8AAAMYAAAAAAA
AAAAA==
Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona
Certificate,O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements: recv-required=encrypt
Encryption-Identity: DN-1779, null, CN=Setec Astronomy, OU=Persona
Certificate,O="RSA Data Security, Inc.", C=US;
SHTTP-Privacy-Enhancements: recv-required=encrypt
<A name=tag1 HREF="shttp://www.setec.com/secret">
Don't read this. </A>
============================================================
<A name=tag1 HREF="shttp://www.setec.com/secret">
Don't read this. </A>
============================================================
An appropriate HTTP request to dereference this URL would be:
取消引用此URL的适当HTTP请求为：
============================================================
GET /secret HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.2beta
Accept: *.*
Key-Assign: Inband,1,reply,des-ecb;7878787878787878
============================================================
GET /secret HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.2beta
Accept: *.*
Key-Assign: Inband,1,reply,des-ecb;7878787878787878
============================================================
============================================================
The added Key-Assign line that would not have been in an ordinary HTTP request permits Bob (the server) to encrypt his reply to Alice, even though Alice does not have a public key, since they would share a key after the request is received by Bob. This request has the following S-HTTP encapsulation:
添加的密钥分配行不会出现在普通HTTP请求中，它允许Bob（服务器）加密他对Alice的回复，即使Alice没有公钥，因为Bob收到请求后，他们将共享密钥。此请求具有以下S-HTTP封装：
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Content-Privacy-Domain: CMS
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u
YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG
cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz
lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16
+mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK
BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW
Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k
1JLSAAAAAAAAAAAAAA==
============================================================
MIAGCSqGSIb3DQEHA6CAMIACAQAxgDCBqQIBADBTME0xCzAJBgNVBAYTAlVTMSAw
HgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEcMBoGA1UECxMTUGVyc29u
YSBDZXJ0aWZpY2F0ZQICALYwDQYJKoZIhvcNAQEBBQAEQCU/R+YCJSUsV6XLilHG
cNVzwqKcWzmT/rZ+duOv8Ggb7oO/d8H3xUVGQ2LsX4kYGq2szwj8Q6eWhsmhf4oz
lvMAADCABgkqhkiG9w0BBwEwEQYFKw4DAgcECFif7BadXlw3oIAEgZBNcMexKe16
+mNxx8YQPukBCL0bWqS86lvws/AgRkKPELmysBi5lco8MBCsWK/fCyrnxIRHs1oK
BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW
Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k
1JLSAAAAAAAAAAAAAA==
============================================================
The data between the delimiters is a CMS message, RSA enveloped for Setec Astronomy.
分隔符之间的数据是CMS消息，为Setec天文学封装了RSA。
Bob decrypts the request, finds the document in question, and is ready to serve it back to Alice.
Bob解密请求，找到有问题的文档，并准备将其返回给Alice。
An appropriate HTTP server response would be:
适当的HTTP服务器响应为：
============================================================
HTTP/1.0 200 OK
Security-Scheme: S-HTTP/1.4
Content-Type: text/html
============================================================
HTTP/1.0 200 OK
Security-Scheme: S-HTTP/1.4
Content-Type: text/html
Congratulations, you've won.
<A href="/prize.html"
CRYPTOPTS="Key-Assign: Inband,alice1,reply,des-ecb;020406080a0c0e0f;
SHTTP-Privacy-Enhancements: recv-required=auth">Click here to
claim your prize</A>
============================================================
Congratulations, you've won.
<A href="/prize.html"
CRYPTOPTS="Key-Assign: Inband,alice1,reply,des-ecb;020406080a0c0e0f;
SHTTP-Privacy-Enhancements: recv-required=auth">Click here to
claim your prize</A>
============================================================
This HTTP response, encapsulated as an S-HTTP message becomes:
此HTTP响应（封装为S-HTTP消息）将变为：
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1
Content-Privacy-Domain: CMS
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy
x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir
r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW
aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5
l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0
5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl
nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7
AAAAAAAAAAA=
============================================================
MIAGCSqGSIb3DQEHBqCAMIACAQAwgAYJKoZIhvcNAQcBMBEGBSsOAwIHBAifqtdy
x6uIMYCCARgvFzJtOZBn773DtmXlx037ck3giqnV0WC0QAx5f+fesAiGaxMqWcir
r9XvT0nT0LgSQ/8tiLCDBEKdyCNgdcJAduy3D0r2sb5sNTT0TyL9uydG3w55vTnW
aPbCPCWLudArI1UHDZbnoJICrVehxG/sYX069M8v6VO8PsJS7//hh1yM+0nekzQ5
l1p0j7uWKu4W0csrlGqhLvEJanj6dQAGSTNCOoH3jzEXGQXntgesk8poFPfHdtj0
5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl
nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7
AAAAAAAAAAA=
============================================================
The data between the delimiters is a CMS message encrypted under a randomly-chosen DEK which can be recovered by computing:
分隔符之间的数据是在随机选择的DEK下加密的CMS消息，可通过计算恢复：
DES-DECRYPT(inband:1,697fa820df8a6e53)
DES-解密（带内：1697FA820DF8A6E53）
where 'inband:1' is the key exchanged in the Key-Assign line in the original request.
其中，“带内：1”是原始请求中密钥分配行中交换的密钥。
There is a link on the HTML page that was just returned, which Alice dereferences, creating the HTTP message:
刚刚返回的HTML页面上有一个链接，Alice取消引用该链接，创建HTTP消息：
============================================================
GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
============================================================
GET /prize.html HTTP/1.0
Security-Scheme: S-HTTP/1.4
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
============================================================
============================================================
Which, when encapsulated as an S-HTTP message, becomes:
当封装为S-HTTP消息时，将成为：
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
MAC-Info:31ff8122,rsa-md5,b3ca4575b841b5fc7553e69b0896c416,inband:alice1
Content-Privacy-Domain: CMS
============================================================
Secure * Secure-HTTP/1.4
Content-Type: message/http
MAC-Info:31ff8122,rsa-md5,b3ca4575b841b5fc7553e69b0896c416,inband:alice1
Content-Privacy-Domain: CMS
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp
dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx
LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA
============================================================
MIAGCSqGSIb3DQEHAaCABGNHRVQgL3ByaXplLmh0bWwgSFRUUC8xLjAKU2VjdXJp
dHktU2NoZW1lOiBTLUhUVFAvMS4xClVzZXItQWdlbnQ6IFdlYi1PLVZpc2lvbiAx
LjFiZXRhCkFjY2VwdDogKi4qCgoAAAAA
============================================================
The data between the delimiters is a CMS 'Data' representation of the request.
分隔符之间的数据是请求的CMS“数据”表示。
Appendix: A Review of CMS
附录：CMS综述
CMS ("Cryptographic Message Syntax Standard") is a cryptographic message encapsulation format, similar to PEM, based on RSA's PKCS-7 cryptographic messaging syntax.
CMS（“加密消息语法标准”）是一种加密消息封装格式，类似于PEM，基于RSA的PKCS-7加密消息语法。
CMS is only one of two encapsulation formats supported by S-HTTP, but it is to be preferred since it permits the least restricted set of negotiable options, and permits binary encoding. In the interest of making this specification more self-contained, we summarize CMS here.
CMS只是S-HTTP支持的两种封装格式之一，但它是首选的，因为它允许最小限制的可协商选项集，并允许二进制编码。为了使本规范更加完备，我们在此总结CMS。
CMS is defined in terms of OSI's Abstract Syntax Notation (ASN.1, defined in X.208), and is concretely represented using ASN.1's Basic Encoding Rules (BER, defined in X.209). A CMS message is a sequence of typed content parts. There are six content types, recursively composable:
CMS是根据OSI的抽象语法表示法（ASN.1，在X.208中定义）定义的，并使用ASN.1的基本编码规则（BER，在X.209中定义）具体表示。CMS消息是一系列键入的内容部分。有六种可递归组合的内容类型：
Data -- Some bytes, with no enhancement.
数据——一些字节，没有增强。
SignedData -- A content part, with zero or more signature blocks, and associated keying materials. Keying materials can be transported via the degenerate case of no signature blocks and no data.
SignedData——内容部分，具有零个或多个签名块以及相关的密钥材料。密钥材料可以通过没有签名块和数据的退化情况传输。
EnvelopedData -- One or more (per recipient) key exchange blocks and an encrypted content part.
EnvelopedData--一个或多个（每个收件人）密钥交换块和一个加密的内容部分。
DigestedData -- A content part with a single digest block.
DigestedData--具有单个摘要块的内容部分。
EncryptedData -- An encrypted content part, with key materials externally provided.
EncryptedData--一个加密的内容部分，外部提供了密钥材料。
Here we will dispense with convention for the sake of ASN.1-impaired readers, and present a syntax for CMS in informal BNF (with much gloss). In the actual encoding, most productions have explicit tag and length fields.
在这里，为了ASN.1受损的读者，我们将省去常规，并在非正式的BNF中提供CMS的语法（非常有光泽）。在实际编码中，大多数产品都有显式的标记和长度字段。
Message = *Content
Content = Data | SignedData | EnvelopedData |
DigestedData | EncryptedData
Data = Bytes
SignedData = *DigestAlg Content *Certificates
*CRLs SignerInfo*
EnvelopedData = *RecipientInfo BulkCryptAlg
Encrypted(Content)
Message = *Content
Content = Data | SignedData | EnvelopedData |
DigestedData | EncryptedData
Data = Bytes
SignedData = *DigestAlg Content *Certificates
*CRLs SignerInfo*
EnvelopedData = *RecipientInfo BulkCryptAlg
Encrypted(Content)
DigestedData = DigestAlg Content DigestBytes
EncryptedData = BulkCryptAlg Encrypted(Bytes)
SignerInfo = CertID ... Encrypted(DigestBytes) ...
RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)
DigestedData = DigestAlg Content DigestBytes
EncryptedData = BulkCryptAlg Encrypted(Bytes)
SignerInfo = CertID ... Encrypted(DigestBytes) ...
RecipientInfo = CertID KeyCryptAlg Encrypted(DEK)
Appendix: Internet Media Type message/s-http
附录：互联网媒体类型消息/s-http
In addition to defining the S-HTTP/1.4 protocol, this document serves as the specification for the Internet media type "message/s-http". The following is to be registered with IANA.
除了定义S-HTTP/1.4协议外，本文档还作为Internet媒体类型“message/S-HTTP”的规范。以下内容将在IANA注册。
Media Type name: message Media subtype name: s-http Required parameters: none Optional parameters: version, msgtype
媒体类型名称：消息媒体子类型名称：s-http必需参数：无可选参数：版本，msgtype
version: The S-HTTP version number of the enclosed message (e.g. "1.4"). If not present, the version can be determined from the first line of the body.
版本：随附消息的S-HTTP版本号（例如“1.4”）。如果不存在，则可从正文的第一行确定版本。
msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
msgtype：消息类型--“请求”或“响应”。如果不存在，则可从主体的第一行确定类型。
Encoding considerations: only "7bit", "8bit", or "binary" are permitted.
编码注意事项：只允许使用“7位”、“8位”或“二进制”。
Security considerations: this is a security protocol.
安全注意事项：这是一个安全协议。
Bibliography and References
参考书目
[BELL96] Bellare, M., Canetti, R., Krawczyk, H., "Keying Hash Functions for Message Authentication", Preprint.
[BELL96]Bellare，M.，Canetti，R.，Krawczyk，H.，“用于消息认证的键控哈希函数”，预印本。
[FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 (supersedes FIPS PUB 46, 1977 January 15).
[FIPS-46-1]联邦信息处理标准出版物（FIPS PUB）46-1，数据加密标准，1988年1月22日重申（取代FIPS PUB 46，1977年1月15日）。
[FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
[FIPS-81]联邦信息处理标准出版物（FIPS PUB）81，DES操作模式，1980年12月2日。
[FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
[FIPS-180]联邦信息处理标准出版物（FIPS PUB）180-1，“安全哈希标准”，1995年4月17日。
[FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 1994 May 19.
[FIPS-186]联邦信息处理标准出版物（FIPS PUB）186，数字签名标准，1994年5月19日。
[HAST86] Hastad, J., "On Using RSA With Low Exponents in a Public Key Network," Advances in Cryptology-CRYPTO 95 Proceedings, Springer-Verlag, 1986.
[HAST86]Hastad，J.，“关于在公钥网络中使用低指数RSA”，密码学进展-密码95会议录，Springer Verlag，1986。
[JOHN93] Johnson, D.B., Matyas, S.M., Le, A.V., Wilkins, J.D., "Design of the Commercial Data Masking Facility Data Privacy Algorithm," Proceedings 1st ACM Conference on Computer & Communications Security, November 1993, Fairfax, VA., pp. 93-96.
[JOHN93]Johnson，D.B.，Matyas，S.M.，Le，A.V.，Wilkins，J.D.，“商业数据屏蔽设施数据隐私算法的设计”，《第一届ACM计算机与通信安全会议论文集》，1993年11月，弗吉尼亚州费尔法克斯，第93-96页。
[KRAW96b] Krawczyk, H. personal communication.
[KRAW96b]Krawczyk，H.个人沟通。
[LAI92] Lai, X. "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[LAI92]Lai，X.“关于分组密码的设计和安全性”，信息处理中的ETH系列，v。康斯坦茨：哈东·高尔·韦拉格，1992年。
[PKCS-6] RSA Data Security, Inc. "Extended Certificate Syntax Standard", PKCS-6, Nov 1, 1993.
[PKCS-6]RSA Data Security，Inc.“扩展证书语法标准”，PKCS-61993年11月1日。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC-1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
[RFC-1319]Kaliski，B.，“MD2消息摘要算法”，RFC 1319，1992年4月。
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC-1321]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[RFC-1421]Linn，J.，“互联网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 14211993年2月。
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[RFC-1422]Kent，S.，“因特网电子邮件的隐私增强：第二部分：基于证书的密钥管理”，RFC 1422，1993年2月。
[RFC-1779] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[RFC-1779]Kille，S.，“专有名称的字符串表示”，RFC 1779，1995年3月。
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, September 1993.
[RFC-2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451993年9月。
[RFC-1738] T. Berners-Lee, "Uniform Resource Locators (URLs)", RFC 1738, December 1994.
[RFC-1738]T.Berners Lee，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Muliparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847]Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[RFC-1848] Crocker, S., Freed, N., Galvin, J., and S. Murphy, "MIME Object Security Services", RFC 1848, October 1995.
[RFC-1848]Crocker，S.，Freed，N.，Galvin，J.，和S.Murphy，“MIME对象安全服务”，RFC 18481995年10月。
[RFC-1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[RFC-1864]迈尔斯，J.和M.罗斯，“内容-MD5标题字段”，RFC 18641995年10月。
[RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2616, June 1999.
[RFC-2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”RFC 2616，1999年6月。
[RFC-2617] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC-2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC-2104]Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[SHTML] Rescorla, E. and A. Schiffman, "Security Extensions For HTML", RFC 2659, August 1999.
[SHTML]Rescorla，E.和A.Schiffman，“HTML的安全扩展”，RFC 2659，1999年8月。
[VANO95] B. Prennel and P. van Oorschot, "On the security of two MAC algorithms", to appear Eurocrypt'96.
[VANO95]B.Prennel和P.van Oorschot，“关于两种MAC算法的安全性”，将出现在Eurocrypt'96上。
[X509] CCITT Recommendation X.509 (1988), "The Directory - Authentication Framework".
[X509]CCITT建议X.509（1988），“目录认证框架”。
Security Considerations
安全考虑
This entire document is about security.
整个文档都是关于安全性的。
Authors' Addresses
作者地址
Eric Rescorla RTFM, Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
Eric Rescorla RTFM，Inc.加利福尼亚州东帕洛阿尔托市纽厄尔路30号，邮编：94303
Phone: (650) 328-8631 EMail: ekr@rtfm.com
电话：（650）328-8631电子邮件：ekr@rtfm.com
Allan M. Schiffman SPYRUS/Terisa 5303 Betsy Ross Drive Santa Clara, CA 95054
阿兰·希夫曼·斯皮罗斯/特里萨5303贝西·罗斯大道圣克拉拉，加利福尼亚州95054
Phone: (408) 327-1901 EMail: ams@terisa.com
电话：（408）327-1901电子邮件：ams@terisa.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。