RFC3261: SIP:23.4.1.2 保密性

23.4.1.2 Confidentiality
23.4.1.2 保密性

   When messages are encrypted, header fields may be included in the encrypted body that are not present in the "outer" message.

当对消息进行加密时，“外部”消息中不存在的加密正文中可能会包含报头字段。

   Some header fields must always have a plaintext version because they are required header fields in requests and responses - these include:

某些报头字段必须始终具有纯文本版本，因为它们是请求和响应中必需的报头字段，包括：

   To, From, Call-ID, CSeq, Contact.  While it is probably not useful to provide an encrypted alternative for the Call-ID, CSeq, or Contact, providing an alternative to the information in the "outer" To or From is permitted.  Note that the values in an encrypted body are not used for the purposes of identifying transactions or dialogs - they are merely informational.  If the From header field in an encrypted body differs from the value in the "outer" message, the value within the encrypted body SHOULD be displayed to the user, but MUST NOT be used in the "outer" header fields of any future messages.

To, From, Call-ID, CSeq, Contact。虽然为Call-ID, CSeq或Contact提供加密的替代方案可能没有用处，但允许为“外部”To或From中的信息提供替代方案。请注意，加密主体中的值不是用于识别事务或对话的，它们只是信息性的。如果加密正文中的From报头字段与“outer”消息中的值不同，则应向用户显示加密正文内的值，但不得在任何未来消息的“outer”报头字段中使用。

   Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, and Warning.  If any of these header fields are present in an encrypted body, they should be used instead of any "outer" header fields, whether this entails displaying the header field values to users or setting internal states in the UA.  They SHOULD NOT however be used in the "outer" headers of any future messages.

用户代理主要希望加密具有端到端语义的报头字段，包括：Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server和Warning。如果这些报头字段中的任何一个存在于加密体中，则应使用它们来代替任何“outer”报头字段，无论这需要向用户显示报头字段值还是设置UA中的内部状态。但是，它们不应用于任何未来消息的“outer”报头。

   If present, the Date header field MUST always be the same in the "inner" and "outer" headers.

如果存在，“内部”和“外部”报头中的“Date”报头字段必须始终相同。

   Since MIME bodies are attached to the "inner" message, implementations will usually encrypt MIME-specific header fields, including: MIME-Version, Content-Type, Content-Length, Content-Language, Content-Encoding and Content-Disposition.  The "outer" message will have the proper MIME header fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as normal MIME header fields and bodies received in a SIP message.

由于MIME主体附加到“内部”消息，因此实现通常会加密MIME特定的报头字段，包括：MIME-Version, Content-Type, Content-Length, Content-Language, Content-Encoding和Content-Disposition。“外部”消息将具有适当的S/MIME正文的MIME报头字段。这些报头字段（以及它们前面的任何MIME正文）应被视为SIP消息中接收的普通MIME报头字段和正文。

   It is not particularly useful to encrypt the following header fields: Min-Expires, Timestamp, Authorization, Priority, and WWW-Authenticate.  This category also includes those header fields that can be changed by proxy servers (described in the preceding section). UAs SHOULD never include these in an "inner" message if they are not included in the "outer" message.  UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values.

加密以下报头字段不是特别有用：Min-Expires, Timestamp, Authorization, Priority和WWW-Authenticate。此类别还包括那些可以由代理服务器更改的报头字段（如前一节所述）。如果UA不包含在“外部”消息中，则它们不应包含在“内部”消息中。在加密主体中接收任何这些报头字段的UA都应该忽略加密值。

   Note that extensions to SIP may define additional header fields; the authors of these extensions should describe the integrity and confidentiality properties of such header fields.  If a SIP UA encounters an unknown header field with an integrity violation, it MUST ignore the header field.

注意，对SIP的扩展可以定义额外的报头字段；这些扩展的作者应该描述这些报头字段的完整性和机密性。如果SIP UA遇到具有完整性冲突的未知报头字段，则必须忽略该报头字段。