6

我不明白为什么存在 JWS 不受保护的标头。

对于某些上下文：JWS 未受保护的标头包含不受完整性保护的参数，并且只能在 JSON 序列化的每个签名中使用。

如果它们可以用作顶级标题，我可以理解为什么有人可能想要包含一个可变参数（这不会改变签名）。然而，这种情况并非如此。

谁能想到一个用例或知道它们为什么包含在规范中？

谢谢！

JWS 规范

4

1 回答 1

8

弗洛伦特的回答让我不满意。

关于使用 JWT 签署文档哈希的示例......断言是算法和 keyID 将是需要“保护”的“敏感数据”。我想他的意思是“签名”。但是不需要对算法和 keyID 进行签名。

例子

假设 Bob 创建了一个签名的 JWT，其中包含一个断言 alg=HS256 和 keyid=XXXX1 的不受保护的标头。此 JWT 旨在传输给 Alice。

情况1

假设 Mallory 截获 Bob 发送的签名 JWT。Mallory 然后创建一个新的未受保护的标头，断言 alg=None。

接收者 (Alice) 现在负责验证有效负载上的签名。爱丽丝一定不能满足于“没有签名”；事实上，Alice 不能依赖客户端（发送者）断言来确定她可以接受哪种签名算法。因此，Alice 拒绝了带有人为的“无签名”标头的 JWT。

案例2

假设 Mallory 设计了一个带有 alg=RS256 和 keyId=XXX1 的标头。现在 Alice 尝试验证签名并发现：

  • 算法不合规
  • 为该算法指定的密钥不存在

因此 Alice 拒绝了 JWT。

案例3

假设 Mallory 设计了一个带有 alg=HS256 和 keyId=ZZ3 的标头。现在 Alice 尝试验证签名并发现密钥未知，并拒绝 JWT。

在任何情况下，算法都不需要成为签名材料的一部分。不存在未受保护的标头导致漏洞或完整性违规的情况。

回到最初的问题

最初的问题是：不受保护的 JWT 标头的目的是什么？

简而言之，未受保护的 JWS 标头的目的是允许传输一些可用作接收者提示的元数据。像 alg（算法）和 Kid（密钥 ID）。Florent 建议将数据填充到未受保护的标头中可能会提高效率。这不是一个很好的理由。这是关键点：未受保护的标头中的声明是提示，不应依赖或信任。

一个更有趣的问题是：受保护的 JWS 标头的目的是什么？为什么有一个同时签署“标题”和“有效载荷”的条款？在 JWS 受保护的标头的情况下，标头和有效负载将连接起来，并对结果进行签名。假设标头是 JSON，有效负载是 JSON，此时标头和有效负载之间没有语义区别。那么，为什么要签署标题呢？

可以只依赖具有不受保护的标头的 JWS。如果需要完整性保护声明，请将它们放入有效负载中。如果需要提示，请将它们放在未受保护的标题中。签署有效载荷而不是标头。简单的。

这有效，并且有效。但它假定有效负载是 JSON。JWT 是这样，但并非所有 JWS 都是如此。 定义 JWS 的 RFC 7515不要求签名的有效负载是 JSON。想象一下，有效载荷是医学扫描的数字图像。这不是 JSON。不能简单地“附加要求”。因此，JWS 允许使用受保护的标头，以便可以对（非 JSON）有效负载和任意声明进行签名并检查完整性。

在负载为非 JSON 且标头受保护的情况下，无法将“额外的非签名标头”包含到 JWS 中。如果需要发送一些需要完整性检查的数据和一些简单的“提示”，那么实际上只有一个容器：受保护的标头。提示与真实声明一起签署。

只需在要签名的数据周围包装一个 JSON 哈希，就可以避免这种受保护的标头技巧。例如：

{
   "image" : "qw93u9839839...base64-encoded image data..."
}

在这样做之后，可以向这个 JSON 包装器添加声明。

{
   "image" : "qw93u9839839...base64-encoded image data..."
   "author" : "Whatever"
}

然后这些声明将被签署并受到完整性保护。

但在二进制数据的情况下，将其编码为字符串以允许封装成 JSON 可能会显着膨胀数据。具有非 JSON 有效负载的 JWS 可以避免这种情况。

高温高压

于 2017-09-18T21:49:36.653 回答