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