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: > ... > 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). 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. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
