Richard Barnes <[email protected]> schrieb am Mi., 27. Apr. 2016 20:51:
> 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.
>
> 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.
>
We might need something similar for multiple issuers but the same CA. This
is required for having both, RSA and ECC intermediates.
Regards, Niklas
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
>
> On Wed, Apr 27, 2016 at 11:48 AM, Salz, Rich <[email protected]> wrote:
>
>> Is there any other feedback from what Phil proposed? (Start here
>> http://www.ietf.org/mail-archive/web/acme/current/msg01035.html even
>> though we’re still waiting for his promised PR, which he reasonably says he
>> wants to know if the WG is interested in his moving forward)
>>
>>
>>
>> As an individual, I kinda like the JSON changes.
>>
>>
>>
>> /r$
>>
>>
>>
>> --
>>
>> Senior Architect, Akamai Technologies
>>
>> IM: [email protected] Twitter: RichSalz
>>
>>
>>
>> _______________________________________________
>> Acme mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
