Re-adding the list. I dropped it by accident. On 07/07/2016 01:50 PM, Richard Barnes wrote: > > > On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews <j...@eff.org > <mailto:j...@eff.org>> wrote: > > 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. > > > Oh yeah, totally fine having the status field. > > > 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. > > > Yeah, I was thinking something basically the same as authorizations: > - pending: You still need to fulfill some requirements > - invalid: This one is bad, you need to start over > - valid: You can use this to issue certs > - expired: You can't use this any more > > The only question I'm pondering is whether we need to separate "you > can't use this any more because you didn't complete the requirements > fast enough" from "... because you already issued all the certs you > were allowed to issue" (maybe with "closed" for the latter). I think > I'm fine conflating them for a first pass. I think there should be a one-to-one correspondence between these "preconditions" or "requirements" objects (still trying to come up with a good name) and certificates. I.e., you create one, and then you submit it, and it's used up. To create another certificate you have to submit a new request. There do wind up being some interesting interactions with rate limiting: Do you check and decrement the rate limit before creating the preconditions object, or when finalizing it? Nothing insurmountable, I think.
Regarding out of band: In this PR you have "out-of-band" as a type of object that can appear in a preconditions object, but we already have a challenge type "out-of-band." We should reconcile those. For instance, we could say that a preconditions object contains a list of authorizations. The "doneness" of each item in the list could then be expressed through each authorization's status field. Problem: For paid CA's, I think payment is a property of an order rather than a property of a domain name. One possible workaround would be for those CAs to define a new identifier type, e.g. "order number", and create authorizations for order numbers that have out-of-band payment URLs. Alternately, we could remove the oob-01 challenge in favor of implementing the out-of-band functionality at the preconditions level instead. Andrew, what are your thoughts?
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
