Subject: [Acme] "Slide 16" ("up" Link Relation) Follow Up from IETF 98

From: Logan Widick <[email-masked]>
Date: Wed, 26 Apr 2017 13:09:46 -0500

According to the draft minutes, as of the end of IETF 98, the plan was to
eliminate the "up" link relation from authorization to order since an
authorization can belong to multiple orders and nobody seemed to rely on
this relation. However, I still see this "up" relation on GitHub. Is the
plan still to remove that "up" relation, has the plan changed, or is the
plan to wait and see if anyone uses the relation first?

As for the "up" link relation from challenge to authorization (not
mentioned on slides), this could encounter a similar problem. As a simple
example to illustrate the potential problem, assume a server issues an
order with two authorizations: one authorization for (http-01 or dns-01),
and another authorization for (tls-sni-02 or dns-01). To prevent the client
having to complete the same challenge twice, assume that the server used
the same dns-01 challenge instance for both authorizations. For the common
dns-01 challenge, where does the "up" relation point to? This could become
a more significant issue as new identifiers, challenges, etc. are added in
the future. How should this be addressed?

Sincerely,

Logan Widick

---

From: Richard Barnes <[email-masked]>
Date: Wed, 26 Apr 2017 15:50:46 -0400

> plan to wait and see if anyone uses the relation first?

We just haven't gotten around to implementing it yet :)  Here's a PR:

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

> the future. How should this be addressed?

Why would a server do what you're saying?  It seems like the construct you
propose basically just takes the OR combinations of challenges in the
individual authz and ANDs them.  We had agreed a long time ago that a
single OR layer was sufficient for all known use cases.  And if you want to
create an AND, this is about the least elegant way you could create the
AND, vs. say a conjuction challenge type, or the "combinations" array we
had before.

Given that, I'm comfortable saying that each challenge belongs to exactly
one authz.

--Richard

>
> Sincerely,
>
> Logan Widick
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Logan Widick <[email-masked]>
Date: Wed, 26 Apr 2017 18:31:38 -0500

> https://github.com/ietf-wg-acme/acme/pull/298

Good to know. Thanks!

> Given that, I'm comfortable saying that each challenge belongs to exactly

I was thinking that there could be situations where a challenge belongs to
multiple authzs (which would complicate the "up" link). I thought of two
types of such situations:

   1. A server that follows something like the above scenario. This might
   not be that likely.
   2. A type of "thing" that people may want to put in a certificate in the
   future that may require multiple identifiers to represent. This would mean
   that a challenge could end up validating multiple identifiers. That would
   require multiple authzs for the same challenge, since an authz is for one
   identifier only.

For the second type of situation, I was going to reply with a scenario that
involved future demand for physical addresses in certificates. A physical
address is already required for some types of certificates (see section
9.2.7, "Subject Physical Address of Place of Business Field", in the EV
spec at https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf as an
example) and
I thought that a physical address would be example of one "thing" that
would require multiple identifiers to represent (street, city/town,
state/province, country, and postcode). However, I think one could get
around that with some type of special representation. Initial but likely
inelegant possibilities could include encoding the address components as
URL query parameters inside the value string (e.g.
"streetAddress=123%20Test%20Street&localityName=Testville&stateOrProvince=
AnyState&country=AnyCountry&postCode=123456"), or as a similar JSON object
inside the value string (e.g. '{"streetAddress": "123 Test Street",
"localityName": "Testville", "stateOrProvince": "AnyState", "country":
"AnyCountry", "postcode": "123456"}').

(I know that the guiding use case for ACME is DV not EV, but I was thinking
that there may be demand for ACME-based EV in the future.)

A physical address was the most complex example of a "thing" that I could
think of that someone may want to put in a certificate in the future, and
that I thought may require multiple identifiers to represent. However, as
mentioned above, there could even be a way to merge the parts of a physical
address into a single identifier. Thus, I am now convinced that each
"thing" that someone could ever want put in a certificate could be
represented as a single identifier. Therefore, I would be comfortable
saying that a challenge validates exactly one identifier. Combine this with
the low (or zero) odds of my initial scenario happening, and I am also now
comfortable saying a challenge belongs to exactly one authz.

Logan