This policy is valid from 27 April 2004 for signatures made by the following OpenPGP keys:

It may be replaced at any time with a new version. If a new version incorporates changes that might affect the strength or perceived strength of the resulting signature, the old version will be linked from the new one.

Should you have any concern as to the integrity of my public keys, please send a message, including any indications you might have to <stewartvwright@gmail.com>, and ALL the addresses listed in my public keys shown above.

This is version 1.2:

• v1.2 - 17 May 2005 *CURRENT VERSION*
  - Minor typographical corrections.
  - Changes in The act of signing : Added the additional option of having a signed key encrypted and mailed to the key owner.
  - Differences from v1.1.
• v1.1 - 27 Apr 2004
  As I didn't sign any keys with the previous policy I am not providing a link to it.
• v1.0.1 - minor changes not affecting the policy.

Content

1. Prerequisites for signing
2. Signature Classes
3. The act of signing

Prerequisites for signing

The signee (i.e. the key holder who wishes to obtain a signature from me, the signer) must make her OpenPGP public key available on a publicly accessible keyserver, such as the .pgp.net servers.

The signee must prove her identity to me by way of a passport, national ID card or a driver's licence or a credit card. The token must feature a photographic picture of the signee.

Exceptions will be made when the signee can come up with other means of proof of identity. However at least one of the above tokens will stay the minimum requirement.

The signee should have prepared a strip of paper with a printout of the output

(or an equivalent command if you're not using GnuPG), where 0xDEADBEEF is the key ID of the key that is to be signed.

A hand-written sheet featuring all user IDs the signee wants me to sign and the fingerprint will be accepted, too.

The signee should be willing to cross-sign with me.

Signature Classes

I will sign keys using one of the three signature classes:

Signature Class I

Used for sign-only keys where the below challenge/response dialogue was not possible or when signees do not wish to have their email addresses verified in this way. The latter should never happen, though.

Signature Class II

Used for all other signatures, where I don't have a strong personal relationship with the signee.

Signature Class III

Used for all other signatures, where I have a strong personal relationship with the signee.

I define a strong personal relationship as knowing the signee outside a key signing situation.

A signature of Classes II and III always means the email addresses were verified to belong to the signee.

A signature of Class I always means the email addresses were not verified to belong to the signee.

The act of signing

The signee should sign above strip in my presence. For efficiency, exceptions will be accepted on larger key signing parties.

After having received (or exchanged) the proof detailed in the above, I will sign the sheet of paper myself to avoid fraud.

At home, I will prepare emails and send one to each of the mail addresses featured in the user IDs that I was asked to sign.

Either

The emails will contain random strings and will be encrypted to the public key whose fingerprint is printed on the paper. In the event that the signee requires a signature only key to be signed I will require an encryption-enabled key that lists the same addresses as the signature only key. Failing that, the signature (if any) will only be of Class I. I will also require replies to be signed by the key to be certified, even if the challenge was encrypted to a different key.

Upon reception of encrypted replies, I will check the returned random string for equality with what I sent.

User IDs that pass the above test are signed. If one of the user IDs fails the test, a warning is sent to the rest of the user ID addresses and the procedure retried with a new challenge at most three times until a successful response has been received or the procedure has been canceled by the signee.

The signed keyblock is sent to a randomly chosen, signed, user ID address and one or more keyservers.

When not cross-signing, the signed keyblock is uploaded immediately to a randomly chosen set of keyservers.

The signee may hint on which keyservers to use.

Or

I will sign each User ID on the key separately and email the signed key, encrypted to the email address associated with the User ID. The signee (who thus controls both the email address and private key) is then able to upload the signed key to a public keyserver of their choice (or not).

NOTE: The choice of signing method will be determined by the signee. An exceptions will be made for larger key signing parties where the I will determine the optimal method.

Email Signing

As of 2003-05-15, I am trying to sign all outgoing email with my OpenGPG subkey (0x35DB7472). These signatures shall only mean that I am most likely the author of the signed text unless otherwise stated, and nothing more.

(You may retrieve my public key from http://www.physics.adelaide.edu.au/~swright/security/gpg-key.html)

There may be situations where I'm unable, or unwilling to electronically sign an email. Should there be any doubt about the authenticity of an email, you should ask for a confirmation of the content. You may do this by sending an encrypted request for a signed message, plus the message you are concerned about to <stewartvwright@gmail.com>, or any combination of email addresses listed on my public keys listed at the top of this document.

File Signing

Files will be signed with my OpenGPG subkey (0x35DB7472), and web pages (apart from this one) with my OpenPGP subkey (0x246383E6). Any concerns should be dealt with in a similar manner to the Email Signing discussed above.

Reality Check

The subkeys on my key 0xB3334559 have expiry dates of 2005-05-13. This is a result of employment reality and security concerns. These subkeys are used on a networked machine for practicality purposes (the primary key is NOT), and my contract is until October 2004. Thus the chance that these keys may be compromised is greater than 0x682B44D6 or the primary 0xB3334559. Thus after a period for me to get settled in my next position and generate additional subkeys, the current subkeys will expire.

Unsigned messages are easily forged and that means you have next to no guarantee that the message comes from me. A signature on a file, or an email, indicates a high probability that I did indeed sign the file, however there is a small, but real, chance that my keys will be compromised (real world signatures get forged every day). Thus a signature is not a guarantee, and is left to you to make your own judgment as to the value you put on such a signature.

Some references that came in useful (i.e. I swiped large amounts of them!) when preparing this document are the following:

• The OpenPGP Key Signing Policy of Marc Mutz.
• Adrian von Bidder's email and OpenPGP key signing policies.
• Matt Wronkiewicz Email and Key Signing Policy.

Information:

• Signed web pages and their verification:
  • Local information.
  • PGPHTML from SANFACE Software
  • Edward Bell's PGP signed web-pages.
• My public keys [ HTML | TEXT ]

The address of this page is http://www.physics.adelaide.edu.au/~swright/security/gpg-policy.html.