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

2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker <phill@hallambaker.com>:

> 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:cert-admin@example.com", ..]
>   }
>
> 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.
>

And hopefully there will never be such a restriction. The order shouldn't
matter in any JSON representation. It does already matter in key
authorization hashes. I think if it matters, no JSON should be used.

> 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:
>

The description is just a protection. The server accepting the request
should already know what to expect based on the URI and header values.

> {
>   "new-reg" : {
>     "contact": [ "mailto:cert-admin@example.com", ..]
>     }
>   }
>
> 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.
>

We don't have large payloads in ACME and having to care about order makes
ACME harder to implement.

> 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?
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>