OK, I gave the PR a closer read, and recognize that I misunderstood some stuff below. Let me try again :) It seems like this PR does basically two things:
1. Remove "requirements" as a level of abstraction 2. Convert from "identifier authorization" to "DNS name authorization" Can you explain to me why (2) is desirable? It seems like a pure reduction in extensibility. As for (1), I don't really think you're getting what you think you're getting. The functionality we need here is going to require two levels of abstraction: 1. The CA wants you to do something -- "requirement" vs. "authorization" 2. The CA wants you to do this specific thing -- "authorization" vs. "subtype-of-authorization" You just haven't gotten to the second level of abstraction in this PR because you haven't re-added OOB. I think when you do that (or any other function), you'll find that you're going to want separate subsections for "authorization authorizations" and "OOB authorizations", with different content, etc. The net effect of this is just to push the multiplexing out a layer -- you have to dereference the URL in the requirements array before you figure out what the specific task is (from the "type" in the authorization object), as opposed to being able to figure it out from a requirement object. --Richard On Wed, Oct 26, 2016 at 2:27 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote: > On 10/02/2016 07:46 AM, Richard Barnes wrote: > > I'm worried that we're losing a lot of useful, clear semantics here in > > order to save a few bytes. > This misunderstands the intent of this change. I'm not trying to save > bytes here, I'm trying to clarify the semantics by (a) having fewer > distinct types of objects, and (b) having a single, canonical place for > clients to check the status of things. > > The current approach of inlining the status field, or even inlining the > whole authorization as your propose, would reduce semantic clarity and > potentially introduce adding bugs, for the sake of saving a request. > > Here's another way of looking at it: The "requirements" notion has a lot > in common with authorizations, in particular the need to do an action, > poll for ready status, and ensure that each one present in a set is > satisfied. Why define an entirely separate type? Also: Why are they not > individually addressable, when authorizations are? If we make them > individually addressable, why not make them the same type of object? > This will make it easier for clients to implement them. > > > However, I'm not really sure that even that is worthwhile. Consider > > that authorizations can be re-usable for multiple applications; we > > envisage clients being able to authorize a bunch of domains, then > > issue certificates for arbitrary combinations. > I don't see how my proposal conflicts with authorization reuse. The > server chooses which authorizations to require for a new application. It > can choose to reuse those that are reusable (dns-name) and generate a > new one each time for those that are a per-issuance requirement (payments). > > > This PR also removes two important pieces of functionality: > > - The generic OOB requirement type - Would need to be replaced by new > > authorization types > This is a good point, I'll re-introduce an OOB authorization type to > satisfy this need. > > > - The ability of the protocol to cleanly support new identifier types; > > instead of just defining a new identifier type and some challenges, > > you need to copy / paste the whole definition of the dns-name challenge. > I'm not sure what this means. There's no "dns-name challenge." There are > a set of challenges that are valid for dns-name authorizations. If > somone defines a new identifier type, say email address, the set of > challenges that are valid for that identifier type will definitely be > different. This PR actually clarifies that situation. > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
