Subject: Re: [P2PSIP] RELOAD Base: Question on certificate renewal

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 05 Dec 2012 08:22:51 -0800

On 11/14/2012 02:44 PM, Dean Willis wrote:
> 
> On Nov 9, 2012, at 10:37 AM, Dean Willis wrote:
> 
>> AD asks:
>> 
>> How is node key rollover done? Do I loose all stored data? I think you
>> need to make all those clear.
>> 
>> 
>> 
>> So, what I think we're talking about is what happens to my data when my 
>> certificate expires.
>> 
>> Does my NodeID change?
>> 
>> Is there a way to re-cert my stored data?
>> 
>> What exactly is the process for refreshing the data I have stored?
>> 
>> -- Dean
>> 
> 
> 
> I met with Cullen and EKR today, and here's what I think we have:
> 
> If the NodeID cert expires, you lose all data stored with that NodeID. If
> we want to invent a "recertification" technique (Marc suggested that the CA
> can issue a new cert with the same NodeID) we can do that in a separate 
> document.
> 
> We will need to add a clarifying sentence to the draft.
> 

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.

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.

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

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Dean Willis <[email-masked]>
Date: Fri, 7 Dec 2012 21:52:16 -0600

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

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

> multiple devices from the same account) and for the server (no need to

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