GPG Key Signing Policy of Matt Brown

To communicate with me using GPG please use the key below.
pub   1024D/59B2D9A0 2005-02-03
      Key fingerprint = 6583 A11F 1428 FCDD 65FC  C7B5 E0CD 3CDC 59B2 D9A0
uid                  Matthew G L Brown (Default Key) <matt@mattb.net.nz>
uid                  Matt Brown (WLUG Key) <matt@wlug.org.nz>
uid                  Matt Brown (CRCnet Key) <matt@crc.net.nz>
uid                  [jpeg image of size 4390]
uid                  Matt Brown <mattb@debian.org>
sub   1024D/36933EA3 2007-12-23 [expires: 2010-01-11]
sub   1024g/DF8A0504 2005-02-03
You can import it from here (ascii armored).

I have a second key which I use exclusively for signing packages that I distribute. This key is never used to sign other keys, however it is signed by my primary key listed above.
pub   1024D/3B4B8C19 2005-06-12
      Key fingerprint = BD49 9FF3 00AE 0AD9 45C8  D1B4 87F5 B915 3B4B 8C19
uid                  Matt Brown (Package Signing Key) <debian@mattb.net.nz>
sub   1024g/670A4F65 2005-06-12
My package signing key can be imported from here (ascii armored).

Signed Keys

See the complete list of keys I have signed here.

OR, search for a particular key:
Key ID:  

Key Signing

I have a fairly strict key signing policy that I adhere to. This policy is described in the details below. As a part of this policy I maintain a registry of the keys I have signed and the verification steps I took before signing on this website. A link to the appropriate entry in this registry is appended to each UID I sign as a policy URL.

Despite debate over the value of the different signature types (see RFC 2440 section 5.2.1), I perceive them to be beneficial, if only for my own personal use. The following table lists the minimum requirements that I will require to be satisified before I will sign a UID. This table is a guide and you should refer to the policy URL on an individual signature for the definitive description of the steps I took before signing that particular UID.
Type Description My Policy
0x10 Generic Certification I hope to only rarely use this type of signature. One example of a case where I would use it would be if a keyholder has satisified by casual signature requirements, but there is a problem with their key (such as an inspecific uid) that leads me to believe their key is not so useful for verifying their identity.
0x11 Persona Certification I do not intend to use this signature type. In my opinion it breaks the point of signing keys, I will trust you less if you make signatures of this type.
0x12 Casual Certification To sign your key with a casual signature, I will need to have met you in person and sighted at least one form of government issued photo identification. For each uid that you want me to sign, I will need to verify that the email address is active and accessible by the keyholder.
0x13 Positive Certification To sign your key with a postive signature, you will need to satisfy my requirements for a casual signature AND additionally, have been personally known to me for at least one year.

Why are you sending me email?

If we recently met and exchanged key details with a view to signing each others keys then it is highly likely that you will receive a verification email from me. This email will be signed by my key (as shown above) and encrypted to the key you have requested me to sign. Within the email will be a token, that you will need to return to me in an email signed with your key (and preferably encrypted to me). I need to complete this process to satisfy my key signing policy as described above.

My apologies if you receive this email to multiple uids, it is necessary to reply to each one individually.

Comments

If you have comments about my key signing policy, please feel free to contact me using the details on the contact page of my site.

Revision History