On Tue 2015-07-28 12:55:33 -0400, Ted Hardie wrote:
> 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.
This seems like a reasonable approach to me.
> 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).
on CA Z's side, it could handle the first connection by immediately
creating a high-entropy secret for the validation, handing it over to
the part of the CA infrastructure that does "offline" validation, but
*not* revealing it to the client. If the offline validation process
completes successfully, it would divulge the high-entropy secret to the
client for the subsequent ACME connection.
On CA Z's side, there is really very little state to manage for the ACME
side of things -- only the creation of a single secret.
--dkg
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
