Subject: [sidr] single-use and multi-use EE certs

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Oct 2010 10:59:04 -0400

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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Oct 2010 17:59:25 +0200

Hi Steve, all,

On 10/13/10 4:59 PM, Stephen Kent wrote:
> 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.
> 

Actually...

<disclaimer>
This ship may have sailed a long time ago. I was not involved in the
early stages of this. So I am not aware of the arguments that may have
been raised in the past to come up with multi-use EEs in the first place..
</disclaimer>

but, bottom-line: I think it would be simplest if the drop multi-use EEs
were dropped altogether.

As you mention the overhead for single use is not that big.

> <snip>
> 
> 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.
> 

I think it's better to implement the knowledge about fate sharing
elsewhere, and then just revoke em all as needed. Ideas about which
objects should be fate sharing may change over time and with multi-use
changes can not be made after object creation: one cannot de-fate-share
an existing object.

>     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.
> 

Okay, but I would actually still prefer single use here: it allows me to
throw away the key. In any case I think simplification of the standards
(and CA software, and validators) outweighs the overhead of using single
use EEs here.

But as I said in the disclaimer, I may be overlooking other good reasons
for the multi-use here...

Regards

Tim

---

From: Arturo Servin <[email-masked]>
Date: Wed, 13 Oct 2010 21:12:39 -0200

> but, bottom-line: I think it would be simplest if the drop multi-use EEs

	As a new comer to RPKI I do not have strong arguments about this but I was thinking the same than Tim while I was reading Steve post.

	Also I share the same concerns than Tim of overlooking something obvious that was discussed a while ago.

> for the multi-use here...

Best wishes,
-als

---

From: Arturo Servin <[email-masked]>
Date: Wed, 13 Oct 2010 21:12:39 -0200

Best wishes,
-als