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 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: Joe User <joe@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: joe@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 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 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: JOE1-RIPE
upd-to: joe@example.net
auth: PGPKEY-4B8AE00D
mnt-by: EXAMPLE-MNT
changed: joe@example.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.
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:
|
you are here: home -> RIPE Database
