Subject: [sidr] key rollover and algorithm migration

From: Stephen Kent <[email-masked]>
Date: Fri, 11 Jun 2010 18:08:23 -0400

Folks,

The design team (Roque, Sean, and I) has been working on an I-D to 
deal with algorithm migration (as directed by our cognizant AD, Tim). 
In the course of exploring ways to do this, we (at least I) became 
convinced that we first needed to document how to perform 
(non-emergency) key rollover when the algorithm suite stays constant. 
I view this as a very similar transition problem, and one that needs 
to be addressed first, to provide guidance to the algorithm migration 
problem.

Anyway, in the course of exploring solutions we have encountered some 
problems with some aspects of the current RPKI design details. So, 
before we proceed too far, we wanted to share our perceptions of the 
requirements for key rollover (and algorithm migration), to make sure 
that there is WG agreement on the basis for this work.  Also, this 
provides a context and rationale for some of the changes that we 
believe may be needed for two, current SIDR I-Ds (resource 
certificate profile and repository structure).

The RPKI must accommodate transitions between the public keys used by 
CAs. Transitions of this sort are usually termed "key rollover". 
Planned key rollover will occur at regular intervals throughout the 
life of the RPKI, as each CA changes its public keys, in a 
non-coordinated fashion. (By non-coordinated we mean that the time at 
which each CA elects to change its keys is locally determined, not 
coordinated across the RPKI.) Moreover, because a key change might be 
necessitated by suspected private key compromise, one can never 
assume coordination of these events among all of the CAs in the RPKI. 
In an emergency key rollover, the old certificate is revoked and a 
new certificate with a new key is issued. (We do not plan to provided 
a detailed discussion regarding emergency key rollover in this 
document unless the WG requires such.)

In discussing key rollover we make a few assumptions (goals?):

