S/MIME

SIP消息可以加载一个MIME 消息体，并且MIME标准包括了MIME内容的保密机制，确保完整性和机密性（包括“multipart/signed”和“application/pkcs7-mime”的MIME类别，参见RFC 1847[22]，RFC 2630[23]，RFC2633[24]）。实现中应当注意，不管怎样，也会有很少的网络节点（不是典型的proxy服务器），会依赖于查看修改SIP消息（特别是SDP），采用加密的MIME可以防止这类网络节点操作。

 

这个实现特别对某些类型防火墙有效。

 

在RFC2543描述的对于SIP头域和包体的PGP加密机制，已经不建议使用了。

 

1. S/MIME 认证

用于区别服务器使用的S/MIME而进行的最终用户的鉴定，有一种重要的特点－这些信任状的持有者是被最终用户地址鉴定的，而不是由一个特定的hostname所鉴定的。这个地址是由SIP或者SIPS URI的“userinfo”“@”和“domainname”组成的（换句话说，就是用的email格式，类似bob@biloxi.com）,最常见的就是和用户的address-of-record对应的地址。

 

这些认证也同样和用于标记或者加密SIP消息包体的密钥相关联。包体由发送方的私钥所标记（这个发送方在适当情况下，可以包含他们的公钥），并且包体是由被接受方的公钥所加密。显然，发送方必须事先知道接受方的公钥，这样才能加密包体。公钥可以在UA的一个虚拟的钥匙环上保存。

 

每一个支持S/MIME的UA都必须包含用于终端用户验证的一个特定密钥组。这个密钥组应当由address-of-record和相应的认证信息的映射组成。在时间上，当用户产生具有相同address-of-record的原始的信号URI（From头域）时，用户应当使用相同的认证信息。

 

任何依赖于现存的终端用户认证的机制都是严格受限于：事实上，目前没有一个统一的权威认证机构为终端用户应用提供认证。不过，用户应当从已知的公共认证机构获得认证。作为替代，用户可以创建自标记(self-signed)的信任书。self-signed信任书。在实现中，也可以采用在配置中存放预先配置的信任书，这个配置中存放的是上次SIP实体之间的信任关系。

 

在获得终端用户的认证问题上，很少有广为人知的集中发布终端用户认证的目录机构。信任书的拥有者应当在一些公共的目录机构中，适当的发布自己的信任书。类似的，UAC应当支持从与SIP请求的目标URI有关的公共目录机构导入信任书（手工或者自动的）。

 

2. S/MIME 密钥交换

SIP自身可以根据下列的方法发布公钥。

 

无论何时SIP的S/MIME使用了CMS SignedData消息，他必须包含由公钥所加密的信任书，用于检查签名。

 

当UAC发送一个创建对话的请求，包含了一个S/MIME包体，或者在对话外发送一个非INVITE请求，UAC应当创建一个S/MIME ‘multipart/signed’CMS SignedData包体结构的包体。

 

如果特定的CMS服务时EnvelopedData(并且知道目标用户的公钥)，UAC应当在一个SignedData消息中发送EnvelopedData消息。

 

当UAS接收到一个包含S/MIME CMS包体的请求，并且这个包体包含一个信任书，UAS应当首先检查这个信任书，如果可能，使用以后的root信任书来进行信任书检查。UAS也应当检查信任书的主题（subject）（对于S/MIME，SubjectAltName应当包含了适当的标记）并且，把这个值和请求From头域进行比较。如果信任书不被通过，因为它是self-signed(自签发)，或者被置位的信任机构所颁发的，或者它是可信任的，但是他的主题和请求的From头域不匹配，UAS必须把这个通知用户（包括信任书的主题，签发者，和密钥指纹信息），并且在继续处理之前，要求用户确认。如果信任书成功通过认证，并且信任书的主题（subject）和SIP请求的From头域相同，或者如果用户（在知会之后）批准了这个信任书的使用，那么UAS应当增加这个信任书到本地密钥组中（keyring），并且用信任书拥有者的address-of-record作为索引。

 

当UAS要发送一个包含S/MIME消息体的应答，这个应答回应了在对话中的前一个请求，或者是给对话外的一个非INVITE请求的应答，UAS应当构造一个S/MIME‘multipart/signed’CMS SignedData包体。如果给定的CMS服务要求EnvelopedData，UAS应当发送一个EnvelopedData的SignedData消息

 

当UAC收到一个包含S/MIME CMS包体的应答，这个应答中包含了一个信任书，UAC应当首先检查这个信任书，如果可能，使用任何适当的root信任书来进行检查。UAC应当同样检查信任书的主题（subject），并且和应答的To头域进行比较；虽然两个可能完全不同，这个也没有必要当作是不安全的。如果因为self-signed，或者由未知认证机关颁发而导致信任书不能通过认证，那么UAC应当通知它的使用者这个状态（包含信任书的主题，它的签发者，以及密钥的指纹信息），并且在继续操作之前，要求使用者确认。如果信任书通过了认证，并且信任书的主题和应答的To头域相同，或者用户（在提示确认后）明确，确认这个信任书以后，UAC应当把这个信任书放在本地密钥组中，用这个信任书的拥有者的address-of-record作为索引。如果UAC没有把自己的信任书事先传送给UAS，它在下一个请求或者应答时应当使用一个CMS SignedData包体。

 

在以后，当UA接收到包括一个From头域的请求或者应答，并且这个From头域和本地的一个密钥组的索引匹配，那么UA应当比较消息中的信任书和这个密钥组对应索