PGP Authentication in the RIPE Database
Supplying public keys to the server
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; 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 RIPE Database Manuals This is an example of a valid key-cert object as it might appear in the database:
key-cert: PGPKEY-4B8AE00D method: PGP owner: Joe User <joe _at_ example _dot_ 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: joe _at_ example _dot_ 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 an MD5 password), 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 us 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: JOE1-RIPE upd-to: joe _at_ example _dot_ net auth: PGPKEY-4B8AE00D mnt-by: EXAMPLE-MNT changed: joe _at_ example _dot_ net 19981117 source: RIPE
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.