On Tue, May 29, 2018 at 4:02 PM Eric Rescorla <e...@rtfm.com> wrote: > > > On Mon, May 28, 2018 at 9:57 PM, Russ Housley <hous...@vigilsec.com> > wrote: > >> Eric: >> >> >> > > Do you want to specify a set of acceptable signature algorithms here? >>>> > >>>> > I am inclined not to. We have already forbidden "none" and MAC. We >>>> > shouldn't specify "MUST"s here, because CABF sets their own list of >>>> > required algorithms, and we don't want to conflict. I guess you >>>> > could specify some MUST NOTs pretty safely, but given that they're >>>> > already forbidden by CABF, it seems kind of duplicative. >>>> >>>> This is about the signatures that ACME accepts, not the signatures >>>> in certs. Does CABF have a position on what signature algorithms >>>> that ACME uses? >>>> >>> >>> Good point. As Ryan pointed out, this is not something on which there >>> is currently CABF guidance. >>> >>> Nonetheless, I'm still disinclined to have MUSTs here for other >>> reasons. If they're positive "MUST support" requirements, then we would >>> need to come back and revise this document in the event of an algorithm >>> break (though admittedly, that would be pretty far down on the TODO list). >>> And looking at the current list of JWS algorithms, I don't see any I would >>> MUST NOT, except possibly the ones based on SHA-1 >>> >> >> Hmm... Common practice in security protocols is to specify MTI >> algorithms. Why is this different? >> >> >> PKIX chose not to specify mandatory-to-implement algorithms. This was >> done because the application that made use of the certificate needed to be >> able to impose such requirements. >> >> Here is one place from the PKIX WG archive in 2011 that states this >> approach: >> >> ( >> https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs) >> >> PKIX defines PKI specs for a very wide range of apps, which is why we >> do not mandate any alg suite. Different apps may use different alg >> suites. >> TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself. >> >> It seems to me that ACME is being used to support certificate enrollment >> for many different applications, so the same approach seems appropriate. >> > > Hmm... This seems like it would be more persuasive if there weren't a > dependency on TLS and its MTI algorithms > > From my perspective, this is sort of on the bubble. Historically, I've > seen the IESG insist on MTI algorithms, but it's not consistent. I would > like to understand if this is something that has strong consensus in the > WG, in which case I'll support that (though other IESG members may feel > differently) or if it just happened, in which case I'd ask the WG to > reconsider. >
I think it's more in the latter category in the former, but TBH, I think that kind of argues in favor of the status quo -- we have a fair bit of implementation / deployment experience, and this has not been an interop problem. In a similar vein, where we have had discussion of versioning (a similar issue) there's been consensus *not* to go the traditional route of having version numbers -- you just have to know what version of ACME the endpoint you're talking to speaks. It doesn't seem totally crazy to me for the same to be true of the signing algorithms you use. I guess I don't really know what value you're solving for here. Just to try to make this concrete, if you were going to propose some algorithms to be MTI / MTnotI, what would you list? --Richard
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
