I want at first to say sorry that my last email wasn't sent to new thread.
Now for the suggestions, i will start with the reason behind them it
might be easier to convoy the idea, i believe that this draft is one of
the most important protocol drafts in this year, with all those consumer
routers coming out of the box with support for dynamic domains and lot
of them comes with configured subdomains and they are all have HTTP
servers, so in not far future they will use this protocol to switch to
HTTPS, there is also countless server apps for mobile devices (and even
smart TV's) that utilize HTTP to share media over the internet and they
will use this protocol, in short i see this protocol to be very widely
used and specially in devices that is hard to reprogram or change
behavior, those devices will utilize some specific implementation (open
or closed source library), on other hand most libraries and
implementations will follow best practice to let the user to accept
terms of service, while most the developed software based on those
libraries will ignore that completely and accept blindly.
Now my suggestion is to add side info channel for both server and
client, it is optional but if this draft suggest that this info is
optional and it should be parsed and logged if there is log system, then
every software will follow that and log that text which can save time
and lead to better usage for both server and client."meta" object is
described in 9.7.6 and it is only for directory, i suggest to make this
meta object possible (optional) for every response with dedicated field
lets say "message" (or "critical" or... doesn't really matter ) , and
client is encouraged parse this "message" and keep (log it), it might
contain important information about the service itself ,examples for
such message:
"message" : "we updating infrastructure, we have scheduled maintenance
between 2018-10-08 3:00 and 2018-10-08 50:00 ; 2018-11-01 8:00 and
2018-11-01 11:00 (UTC timing) ; service be might appear offline in those
periods"
"message" : "this is beta service and will be discontinued on 1st of
December 2019, please consider switching to xxxxx "
"critical" : "RSA keys with 2048bits will not be allowed after june 2020"
"advice" : "(somelib here form user-agent) is known for security issues
or wrong handling the certificate chain please consider use our
(someotherlibrary) "
"server" : "our servers is under DDoS attack and we limiting
certificates issuance to 1 certificate per account per hour until Monday"
"serverMessage" : "our Terms of Service will be updated on 18th October
2019, to read more about the new termsOfService and its changes please
visit (url) "
Most usage of this protocol will have success and failure report/log,
but will not record or parse such info that service deemed important and
might enhance the quality of the service for both parties, BUT if it
mentioned with such examples in this draft it will go mainstream, in
case of failure there is big chance you already know the reason in the
current log or past log, and end user might be able to fix the failure
on his own based on that message (like changing keys, replacing
directory URL, or just wait few hours ....) without even contacting the
service provider or consulting with the wise Google.
Now for client side i suggest new optional URL in the directory (like
"feedBack") where client can send some info message or petition or just
(thank you!) to server, it is optional for the server to parse and log
this or ignore it while i think the URL itself if you deemed useful
should not be, the service might be asking for feedback for statistical
data or just the sake of receiving thank you, and it could be something
like the following example ( here the request is already signed but it
might be not, it is optional ) :
POST /acme/feedBack HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1";,
"nonce": "ntuJWWSic4WVNSqeUmshgg",
"url": "https://example.com/acme/feedBack";
}),
"payload": base64url({
"message": "Please consider supporting ES512, and thank you !"
}),
"signature": "earzVLd3m5M4xJzR...bVTqn7R08AKOVf3Y"
}
About naming it can be one identifier in meta or a new message object or
two identifier in some object, i trust there is more qualified persons
here to decide how and what it should be, and you know what is better .
Best regards,
K. Obaideen
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
