Hi Rich, On Mon, Jul 27, 2015 at 1:06 PM, Salz, Rich <[email protected]> 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 > /r$ > > > > -- > > Senior Architect, Akamai Technologies > > IM: [email protected] Twitter: RichSalz > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
