Having both new-application and new-authz seems simple enough from a server perspective, but I think it will create interoperability problems for clients. Specifically, most clients will choose to implement one flow or the other. Most likely the existing clients will choose to implement the new-authz flow because it will require minimal changes.
However, if I recall correctly, part of your reason for proposing the new-application flow was that it more closely matches the workflow of non-Let's Encrypt CAs, which tie actions to a certificate order or certificate request. From that, I assume that such CAs would not implement the new-authz flow. So we would have a large base of clients that would not interoperate with CAs other than Let's Encrypt, which defeats the purpose of having a standardized protocol. The other motivation for the new-application flow was to provide a framework that could support validation and issuance of wildcard names. However, the current spec doesn't actually go into detail about a validation method for wildcard names. 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
