just an FYI - don't panic

>  As to PGP, a major design issue needs to be solved first: Where to store
>  the public keys. It seems that the RA team is prepared to maintain the
>  keys manually and separately from the database proper. Given the immediate
>  number of updates this may be feasible. In the long run it might be better
>  to store the keys as part of the maintainer object itself.

Daniel,

For the moment, I think the need to have your code support PGP object
authentication, leaving key management explicitly out of band, is
large enough to warrent support.  We certainly do not mind having key
management as an out of band activity, at least initially. We do,
however, want something stronger than the current system.

I would like to be able to sign an entire database, as well. We
currently maintain what is effectively a local and exported version of
our database.  The exported version may have aggregates surpressed,
advisory tags added, etc for the happiness of the downstream ACL
builder. Right now, this is somewhat easier than trying to get users
to maintain community strings. The local db version has everything.
Signing the published db would be a positive check on whether it is
authentic or not.

While I recognize it does not scale and that we need something else, I
actually *like* the idea of OOB key management. The reason is that I
view the database as an repository of the transactions of a trusted
administrative relationship. OOB key management is just another
opportunity to find out who it is I am actually about to trust.  Maybe
the RA could set up a PGP key server as a value added service for
routing coordination?

Eric Carroll	University of Toronto Network & Operations Services
		External Networking Facilities Management



-------- Logged at  Tue May 16 16:20:41 MET DST 1995  ---------