1. We assume that each relying party (RP) accesses the repository 
system in a locally-controlled fashion. The RP may employ a top-down 
tree walk, as suggested in the repository structure I-D, but that 
tree walk may be interrupted by communication problems, publication 
point lockout (to enable a publisher to add or remove objects in an 
"atomic" fashion, local processing problems, etc. As a result, an RP 
may skip over one or more publication points and return to them 
later. Moreover, an RP may suffer a partial of total loss of data 
from the local cache that the repository structure documents suggests 
each RP maintain. Thus we cannot assume that an RP visits every 
publication point in order, in a continuous, top-down fashion. We 
also cannot be certain how long it may take an RP to complete its 
traversal of the repository tree. Thus we must be prepared to 
accommodate situations in which an RP elects to process the data it 
has collected, even if that data is a mix of old and new retrievals. 
We are pursuing a strategy for key rollover (and algorithm suite 
migration) that minimizes the likelihood that an RP will be unable to 
verify data that it has retrieved from the repository, under the 
processing and communication assumptions noted above.

2. It is necessary for a CA to be able to rollover a key without 
affecting subordinate CAs, e.g., these CAs MUST NOT be required to 
reissue any certificates or signed objects that they manage in their 
directory (repository publication point). This assumption implies 
that only CAs are involved in key rollover: the CA requesting the 
rekey, and its parent.

3. In the case of algorithm migration, we expect that it will take 
some time for ALL CAs and ALL RPs to be prepared to generate and 
consume signed objects produced using a new algorithm suite. To 
simplify the migration, we assume that the upper tiers of the RPKI, 
e.g., IANA and the RIRs, will be the first to support a new algorithm 
suite. This assumption means that a lower tier CA will not be able to 
issue certificates, CRLs, and signed objects under a new algorithm 
suite until all of its parents have begun to do so.  We want to know 
if this is a reasonable assumption. Because we also assume that 
migration will take a while (a year or more?), it will be essential a 
CA that has begun to use the new suite publish certificates, CRLs, 
and signed objects under both the old and new suites during the 
migration period.

Given these assumptions, we have adopted an initial design in which 
both key rollover and algorithm suite migration entail an interval 
during which old and new CA certificates, CRLs, and signed objects 
are maintained in parallel in the repository system.  For key 
rollover, we anticipate that this interval will be relatively brief, 
say 3-7 days. For algorithm suite migration we anticipate that it 
will be much longer, as noted above in assumption #3.

One implication of this initial design is that the definition of the 
AIA pointer in each (non-self-signed) certificate needs to be 
changed. The certificate profile calls for this extension to point to 
the file containing the parent (CA) certificate. The problem with 
this definition is that it conflicts with assumption/goal #2. When a 
CA rekeys it is issued a new certificate, by definition. That CA will 
then have to reissue certificates to its subordinate CAs, under the 
rekeyed CA's new key. This can be done without coordinating with the 
subordinate CAs. However, each certificate issued by one these 
subordinate CAs contains an AIA extension that points back to the OLD 
subordinate CA certificate. That means that these subordinate CAs 
would have to reissue their EE and subordinate CA certificates, to 
incorporate a new AIA extension, and this would have to propagate 
down the whole RPKI hierarchy! There is a simple fix to this, i.e., 
make the AIA extension point to the directory in which the parent CA 
certificate is stored. That way, when a CA rekeys and reissues 
subordinate CA certificates, IF those certificates are stored in the 
same directory as the old certificates, the rekey event does not 
affect subordinate CAs, as per #2 above. Note that this approach to 
using the AIA extension is consistent with what PKIX mandates for 
other, directory environments, i.e., X.500 and LDAP. The SKI/AKI 
extensions, which are mandated in the RPKI, are designed to enable an 
RP to select the "right" CA certificate from a directory that may 
contain more than one certificate associated with the same CA, but 
containing different keys. So, the RPKI certificate profile already 
includes the needed extensions to enable an RP to determine which CA 
certificate is appropriate for a given child certificate (CA or EE).

An implication of assumptions #1 and #3 is that, during a transition 
interval, old and new CA certificates, CRLs, and signed objects 
associated with a rekeying CA will co-exist. This means that there 
must be a way to generate file names for these entities that do not 
conflict.  The current file name generation approach described in the 
repository structure I-D does not accommodate this for subordinate CA 
certificates. There is no problem for CRL or manifest files, because 
their file names are generated form the rekeying CA's public key, and 
that has changed, by definition. However, the files that contain 
subordinate CA certificates need a slightly modified naming 
procedure, since the public key for each of these certificates has 
not changed. It should be easy to modify the naming generation 
algorithm to call for appending a delimiter (maybe a dash?) and one 
digit, to allow old and new to coexist. A single digit qualifier 
should suffice as we don't seem to need to maintain more than that 
two instances of these CA certificate files. (We might make the value 
be a mod 2 counter?)

We would like to receive feedback from the WG before we go to far 
with this design.  Please consider the assumptions/goals described 
above and let us know if you agree with them, if you think they 
should be modified, or if you want to suggest others. 

Also, please consider the impact of the two changes noted above, 
relative to the resource certificate profile and repository structure 
I-D's. We have tried to explain why we believe that these changes are 
required, but we recognize that a number of folks have been writing 
code based on these I-Ds, and thus there are impacts when changes of 
this sort are proposed.

Finally, as I noted in my comments on the repository structure I-D on 
5/26, and in my review and suggested edits of that document posted a 
few days before, I am still wondering why we need to change the name 
of CA when we rekey it. This is not normally mandated in a PKI, 
although we are free to impose such a requirement for the RPKI if 
appropriate.  I even generated text for the resource certificate 
profile to specify how to do this, using a combination of the common 
name and serial number attributes.  (This was proposed as a way to 
accommodate the need to change the CA name, while retaining some part 
of it that might be a locally significant ID, e.g., a database key.) 
While I don't see a problem with performing key rollover and 
algorithm migration if we have to retain this requirement, I do 
believe that we ought to document the rationale for it.

Thanks,

Steve

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Jun 2010 09:09:27 +1000

On 12/06/2010, at 8:08 AM, Stephen Kent wrote:
> 
> Finally, as I noted in my comments on the repository structure I-D on 5/26, and in my review and suggested edits of that document posted a few days before, I am still wondering why we need to change the name of CA when we rekey it. This is not normally mandated in a PKI, although we are free to impose such a requirement for the RPKI if appropriate.  I even generated text for the resource certificate profile to specify how to do this, using a combination of the common name and serial number attributes.  (This was proposed as a way to accommodate the need to change the CA name, while retaining some part of it that might be a locally significant ID, e.g., a database key.) While I don't see a problem with performing key rollover and algorithm migration if we have to retain this requirement, I do believe that we ought to document the rationale for it.

The requirement was introduced into the res-cert draft in response to a review comment from David Cooper:

3) Section 3.9.5 states:

    In this profile, the scope of the CRL is specified to be all
    certificates issued by this CA issuer using a given key pair.

 The scope of a CRL MUST be all certificates issued by the issuing CA
 unless the CRL includes an issuingDistributionPoint extension.  So, if
 the scope of CRLs is to be limited to certificates signed with a given
 key pair, then the profile must either require inclusion of the
 issuingDistributionPoint extension in CRLs or forbid CAs from performing
 key rollover. The latter option may be implemented by having issuers
 change names whenever changing the key pair used to sign certificates.

