The key-cert object is used for storing PGP public keys and X.509 certificates 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]   [ ]
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-<id> where <id> 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:" attribute. 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 <zola.abalo@example.net>
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:  zola.abalo@example.net 19981117
source:   TEST

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 CRYPT-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 for in the usual ways with whois by asking for a specific key as defined in the "key-cert:" attribute or using the inverse option with -i fingerpr <finger print>.

The RIPE NCC 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.

Use in the maintainer object

PGP authentication can be activated by setting the value of an"auth:" attribute to PGPKEY-<id> where <id> 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.

There are currently no referential integrity checks carried out on the"auth:" attribute values. If you change your "auth:" to refer to a non
existent key-cert object, or someone else's key-cert object you have locked your mntner. You will then have to contact ripe-dbm@ripe.net for assistance to un-lock 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:   zola.abalo@example.net
auth:     PGPKEY-4B8AE00D
mnt-by:   EXAMPLE-MNT
changed:  zola.abalo@example.net 19981117
source:   TEST

Using authentication when sending updates

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 be used with updates submitted by e-mail or using the syncupdates facility. It cannot be used with the webupdates interface.

Legal issues

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.

More information:

* GnuPG FAQ, user guide and howto
* Bert-Jaap Koops' survey of crypto laws in different countries