Not seeing any blockers on this from the subsequent discussion. Chairs, what say you?
On Fri, Aug 26, 2016 at 5:17 PM, Eric Rescorla <[email protected]> wrote: > > > On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker < > [email protected]> wrote: > >> On 08/26/2016 12:25 PM, Eric Rescorla wrote: >> > >> > >> > On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker >> > <[email protected] <mailto:[email protected]>> wrote: >> > >> > On 08/06/2016 10:49 AM, Eric Rescorla wrote: >> > > >> > > >> > > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews < >> [email protected] <mailto:[email protected]> >> > > <mailto:[email protected] <mailto:[email protected]>>> 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 >> > > [email protected] <mailto:[email protected]> >> > > https://www.ietf.org/mailman/listinfo/acme >> > <https://www.ietf.org/mailman/listinfo/acme> >> > > >> > >> > _______________________________________________ >> > Acme mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/acme >> > <https://www.ietf.org/mailman/listinfo/acme> >> > >> > >> > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
