On Fri, Oct 28, 2016 at 6:01 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> On 10/28/2016 01:57 PM, Richard Barnes wrote:
> > 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"
>
> Yep, good summary.
>
> > Can you explain to me why (2) is desirable? It seems like a pure
> > reduction in extensibility.
> Same reason as (1), to remove a level abstraction. If we do just (1), we
> would have authorizations with two type fields:
>
> {
> "type": "identifier",
> "identifier": { "type": "dns", "value": "example.com"},
> ...
> }
>
> This is a bit awkward, but more to the point, it doesn't increase
> expressivity. A DNS identifier authorization doesn't have anything in
> common with a hypothetical telephone number authorization, except (a)
> they both have a status, and (b) they both have a list of challenges.
This is where you lose me. You're underestimating the degree of
commonality here. Yes, you're going to do different challenges per
identifier type (SMS vs. HTTP, say), but the overall flow at the *ACME*
level is the same:
1. Get the list of challenges offered by the server
2. Choose one and prepare to respond to it
3. POST a response to the challenge
That means you can build clients and servers that can be dynamically
configured with challenge/validation types, and use all the same ACME
code. For example:
https://github.com/bifurcation/rocket-skates/#architecture
I don't think it's worth losing this flexibility just to go from
"type+value" to "value".
> It
> turns out those properties are also shared in common with an "oob"
> authorization. So we can flatten that abstraction neatly. We could have
> authorizations with types: "dns-name", "telephone-number",
> "email-address", and "oob".
>
Like I said, you would have to reinvent or copy/paste the whole
challenge/response machinery for each new identifier type.
Also: OOB has no challenges. Not sure what you're referring to there.
It's totally different from the authz flow.
>
> > 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"
> Can you explain this more? I don't think I understand the distinction
> you're getting at, or why it needs a separate type of object.
>
> The main thing that you want a separate "requirement" type for is OOB
> actions. That means both "the CA wants you to do something" AND "the CA
> wants you do do this specific thing (click on the link and follow the
> instructions)."
>
I think the crux of our disagreement is actually above. You seem to be
arguing that authz for different identifier types are as different from one
another as OOB is from DNS-name. I'm saying that the identifier validation
process is going to be the same for many different identifiers, so the
"authorization" abstraction is meaningful.
--Richard
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
