Subject: [Acme] Suggestion for optional side channel information

From: Kas <[email-masked]>
Date: Fri, 5 Oct 2018 14:40:21 +0300

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