您可以手动向 PGP 公钥块添加注释而不破坏它吗？答案

【问题标题】：Can you manually add a comment to a PGP public key block and not break it?您可以手动向 PGP 公钥块添加注释而不破坏它吗？
【发布时间】：2020-02-29 22:18:37
【问题描述】：

假设以下是有效的PGP PUBLIC KEY BLOCK：

我可以手动添加如下图所示的注释——比如说，使用 vim——它仍然有效吗？我知道我可以重新运行 gpg(1) 命令来执行此操作，但我手边没有。

谢谢。

【问题讨论】：

标签： email encryption public-key-encryption pgp openpgp

【解决方案1】：

是的，这是有效的，

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.6+
Comment: Hostname: pgp.key-server.io

如上，comment 和 version 标签都是经常使用的，包括其他的，根据RFC4880，允许的Armor Header Keys包括：

 - "Version", which states the OpenPGP implementation and version
   used to encode the message.

 - "Comment", a user-defined comment.  OpenPGP defines all text to
   be in UTF-8.  A comment may be any UTF-8 string.  However, the
   whole point of armoring is to provide seven-bit-clean data.
   Consequently, if a comment has characters that are outside the
   US-ASCII range of UTF, they may very well not survive transport.

 - "MessageID", a 32-character string of printable characters.  The
   string must be the same for all parts of a multi-part message
   that uses the "PART X" Armor Header.  MessageID strings should be
   unique enough that the recipient of the mail can associate all
   the parts of a message with each other.  A good checksum or
   cryptographic hash function is sufficient.

   The MessageID SHOULD NOT appear unless it is in a multi-part
   message.  If it appears at all, it MUST be computed from the
   finished (encrypted, signed, etc.) message in a deterministic
   fashion, rather than contain a purely random value.  This is to
   allow the legitimate recipient to determine that the MessageID
   cannot serve as a covert means of leaking cryptographic key
   information.

 - "Hash", a comma-separated list of hash algorithms used in this
   message.  This is used only in cleartext signed messages.

 - "Charset", a description of the character set that the plaintext
   is in.  Please note that OpenPGP defines text to be in UTF-8.  An
   implementation will get best results by translating into and out
   of UTF-8.  However, there are many instances where this is easier
   said than done.  Also, there are communities of users who have no
   need for UTF-8 because they are all happy with a character set
   like ISO Latin-5 or a Japanese character set.  In such instances,
   an implementation MAY override the UTF-8 default by using this
   header key.  An implementation MAY implement this key and any
   translations it cares to; an implementation MAY ignore it and
   assume all text is UTF-8.

【讨论】：

谢谢你。而且你可以在事后添加任何这些，对吗？
@NYCeyes，是的！许多密钥服务器会将他们的评论添加到没有提交的密钥中。请记住，尽管根据 RFC，装甲的全部意义在于提供 7 位干净的数据。因此，如果评论中的字符超出了 UTF 的 US-ASCII 范围，它们很可能无法在传输过程中存活。
啊，好吧。在将密钥上传到 SKS 服务器时，我注意到了评论插入。再次感谢您的澄清和回答。标记为已回答。
P.S.我最初问题的原因是我想添加该密钥对应的电子邮件地址作为其comment；因为 PGP 搜索服务器有时响应很慢，而且经常超时。我想知道将关联的电子邮件地址添加为评论是否存在安全隐患？
很高兴为您提供帮助。我不明白为什么这会带来安全隐患。我看你的想法没有问题！无论如何，公钥通常与某个电子邮件地址相关联。这样评论不是问题。