On Mon, Mar 9, 2015 at 11:39 AM, Stephen Farrell <[email protected]> wrote:
> > Hiya, > > On 09/03/15 15:27, Salz, Rich wrote: > > Our main goal is not to handle all certificate enrollment use-cases, > > but rather focus on "I want to secure my website." We expect that > > there will be things we can do to the base I-D to make it more > > amenable to future expansion to handle NFV/SDN down the line. Or > > that those communities could an enhanced protocol as a starting > > point. > > > > But enumerating some of the requirements seems to make sense in the > > "additional requirements" agenda item. > > Right. > > Accumulating use-cases is a fine thing to do. But, and it's a BIG > but, those additional use cases are only of interest if they don't > deflect or distract from meeting the primary goals of this work. > (Which the BoF and list determine of course.) > > The IETF has messed up certificate management sufficiently often > that as an AD, (and as a past participant in messing this up;-), > I'll not be sponsoring work that I think is overly broad or that > lacks a laser-like focus on getting one or a few things done and > done well enough to see useful deployment. I don't think that is going to be a problem in this case. The concern for the requirements in my view is that we don't end up painting ourselves into a corner with some assumption in the base spec. For example, don't assume that the CA can give an immediate yes/no response without any human interaction ever. Even with a DV cert there is a requirement to check for certain look-alike names. Don't assume that the key will be generated in a particular way or at a particular location either. Until we move away from RSA, I do not want my cloud based web servers generating their own private key pairs on a machine the attacker could rent space on. I don't want the servers having one year certs either... So long as the protocol is in JSON and we don't have statements of the form X MUST <do something that assumes something that isn't necessarily the case>. I think we are OK. We didn't just mess it up in IETF either...
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
