Network Working Group J. Zsako
Request for Comments: 2726 BankNet
Category: Standards Track December 1999
PGP Authentication for RIPE Database Updates
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document presents the proposal for a stronger authentication
method of the updates of the RIPE database based on digital
signatures. The proposal tries to be as general as possible as far as
digital signing methods are concerned, however, it concentrates
mainly on PGP, as the first method to be implemented. The proposal
is the result of the discussions within the RIPE DBSEC Task Force.
1. Rationale
An increasing need has been identified for a stronger authentication
of the database maintainer upon database updates (addition,
modification and deletion of objects). The existing authentication
methods have serious security problems: the MAIL-FROM has the
drawback that a mail header is very easy to forge whereas CRYPT-PW is
exposed to message interception, since the password is sent
unencrypted in the update mail message.
The goal was to implement a digital signature mechanism based on a
widely available and deployed technology. The first choice was PGP,
other methods may follow at a later date. PGP is presently quite
widely used within the Internet community and is available both in
and outside the US.
The current aim is for an improved authentication method and nothing
more (in particular, this paper does not try to cover authorization
issues other than those related to authentication).
Zsako Standards Track [Page 1]RFC 2726 PGP Authentication for RIPE Database Updates December 19992. Changes to the RIPE database
In order to make the database as much self consistent as possible,
the key certificates are stored in the RIPE database. For efficiency
reasons a local keyring of public keys will also be maintained,
however, the local keyring will only contain a copy of the key
certificates present in the database. The synchronization of the
database with the local keyring will be made as often as possible.
The database objects will be created only via the current e-mail
mechanism (auto-dbm@ripe.net), in particular no public key
certificate will be retrieved from a key server by the database
software.
The presence of the key certificates in the database will allow the
users of the database to check the "identity" of the maintainer, in
the sense that they can query the database for the certificate of the
key the database software uses for authenticating the maintainer.
This key certificate can then be checked for existing signatures and
can possibly be compared with the key certificate obtained by other
means for the same user (e.g. from the owner himself of from a public
key server). Although the key certificates can be stored in the RIPE
database with any number of signatures, since the RIPE database is
not communicating directly with the public key servers, it is a good
practice to add the key certificate with the minimum number of
signatures possible (preferably with just one signature: the one of
itself). See also section 4. for more details.
2.1. The key-cert object
A new object type is defined below for the purpose of storing the key
certificates of the maintainers:
key-cert: [mandatory] [single] [primary/look-up key]
method: [generated] [single] [ ]
owner: [generated] [multiple] [ ]
fingerpr: [generated] [single] [ ]
certif: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
The syntax and the semantics of the different attributes are
described below.
Zsako Standards Track [Page 2]RFC 2726 PGP Authentication for RIPE Database Updates December 1999
key-cert: Is of the form PGPKEY-hhhhhhhh, where hhhhhhhh stands for
for the hex representation of the four bytes ID of the PGP key.
The key certificate detailed in the certif attribute belongs to
the PGP key with the id hhhhhhhh. The reason for having PGPKEY- as
a prefix is to allow for other types of key certificates at a