These are the procedures that I stick to when signing other peoples PGP/GnuPG keys. （中文译本）
This policy is valid for all signatures made by the following GnuPG keys:
pub rsa2048/0xFEBB1B95F7964FB5 2013-02-01 [SC] [expires: 2024-01-12]
Key fingerprint = 328C 0C0A 5F78 B322 C7D0 7DA1 FEBB 1B95 F796 4FB5
uid [ultimate] Allen Zhong (Personal Master Key) <allen@atr.me>
uid [ultimate] Allen Zhong (Personal Development Key) <moeallenz@gmail.com>
uid [ultimate] Zhong Benli (Amateur Astronomer) <asfunomy@wobu.se>
uid [ultimate] Allen Zhong (Nyan~) <allen@moe.cat>
uid [ultimate] Allen Zhong (Network Time Foundation) <zhong@ntp.org>
sub rsa2048/0xB2A5D98748A2992A 2013-02-01 [E] [expires: 2024-01-12]
sub rsa4096/0xE716D10E16EABFBF 2014-05-12 [S] [expires: 2024-01-12]
sub brainpoolP384r1/0xDB94E46EEDEB9AFD 2016-01-13 [S] [expires: 2024-01-12]
sub brainpoolP384r1/0x3917C25F85E6BE7E 2016-01-13 [E] [expires: 2024-01-12]
sub rsa4096/0xDCBABBBA797EBEB0 2016-08-24 [E] [expires: 2024-01-12]
pub ed25519/0x7D78D22D23333B33 2018-10-10 [SC] [expires: 2024-06-25]
Key fingerprint = 5C7C FA3B 74A5 782B 5A20 441A 7D78 D22D 2333 3B33
uid [ultimate] Allen Zhong (Personal Master Key) <allen@atr.me>
uid [ultimate] Allen Zhong (Personal Development Key) <moeallenz@gmail.com>
uid [ultimate] Allen Zhong (Nyan~) <allen@moe.cat>
uid [ultimate] Allen Zhong (Network Time Foundation) <zhong@ntp.org>
uid [ultimate] Zhong Benli (Amateur Astronomer) <allen@astronomical.party>
sub cv25519/0x4C01B18F97AA532A 2018-10-10 [E] [expires: 2024-06-25]
sub ed25519/0x60EEFC16A5CF56BC 2018-10-17 [S] [expires: 2024-06-25]
sub rsa4096/0x03EBA14C38FA65D9 2018-10-17 [SEA] [expires: 2024-06-25]Since Jan 2019, I started to use the ECC key 0x23333B33, which has stronger security on cryptology, for signing new keys by default. The old RSA key 0xF7964FB5 is still been used, but one can expect it been deprecated in few more years. However, there might be compatibility issues with ECC keys on some legacy implemention of PGP/GnuPG softwares, for circumstances where an ECC key can not be supported, I could still use the old RSA key for signing. My signatures on other keys with either key above are equivalent.
These keys will always be available on keyservers like pgp.gnd.pw. You can also get my key 0xF7964FB5 and 0x23333B33 on this page, but the latest updated version is likely to be on a keyserver.
This policy was originally written on 2013-10-14 and will be followed from this date on, but it may be replaced with a new version at any time. Content and structure of this document is inspired by the GnuPG Key Signing Policy of Olaf Gellert and the PGP Keysigning Policy of Aaron Toponce.
I live in Hangzhou, China at present, and may be at home in Chengdu for vacations. I am open to sign keys at any time. The easiest way for verifying keys would be to meet me either in Hangzhou, Beijing or in Chengdu. Another opportunity to get in personal contact would be to see me at certain public events. I am also listed at biglumber.com, a webpage about key signing coordination.
Depending on the character of the key which is to be signed by me I will use different levels of signatures, please note that these level descriptions may be not the same as they are in GnuPG’s documentation.
Level 0 (generic certification) >I will issue this type of signature for keys that represent a group or an organization, as well as any key that only passed email verification. My signature on such a key indicates only that I am “pretty sure” that there is a correspondence between the key and the group / email address.
Level 1 (persona certification) >I will issue this type of signature for keys that been authenticated by a trusted third party, witch will be detailed afterwards. Or for a key which I have met its holder in person, but identification of that personal not verified. In this case I have determined only that the same personal controls the key and the e-mail addresses listed in the signed UIDs. No claim is made regarding the connection between the key and any real-life identity.
Level 2 (casual certification) >I will issue this type of signature if I have met the keyholder in person and verified their identity according to the procedure below; or, if possible, to have the real identification of the key holder determined by me in other proper ways.
Level 3 (positive certification) >I will issue this type of signature only if I know the keyholder well personally and feel comfortable being with them that I determine they are reliable.
The signee (the key owner who wishes to obtain a signature to their keys from me, the signer) must make their PGP keys available on a publicly accessible keyserver (e.g, pgp.gnd.pw).
If an offline meeting up is arranged, the signee should have prepared a strip of paper with their names and a printout of the output
gpg --fingerprint 0x12345678(or any equivalent command if the signee does not use GnuPG) where 0x12345678 is the key ID of the key which is to be signed. A handwritten piece of paper featuring the fingerprint and all UIDs the signee wants me to sign will also be accepted.
The signee must send me an email signed with the key they want me to sign and encrypted with my key listed at the start of this documentation. The email must contain follow information:
I accept a tricky way to verify the identity of a keyholder, that I think a transaction through Paypal or Alipay is worth to believe. So as an extra to level 0, the signee should also:
As these emails don’t present in the UIDs of my key, the signee may (optional) put a random string in the transaction message as well, I will include this string in later email, as a verification of myself.
I will not return the money back to signee unless clearly asked to, regardless of whether the procedure succeeded or not.
The signee is supposed to send me an email signed with the key they want me to sign and encrypted by my key listed at the start of this documentation to arrange a meet up at first.
The signee must prepare a strip of paper as formerly descried and their valid, government-issued photo ID, then bring them to the meeting to present to me. I will accept all valid identities in P.R.China or a valid passport from any other country.
There is no proper ways available at present that I determine suitable to verify a key except above procedures.
At home I will send one e-mail to each of the mail addresses which are listed in the UIDs which I was asked to sign. These verification mails contain random strings and will be encrypted to the public key whose fingerprint is printed on the sheet. Upon reception of encrypted and signed replies I will check the returned random string for equality with what I sent.
UIDs which pass the above test are going to be signed. If one of the UIDs fails the test a warning will be sent to one of the other mail addresses and the procedure will be halted until a satisfactory explanation has been received or the procedure has been cancelled by the signee.
The signed keyblock will then be uploaded to pgp.gnd.pw, or another keyserver that is synchoronized with it. The signee can get it from there or choose to receive it through mail instead. It should be obvious that I expect the signee to sign my keys without any avoidable delay. The signee can either upload my keys to a keyserver or send it back to me by e-mail.
When I request others to sign my key, I will sign their keys at the same level they do to mine in return upon reception of my signed key (following their key signing policies). Meanwhile, I expect to get signature at the same level I made to other keys from their keyholders.
I prefer to have keys cross-signed so it does not make any sense to ask me for signing keys if the signee is not willing to sign mine.
When signing key with GnuPG, using --ask-cert-level
argument to choose proper signature level.
2023-03-15: Update UID list
2021-09-08: Update keyserver and remove pathtracer.
2020-01-17: Add hints
2019-04-22: Minor updates
2019-03-04: Add new ECC key 0x23333B33 and update description of sig1.
2018-05-20: Update UID list & Remove special circumstance as I no longer work at Alibaba.
2017-05-03: Update subkeys & keyserver
2016-01-12: Update UID list & Minor adjustments
2015-11-07: Add some notes & Minor fixes
2015-11-04: Update location & Add special verification method for colleagues.
2013-10-25: Add pathtracer.
2013-10-16: Add a local keyfile for download and typo fixes, Chinese translation released.
2013-10-14: Initial Release.
Copyright (C) 2013-2023 Allen Zhong.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation.
A signed version of this documentation in Markdown is available at:
https://atr.me/~pgp/policy-signed.txt