On Wed, May 30, 2018 at 5:41 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Hi Russ, > > On 30/05/18 22:31, Russ Housley wrote: > > It seems to me that ACME is being used to support certificate > > enrollment for many different applications, so the same approach > > seems appropriate. > I agree with your description of the past:-) > > I don't agree with not specifying MTI algs though. > > My main reasons are that I think having MTI algorithms for > acme may lead to better interop and less proliferation of > algorithms/suites and less broken/non-tested code. (I > forget what I thought about this years ago, but I may have > changed opinion - it was reasonable for PKIX to not specify > MTI algs a decade or two ago, but that that is no longer a > good plan, as we now do really use all this stuff.) > > That said, I don't feel too strongly about it - in practice > I reckon all acme clients will in any case want to implement > and be able to use whatever works with LE, at least for the > next while, and so this won't be a practical problem either > way. > I am also not that sanguine about this topic, but I lean in the opposite direction. The list of JWS algorithms [1] is not that long, and not growing quickly. And there's no Ed25519. So if we were to pick one or more MTIs out of this list, we would basically be locking in to ECDSA or RSA-PSS. As far as MTnotI: The SHA-1-based algorithms are already marked "Prohibited". I guess you could ban RSA with PKCS#1v1.5, but that seems fairly low-value. Basically, it seems like the burden of those who want MUSTs here to make a proposal for what the MUSTs would be. --Richard [1] https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
