Folks,
The repository structure doc devotes a moderate amount of text to
accommodate what are termed "multi-use" EE certs. I'd like to
simplify these docs if we can, by dropping special repository
treatment for multi-use certs, if there are no strong objections.
Recall that almost almost all EE certs used in the RPKI are contained
in CMS signed objects (that conform to the newly adopted RPKI signed
object spec). The simplest model for EE certs in this context is to
maintain a 1-1 correspondence between the EE cert and the object that
is verified using the cert. That way one can revoke the EE cert and
kill the associated object, with no collateral damage :-). Also,
because of the limited scope of the cert, one can dispose of the
private key associated with the cert, as soon as the object in
question has been signed.
A multi-use EE cert is a cert used to verify more than one RPKI
signed object. In the RPKI context this means that, if one revokes a
multi-use cert, all of the objects that are verified using that cert
are killed when the cert is revoked. Thus one needs to choose
carefully which set of objects should be verified under a multi-use
cert. (Note that this is an EE cert; all CA certs are intrinsically
multi-use, and are treated differently in the RPKI repository
system.) If the objects to be verified under a multi-use cert are
created and signed over time, the private key cannot be destroyed
until the last of these objects has been signed.
I can imagine two circumstances that may motivate employing a
multi-use EE cert vs. a set of single-use EE certs:
1. there may be a set of objects that "fate share" and thus
if any one needs to be revoked, all will be revoked. An example might
be a set of ROAs that are perceived to be linked in some fate sharing
fashion.
2. a series of object instances may be signed over time, and
there a perception that revocation of any instance of the object is
unlikely (prior to object expiration). The obvious example here is a
sequence of manifests, where each manifest is replaced on a daily
basis, as a consequence of daily CRL issuance.
By employing a multi-use cert in either of these cases, one avoids
the need to generate multiple, single-use certs (and associated key
pairs), a possible performance concern. However, generating a cert
is not an expensive process. Key pair generation is fairly quick
these days. Filling in the data structure for the cert is very
quick, as is DER encoding. Signing the message is also fast. So, I
don't think the overhead of cert generation ought to be a deciding
factor here, unless we are talking about 100 or more objects at a
time. (For manifest instances, this clearly is not a consideration,
since each manifest is generated and signed at a different time.)
The first case above does not seem to merit the special treatment
that the repository structure document calls out for multi-use EE
certs. I say this because ROAs live at a publication point controlled
by the CA (instance) that issued the EE cert in each ROA. Thus one
would not store ROAs differently whether a single or multi-use EE
cert were used to them.
The second case above also does not seem to merit the special
treatment that the repository structure document calls out for
multi-use EE certs. A manifest lives at a publication point for a set
of signed products associated with a CA instance, and the manifest
spec specifically prohibits the EE cert associated with it from
appearing as a discrete object in the repository. So, again, the
location for a manifest in the repository system would not change
based on whether a single or multi-use cert were employed with it.
So, it is not clear to me that we need to call out special treatment
for single vs. multi-use EE certs in the repository spec, based on
the kinds of signed objects that we have defined so far. If we agree
to eliminate this special treatment, the spec becomes simpler.
I am not opposed to describing single vs. multi-use EEC certs in the
cert profile. In that doc there is relatively little text devoted to
these two types of certs, and I don't see a problem with what is said
there.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
