On Wed, 21 May 2025 at 15:59, Alicja Kario <hkario= 40redhat....@dmarc.ietf.org> wrote:
> On Tuesday, 20 May 2025 21:08:51 CEST, Viktor Dukhovni wrote: > > On Tue, May 20, 2025 at 07:31:23PM +0200, Alicja Kario wrote: > > > >> I would like to point out that we need the same kind of > >> codepoints no matter > >> if we want to use SLH-DSA in the end entity certificates or in CA > >> certificates. > > > > This assumes that one bothers signalling support for certificate > > signature algorithms separately from TLS signature algorithms. AFAIK, > > that's rarely done in practice. If SLH-DSA is not enabled for signing > > the certiificate verify message, I don't expect to see it supported in > > CA certificates either, at least in the near term. > > you're talking about implementation details, I'm talking about operational > requirements > > yes, it may mean the "unfortunate" reality that we need to have > speficication > for use of it in CertificateVeriy when the "primary" use case is for certs, > but as it was already discussed on the list, there are groups that are > willing > to pay the performance penalty even for CertificateVerify, so separating > those definitions isn't really solving anything > The draft discusses trade-offs in detail and the SLH-DSA suitability for CA certs, see https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-01.html#section-2. The overhead of sending intermediate certificates can be avoided by using techniques like ietf-tls-cert-abridge or draft-kampanakis-tls-scas-latest. -Tiru > -- > Regards, > Alicja Kario > Principal Quality Engineer, RHEL Crypto team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
