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:
sec rsa2048/0xFEBB1B95F7964FB5 2013-02-01 [SC] [expires: 2022-08-03]
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>
uid [ultimate] Benli Zhong (PingCAP) <zhongbenli@pingcap.com>
ssb rsa2048/0xB2A5D98748A2992A 2013-02-01 [E]
ssb rsa4096/0xE716D10E16EABFBF 2014-05-12 [S] [expires: 2019-08-04]
ssb brainpoolP384r1/0xDB94E46EEDEB9AFD 2016-01-13 [S] [expires: 2021-01-11]
ssb brainpoolP384r1/0x3917C25F85E6BE7E 2016-01-13 [E] [expires: 2021-01-11]
ssb rsa4096/0xDCBABBBA797EBEB0 2016-08-24 [E] [expires: 2019-08-04]
This key will always be available on keyservers like pool.sks-keyservers.net. You can always get my key 0xF7964FB5 here, 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, occasionally travel to Beijing for work, 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.
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.
I will issue this type of signature for keys that been authenticated by a trusted third party, witch will be detailed afterwards. In this case I have determined only that the same person 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.
I will issue this 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.
I will issue this 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, pool.sks-keyservers.net).
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 pool.sks-keyservers.net, 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 key 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 sense to ask me for signing keys if the signee is not willing to sign mine.
My key is in so called "Strong Set", you can use the pathfinder of Henk P. Penning at http://pgp.cs.uu.nl/ which gives you a simple text printout:
My key statistics is here.
2018-05-20: Update UID list & Remove special circumstance as I no longer work in 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-2018 Allen Zhong.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 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