Subject: [Acme] Account deactivation

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 12 May 2016 09:19:50 -0700

Proposed change: instead of deletion of accounts and authorizations,
specify deactivation. This simplifies both the spec and the
implementation, and leaves data retention choices up to CA policy.

https://github.com/ietf-wg-acme/acme/pull/125

---

From: Ron <[email-masked]>
Date: Fri, 13 May 2016 03:57:11 +0930

> https://github.com/ietf-wg-acme/acme/pull/125

RE:

 "It is up to server policy how long to retain data related to that
 account, whether to revoke certificates issued by that account, and
 whether to send email to that account's contacts."

Should that still say something about the server revoking authz?
Since there is no way to revoke that once the account key is revoked
(unless we do the auto-revoke thing when authz is obtained for another
account key).

If we're going to say "the result of this depends on server policy"
we do need a way for clients to query the resulting state in an
automated way and resynchronise their state with the server again.
Users shouldn't have to hand-hack local config and state based on
an out of band declaration of server policy.

Instead of leaving it up to the server to decide whether to revoke
certs, what if we make that an option of the client request?
i.e., something like:

 - status "deactivated", disables the account but does not revoke
   currently issued certs.

 - status "revoked", disables the account *and* revokes certs
   (and probably everything else associated with the account too).

We already determined there wasn't a good One Size Fits All answer
to whether to revoke certs by default in that case or not, but the
user is the one who will be unhappy if we pick the wrong one for
them, and saying "the CA will decide that for you" doesn't solve
that like letting them tell it exactly what they need would.

In the example given of "Clients may wish to do this when the account
key is compromised.", they may have no other way to get the certs
revoked, since they may not possess the certificate key for everything
issued after the account key was compromised.

But this way we'd also have the softer "deactivated" option to disable
an existing key after a planned roll-over event, without immediately
revoking the current certs.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 12 May 2016 11:41:46 -0700

> Should that still say something about the server revoking authz? Since
there is no way to revoke that once the account key is revoked (unless
we do the auto-revoke thing when authz is obtained for another account key).

I think from the previous discussion, the best way to do this is by
auto-deactivating authzs once they are superseded. I'm not including
that in this change because I wanted to keep it small and do that as a
follow-on.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 23 May 2016 15:21:10 -0700

Any objections to this? I'd like to get it merged so we can go ahead
with implementation.

On 05/12/2016 09:19 AM, Jacob Hoffman-Andrews wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Jason - <[email-masked]>
Date: Tue, 24 May 2016 01:46:20 +0300

Hi, Jacob.
I strongly object to that proposed change, if my objection matters at all.
Let me explain a bit more: Shall a CA receive a valid and trustworthy request for deletion of an account/authorization, the CA must totally erase any trace of data regarding that account, except perhaps the certificates issued. Or else there are privacy issues to be taken into account for each and every CA and thankfully EU has relevant laws of the right-to-be-forgotten, which I think applies in this case. So, because CAs are global, I believe that they should take into account the best interests of the users, which in this case is exactly this right: the right-to-be-forgotten. Finally, I don't think that US laws should apply to the whole world and, since EU has accounted for the aforementioned right, that should absolutely be taken into consideration.
To summarize, I disagree with the proposed change in the exact part of "leaves data retention choices up to CA policy". CAs follow the best interests of the users, don't they? Also, possible privacy laws allow for that possibility to the user. Therefore, if a user requests (and the request is deemed trustworthy and valid) complete deletion of their account/authorization, the CA shall not be free to keep the data.
Best regards,Jason Milionis

> To: [email-masked]
> From: [email-masked]
> Date: Mon, 23 May 2016 15:21:10 -0700
> Subject: Re: [Acme] Account deactivation
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 May 2016 23:07:16 +0000

> Let me explain a bit more: Shall a CA receive a valid and trustworthy request for deletion of an account/authorization, the CA must totally erase any trace of data regarding that account

Speaking as a WG chair, I disagree.  EU data retention, like US Calea laws, are outside the scope of the protocol.

> CAs follow the best interests of the users, don't they?

As commercial vendors, their shareholders should come first.

Speaking as an individual, I support the MR.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 23 May 2016 16:17:21 -0700

Hi Jason,

I replied on the GitHub issue as well, along the same lines as Rich: the
protocol should not attempt to specify policy.

To add a little more detail: I'm definitely a big advocate of "real"
account deletion, where all records are actually purged after a certain
amount of time. At past jobs, I've worked hard to make sure that
happens. However, the balance of privacy versus public value is very
different in the case of certificate issuance. The data in a certificate
is not private - it's intended to be trusted by the public. That's why
Let's Encrypt logs all certificates to CT.

