I went ahead and posted a PR implementing EKR's suggestion: https://github.com/ietf-wg-acme/acme/pull/429
On Wed, May 30, 2018 at 4:23 PM Daniel McCarney <c...@letsencrypt.org> wrote: > We have multiple CA’s that support it, and other implementations as well. > > > Of the multiple CAs that support ACME, which support something resembling > the current draft? When I looked last the non-Let's Encrypt ACME server > implementations all seemed to be targeting Certbot and the "ACMEv1" era of > this draft (e.g. are not using the order based issuance flow at all). There > have been substantial backwards compatibility breaking changes in the draft > since this time. > > I second EKR's sentiment that there has been little true ACME inter-op > testing of the protocol as described in draft-12 outside of that done with > Let's Encrypts ACMEv2 endpoint. > > - Daniel / cpu > > On Wed, May 30, 2018 at 3:56 PM, Salz, Rich < > rsalz=40akamai....@dmarc.ietf.org> wrote: > >> >> - 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. >> >> >> >> We have multiple CA’s that support it, and other implementations as >> well. Certainly LE dominates, but it’s not the only usage. And certainly >> not the only anticipated future usage. >> >> >> >> - I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA >> with X25519. >> >> >> >> That would make the MTI limited to a subset of the WebPKI supported by >> the latest browsers, which seems wrong. But let’s not bikeshed too much >> and see what the WG consensus is. >> >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
