On Thu, Jul 7, 2016 at 5:10 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote:
> 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> > 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. > Oh, please no hacks like that. I think it's clear that we need some OOB thing at the "application" / "requirements" level, precisely in order to avoid hacks like this. If we're going to remove one of these, we should remove the OOB challenge type. But I don't really think it's tragic to have both; they serve slightly different purposes. --Richard > 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
