If anyone objects to this, and there is ensuing discussion on the WG mail list, we’ll work to resolve it. Otherwise, “silence implies agreement” and we’ll declare consensus next Tuesday.
Thanks. -- Senior Architect, Akamai Technologies IM: [email protected] Twitter: RichSalz From: Richard Barnes [mailto:[email protected]] Sent: Thursday, September 08, 2016 1:07 PM To: Eric Rescorla Cc: IETF ACME; Roland Bracewell Shoemaker Subject: Re: [Acme] Pre-authorization approach 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]<mailto:[email protected]>> wrote: On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker <[email protected]<mailto:[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]> > <mailto:[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]>> > > <mailto:[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]> > <mailto:[email protected]<mailto:[email protected]>> > > > https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=> > > <https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>> > > > > _______________________________________________ > Acme mailing list > [email protected]<mailto:[email protected]> > <mailto:[email protected]<mailto:[email protected]>> > > https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=> > > <https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>> > > _______________________________________________ Acme mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
