On 08/26/2016 12:25 PM, Eric Rescorla wrote: > > > On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker > <rol...@letsencrypt.org <mailto:rol...@letsencrypt.org>> wrote: > > On 08/06/2016 10:49 AM, Eric Rescorla wrote: > > > > > > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews <j...@eff.org > <mailto:j...@eff.org> > > <mailto:j...@eff.org <mailto:j...@eff.org>>> wrote: > > > > > > I also think EKR's comment that we need the ability to authorize > domain > > names without immediately issuing is a solid one*. So I think we > should > > take the conservative approach and roll back the new-application > flow > > for now. I do think we should document wildcard validation before we > > finalize the spec, but new-application may not be the best way to do > > that. > > > > *Eric, would you mind repeating what you said for the benefit of the > > list? All we have right now are the notes and Richard's paraphrase. > > > > > > To the best of my memory, my comment was that I thought it was > unfortunate > > that in order to register a domain you would have to generate a valid > CSR > > and potentially actually get it issued. This is especially true if the > > key you > > plan to use for authorization is of a type you never intend to issue > into an > > EE (e.g., you are authorizing with Ed255159 but you are planning to > > issue ECDSA and RSA). And it may not be possible to make these align > > if you have various restrictions due to HSMs. > > Sorry to jump into this so late but could you elaborate on the use case > your are suggesting here? I am slightly confused about in what > circumstances you would want to authorize a domain for issuance, but not > actually issue for it. > > In a situation where you i.e. don't know all of the names you want to > issue for in the future why not just wait until you do know all of those > names to create the authorizations? The same goes for the HSM situation > you describe, the key will be needed to sign the CSR at some point > anyway so why do the authorizations need to be created before the key is > used? > > > The pattern here is you would have a management box that was responsible for > the domain authorization process and for signing off on CSRs for other > devices > but was not itself intended to act as a Web server for the domain (this > is more > plausible with non-SimpleHTTPS authentication). In that case, you might > pre-authorize all the domains but then on-the-fly have the actual origin > servers > make their own CSRs and get them signed off on by the management box. In > this case, you wouldn't ever need an account key to sign the CSR. >
I'm still unsure why this is not currently possible with the new-app flow? Assuming in your example the management box passes back a certificate after receiving a CSR from a origin server the only difference I can see is there may be increased latency as the management box has to complete authorizations instead of instantly getting a certificate back from the ACME server. > -Ekr > > > > > > -Ekr > > > > > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org <mailto:Acme@ietf.org> > > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org <mailto:Acme@ietf.org> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
