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. -Ekr > Russ > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
