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

Stephen Kent <> Tue, 28 May 2013 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B18C121F989B for <>; Tue, 28 May 2013 09:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEpmjQIyRxzP for <>; Tue, 28 May 2013 09:34:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C01E721F9889 for <>; Tue, 28 May 2013 09:34:52 -0700 (PDT)
Received: from ([]:50004) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1UhMrJ-000LrU-Uv; Tue, 28 May 2013 12:34:50 -0400
Message-ID: <>
Date: Tue, 28 May 2013 12:34:49 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Sam Hartman <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [karp] rt-dir review of draft-ietf-karp-crypto-table
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 May 2013 16:34:58 -0000

On 5/23/13 3:08 PM, Sam Hartman wrote:
>>>>>> "Stephen" == Stephen Kent <> 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.
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.

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