委托凭证是数字签名的数据结构，由两部分组成：有效间隔和公钥（及其关联的签名算法）。 他们充当“授权书”对于表明他们被授权的服务器
委托凭证的设计目的是提高安全性。 因此，它们具有 IEFT 草案中定义的某些特征。“一种有限的授权机制，允许 TLS 对等方在外部 CA 颁发的证书范围内颁发自己的凭据。 这些凭据只能让委托的接收者说出 CA 授权的名称。”
- 委托凭证的最长有效期为 七（7）天 如果私钥被泄露，以尽量减少暴露。 较短的有效期并不意味着应轻视委托凭证的安全性。 为保护终端实体证书的私钥而采取的措施也应适用于 DC 的保护。 其中包括文件系统控制、物理安全和硬件安全模块等。 此外，委托凭证应该只在彼此共享某种信任关系的各方之间使用。
- 委派的凭据是 密码绑定 到最终实体证书。 具体而言，终端实体证书的私钥用于通过凭据指定的算法计算 DC 的签名。 签名有效地将 DC 绑定到最终实体证书的名称。
- 委托凭证由客户端颁发，这比创建由 CA 签署的证书容易得多。 即使 CA 停机，客户端颁发的证书也有助于保持服务正常运行。 此外，组织可以试验 CA 未正式支持的算法，而不会影响最终实体证书的安全性。
- 根据定义，委托凭证的有效期很短。 在设置委托凭证的生命周期时，服务器需要考虑客户端时钟偏差以避免拒绝证书。 客户端时钟偏差对于原始证书也很重要，但对于短期委托私钥至关重要。 在有效期的开始和结束时都应考虑客户端时钟偏差。
- 委托凭证没有撤销机制。 一旦有效期届满，它们就会失效。 但是，撤销最终实体证书（用于签署委托凭证）的私钥会隐式撤销委托凭证。
- 委派凭据旨在用于 TLS 1.3 或以后。 当存在已知漏洞时 TLS 1.2 服务器支持 RSA 密钥交换，允许在任意消息上伪造 RSA 签名。 假设攻击者能够伪造签名。 在这种情况下，他们可以为最终实体证书的整个有效期创建伪造的委托凭证。 此漏洞不存在于 TLS 1.3 或更高版本。 此外，该漏洞不影响椭圆曲线加密的证书，它 SSL.com 提供。
- 组织可以使用现有的自动发行 API（如 ACME）来提供委托凭证。 在这种情况下，使用的算法只是 CA 支持的算法，但这种做法降低了密钥泄露的可能性。 SSL.com 赞同这种做法。
- 委托凭证不能在多个上下文中重复使用。 发行方使用对预期角色（客户端或服务器）唯一的上下文字符串来计算签名，从而使客户端和服务器身份验证无法使用相同的委托凭证。
