Re: [Acme] Supporting off-line (manual) validation

[Richard Barnes <[e-mail]>]

On Tue, Jul 28, 2015 at 12:55 PM, Ted Hardie <[e-mail]> wrote:
> On Mon, Jul 27, 2015 at 6:45 PM, Richard Barnes <[e-mail]> wrote:
>>
>> On Mon, Jul 27, 2015 at 7:51 PM, Phillip Hallam-Baker
>> <[e-mail]> wrote:
>> > As a general rule, any protocol that contains a component that may be
>> > subject to variation in the field needs an IANA registry. Since we are
>> > going
>> > to have multiple automatic validation processes we will be required to
>> > have
>> > a registry even if there is only one entry at first.
>>
>> ACME has always been structured with a registry in mind; the IANA
>> considerations just haven't been written up :)
>>
>
> So, I think Rich's initial suggestion of FCFS was derived from the notion
> that there would be many proprietary validation mechanisms and that a
> registry should be low friction.  If we are going to use a single mechanism
> and a parameter ("offline", URL), then I think the bar should go up a bit
> and I think it will be between Standards Action and Expert Review.
>
> Any initial thoughts there?

This is getting a bit off-topic for this thread, assuming you're
talking about the overall registry of challenges.

But in any case, I would set the minimum bar at Specification
Required, maybe Expert Review with an eye toward deduplication.  I
don't think there's a need for a ton of review for things to go into
the registry, since you're going to have organizations like CABF and
the CAs themselves making secondary decisions about which mechanisms
they think are suitable.


>> > For the offline part, I don't think that the border between automatic
>> > and
>> > offline is quite as clear as some folk seem to think. Some validation
>> > mechanisms are intrinsically offline we have a proposal for a completely
>> > automatic one but virtually all the processes in use today are a mix of
>> > the
>> > two.
>> >
>> > Even EV issue can be automated if you have an already validate
>> > credential
>> > and a DV issue can return 'pending' for a host of reasons. And even if
>> > you
>> > are doing EV you have to pass domain validation as well.
>>
>> I think what's being proposed is a generic "offline" thing for cases
>> where the validation method you want to use hasn't been defined and
>> registered, or doesn't have broad client support.  So the idea
>> wouldn't be to draw a clear distinction between online and offline
>> validation, but rather to provide an escape valve for cases where the
>> CA and the client can't agree on a fully automated way to do things.
>>
> I think we still need a failure case here, though, for situations where the
> validation mechanism can't be supported.  (There likely will be deployments
> where encountering "offline" causes the client to conclude that the
> validation mechanism can't be used no matter what is at the URL, because
> there is no human to check it.)  More troubline is that with the ("offline",
> URL) version the protocol state machine gets stopped part way, and
> distinguishing between "long process" and "abandoned" is difficult.  It
> might be useful to actually recast these so that encountering one results in
> "failure" for the ACME protocol's first run, but results in success with a
> second run using the results of the offline validation.
>
> That would result in something like this: client A goes to CA Z and asks for
> a cert. CA Z  provides an offline challenge, and Client A soft fails while
> it takes the challenge.  When client A completes the offline process, CA Z
> provides a token using the offline method to be used in proof-of-possession.
> Client A can then recontacts CA Z and asks for the cert, and CA Z provides a
> proof-of-possesion based challenge.
>
> That does require some state on CA Z's side to note client A has completed
> the offline challenge and so can use proof-of-possession, but the failure
> case doesn't seem to bad (as you can fail to get a cert, but still can't get
> one you're not entitled to).
>
> Does that logic track for others?

I think the requirement you've identified here is for the client to
have a way to terminate an authorization.  That might happen because
the client gets the challenges and realizes it can't fulfill any of
them (e.g., because "offline" is all it supports, and it has no
human), or it might happen in a situation like you describe above,
where the first transaction gets cancelled in favor of the second.

It's not immediately obvious how to encode this syntactically, but it
seems like it shouldn't be too hard.

--Richard


>
> Ted
>
>
>
>>
>> --Richard
>>
>> > So I don't think this is a taxonomy thing. It is a 'label the process so
>> > the
>> > automatic bits can be identified' thing and a 'this may not work
>> > automatically' thing. So no to offline/xxxx but yes to a registry of
>> > validation schemes.
>
>