On Wed, Aug 6, 2025 at 9:04 AM Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> wrote:
> > - If they do it on public facing HTTPs servers, accessed by a wide > variety of clients (not just browsers that don't enable support for those > algorithms) they should expect disappoitment > > > Will they? Or won’t it be like RSA/ECDSA server certs? > It depends what the cert chains look like. Specifically, if the ML-DSA cert chains back to some existing traditional trust anchor, then you can safely offer the certificate to any client that offers ML-DSA (assuming you could safely offer a traditional cert to the same trust anchor). If the chain is ML-DSA only, then you have to worry about whether the client in question supports the new ML-DSA trust anchor. In the interest of clarity, I would note that the main reason to offer ML-DSA certificate on a publicly accessible server at this point is to get some experience with ML-DSA deployment. As long as the client supports traditional algorithms, there's no security benefit even if the attacker has a CRQC because they will just attack the traditional chain (whether or not the ML-DSA certificate chains to an ML-DSA root) [0]. There's nothing wrong with getting experience, but it's important to know what you're getting. -Ekr [0] See https://educatedguesswork.org/posts/pq-emergency/#signature-algorithms for more on this.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
