Subject: [Acme] Quick feedback on two PRs

From: Richard Barnes <[email-masked]>
Date: Sun, 20 Mar 2016 22:14:19 -0400

Hey all,

I've published a two PRs that I think should be non-controversial, but
they're significant enough that I wanted to run them by the group.  I would
appreciate it if you could take a look and give a quick thumbs up / thumbs
down in Github (at the indicated URIs).  If you have any substantive
comments, please reply in this thread.

#101 Remove proof-of-possession challenge
https://github.com/ietf-wg-acme/acme/pull/101

#102 Replace in-band account recovery with `meta`
https://github.com/ietf-wg-acme/acme/pull/102

I'm happy to hold any of these if they need more discussion, but if there's
no disagreement before the I-D deadline at midnight UTC, I'll go ahead and
merge them before I post -02.

Thanks,
--Richard

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 21 Mar 2016 09:49:55 +0100

as the situation is now I am against removing the PoP becase it is really
helpful when the automation cannot do its thing (there are so many reasons
why you cant really automate everything. but when there will be some other
changes to the challenges which would make it a bit more humanly possible
to create a SAN certificate with more than just 2 domains.

regards

2016-03-21 3:14 GMT+01:00 Richard Barnes <[email-masked]>:

> I'm happy to hold any of these if they need more discussion, but if
> there's no disagreement before the I-D deadline at midnight UTC, I'll go
> ahead and merge them before I post -02.
>
> Thanks,
> --Richard
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: "J.C. Jones" <[email-masked]>
Date: Mon, 21 Mar 2016 11:42:22 -0700

Richard,

I have reviewed both PRs on Github; I've only minor comments on the PoP
challenge removal; r+ (assuming consensus).

One observation that I do have regarding the 'account-mgmt' link is that
the placement of this URI in the directory means that it is only useful for
recovery scenarios as it is not customizable; In non-recovery scenarios, it
could be a useful thing after a signed request, to instead give back a URI
that contains a one-time value that would help tie a browser session to a
given account key. I don't see a good endpoint for such a thing at present,
so the hour is probably too late for such a change.

My $0.02,

- J.C.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 21 Mar 2016 11:47:25 -0700

> https://github.com/ietf-wg-acme/acme/pull/101
This looks fine. As an implementer, I think we may want to implement
some proof-of-possession concept in the future, but I think this
mechanism is not quite right. And we should take it out till we're more
confident in what we want to do.

> https://github.com/ietf-wg-acme/acme/pull/102
This is pretty ambiguous. In the spirit of the above, I would leave this
unspecified until we have a clearer idea of what we want out of this.

As a process point: I'm guessing there is some meta list where deadlines
for I-Ds are posted, but I'm not on it. Would you mind cross-posting a
reminder about such deadlines to the ACME list a couple weeks in
advance, so we have more time to consider and work on changes like these?

Thanks,
Jacob

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Mar 2016 14:52:21 -0400

> advance, so we have more time to consider and work on changes like these?

The deadline is related to the IETF meeting; they impose a few weeks'
black-out on document updates before the meeting to try to give people a
baseline (and because in certain corners of the IETF, it's still the 1970s):

http://ietf.org/meeting/important-dates-2016.html

Note that this doesn't need to stop work in Github.  It only affects the
"official" versions that get submitted to the IETF.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Mar 2016 16:52:34 -0400

OK, thanks all.  On balance, feedback here seems OK, so I'm going to go
ahead and merge.  We can look at adding back some sort of PoP / recovery,
but I agree with Jacob that these are better un-spec'ed for the moment.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 21 Mar 2016 14:17:34 -0700

> unspecified until we have a clearer idea of what we want out of this.
To clarify my feedback: I am find with removing the in-band recovery
until it's needed, when we'll have a clearer idea of requirements. But I
think adding the new 'meta' field may not be the right direction either,
so we should leave that bit out.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Mar 2016 18:16:13 -0400

> so we should leave that bit out.

Thanks for the clarification, Jacob.  I have made the change to remove
in-band recovery without adding an alternative mechanism.

https://github.com/ietf-wg-acme/acme/pull/108

--Richard