http://www.ietf.org/mail-archive/web/sidr/current/msg00476.html (and the ensuing brief thread).

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Sat, 12 Jun 2010 09:20:38 +1000

On 12/06/2010, at 8:08 AM, Stephen Kent wrote:

> 
> Given these assumptions, we have adopted an initial design in which both key rollover and algorithm suite migration entail an interval during which old and new CA certificates, CRLs, and signed objects are maintained in parallel in the repository system.  For key rollover, we anticipate that this interval will be relatively brief, say 3-7 days. For algorithm suite migration we anticipate that it will be much longer, as noted above in assumption #3.
> 

For algorithm suite migration this extended period of parallel operation with an imposition of top down migration is certainly an interesting approach. The comments in section 3 of draft-ietf-sidr-rpki-algs-01.txt address this form of algorithm migration and cast some doubt as to the feasibility of such an approach within the scope of conventional operational practices when looking at the behaviour of widely distributed data structures. If the operational impost of maintenance of parallel structures over an extended period was considered to be too risky in terms of ensuring a requirement for precise coherence between the multiple structures and ensuring identical outcomes for every relying party , are there alternative approaches that mitigate some of these risks?

> 
> We would like to receive feedback from the WG before we go to far with this design.  Please consider the assumptions/goals described above and let us know if you agree with them, if you think they should be modified, or if you want to suggest others. 

At this point, I do not agree with the approach you describe here, given the considerations summarized above. It appears to describe a path of high complexity and high risk of chaotic outcomes.

Geoff

---

From: Stephen Kent <[email-masked]>
Date: Sun, 13 Jun 2010 10:14:53 -0400

At 9:09 AM +1000 6/12/10, Geoff Huston wrote:
>O...

Geoff,

Thanks for the explanation. David suggested two solutions to the 
problem, and you chose to mandate changing the CA name rather than 
adding the IDP extension into the CRL.

The ensuring brief thread, that I just (quickly) reviewed, entailed 
message exchanges between only you and David, and involved clarifying 
discussion about how one could use the iDP extension to qualify the 
scope of a CRL when rekeying. (It also included a confusing excursion 
into revocation reason codes, and a discussion of appropriate key 
lengths to match hash algs. That latter discussion may have been 
unduly biased by some NIST guidance that focuses on long term sigs 
vs. certs, but ...)

I'd just like to make sure that, that the WG still agrees that this 
is the preferred solution.  If so, we can accommodate that in the 
key/alg rollover document, and note the rationale.  I do think the 
rationale also should appear in the repository structure document as 
well, maybe the resource cert profile too. It would take only a short 
paragraph to do so.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 13 Jun 2010 10:15:37 -0400

