On Wed, Jul 5, 2017 at 5:48 PM, Yaron Sheffer wrote:
> The problem with saying "Tokens registered as ACME challenge types MUST
> NOT be used to identify non-ACME validation methods" is that ACME might
> want to come up with additional method names in the future, and those just
> might happen to c
On 06/30/2017 09:54 AM, Dunning, John wrote:
> Based on your description below, I think door A makes more sense to
> me. My paraphrase of it is that key authorizations get bound at
> creation time, and thus get “grandfathered” in after a credential
> rotation.
This is a good paraphrase. What do ot
The problem with saying "Tokens registered as ACME challenge types MUST
NOT be used to identify non-ACME validation methods" is that ACME might
want to come up with additional method names in the future, and those
just might happen to conflict with methods that have been used by other
organizat
Just for context here: I think the original operating model for CAA was
that the CA would tell the customer what values to put in there in order to
authorize issuance. So it was safe to use arbitrary values because it was
basically a closed loop CA -> Customer -> CAA -> CA.
Nonetheless, I sympath
I support moving forward with the document.
However I think the treatment of the acme-methods (or
validation-methods) param is inconsistent, before and certainly after
Richard's PR. The original draft only allows ACME methods and the
special name "non-acme". This leaves the responsibility to e
https://github.com/ietf-wg-acme/acme-caa/pull/2
On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich wrote:
> > There's no listing going on here, since there's no registry for the
> values. CABF could put tokens in their documents if they like.
>
> Okay, please propose wording (or did you? Sorry if so)
> There's no listing going on here, since there's no registry for the values.
> CABF could put tokens in their documents if they like.
Okay, please propose wording (or did you? Sorry if so) to change for the CAA
draft.
___
Acme mailing list
Acme@iet
There's no listing going on here, since there's no registry for the
values. CABF could put tokens in their documents if they like.
On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich wrote:
> > The two last ones are editorial, but the first about enumerating all BR
> > methods isn't (since it needs new