符号提供了将信息添加到签名或证明（这也是一种特殊类型的签名）的含义。来自RFC 4880, 5.2.3.16。符号数据：

这个子包描述了发行者希望做出的签名上的“符号”。该符号有一个名称和一个值，每个都是八位字节的字符串。签名中可能有多个符号。符号可用于签名发行者希望进行的任何扩展。[...]

符号在实践中很少使用（实际上我从未见过真正的用法，尽管在关键服务器转储中可以找到很少的符号子包）。示例用法可能是在密钥签名期间添加身份检查的位置，或显示的文档类型。

每个表示法由一个表示法名称和一个值组成，而该值是一个任意的 UTF-8 编码字符串。

关于@，这是符号命名空间的一部分。命名空间有助于区分符号，如果它们使用相同的名称，但由不同的人定义。再次来自 RFC 的同一部分：

符号名称是用 UTF-8 编码的任意字符串。它们驻留在两个名称空间中：IETF 名称空间和用户名称空间。

IETF 命名空间已向 IANA 注册。这些名称不得包含“@”字符 (0x40)。这是用户命名空间的标签。

用户命名空间中的名称包含一个 UTF-8 字符串标记，后跟“@”，然后是 DNS 域名。请注意，标签不得包含“@”字符。例如，Example Corporation 使用的“sample”标签可以是“sample@example.com”。

用户空间中的名称由该域的所有者拥有和控制。显然，在您不拥有的 DNS 空间中创建新名称是一种不好的形式。

由于用户命名空间是电子邮件地址的形式，实施者可能希望将该地址安排给可以就命名标签的使用进行咨询的人。请注意，由于 UTF-8 编码，并非所有有效的用户空间名称标签都是有效的电子邮件地址。

换句话说，可以有some-notation-name由标准定义并在 IANA 注册的形式的官方符号。另一方面，每个人都可以声明自己的符号，其形式应为my-notation-name@example.com。例如，如果我使用some-notation-name@jenserat.de，它不会与some-notation-nameIANA 命名空间中的（假定的）官方表示法冲突。