At 9:20 AM +1000 6/12/10, Geoff Huston wrote:
>>  Given these assumptions, we have adopted an initial design in 
>>which both key rollover and algorithm suite migration entail an 
>>interval during which old and new CA certificates, CRLs, and signed 
>>objects are maintained in parallel in the repository system.  For 
>>key rollover, we anticipate that this interval will be relatively 
>>brief, say 3-7 days. For algorithm suite migration we anticipate 
>>that it will be much longer, as noted above in assumption #3.
>>
>
>For algorithm suite migration this extended period of parallel 
>operation with an imposition of top down migration is certainly an 
>interesting approach. The comments in section 3 of 
>draft-ietf-sidr-rpki-algs-01.txt address this form of algorithm 
>migration and cast some doubt as to the feasibility of such an 
>approach within the scope of conventional operational practices when 
>looking at the behaviour of widely distributed data structures.

Can you elaborate on this concern?

>If the operational impost of maintenance of parallel structures over 
>an extended period was considered to be too risky in terms of 
>ensuring a requirement for precise coherence between the multiple 
>structures and ensuring identical outcomes for every relying party , 
>are there alternative approaches that mitigate some of these risks?

I initially investigated an approach that allows a CA at any point in 
the hierarchy to begin using the next alg suite, subject only to the 
constraint that the CA's parent is prepared to effect PoP with the 
new alg suite when issuing a cert to that CA. However, this approach 
seems to result in much greater complexity than a top-down approach.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jun 2010 11:19:10 -0400

Geoff,

Thnaks for the speedy reply.  As I noted, if the WG is still 
comfortable with the name-change approach to key rollover, I am not 
opposed, and I don't see it causing problems for key rollover (or alg 
migration) approaches that we're developing.

I'm not sure that the issuing CDP is a bad option. Each resource cert 
already contains a CRLDP extension, pointing to the CRL on which the 
cert will appear if it is revoked.  If one put the same URI into the 
CRL, in the Issuing distribution point extension, that would seem to 
allow an easy check to ensure that the CRL being checked it the right 
one for the cert in question. (That's the reason the CRL IDP 
extension exists.) I'll ask David Cooper, Tim, and Russ for their 
perspectives on this.  My view is that not having to change the CA 
name each time the CA rekeys is simpler, and if we can remove the 
serial number attribute feature that we added to compensate for the 
name change, I think that would be preferable as well.

Upon further reflection I agree with you that the res cert profile is 
probably the best place to document the decision, if we elect to keep 
the name change procedure.  We also would need to document the use of 
the CRL IDP extension, and explain the rationale for its use here, if 
we elect to go that way.

Steve

---

From: Rob Austein <[email-masked]>
Date: Mon, 14 Jun 2010 11:22:02 -0400

I need to read this thread a couple more times before I'll be sure I
really understand all the questions Steve is asking, but one
particular paragraph leapt out at me:

At Fri, 11 Jun 2010 18:08:23 -0400, Steve Kent wrote:
> ...

I see some issues lurking here:

1) Our use of the AIA pointer has always been a little weak.  At least
   in my validation code, which always runs top-down, the AIA pointer
   serves largely as a sanity check or source of gratuitous errors,
   depending on one's point of view.  That is: I check whether the AIA
   pointer matches up with the parent, per the res-certs profile; if
   it doesn't, the child fails validation, which might be good or
   might be bad depending on why the AIA pointer doesn't match.  Our
   use of the AIA pointer has always been problematic for things like
   Steve's local trust anchor proposal.

2) I don't think that just redefining the AIA pointer to point to the
   directory will work, due to approximately the same problem that
   caused us to add manifests to the SIA extension.  The situation is
   different here, though, because pretty much by definition the child
   doesn't know the set of parents signing it would be (forgive the
   imprecise language, Steve) so it couldn't generate a manifest if it
   wanted to do so.  So I think that this approach would leave us
   potentially vulnerable to drop-out and replay problems.

More generally, I'm not sure I believe the model you're using here.
We've been doing rekey operations with my software for years now, and
it seems to work, without needing to change the AIA definition.  We
handle it by reissuing one level down, to fix the AIA pointers.  One
doesn't have to reissue further down, unless there are other changes.
Essentially what happens is that one ends up in a transient state with
two (or more) paths down to the same certificate, one of which
validates and one of which doesn't, depending on exactly which updated
objects the RP has managed to retrieve at any given moment.  So one
does the usual cycle of publishing new stuff, waiting a while for it
to propagate, then cleaning up the old stuff.  We ended up making the
"wait for it to propagate" a manual control, ie, publishing the new
stuff and cleaning up the old stuff are two separate operations and
the time between them is controlled by the operator, not the software,
because we didn't think there's a one-size-fits-all answer to how long
to wait.

