At 11:22 AM -0400 6/14/10, Rob Austein 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.
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.
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.
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.
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.
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.
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 :).
I'm not comfortable killing off the AIA extension, in whatever form
we agree to use.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
