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

From: Stephen Kent <[email-masked]>
Date: Tue, 3 May 2011 05:05:01 -0400

At 12:02 PM -0400 4/25/11, Sam Hartman wrote:
>...
>
>
>However, when I look at section 2.1.4 in the signed-object document ,
>the signer can only include one certificate.
>How does that work during phase 2 when some of the RPs support the new
>format and some only support the old format?
>Your text above suggests that RPs grab the certificates from the RPKI
>repository, but it seems at least for end entity certificates they are
>included in the signed object.
>What happens for end entity certificates during this form of upgrade?

Sam,

Yes, only one cert is associated with an RPKI signed object, and yes, 
this cert is embedded in the signed object format. So, when a new 
cert is issued, using a new format, the object itself is changed. 
Thus, the text describing Phase 2 is saying that there will be 
parallel instances of certs, CRLs, and signed objects in the RPKI 
repository system, associated with the old and new cert/CRL formats.
I could add a sentence or two making this explicit, and referring the 
reader to the  phased transition strategy used for algorithm 
transition in the RPKI, and described in 
draft-sidr-algorithm-agility. The reference would be informative, as 
this I-D is still in development and I don't want to hold up the 
progress of the rest of the SIDR docs.

Let me know if this addresses your question.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 May 2011 05:05:58 -0400

At 9:27 AM -0400 4/17/11, John C Klensin wrote:
>Steve,
>Two things:
>
>
>(1) Given the variable amount of time it takes to get RFCs
>issued/ published after IESG signoff, are you and the WG sure
>that you want to tie the phases of the phase-in procedure to RFC
>publication?

It probably would help if the IESG coordinated with the RFC Editor to 
try to avoid having any problems here. But, we anticipate that the 
durations for the phases will be long enough so that a few months in 
the RFC editor's queue can be managed.

>
>(2) There is an incomplete sentence at the end of (2): "This
>allows CAs to issue certificates under" (more context below).
>
>    john

Whoops.  The final sentence should be:

This allows CAs to issue certificates under the new format before all 
relying parties are prepared to process that format.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 May 2011 11:05:18 -0400

Let me make sure I'm understanding what you're saying.  I can have
multiple ROAs for the same set of prefixes in the repository and valid
at the same time: one signed by a new certificate and one signed by a
previous certificate?  If so, I think I now begin to understand why the
SIDR working group believes this is a reasonable strategy.

I guess the only question I'd have remaining is whether ROAs or other
signed objects are intended to be used in other protocols besides simply
living in the SIDR repository?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 3 May 2011 15:16:28 -0400

>SIDR working group believes this is a reasonable strategy.

yes, that is correct.  This is an essential part of the alg transition
mechanism.

>living in the SIDR repository?

The RPKI repository is designed to support a specific, narrow set of
apps. That's what the CP says, and we try to make these certs unattractive
for other apps, e.g., by use of the non-meaningful names.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 May 2011 18:07:59 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    >> 
    >> I guess the only question I'd have remaining is whether ROAs or
    >> other signed objects are intended to be used in other protocols
    >> besides simply living in the SIDR repository?

    Stephen> The RPKI repository is designed to support a specific,
    Stephen> narrow set of apps. That's what the CP says, and we try to
    Stephen> make these certs unattractive for other apps, e.g., by use
    Stephen> of the non-meaningful names.

You had mentioned that about the PKI before.  Now, though I'm focusing
on the ROAs and other signed objects, not the certificates and CRLs.  Do
these narrow applications involve simply storing these objects in the
repository, or are there plans to use ROAs or other signed objects as
elements in protocols?  At least years ago, for example, there was
discussion of carrying signatures of objects in BGP. I understand that's
not within SIDR's current charter, but is SIDR intended to support that
style of use, or have things been narrowed to a point where that would
require reworking details of the repository and PKI?

If the answer is that those sorts of uses are not in scope for the SIDR
architecture, then I think you've basically resolved my concerns.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 May 2011 04:00:18 -0400

Sam,

You might want to look again at the SIDR charter, since it has just 
been revised to include BGP path validation. The path validation 
approach being pursued makes use of the RPKI, consistent with the 
scope of the CP, not surprisingly.

The BGPSEC protocol being defined does not pass around ROAs or other 
RPKI repository objects. It defines two new, signed objects that are 
passed in UPDATE messages, and are not stored in the repository. 
These objects are verified using RPKI certs and CRLs, so there is a 
linkage.

Does that answer your question?

Steve

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 07:48:44 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> 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?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 May 2011 09:14:30 -0400

Sam,

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

It would be inappropriate to suggest delaying this doc (or to suggest 
changes to it) based on discussions that will take place in the 
future, for a protocol that is just being adopted as a WG item now.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 10:32:36 -0400

>> 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?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 4 May 2011 13:20:38 -0400

>ROAs and other objects in the repository.

requirements that already exist to accommodate key rollover and alg 
transition for the RPKI. We have a SIDR doc describing both key 
rollover,

>parties implementing a new protocol would be possible.

I find your last sentence above confusing.  I would say that the 
BGPSEC protocol will have to define how it deals with alg changes for 
the signed objects it defines, with key changes for RPKI certs, with 
alg changes for all RPKI objects, and with format changes for RPKI 
objects and for its own objects.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 May 2011 14:31:39 -0400

Steve, I'd like to thank you for working through these issues with me.
I think the new texxt you added before approval is very helpful.  You
indicated you could add an additional sentence pointing out that
multiple signed objects would need to be used in order to deal with
phase 2 for end-entity certificates.  While I think that would be
reasonable to add, I also don't think it is necessary.
I'm sorry the upgrade approach was not more obvious from the beginning.
>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    Stephen> I find your last sentence above confusing.  I would say
    Stephen> that the BGPSEC protocol will have to define how it deals
    Stephen> with alg changes for the signed objects it defines, with
    Stephen> key changes for RPKI certs, with alg changes for all RPKI
    Stephen> objects, and with format changes for RPKI objects and for
    Stephen> its own objects.

Excellent.  Please consider it early input to the WG process that how
the protocol deals with all of these issues should be documented. The
sort of structure you adopted for the text added to cert profile seems
like a fine style to use, although of course there are others that would
also work.  What I think is important is that the IESG and community at
large be able to evaluate these transition issues when the protocol
comes up for IETf review.

In conclusion, thanks again for your help. I see you're giving a talk
next Thursday on these issues at an ISOC chapter meeting; I hope to attend and better come up to
speed.