So (a) I'm not sure I agree with the problem as stated, but (b) we
might just want to get rid of the AIA pointer anyway, or at least make
it purely advisory (not a res-certs profile conformance violation if
the AIA pointer is whacked).  Not sure yet.  Maybe both :).

But maybe I'm missing something, I'm only on my second cup of tea.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Jun 2010 16:07:10 -0400

At 8:45 AM -0500 6/14/10, George, Wes E IV [NTK] wrote:
>
>... (We do not plan to provided a detailed discussion regarding 
>emergency key rollover in this document unless the WG requires such.)
>[[WEG]] I think that depends on your definition of "detailed" as to 
>whether I'm ok with that. Is that one sentence the sum total of your 
>planned discussion, or are you going to expand it somewhat?

I envision saying only that an emergency key rollover requires 
immediate revocation of the old CA cert and issuance of a new one, 
and thus there is may be no overlap period (unless the emergency 
rekey takes place during a planned rollover).

>  Depending on the order of the final document, you may need to 
>explain the difference in general terms - the idea of immediate 
>revocation as a difference won't be obvious if you haven't yet 
>discussed old and new key existing in parallel for some period of 
>time as in a scheduled roll.

good point.

>Also, either way I think you need to discuss what immediate 
>revocation means in terms of the behavior of the system. You imply 
>that it's virtually a requirement to have an overlap period since 
>there is no coordinated change, so I think you need to discuss at 
>least in general terms what happens if you forego the overlap period 
>with an immediate revocation, and how to mitigate any issues that 
>arise from that, even if it's to recommend that emergency rolls 
>require some means of coordination to minimize their impact.

another good point. I can see that we probably will need a few 
paragraphs to address your comments.

>  And yes, I realize that coordination, especially on an emergency 
>timeline may be impossible, so it may be up to the community to look 
>at the potential impact and say, "go back to the drawing board" or 
>accept it as-is and hope that there is never an emergency.

OK.

Steve

---

From: Geoff Huston - SIDR <[email-masked]>
Date: Tue, 15 Jun 2010 16:16:14 +1000

My second response to Steve Kent, also sent to the sidr WG 24 hours ago, does not appear to be in the WG mailing list archive either.

Let met try once more to send this to the sidr wg.

Geoff

--------------------------
On 14/06/2010, at 12:15 AM, Stephen Kent wrote:

>> For algorithm suite migration this extended period of parallel operation with an imposition of top down migration is certainly an interesting approach. The comments in section 3 of draft-ietf-sidr-rpki-algs-01.txt address this form of algorithm migration and cast some doubt as to the feasibility of such an approach within the scope of conventional operational practices when looking at the behaviour of widely distributed data structures.
> 
>> If the operational impost of maintenance of parallel structures over an extended period was considered to be too risky in terms of ensuring a requirement for precise coherence between the multiple structures and ensuring identical outcomes for every relying party , are there alternative approaches that mitigate some of these risks?
> 
> I initially investigated an approach that allows a CA at any point in the hierarchy to begin using the next alg suite, subject only to the constraint that the CA's parent is prepared to effect PoP with the new alg suite when issuing a cert to that CA. However, this approach seems to result in much greater complexity than a top-down approach.

As a general comment, I have doubts about any high degree of isomorphism between key rollover and algorithm migration, and consequently I wonder if the proposed approach of attempting to use a single document is creating a artificial incentive to define a single approach when in fact they are operationally quite distinct functions and may justifiably be efficiently addressed by distinct algorithms. If that is indeed the case that the most operationally effective and efficient procedures are quite distinct then the rationale to describe these procedures in a single document would appear to me to pretty much entirely unconvincing.

