On Dec 5, 2012, at 10:22 AM, Marc Petit-Huguenin <[email protected]> wrote:
> > My suggestion was not about "recertification" - I think that the current > mechanism, which is to resend the data signed with the new certificate is OK > for now. What I was talking about is the unfinished discussion from > Vancouver, on how to renew a certificate so the Node-ID(s) previously > allocated do not change when the certificate is renewed. > Well, that's what I was calling "recertification"; new vert, same Node-ID. One could call it "certificate replacement", I suppose. > The spec currently uses a server side mechanism to "remember" the Node-IDs > (which can be storage based or, as EKR suggested in Vancouver, hash based). > The problem I see with this is the requirement that there is only one > certificate per account, which can make things difficult for example if a user > has multiple devices (with a device possibly hosting multiple nodes) but only > one account. The user can request a multiple Node-ID certificate, but has to > find a way to know which Node-ID(s) goes into which devices. Maybe we should expand this discussion with some use cases. When would a user need multiple devices? I personally only have a half-dozen or so smartphone/tablet devices, three laptops, and a couple of server boxes. Are those different users or different devices with one user? Jabber has some disambiguation; each user-device binding gets a sub-name in the space of the username. > My proposal was to use the previous certificate instead of the CSR when > requesting a renewal. Because requesting a certificate with a CSR would > return a different set of Node-IDs each time, a single account can be used on > multiple devices. IMO that makes things easier for the client (can manage > multiple devices from the same account) and for the server (no need to > "remember" anything). Logically, that seems ok to me as long as the previous cert hasn't yet expired or been revoked. So it seems feasible to get a new cert for the same node-IDs preemptively, but if you're offline and your cert expires, you have to re-store everything with the new cert. That seems like an acceptable limitation. An active peer node keeps its data from churning, and a disconnected node churns more. Of course, a "disconnected but connectable" client node could wake up, re-cert, and then go back to sleep periodically without churning. But I'm not sure how to run OpenSSL's CA in such as way as to get a new cert based on an old cert, without an intermediate CSR. How does that work? -- Dean _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
