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

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

On Wed, Feb 3, 2016 at 3:07 PM, Niklas Keller <[e-mail]> wrote:
> 2016-02-03 20:55 GMT+01:00 Phillip Hallam-Baker <[e-mail]>:

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

There cannot be a restriction on the order of tags inside a JSON
object and it still be JSON. That is XML Schema nonsense we have left
behind.


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

Assuming that we are going to be wedded to HTTP forever.

I don't think that is a very good plan. I am very much a HTTP
supporter, I worked on HTTP/1.0. But it is a protocol that is designed
to support Web Browsers, not Web Services.

As we get into Internet of Things we are going to want to register for
certificates on devices that have JSON serialization but not TCP/IP,
let alone HTTP.

There should be a clean separation between the application and the
transport/presentation layer.



>>
>> {
>>   "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.
>
>
> We don't have large payloads in ACME and having to care about order makes
> ACME harder to implement.

My point was that we don't have to worry about order if we do nesting
instead. ACME already has nested objects.

The structure I am proposing is:

{ <Request-Name>  :  { <Request-Data> } }

That will ensure that <Request-Name> is always emitted first as a
matter of course. It is also slightly shorter and avoids the need to
create a reserved name for the resource type.