With respect to a CA performing a key rollover, as I understand it, a key rollover is intended to be a local operation performed by a CA. While there is a forced impact on the CA's immediate parent in terms of issuing a new certificate, the intent of the key rollover procedure was, I thought, to limit the impact on the CA's subordinates. An algorithm migration is a collective procedure where, as I understand it, there is the desire to head to an end state where all parties, CAs, EEs, and Relying Parties have migrated to exclusive use of the "new" algorithm, and the issue here is to define a procedure for collective action across the entire RPKI that does not necessarily involve critical or forced dependencies. At present the key rollover procedure is documented as part of the "design notes" of the res-cert draft. The choice of a design note was to delineate the standard specification component of the draft, namely that of a standard profile of fields for certificates, CRLs and certificate requests, from the descriptions of procedures and constraints that were not necessarily an integral part of the standard specification.

With respect to algorithm migration migration, there is an imposed requirement for some level of coordination of actions over an extended period, and also a need for duplication of actions, which is not necessarily the case in key rollover. In one form of the key rollover algorithm (the one documented in draft-ietf-sidr-res-certs) the entity performing the key rollover firstly requests a certificate for the new key, while leaving the old certificate in place. The entity can then wait for replying parties to "catch up", by giving relying parties some time to retrieve the new certificate. After this time it is an option for the entity to reissue the subordinate products using the new key, and it is possible to have the old set of subordinate products be overwritten (or replaced) with the new set. The algorithm migration procedure cannot assume that there is some small "catch up" time after which all relying parties can be assumed to be able to use the new algorithm. The consequence, as I understand it, is that the entity has to in effect operate in a mode where all actions are duplicated, once for each algorithm. This is, in effect, specifying the construction and operation of a parallel RPKI structure that is entirely distinct from the "current" RPKI structure by virtue of its exclusive use of a "new" algorithm for signature generation.  The latter option, that of the concurrent operation of parallel RPKI structures, poses some complex issues in terms of synchronisation of actions across the set of RPKI CAs, as well as issues of consistency and coherency in the operation of multiple parallel RPKI frameworks, as well as the uncertainties associated with a global determination of when any such transition can be considered "complete". This poses some issues which to my mind are not dissimilar to the difficulties that are being presented with the current IPv6 transition. The notes in the draft-sidr-algs draft pointed to the possible direction of maintained a single collection of signed objects, and use a CMS structure of multiple signatures. while this does not mitigate the need for multiple certificate hierarchies (one per algorithm) it does at least address the issue of multiple distinct sets of signed objects by collapsing these back to a single (distributed) set of signed objects,

regards,

 Geoff

---

From: Geoff Huston - SIDR <[email-masked]>
Date: Tue, 15 Jun 2010 18:35:38 +1000

My response to Steve Kent, sent to the SIDR WG > 24 hours ago, does not appear to be in the WG mailing list archive. It appears that using IPv6 to send mail to the sidr mailing list is not a good idea. The mail appears to to have been sent to the IETF mail servers according to the local mail log but never makes it to the mailing list on the IETF's systems. (So much for IPv6 robustness at the IETF, if thats indeed what has happaned!)

Let met try once more to send this to the sidr wg using a different mechanism....

Geoff

Geoff

On 14/06/2010, at 12:14 AM, Stephen Kent wrote:

> Thanks for the explanation. David suggested two solutions to the problem, and you chose to mandate changing the CA name rather than adding the IDP extension into the CRL.

This is true, although I have a recollection of consulting with some others at the time.
> 
> The ensuring brief thread, that I just (quickly) reviewed, entailed message exchanges between only you and David, and involved clarifying discussion about how one could use the iDP extension to qualify the scope of a CRL when rekeying. (It also included a confusing excursion into revocation reason codes, and a discussion of appropriate key lengths to match hash algs. That latter discussion may have been unduly biased by some NIST guidance that focuses on long term sigs vs. certs, but ...)

