On Wed, Apr 26, 2017 at 2:50 PM, Richard Barnes <[email protected]> wrote: > > > On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick <[email protected]> > wrote: > >> 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? >> > > We just haven't gotten around to implementing it yet :) Here's a PR: > > https://github.com/ietf-wg-acme/acme/pull/298 >
Good to know. Thanks! > > >> 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? >> > > 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. > 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
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
