四种可能的关键“用法”是

• 认证：签署其他密钥
• 签名：签署数据
• 加密：解密数据
• 身份验证：签署身份验证令牌

当您使用 来查看您的密钥时--edit-key，您会发现每个密钥和子密钥后面列出的用法。默认情况下，密钥类型支持的所有内容都附加到主密钥（因此，RSA 默认为CSEA，DSA 默认CSA为 DSA 密钥不应用于加密）。有一些特殊的密钥类型比它们的算法更受限制（例如，“RSA（仅签名）”只支持CSA）。

创建子密钥时，在将子密钥绑定到主密钥的签名中为其分配密钥用法；这将此功能委托给子密钥，该子密钥也成为相应操作的默认密钥，而密钥用法对主密钥隐藏。

不能将认证委托给子密钥，因此您将始终需要您的主密钥来签署另一个密钥。

可以委托签名，并且具有签名委托的最新有效密钥将自动用于签名，除非通过指定要使用的密钥在前面带有感叹号来强制使用另一个密钥。

也可以委托加密，并且在发送方自动选择具有加密委托的最新有效密钥，除非使用感叹号强制另一个密钥。

一般的做法是主密钥用于签署其他密钥。例如，请参阅“为什么？”下的例外情况。用于在 Debian 开发中使用 OpenPGP 子项。我不知道有任何系统为此目的创建子密钥，并且根据我的经验，公钥软件并不是那么灵活的野兽。

仅作为意见，我建议以下两个理由：

1. 正如您所说，签名是在受信任的系统上进行的一项活动，并且与外部数据的交互最少。风险级别并不能证明创建一个单独的子密钥是合理的，该子密钥的寿命可能较短，并且其循环会引发系统性的重新信任练习。
2. 主密钥可以被认为是公司，子密钥是“做生意”的身份。后者从前者获得他们的权威，但万能钥匙就是权威。根据定义，签署其他密钥是一种权威行为，并且最适合主密钥而不是子密钥。

实际上，gpg不允许创建具有“C”（认证）能力的子密钥。只有主密钥/主密钥具有该能力。

有充分的理由我们可能希望在子项中具有这种能力。虽然我没有二极管（如该链接中所讨论的），但我不想为了签署某人的密钥而不得不不断地来回访问我的气隙机器。这既是一个安全风险，也是足够的麻烦，我可能不想这样做。

RFC可能并不完全清楚这种能力是否应该是可委派的。（再次查看该链接，但另一方面，请参阅此讨论，然后注意我的评论。）很明显，作为一个实际问题，gpg 开发人员并不总是清楚应该允许哪些键具有哪些能力。（参见例如我偶然发现的这个链接。）

有一个新的 RFC正在讨论中，希望这个问题能得到澄清。