The key-cert object is used for storing PGP public keys on the server. The object template has the following attributes:
key-cert: [mandatory] [single] [primary/look-up key] method: [generated] [single] [ ] owner: [generated] [multiple] [ ] fingerpr: [generated] [single] [inverse key] certif: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
The "key-cert:" attribute is defined as PGPKEY-XXXXXXXX where XXXXXXXX is the PGP key ID of the public key included in the object in the usual eight digit hex format without "0x" prefix.
The public key should be supplied in the "certif:" attributes. Usually this is easily done by exporting the key from your local key ring in ASCII armored format and prepending each line of the key with a string "certif:". Remember to include all the lines of the exported key and also the "Begin" and "End" markers and the empty line which separates the header from the key body.
The attributes marked as generated ("method:", "owner:" and "fingerpr:") are generated by the software. They may be omitted by the user when supplying a key. The software will then derive these attributes from the actual key and a warning will be added to the acknowledgement message informing the user that these attributes have been added. If they are included, the software will still derive them and compare the derived values with the supplied ones. If there are any differences, the derived values will replace the incorrect ones supplied. Another warning will be added to the acknowledgement about the replacement.
The other attributes have their usual meanings as defined in the AFRINIC Database Reference Manual. This is an example of a valid key-cert object as it might appear in the database:
key-cert: PGPKEY-4B8AE00D method: PGP owner: Zola Abalo fingerpr: 9D 82 4B B8 38 56 AE 12 BD 88 73 F7 EF D3 7A 92 certif: ---BEGIN PGP PUBLIC KEY BLOCK--- certif: Version: 2.6.3ia certif: certif: mQA9AzZizeQAAAEBgJsq2YfoInVOWlLxalmR14GlUzEd0WgrUH9iXjZ certif: a/uqWiLnvN59S4rgDQAFEbQeSm9lIFRoZSBVc2VyIDxqb2VAZXhhbXB certif: iQBFAwUQNmLN5ee83n1LiuANAQFOFQGAmowlUYtF+xnWBdMNDKBiOSy certif: YvpKr05Aycn8Rb55E1onZL5KhNMYU/gd certif: =nfno certif: ---END PGP PUBLIC KEY BLOCK--- mnt-by: EXAMPLE-MNT changed: email@example.com 19981117 source: AFRINIC
If you do not already have a maintainer (mntner) object to be used in the mandatory "mnt-by:" attribute, you need to create a new mntner with some other authentication method (for example MD5-PW), then create the key-cert object which references the maintainer just created. After that, you can change the maintainer to use PGP authentication with the key-cert object as an authentication key. These key-cert objects can be queried in the usual ways by searching for a specific key as defined in the "key-cert:" attribute or using the inverse option with -i fingerpr.
AFRINIC does not guarantee that a key belongs to any specific entity; we are not a certificate authority. Anyone can supply any public keys with any ownership information to the database and these keys can be used to protect other objects by checking that the update comes from someone who knows the corresponding secret key.
Please also note that signatures in the keys are ignored. We kindly ask you to limit the number of key signatures to a minimum.
PGP authentication can be activated by setting the value of an "auth:" attribute to PGPKEY- where is the PGP key ID to be used for authentication. This string is the same one which is used in the corresponding key-cert object's "key-cert:" attribute.
Remember that if you have multiple "auth:" attributes in a maintainer or if you have multiple "mnt-by:" attributes in an object, all possible authentication methods are combined by a logical OR which means that any single one of the specified authentication methods can be used. There is no security advantage in using PGP authentication with an object which can also be updated with a crypted password authentication.
If you specify a non-existent key-cert object, or someone else's key-cert object, you will have locked your mntner. You will then have to contact firstname.lastname@example.org for assistance to unlock it. Also, if you delete your key-cert object you will again lock your mntner until you re-create the key-cert object. This is an example of a valid mntner object which uses PGP authentication:
mntner: EXAMPLE-MNT descr: Example maintainer admin-c: ZA4-RIPE upd-to: email@example.com auth: PGPKEY-4B8AE00D mnt-by: EXAMPLE-MNT changed: firstname.lastname@example.org 19981117 source: AFRINIC
PGP signed updates can be sent to the database simply by signing the body of the message containing the updates and sending it to the server. Remember to use ASCII armoring.
Multiple PGP-signed and non-signed parts can be supplied in a single update message, each part is processed separately. You can supply several objects which are protected by different PGP keys in a single update message providing all required signatures are present. PGP parts with invalid signatures are handled as plain text. If the object is protected by an authentication method other than PGP, or has multiple authentication schemes in use and the required authentication is present, it will still be authorised. If PGP is the only form of authentication present the authentication will fail.
PGP authentication can be mixed with any of the other forms of authentication in the same mntner object. Each authentication method used can have multiple instances present. All the authentications present in a mntner object are processed with a logical 'OR' to determine if the authentication is passed. PGP can only be used with updates submitted by e-mail (and not through MyAFRINIC for example).
Please note that encryption technology is subject to legal restrictions in some countries. PGP signatures are based on public key encryption. Consult a lawyer if you are uncertain about your local situation.