> > 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
