Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

[Sam Hartman <[e-mail]>]

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

    Stephen> At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
    >> >>>>> "Stephen" == Stephen Kent <[e-mail]> writes:
    >> 
    Stephen> The BGPSEC protocol being defined does not pass around ROAs
    Stephen> or other RPKI repository objects. It defines two new,
    Stephen> signed objects that are passed in UPDATE messages, and are
    Stephen> not stored in the repository. These objects are verified
    Stephen> using RPKI certs and CRLs, so there is a linkage.
    >> 
    >> OK, so how will the upgrade work for these signed objects?  In
    >> particular during phase 2, when both old and new certs (under the
    >> old and new profile) are in use, what happens with these signed
    >> objects?  Can a party generate both old and new signed objects?
    >> If so, will the protocol scale appropriately?  If not, how does a
    >> party know which signed object to generate?

    Stephen> Sam,

    Stephen> The BGPSEC protocol will have to accommodate changes in the
    Stephen> algs used to validate BGPSEC signed objects, and changes in
    Stephen> algs used to validate RPKI objects, and key (not alg)
    Stephen> changes in the RPKI objects, especially the certs
    Stephen> associated with routers. So, format changes are just
    Stephen> another example of a change in the RPKI that BGPSEC will
    Stephen> have to accommodate. This is a legitimate discussion point
    Stephen> for the BGPSEC protocol design discussions that will take
    Stephen> place in SIDR. It is out of scope for the current set of
    Stephen> docs, since they deal only with origin AS validation.

Let me see if I can summarize where we are:
You've describe an upgrade strategey for the origin validation in the
current set of docs. It depends on the ability to store multiple certs,
ROAs and other objects in the repository.

You agree that when SIDR looks at using RPKI objects in the newly
adopted work it will need some upgrade strategy for format, keys and
algorithms.  There are probably a number of options for how to
accomplish this. Even if the working group did decide to update
processing of RPKI objects at that point, requiring new behavior from
parties implementing a new protocol would be possible.

Is that a reasonable summary?