Other data, such as authorizations, are part of records proving that a
certificate authority did its due diligence before issuing a
certificate. Not only would it be inappropriate to purge these at user
request, it would not, in general, be practical - many certificate
authorities back up issuance records to long-term offline storage.

Thanks,
Jacob

---

From: Philipp Junghannß <[email-masked]>
Date: Tue, 24 May 2016 03:22:14 +0200

I dont even exactly know whether the right to be forgotten works with data
that isnt even public.

my personal opinion on this is that if no certs get revoked that all
account data stays unil the certs expire. this right was mostly executed on
google and their results are public. but your ACME Account data (e.g. your
IP Addresses, domains etc) are all private because nobody can just say
"what domains does User X have" or whatever.
also if there are any laws regarding data retention or anything else
regarding liability and stuff it wouldnt be wise to delete data regarding
that.

also as Rich Salz already said, ACME cant deal with any weird geographic
law. I have no Idea what a "Calea" is, but the laws regarding that "Calea"
thing are probably also something ACME cannot really account for.

that's my opinion.

Regards.

2016-05-24 1:07 GMT+02:00 Salz, Rich <[email-masked]>:

> > Let me explain a bit more: Shall a CA receive a valid and trustworthy
> request for deletion of an account/authorization, the CA must totally erase
> any trace of data regarding that account
>
> Speaking as a WG chair, I disagree.  EU data retention, like US Calea
> laws, are outside the scope of the protocol.
>

---

From: Jason - <[email-masked]>
Date: Tue, 24 May 2016 16:39:42 +0300

My webmail client made a mistake and sent this message just to you. Thank you for telling me. If you hadn't told me, I wouldn't notice that my message wasn't sent to the whole Acme IETF group. So, without further hesitation I am copying the contents of my second message here:

---Start of Message---

Since you speak as a WG chair, I clearly cannot anything, which is why I said in my email "if my opinion matters at all".

 Also, note that the EU right-to-be-forgotten partially contravenes US CALEA laws. Therefore, it's not clear which of those two shall apply.

 However, maybe it is out of scope. In my point of view, deleting data, except certificates and relevant authorizations, which, as Jacob said, may need to be retained for a longer period of time, protects the user's privacy.

 Finally, what I meant (wrong phrasing in my original response) is that the CA ecosystem as a whole follows the best interests of the user and the CAs are required to comply with laws, which in this case isn't that clear. But this is another discussion, of course.

---End of Message---

And now my comments: Since it is out of scope, and possibly it is, I recommend that the wording isn't completely changed to "deactivation" but instead to "deactivation and/or deletion". That would allow for more possibilities to be taken into consideration.

Best wishes,
Jason

From: [email-masked]
To: [email-masked]
Subject: RE: [Acme] Account deactivation
Date: Tue, 24 May 2016 12:47:59 +0000

Did you mean to send this just to me?
 
You can say anything.  If you think a WG chair is wrong, you can talk to the other chair, and you can talk to the Area Director.
 
I think, pretty clearly, that local law enforcement and embedding it in the protocol, is out of scope of the WG as is data retention.  But please feel free
 to disagree publically!!!

-- 

Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

From: Jason - [mailto:[email-masked]]

Sent: Monday, May 23, 2016 8:32 PM

To: Salz, Rich

Subject: RE: [Acme] Account deactivation

Since you speak as a WG chair, I clearly cannot anything, which is why I said in my email "if my opinion matters at all".

Also, note that the EU right-to-be-forgotten partially contravenes US CALEA laws. Therefore, it's not clear which of those two shall apply.

However, maybe it is out of scope. In my point of view, deleting data, except certificates and relevant authorizations, which, as Jacob said, may need to be retained for a longer period of time, protects the user's privacy.

Finally, what I meant (wrong phrasing in my original response) is that the CA ecosystem as a whole follows the best interests of the user and the CAs are required to comply with laws, which in this case isn't that clear. But this is another discussion, of course.

Best regards,

Jason

> From: [email-masked]

> To: [email-masked]; 
[email-masked]; [email-masked]

> Subject: RE: [Acme] Account deactivation

> Date: Mon, 23 May 2016 23:07:16 +0000

---

From: [email-masked]
Date: Tue, 24 May 2016 12:25:38 -0400

Hi,

Yes, while your implementation may have to adhere to particular laws or regulations, we make a point to not enforce any of them in protocol designs.  We may put in controls or features that allow you to decide if you'd like to adhere to policies such as data retention requirements, but they would be a choice.

Best regards,
Kathleen 

Sent from my iPhone

> On May 24, 2016, at 9:39 AM, Jason - <[email-masked]> wrote:
> 
> I think, pretty clearly, that local law enforcement and embedding it in the protocol, is out of scope of the WG as is data retention.  But please feel free to disagree publically!!!
> 
>  
> 
> -- 
> 
> > To: [email-masked]; [email-masked]; [email-masked]