The fundamental point that I think you are missing is that other
people will have different concerns and threat models that you do.
Thus, it's helpful to enumerate the ways things can be done and ensure
that the overall architecture (vs. a specific mechanism that you are
proposing) can admit solutions for a large set of people.

  B. If the tapes are stored in a trusted environment, it should be no
     problem to store the private key along with the tapes.  In addition,
     you can store a copy of the key in a safe.

The point you are missing is that these are then steps that have to be
done right to get data back.  In large organizations it is often hard
to do many things right, and key management for keys you rarely need
is unlikely to be at the top of the priority list.  And, some will not
see the confidentiality advantage from encrypting tapes they already
keep locked up, but will perceive a loss of relibility.  So I believe
that a number of people will choose, and rationally so, not to encrypt
the tapes.

  D. What would be the benefit of this case?  I see only disadvantages here:
     - high load on tapeserver.
     - more surface for attackers.

I don't see much benefit, but it could work with existing krb4 support
for transport (with old clients) and a local modification on the
server.

  So E has no disadvantages here.

With respect to confidentiality, no.  But E is weaker than the cases
that don't encrypt tapes from the backup availability perspective.

  It's true there are many ways to implement all that.  But restricting to
  client-encrypted-pubkey method would greatly simplify implementation
  _and_ configuration.

Sure, it's totally reasonable to implement this mechanism now.  I
didn't mean to argue that you shouldn't.

    define dumptype foo {
      foo-bar-dumptype
      crypt-pubkey  /path/to/pubkey-%h-%d  # public  key is on client
      store-privkey /path/to/privkey-%h-%d # private key is on server
    }

If the private key is on the server the data on the server might as
well be in the clear.  But, not having so makes interactive restores
harder.  This really needs quite a lot of key management thought.  But
later, I see that you intend to be able to implement cleartext on
tapes but with transport encryption via this.

It's broken from a security viewpoint to only configure this on the
server, particularly without authentication of the dump requests.  If
the client's data has a policy that it should only be backed up
encrypted to some key, then one needs configuration on the client to
restrict dumps to only be encrypted to that key.

-- 
        Greg Troxel <gdt AT ir.bbn DOT com>