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

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jul 2015 20:06:14 +0000

Suppose we add a new challenge "offline/xxxx" where /xxxx is an IANA registry (first-come first-served).  The ACME client then stops doing online protocol, communicates with its human who does the appropriate credential validation with the CA. Ultimately (hours, days, weeks, months later), the protocol continues and the "offline" challenge gets its response which is a base64 string.

For the current CA's, what manual process could not be served by this type of challenge?

                /r$

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Ted Hardie <[email-masked]>
Date: Mon, 27 Jul 2015 14:00:09 -0700

Hi Rich,

On Mon, Jul 27, 2015 at 1:06 PM, Salz, Rich <[email-masked]> wrote:

>  Suppose we add a new challenge “offline/xxxx” where /xxxx is an IANA
> registry (first-come first-served).
>

​I don't think I understand the IANA registry bit here.  Is the idea that
FooCA registers something like FooCA-send-us-this-by-registered-mail, and
when the challenge is received by a client it looks at the IANA registry
for something it can parse into human interaction?  How is that better than
a single "offline" challenge where the URL to check for the steps is in the
response?

The ACME client then stops doing online protocol, communicates with its
> human who does the appropriate credential validation with the CA.
> Ultimately (hours, days, weeks, months later), the protocol continues and
> the “offline” challenge gets its response which is a base64 string.
>
>
>

​This seems fairly low on the priority list, honestly, but if we are going
to do it, I think we need to have some thought to what happens at some of
the larger time scales.  If months pass, the contact information may go
stale, to take a simple example.

 For the current CA’s, what manual process could not be served by this type
> of challenge?

​Do CA's asked for one type (e.g. EV) ever offer a lower type (like DV)?
That seems like a valid business response, but very hard to fit into an
automated protocol flow.

regards,

Ted

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jul 2015 21:11:04 +0000

> I don't think I understand the IANA registry bit here.  Is the idea that FooCA registers something like FooCA-send-us-this-by-registered-mail, and when the challenge is received by a client it looks at the IANA registry for something it can parse into human interaction?  How is that better than a single "offline" challenge where the URL to check for the steps is in the response?

It lets a single "generic" client say "I don't understand the OmniPublish offline protocol"  Or lets CA vendors ship plugin libraries for a generic ACME client (such as distributed by LetsEncrypt org).  And yes, maybe it's not needed if the URL is something the human points their browser to.

> This seems fairly low on the priority list, honestly, but if we are going to do it, I think we need to have some thought to what happens at some of the larger time scales.  If months pass, the contact information may go stale, to take a simple example.

I think it's higher than that *if and only if* the commercial CA's find it something they could use.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Jul 2015 18:28:42 -0400

> It lets a single "generic" client say "I don't understand the OmniPublish offline protocol"  Or lets CA vendors ship plugin libraries for a generic ACME client (such as distributed by LetsEncrypt o…

I think you're over-thinking this.  All we need here is a single
escape valve -- "I'm not going to validate this within ACME".  Then
it's up to the CA to make sure that whatever web interface they refer
to explains different options.  Syntactically, I would suggest
something like:

Challenge: { "type": "out-of-band", "href":
"http://example.com/how-to-validate" }
Response: { "type": "out-of-band" }

> I think it's higher than that *if and only if* the commercial CA's find it something they could use.

I'm not an expert in EV, but I have a pretty hard time thinking of
ways to do EV without something like this.  It's also a nice escape
valve to let CAs move things over to ACME incrementally, or to
innovate with new stuff before clients support it.

It seems like something like this would probably be sensible to add if
there are CAs that might use it.

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Jul 2015 22:52:11 +0000

> I think you're over-thinking this.  All we need here is a single escape valve --

WFM.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Jul 2015 19:51:11 -0400

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.

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.

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.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Jul 2015 21:45:06 -0400

On Mon, Jul 27, 2015 at 7:51 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
> 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 :)

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

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Jul 2015 04:53:40 +0200

On Tue, Jul 28, 2015 at 3:45 AM, Richard Barnes <[email-masked]> wrote:

> going

Thats fine, I just wanted to make sure that this hadn't been erased during
the discussion.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 28 Jul 2015 09:55:33 -0700

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

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

> the

---

From: Richard Barnes <[email-masked]>
Date: Tue, 28 Jul 2015 16:02:41 -0400

On Tue, Jul 28, 2015 at 12:55 PM, Ted Hardie <[email-masked]> wrote:
> 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

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.

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

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 28 Jul 2015 16:14:37 -0400

> cert, and CA Z provides a proof-of-possesion based challenge.

This seems like a reasonable approach to me.

> 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

---

From: "Reimer Karlsen-Masur, DFN-CERT" <[email-masked]>
Date: Thu, 30 Jul 2015 11:04:31 +0200

Salz, Rich wrote on 27.07.2015 22:06:
> registry (first-come first-served).  The ACME client then stops doing online
> protocol, communicates with its human who does the appropriate credential
> validation with the CA. Ultimately (hours, days, weeks, months later), the
> protocol continues and the “offline” challenge gets its response which is a
> base64 string.
> 
>  
> 

In my "Sending documents or arbitrary files via ACME from server to client?"
post to this list I had at least a partly manual process in mind where the
CA provides some documents to the ACME client's human that needed to be
returned to the CA. So I had looked for a method to transport PDFs within
the ACME protocol to the client.

>From what I understand now, ACME's agreement URI could be used to tell the
ACME client's human to download a PDF that waits at that URI.

I don't want to send the documents via email to the associated email address
because I see there is room for spoofed/faked mails with faked documents.

So to answer your question: The agreement URI could be used to get
(challenge) docs, invoices or applications forms to the client when an
offline challenge is indicated but it does not seem the right fit. I do like
the possibility to take validation/authorisation off-line because it would
make it easier to use ACME clients with our current work-flows. On the other
hand since the PDF form (challenge) is delivered on-line, the response could
be off-line, e.g. a signed form sent to the CA. In this scenario the ACME
client would not need to continuously poll for the issued certificate, just
a few times per day to check if the CA received and accepted the response
and issued the certificate.

Reimer