On Wed, May 30, 2018 at 11:25 AM, Richard Barnes <r...@ipv.sx> wrote:
> > > 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. > Well, we have a fair bit of experience of a lot of people talking to Let's Encrypt. That's not really the same as a lot of servers and a lot of clients. 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 > I'm not sure what's confusing. The IETF has traditionally required MTI algorithms to ensure that there is a baseline that allows two implementations to talk to each other. We spent an enormous amount of time on this in RTCWEB, so it's not exactly ancient history. .. Just to try to make this concrete, if you were going to propose some > algorithms to be MTI / MTnotI, what would you list? > I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with X25519. -Ekr > --Richard >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
