Hi Steve, all, On 10/13/10 4:59 PM, Stephen Kent wrote: > 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. >
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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
