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

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Feb 2016 13:12:39 -0500

Section 3.

ACME does not use Base64 encoding, it uses Base64url. This is the
correct choice but the document specifies this indirectly.

--- Definitions

Account Key Pair: A public key pair to authenticate certificate
management requests. An ACME server considers the holder of the
private key authorized to manage certificates for a given identifier.
A single key pair MAY be authorized for multiple identifiers.

--- Base64

" ACME messaging is based on HTTPS [RFC2818] and JSON [RFC7159]. Since
JSON is a text-based format, binary fields are Base64-encoded. For
Base64 encoding, we use the variant defined in [RFC7515]."

RFC7515 has:

 Base64url Encoding Base64 encoding using the URL- and filename-safe
character set defined in Section 5 of RFC 4648 [RFC4648], with all
trailing ’=’ characters omitted (as permitted by Section 3.2) and
without the inclusion of any line breaks, whitespace, or other
additional characters. Note that the base64url encoding of the empty
octet sequence is the empty string. (See Appendix C for notes on
implementing base64url encoding without padding.)

I suggest changing the text to

"ACME messaging is based on HTTPS [RFC2818] and JSON [RFC7159].

Binary fields are encoded using Base64url encoding described in
[RFC4648] Section 5, according to the profile specified in JSON Web
Signature  [RFC7515] Section 2. This encoding uses a URL safe
character set. Trailing '=' characters MUST be stripped."

[If it isn't a MUST strip then readers MUST accept padding so no point
talking about it.]

Section 3 is headed Terminology but actually contains normative
descriptive text. I suggest using 'Terminology and References' to make
this clear. I would also suggest that people are more used to finding
this as section 2.

It is a better way to organize though. I am changing some of my docs
to follow suit. Basically, put all the material that relates to
external dependencies in one place.

Suggest more use of subsections though, gather all the JWS stuff into
one place, all the JSON, etc.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Feb 2016 05:38:19 +1100

> correct choice but the document specifies this indirectly.

See https://github.com/ietf-wg-acme/acme/pull/80

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Feb 2016 14:55:46 -0500

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:[email-masked]", ..]
  }

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:[email-masked]", ..]
    }
  }

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?

---

From: Niklas Keller <[email-masked]>
Date: Wed, 3 Feb 2016 21:07:28 +0100

> could be a problem if you are dealing with abuse cases like very long

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.

> the object precedes the object. So I prefer to describe 'new-reg'

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

> for ACME message sizes but would be critical if you were sending a 1GB

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

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Feb 2016 15:48:54 -0500

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

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

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 4 Feb 2016 11:33:53 -0800

>     "contact": [ "mailto:[email-masked]", ..]
I strongly support this. In implementing Boulder for Let's Encrypt, we
ran into a similar problem with challenge types. Since challenges are
distinguished by a "type" field within the JSON itself, we wind up
representing all challenge types as a single super-type that encompasses
all their fields, and then switching on the string value of the type
field. I'd definitely prefer to be able to keep the different types
separate, which is possible in a system like the one you propose.