On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker < rol...@letsencrypt.org> wrote:
> 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. > Who says that the origin server is even up at the time you are authorizing the management box. -Ekr > > > -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
