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

[Ted Hardie <[e-mail]>]

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?



> > 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?

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.
>