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