On Wed, Apr 27, 2016 at 02:51:36PM -0400, Richard Barnes wrote:
> Taking a look back at Phil's email, and his slides from B-A [1], I see a
> few things worth keeping, a couple of questions, and one thing we should
> drop.
>
> KEEP: Clearer description of what's signed. No-brainer. Filed
> https://github.com/ietf-wg-acme/acme/issues/121
>
> KEEP: Full resource URL within the signed object. I agree that it's useful
> to be more independent of HTTP in this way. And of course, we already need
> this to address the issues Karthik raised. I think this falls under
> https://github.com/ietf-wg-acme/acme/issues/112
>
> QUESTION: Should we suggest that an ACME server MAY ignore the HTTP request
> URL, and instead use the URL provided in the JWS? That could be a little
> more robust than comparison, but I'm wary of becoming *that* independent of
> the HTTP layer.
I'm inclined to think this should go the other way, in that what is in
the JWS is a magic octet string (and may not be a URL at all) which
doesn't need to (be) compare(d) to the request URL at all.
It just needs to confirm to the recipient that this JWS was intended
for it by the sender, regardless of how it got sent there.
ie. I don't think the ACME server should ignore either of those pieces
of information, but they don't necessarily need to be comparable to
each other.
> QUESTION: Should ACME support multiple CAs per ACME endpoint? Right now,
> there's an implicit assumption that each ACME server represents a single
> CA. If we were to open this up, we'll have to consider how we do it. For
> example, you could have multiple new-cert URIs for different issuers, but
> then you would probably want them to share policy state (i.e., have a
> common view of authorizations). It seems like there's a complexity tarpit
> here, so I'm inclined to skip it and go with the current single-CA model
> unless people have concrete use cases.
I think we've got enough to still bolt down for the single-CA model to
not want to add that sort of complexity to the initial protocol.
It would be possible for an ACME provider to do something like that
out of band anyway (ie. it could just document that authz is shared
between services it provides), and clients are already supporting
multiple ACME servers (for testing on the LE staging server and
issuing live certificates).
There might be some other nice things which that could enable, but I'd
want to see something compelling about how the current protocol limits
something people really want/need to do.
> DROP: More nesting in JSON objects, i.e., moving from { "type": "FOO"... }
> to { "FOO": { ... } }. The additional nesting doesn't add anything, and it
> would map poorly to a bunch of existing JSON bindings (e.g.,
> challenge.token vs. challenge["http-01"].token). There's not reason to
> distinguish "type" in this way -- why not use "token"? Of the many JSON
> APIs I've looked at, none of them follow this pattern.
>
> --Richard
>
> [1] https://www.ietf.org/proceedings/95/slides/slides-95-acme-1.pdf
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
