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. 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".
> 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)."
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
