(Resending mail where the list got dropped, to make the flow of conversation clearer):
On 07/07/2016 11:16 AM, Richard Barnes wrote: > That wasn't my intent. Rather, I wanted the CA to be able to say, > e.g., "you have to provide a contact". Does that much seem useful? Ah, now I get it. But why would that be part of the cert request flow? It seems like a CA that has a "contact required" policy should enforce that policy when the account is created. Similarly, the "terms required" is already enforced at the per-request level: Let's Encrypt won't allow any authenticated requests until the terms are agreed to. > That's up to the out-of-band system. I feel pretty strongly that we > need this out-of-band thing, and we need it to be flexible. Agreed we need some system for out-of-band requests, but I think we need to flesh out a flow for a hypothetical out-of-band request in more detail. In particular, we need to close the loop. The outbound direction is obvious - load this URL in a browser, expect something human readable with further instructions. However, we need the inbound direction as well. How does the client know when a human has completed the out-of-band instructions satisfactorily? That's why I added the status field in my example. Unrelatedly: I think these request objects probably need a status field and an expiry, like authorizations, and the ability for server or client to deactivate them. For instance, status could be: in-progress, completed, deactivated. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
