PGP Authentication for RIPE Database Updates
RFC 2726

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 1999

2. 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