Subject: [Acme] Combine "requirements" and "authorizations."

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 26 Sep 2016 23:10:49 -0700

The previous definition of requirements created an awkward extra level
of indirection, with status defined both on requirements and
authorizations. It also created another object type, increasing the
complexity of the protocol.

It was added mainly to provide a concept of an "out-of-band" requirement
that could be satisfied, for instance, by adding funds to an account.
However, this concept fits very well within the existing authorization
framework, if we tweak the definition of authorizations so that
authorizations are not always for domain names. Instead, we specify a
type field on the authorization object, which can be "DNSName" or any
other server-defined value. We can use the existing Out-of-Band
challenge type to convey a link for users to visit to, for instance,
provide payment.

For "DNSName" authorizations, the same constraints still hold - there is
a defined DNS name, and the challenges apply to that specific name.

Editorially, I wound up moving the section about verifying correct
Punycode encoding to new-application, since that is where the check
needs to happen.

Pull request: https://github.com/ietf-wg-acme/acme/pull/195

---

From: Hugo Landau <[email-masked]>
Date: Tue, 27 Sep 2016 08:26:13 +0100

> a defined DNS name, and the challenges apply to that specific name.
This looks good. Only a slight nitpick — the label "DNSName" seems
out-of-kilter with the naming convention used by the rest of the
standard. "dns-name" or "dnsName" would be more appropriate?

We should also consider allowing people to use URIs, or some sort of
vendor-prefixed types for authorizations and challenges, to avoid
collisions. e.g. "http://example.ca/account-funding-01" or
"vnd.exampleca.account-funding-01" or "ca.example.account-funding-01".

---

From: Alan Doherty <[email-masked]>
Date: Tue, 27 Sep 2016 08:57:06 +0100

if this is being done

surely ToS  status  could be just another required-authorisation (whichever term becomes the new one)

eg if the account has previously agreed the tos-required-auth is still valid
if the account has not agreed since new ToS (despite oob mail etc)(that CA requires updated agreement to) 
then it just gets a fail result on this required-auth
(just as if balance was 0)

plus the url to remedy (just as if payment was needed)

(thus like payment most tos issues would be handled long before the renewal, but in the event the client has been ignoring the oob warnings from the CA the renewal fails with a simple comprehensible and easily fixed error) 

At 07:10 27/09/2016  Tuesday, Jacob Hoffman-Andrews wrote:
>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 29 Sep 2016 13:32:24 -0700

> standard. "dns-name" or "dnsName" would be more appropriate?

Good feedback, thanks. I've pushed a change.

> "vnd.exampleca.account-funding-01" or "ca.example.account-funding-01".

This also makes sense. I think URIs make more sense, rather than
defining a new namespace. And the URIs can contain more information
about the type. What do other folks think?

> surely ToS  status  could be just another required-authorisation
(whichever term becomes the new one)

Actually an earlier version of the protocol suggested this, but it makes
much more sense to think of ToS agreement as an account-level action
rather than a request-level action.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Sep 2016 13:40:00 -0700

> about the type. What do other folks think?
I'm a little confused about the proposal, especially how the URI would
contain more information about the type.   Would you mind fleshing this out
a bit?

thanks,

Ted

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 29 Sep 2016 13:50:54 -0700

On 09/29/2016 01:40 PM, Ted Hardie wrote:
> On Thu, Sep 29, 2016 at 1:32 PM, Jacob Hoffman-Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > collisions. e.g. "http://example.ca/account-funding-01
>     <http://example.ca/account-funding-01>" or
> contain more information about the type.   Would you mind fleshing
> this out a bit?
Something like this:

Servers that create authorization objects with a non-standard type
should provide a URL as the type string. This allows non-standard types
to be created in a well-defined namespace, to avoid conflicts. Visiting
the URL in a web browser should result in a human-readable web page
describing the non-standard authorization type.

However, I'm very open to other suggestions!

---

From: Ted Hardie <[email-masked]>
Date: Thu, 29 Sep 2016 14:28:20 -0700

On Thu, Sep 29, 2016 at 1:50 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> Servers that create authorization objects with a non-standard type should
> provide a URL as the type string. This allows non-standard types to be
> created in a well-defined namespace, to avoid conflicts. Visiting the URL
> in a web browser should result in a human-readable web page describing the
> non-standard authorization type.
>

Well, I guess I have two thoughts here.  The first is that if we do want to
shift to URIs, then we should move DNSname to also being a URI (a URN at
IANA or an IANA registry entry).  If the client recognizes it, then it
doesn't need to dereference the page, as the content is guaranteed to be
the same (especially so in the case of URNs), but it is getting the same
sort of identifier for standard and nonstandard types.

But I'm not sure that this is the right direction, as I worry that we might
lose interoperability over time.  For out-of-band authorizations, I think
we could use a single common type and an additional field for dereferencing
the out-of-band steps.  But for new general mechanisms, it would be useful
if the client knew from examination whether it could or should use the
authorization type.  If service A and service B use different URIs for the
same mechanism, you have the possibility of a client not recognizing that
it can use service B.

Imagine for a second that someone creates a method to use an entry in a
block chain as an authorization mechanism; if more than one service wants
to use the method the 2nd and later either have to refer to the type using
the first's URI or making up new URIs that aren't automatically recognized
by clients built in response to the first.

I agree with the need to collision, but I'm not sure that we have likely
collisions unless we try to differentiate each out-of-band set of steps
into types.  That doesn't seem that useful to me, personally.

Just an initial reaction,

Ted