On Thu, Oct 19, 2017 at 2:21 PM, Hugo Landau wrote:
> > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
> > > than a prefix, really that useful?
> > >
> >
> > It seems like something we're likely to need at some point, given that
> > there's still
> > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
> > than a prefix, really that useful?
> >
>
> It seems like something we're likely to need at some point, given that
> there's still some diversity in validation methods. But if you're
> uncomfortable, I think we can drop
Picking this up after a long gap...
On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau wrote:
> > > https://github.com/ietf-wg-acme/acme/pull/332
> Alright, if the ACME spec wants to genericise its validation methods
> registry, I'm okay with the validation-methods change as-is.
>
On Thu, Jul 6, 2017 at 6:16 AM, Martin Thomson
wrote:
> On 6 July 2017 at 20:07, Hugo Landau wrote:
> > Vendor-assigned identifiers could be supported as such:
> > vnd:example.com/custom-method
>
> RFC 6648 explains why vendor-prefixes can be a
> > https://github.com/ietf-wg-acme/acme/pull/332
Alright, if the ACME spec wants to genericise its validation methods
registry, I'm okay with the validation-methods change as-is.
Questions:
1. Should we drop "non-acme", since any non-ACME method can have its own
identifier listed? I think
> https://github.com/ietf-wg-acme/acme/pull/332
I like this. I proposed one minor wording clarification.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau wrote:
> >On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com>
> wrote:
> >
> > So let's see. Can we live with this?
> >
> > Create a spec-required registry for validation method names.
> >
> >I
>On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com> wrote:
>
> So let's see. Can we live with this?
>
> Create a spec-required registry for validation method names.
>
>I share Hugo's concern about divergence here. Should we maybe just put
>these in the
On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich wrote:
> So let's see. Can we live with this?
>
> Create a spec-required registry for validation method names.
>
I share Hugo's concern about divergence here. Should we maybe just put
these in the ACME challenge types registry? It
So let's see. Can we live with this?
Create a spec-required registry for validation method names.
Do not reference CABF docs.
Change the CA sample names from A B to X Y or foo bar or this that or whatever.
___
Acme mailing list
Acme@ietf.org
On 6 July 2017 at 20:07, Hugo Landau wrote:
> Vendor-assigned identifiers could be supported as such:
> vnd:example.com/custom-method
RFC 6648 explains why vendor-prefixes can be a bad idea. I think that
you should do as Yaron suggested and establish a registry. Set the
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
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
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
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
> 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
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
I do not see how the comments from Richard Barnes were handled.
Russ
> On Jun 30, 2017, at 10:30 AM, Salz, Rich wrote:
>
> Based on feedback here, Hugo just posted an updated draft,
> https://tools.ietf.org/html/draft-ietf-acme-caa-02
>
> I would like to advance this to
Based on feedback here, Hugo just posted an updated draft,
https://tools.ietf.org/html/draft-ietf-acme-caa-02
I would like to advance this to the IESG in a week. Please speak up if you
disagree.
Also, still looking for a document shepherd (see
On Tue, Jun 13, 2017 at 05:33:48PM +, Salz, Rich wrote:
> > The two last ones are editorial, but the first about enumerating all BR
> > methods isn't (since it needs new validation method identifiers).
>
> Thinking about it a bit more, I don't think it is appropriate for
> ACME to list CABF
> The two last ones are editorial, but the first about enumerating all BR
> methods isn't (since it needs new validation method identifiers).
Thinking about it a bit more, I don't think it is appropriate for ACME to list
CABF things. That's a strong view as an individual, and a moderate view as
> Couple of minor comments:
These seem like all strictly editorial to me. Anyone disagree?
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
___
Acme mailing list
Acme@ietf.org
>>Hugo's CAA draft (already adopted, short, might be
>> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01
This has moved to WGLC. If you know of any reason why it should not advance to
the IESG, please post by end of next week.
If you are willing to be the
23 matches
Mail list logo