On 09/27/2016 12:17 AM, Hugo Landau wrote: > But right now you can use Let's Encrypt without providing any means of > out-of-band communication, so it's not safe to assume that such a > mechanism — e. mail or otherwise — will be available.
This is exactly why we chose to write our Subscriber agreement such that we can update without explicit opt-in. > You mention RSS, but that requires a web interface to have some way of > tying assent to a registration, which would require users to do special > and unusual things with their registration private key to prove they > hold it. RSS is an extreme edge case of an edge case. We're imagining a CA that require explicit assent to changes in the ToS, and additionally does not require an email address for its customers, but *does* offer an RSS feed for notifications about updates to their ToS. Even in such an edge case of an edge case, they could create an individualized RSS URL for each customer. On 09/27/2016 10:00 AM, Jeremy Rowley wrote: >> a) Click a link in the email, read the new ToS, and click "Agree" at the bottom. >> b) Click a link in the email, read the new ToS, and copy and paste the new ToS URL into the customer's ACME client config. > Why not allow both? We'd use (a) over (b), but if email isn't required, then > (b) is certainly an acceptable method of confirming ToS acceptance. Because no one will use (b), and it adds unnecessary complexity and fragility to the protocol. To further emphasize my point that "it will never be used," here are some other examples of CA ToS: ------------------------- https://www.symantec.com/content/en/us/about/media/repository/ssl-subscriber-agreement.pdf Company may revise the terms of this Agreement at any time for the following reasons: (i) it becomes necessary due to applicable laws or industry standards, including, without limitation, any change of the foregoing; (ii) it becomes necessary for technological reasons when any changes is made without materially degrading the Service functionality; (iii) it becomes necessary to maintain the operation of the Service when any change is made without materially degrading the Service functionality; or (iv) changes are in favor of the Subscriber. Any such change will be binding and effective thirty (30) days after publication of the change on Symantec’s website, or upon notification to Subscriber by email. ------------------------- https://www.digicert.com/docs/agreements/DigiCert_SA.pdf DigiCert may amend any of its (i) website and any documents listed thereon, (ii) CPS, (iii) fees, (iv) privacy policy, or (iv) the conditions under which you receive a Certificate. Amendments are effective upon the earlier of DigiCert’s posting the amendment on its website or your receipt of the amendment. ------------------------- https://www.comodo.com/repository/docs/ssl_certificate_subscriber_agreement.pdf Comodo may amend this agreement, the CPS, the Relying Party Agreement, the Relying Party Warranty, its website, and any documents listed in its Repository at any time by posting either the amendment or the amended document in the Repository. Subscriber shall periodically review the Repository to be aware of any changes. Subscriber may terminate the agreement if Subscriber does not agree to the amendment. Subscriber’s continued use of the Services after an amendment is posted constitutes Subscriber’s acceptance of the amendment. ------------------------- It should be clear from these examples that effectively the entire CA industry, like the entire Web industry, and indeed corporations in general, rely on auto-updating terms of service. As I said in my initial post on this topic, I think that's not a great. But pretending it's not so, or trying to litigate that broad policy problem in a spec for automating certificate issuance is both ineffective and worsens the protocol. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