I have not dredged up all the emails from the time, but I recall (possibly not quite accurately) that at the time the general view was that the alternatives involved keeping the CA constant and allowing a CRL signed with the "new" key to revoke objects that were signed with "older" keys, or using a regime whereby the scope of the CRL which was limited to objects that were signed with the same private key that was used to sign the CRL was retained, which appeared to imply the concept of a key rollover implying a new CA. As I recall there was a marked preference for the latter course of action as representing the least impact on the evolving code base and an expectation that this limited CRL scope could be of benefit in this environment of a widely distributed PKI. Hence, the response to David's comments was to forbid CAs from performing a key rollover and implement key rollover via the use of change of CA.  

> 
> I'd just like to make sure that, that the WG still agrees that this is the preferred solution.

I agree that this is a prudent check.

> If so, we can accommodate that in the key/alg rollover document, and note the rationale.  I do think the rationale also should appear in the repository structure document as well, maybe the resource cert profile too. It would take only a short paragraph to do so.

I think it better not to succumb to the temptation to play hide and seek with a future consumer of these documents and embed critical design information and rationales in a whole set of documents. Its probably also unwise to copy this information and rationale and use it in multiple documents given the possibility of latter revision of one of the documents but not the others, resulting in the potential for contradiction. On that basis I would argue in favour of a position that placed constraints on a CA and the rationale for this constraint in a single document. It seems to me that the most logical place is the resource certificate profile document. I do not see a convincing case to duplicate this same rationale in the repository structure document, nor in an algorithm migration document, based on these considerations.

regards,

 Geoff

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Jun 2010 13:28:22 -0400

>    Steve's local trust anchor proposal.

If one always were able to do the tree traversal top down, I can see 
why the AIA pointer might be superfluous. But, I belive that we ought 
to be prepared to accommodate tree traversal that may (temporarily) 
skip over some directories in the process.  As I suggested in my 
note, a directory might be inaccessible due to locking for an update, 
a (hopefully transient) comm error, etc. I'd rather not require RP 
software grind to a halt waiting for these problems to go away , as 
that presents a DoS vulnerability.

>    potentially vulnerable to drop-out and replay problems.

I don't understand this argument. (also note that for a given cert, 
there is exactly one parent, not a "set" as described above. There 
may be more than one CA cert that can be used to validate the target 
cert.  Is that what you referring to above?) If the AIA extension 
points to the directory
that contains the parent CA cert(s) then there should be no problem. 
One can start by acquiring the directory contents. In a normal 
directory environment (e.g., X.500 or LDAP) one would then look at 
all of the certs to find the ones with a Subject name that matches 
the Issuer name in the target cert (the cert being validated). If 
there is more than one such cert, then match the AKI from the target 
cert against the SKI in each CA cert (with the right Subject name). 
The result should be a CA cert than can be used to validate the 
target cert.  Because the RPKI has manifests, we can augment the 
procedure above to filter out "bad" files early in the process, and 
we can alert the RP is a file is missing (one the manifest but not in 
the directory.

>because we didn't think there's a one-size-fits-all answer to how long

I agree that, in general, the model you describe is reasonable, but 
there are some cases in which I fear it may not work.  I'll provide 
examples in a message I am composing in reply to one of Geoff's 
recent messages.

>the AIA pointer is whacked).  Not sure yet.  Maybe both :).

I'm not comfortable killing off the AIA extension, in whatever form 
we agree to use.

Steve

---

From: Sean Turner <[email-masked]>
Date: Tue, 15 Jun 2010 15:14:17 -0400

>    Steve's local trust anchor proposal.

Did you see something in Section 6.1 of RFC 5280 that made you think 
AIA should be used during path validation?  If you use the 
id-caIssuers method in the AIA, then it is useful to locate the 
certificates needed to build the path, but I don't think you need to 
use it during path validation.  There are a couple of pieces of 
information in the certificate that are useful for building the path 
but don't need to be checked during validation.  I think AKI, SKI, and 
AIA fall in to that category. I guess you're free to add any checks 
you like, but if a check causes the path validation to fail that 
should have otherwise passed - then that's a bad thing.

spt

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Jun 2010 15:44:47 -0400

Sean,

The SIDR WG has defined its own certificate validation algorithm in 
Section 7 of draft-ietf-sidr-res-certs-18.  Steps 3 and 4 in Section 7.2 
require the client to check that:

       3.  The certificate contains all fields that MUST be present and
           contains field values as specified in this profile for all
           field values that MUST be present.

       4.  No field value that MUST NOT be present in this profile is
           present in the certificate.

