if this is being done surely ToS status could be just another required-authorisation (whichever term becomes the new one)
eg if the account has previously agreed the tos-required-auth is still valid if the account has not agreed since new ToS (despite oob mail etc)(that CA requires updated agreement to) then it just gets a fail result on this required-auth (just as if balance was 0) plus the url to remedy (just as if payment was needed) (thus like payment most tos issues would be handled long before the renewal, but in the event the client has been ignoring the oob warnings from the CA the renewal fails with a simple comprehensible and easily fixed error) At 07:10 27/09/2016 Tuesday, Jacob Hoffman-Andrews wrote: >The previous definition of requirements created an awkward extra level >of indirection, with status defined both on requirements and >authorizations. It also created another object type, increasing the >complexity of the protocol. > >It was added mainly to provide a concept of an "out-of-band" requirement >that could be satisfied, for instance, by adding funds to an account. >However, this concept fits very well within the existing authorization >framework, if we tweak the definition of authorizations so that >authorizations are not always for domain names. Instead, we specify a >type field on the authorization object, which can be "DNSName" or any >other server-defined value. We can use the existing Out-of-Band >challenge type to convey a link for users to visit to, for instance, >provide payment. > >For "DNSName" authorizations, the same constraints still hold - there is >a defined DNS name, and the challenges apply to that specific name. > >Editorially, I wound up moving the section about verifying correct >Punycode encoding to new-application, since that is where the check >needs to happen. > >Pull request: https://github.com/ietf-wg-acme/acme/pull/195 > >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
