Re: [karp] rt-dir review of draft-ietf-karp-crypto-table

[Sam Hartman <[e-mail]>]

>>>>> "Stephen" == Stephen Kent <[e-mail]> writes:

    Stephen> Randy, You're right that each BGPSEC router has a private
    Stephen> key. However, the key table is designed to manage key
    Stephen> rollover for keys that are shared on a pairwise basis.  The
    Stephen> private router key does not have that property, so it seems
    Stephen> a bad fit.  I should have been more precise in my reply.

Here are some of the reasons I think the key table is a bad fit for
managing asymmetric key pairs:

* Symmetric key pairs have both a public and private portion.  The
  current key table is designed assuming a single asymmetric key.  It
  doesn't have a concept of a portion of a key row that can be public
  nor does it have a concept of making sure the public key corresponding
  to a private key row is available.

* You often need additional public information such as certificates (or
  in some cases CRLs or cached OCSP responses) to provide to a relying
  party to make an asymmetric key useful.  The key table is not designed
  to manage this information.  I don't know much about BGPSEC, but my
  assumption is that it builds on the RPKI's certificate and key
  management practices.  If so, those practices seem very specialized to
  build into something like the key table.

* The concepts of peers, interfaces, key names and protocol specific
  information seem inappropriate to private keys.