So, for a client to conform to draft-ietf-sidr-res-certs-18 it MUST 
check (for example) that certificates include a subject key identifier 
extension, that the extension is marked as non-critical, and that its 
value is the SHA-1 hash of the subject public key.

A couple of years ago I pointed out that these checks were unnecessary, 
that RFC 5280 discourages including checks during path validation for 
the sole purpose of verifying that the certificates were issued in 
conformance with the profile, and that requiring the checks to be 
performed would preclude the use of off-the-shelf path validation 
software in the RPKI.  While no one explained the reason for mandating 
these checks, I was told that "the requirements of steps 3 and 4 very 
definitely are intended to be applied" and the requirements were kept in 
the document.

Dave

---

From: Rob Austein <[email-masked]>
Date: Tue, 15 Jun 2010 16:01:43 -0400

At Tue, 15 Jun 2010 15:14:17 -0400, Sean P Turner wrote:
> AIA should be used during path validation?

No.  The issue is conformance to draft-ietf-sidr-res-certs, which is a
tighter set of constraints than RFC 5280 or RFC 3779.

One might disagree with that profile (and on this particular point
regarding the AIA pointer I've been thinking that perhaps I do) but
I was talking about validation within the context of that profile.

---

From: Sean Turner <[email-masked]>
Date: Tue, 15 Jun 2010 17:09:51 -0400

> require the client to check that:

Dave,

Thanks for the heads up. I'm still learning all the ins and outs of 
these specs.

> definitely are intended to be applied" and the requirements were kept in 

Are we doing these checks to slow the validation process down? ;) 
Like I said I don't see the need to check some of the information in 
the certificate during validation.  I agree with you that it is 
unnecessary to check a few of things during path validation that are 
required to be in some certificates: AKI, SKI, AIA, SIA, and CRLDP.

If these checks can't be explained and it's causing problems for key 
rollover, then maybe we should drop the checks.

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 15 Jun 2010 17:11:49 -0400

> I was talking about validation within the context of that profile.

Rob thanks for setting me straight.  I think I'm starting to disagree ;)

spt

---

From: Robert Kisteleki <[email-masked]>
Date: Tue, 15 Jun 2010 15:37:56 -0700

> the AIA pointer is whacked).  Not sure yet.  Maybe both :).

Please don't kill AIA, it's useful for discovery. I agree that you don't 
need to use it in verification though.

Robert

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Jun 2010 10:29:42 -0400

At 3:37 PM -0700 6/15/10, Robert Kisteleki wrote:
>Please don't kill AIA, it's useful for discovery. I agree that you 
>don't need to use it in verification though.
>
>Robert

I was just thinking about Robert's plan to use RPKI certs to verify 
signed RPLS objects.  This application needs AIA and the other 
bottom-up cert path discovery methods that are common for PKI apps. 
I don't know if we will have other such apps in the future, but if 
so, this is an example of a situation where we cannot always rely on 
a top-down cert acquisition methodology.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Jun 2010 18:04:49 -0400

David & Sean,

We put checks into the validation spec to try to ensure that CAs 
issue certs consistent with the profile.

This profile is for a large, highly distributed system that needs to 
work reliably across the public Internet.  Note that the RPKI asks 
Internet registries and ISPs to act as CAs. They are not 
organizations that set out to act as CAs to make money issuing certs; 
they allocate address space (either as a primary function, or as a 
side effect of offering ISP services). We don't want to make life 
hard for them, either as CAs or as RPs.  Recall that the RPKI is 
unusual (unique?) in that essentially every RP is also a CA, so each 
of these organizations has a dual role.

Over the years we have seen a lot of examples of CAs doing an awful 
job of issuing certs in compliance with the PKIX profiles, and RP 
software that behaves equally poorly, condoning (encouraging?) such 
behavior. My hope (maybe Geoff's ad well) is to try to get RP 
software to help detect bad CA behavior in this respect, to provide a 
feedback loop to help address such problems.

Steve