Re: [Acme] Comments on draft-ietf-acme-acme-01

[Phillip Hallam-Baker <[e-mail]>]

I think Terminology and Dependencies should also have a mention of
HTTP / HTTPS, also RFC3339 (time format).

What I would like to get to eventually is some external document
describing a particular style of JOSE /JSON / HTTP / TLS Web service
that can simply be referenced by a Web Service spec. This means:

* We don't keep having to write out the same thing
* We don't have slightly different versions in different specs
* This can be handled by code synthesizers and support libraries.

I did a pass on this for the Mesh:

https://tools.ietf.org/html/draft-hallambaker-json-web-service-01

So far it looks pretty similar to ACME except that I am introducing a
new JOSE serialization format as I am looking at supporting future
apps that can't tolerate the Base64url encoding of the payload (which
will likely be in GB).


In section 5, actual examples of the messages would be nice.

5.1 There is a mention of cross origin but no explanation of what is involved.

This is worrying, what use is being made of HTTP state mechanisms in
ACME? Why is cross origin relevant? So far I have not read anything
that gives a rationale.

I would prefer to decouple ACME from HTTP as far as possible. HTTP is
far to complex to be analyzed at this point. Reinventing the wheel is
precisely what to do when someone is offering you jet propelled roller
skates.

5.2

I start to get lost at this point. The "resource" values look to me
like protocol transaction requests.

I think it is important to be clear on this because at some point we
are going to want to add in request types that are expressly command
like. Commands like "Hello".

The reason I would like to have consistency across JSON/HTTP type
services is that we are going to hit a requirement for 'service
management' type functions at some point. Things like negotiating
protocol version, features, declaring end of service, transfer to
another, scheduled outages, that sort of thing.

That is a module that I would hope we could define once and then
incorporate by reference in many Web Services.


The syntax of the request is currently:

{
  "resource": "new-reg",
  "contact": [ "mailto:[e-mail]", ..]
  }

Now that has all the information we want but there is no guarantee
"resource" is going to be emitted first in the serialization. That
could be a problem if you are dealing with abuse cases like very long
messages.

As a structural matter, I prefer to guarantee that the description of
the object precedes the object. So I prefer to describe 'new-reg'
object like so:

{
  "new-reg" : {
    "contact": [ "mailto:[e-mail]", ..]
    }
  }

Again, this is something that doesn't make a huge deal of difference
for ACME message sizes but would be critical if you were sending a 1GB
email.

Where it does give a lot of leverage however is when you are using a
protocol synthesizer like ProtoGen. The parser knows what type of
object it is parsing when it starts on that object. That allows for a
more efficient process than having to first scan for the 'resource'
tag and then construct the object to emit.


5.6: We are going to do CFRG curves, right?