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

[Stephen Kent <[e-mail]>]

On 5/23/13 3:08 PM, Sam Hartman wrote:
>>>>>> "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.
asymmetric
>    The
>    current key table is designed assuming a single asymmetric key.
symmetric
>    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.
I agree that the key table is not a good fit for these reasons.
> * 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.
more good reasons. Yes, BGPSEC makes use of the RPKI for distribution
of certs and CRLs for router keys.
> * The concepts of peers, interfaces, key names and protocol specific
>    information seem inappropriate to private keys.
secret

Yes, BGPSEC router keys are neither peer nor interface-specific.

Steve