[lamps] Questions and Comments on draft-ietf-lamps-certificate-discovery

[suzanne wibada <[e-mail]>]

Hello,

I have been reading the certificate discovery draft and would like to share
a few comments and questions.

*1. Simultaneous use of multiple certificates/keys*

The abstract mentions support for multi-key/certificate usage, but the
current use cases seem to focus primarily on scenarios where one
certificate acts as an alternative or backup to another.

It may be interesting to introduce a Hybrid Certificate use case, where
multiple certificates are used simultaneously to authenticate the same
session.

For example, during a post-quantum migration, both a classical certificate
and a PQC certificate could contribute to the authentication of a
connection. In a TLS context, this could potentially be achieved by
introducing a second CertificateVerify message carrying an additional
signature generated using the secondary certificate. In this model, both
certificates would actively participate in establishing trust rather than
serving merely as alternatives to one another.

*2. Use Case 1: Algorithm Agility*

I think the draft could further elaborate on the operational benefits of
algorithm agility.

A server may possess multiple certificates representing the same identity,
each based on different cryptographic algorithms (RSA, ECDSA, ML-DSA,
SLH-DSA, etc.). This approach not only provides flexibility during
algorithm migrations but also serves as an effective risk mitigation
mechanism.

For example:

   - If a vulnerability is discovered in a particular algorithm, the
   corresponding certificate can be disabled.
   - The service can continue operating using one of the remaining
   available certificates.
   - This is particularly relevant for post-quantum migrations, where the
   cryptographic maturity of new algorithms continues to evolve and additional
   weaknesses may be discovered over time.

I also had a few ideas regarding certificate and algorithm agility:

   1. One possible approach would be to treat the Primary Certificate more
   as a certificate discovery object than as the certificate that must always
   be validated first. The client could discover multiple candidate
   certificates and select the one that best matches its capabilities.
   2. Another approach would be to leverage a mechanism similar to TLS
   cipher suite negotiation:


   - The client advertises the certificate algorithms it supports in the
   ClientHello.
   - The server maintains multiple certificates for the same identity.
   - The server selects the most appropriate certificate based on the
   client's capabilities and local policy.
   - The selected certificate is sent directly during the handshake.

This approach would allow the server to select the most appropriate
certificate from the outset, rather than relying on a fallback mechanism
after certificate validation failures. It could also simplify algorithm
migration scenarios while reducing the overhead associated with validating
multiple certificates sequentially.

I really don't know if this idea can work with other protocols, but I based
it on TLS, because it's the one I know best.

*3. Use Case 2: Operational Redundancy*

I also have a few questions regarding the expected behavior of the
Operational Redundancy use case.

My understanding is that the Secondary Certificate is only used after
validation of the Primary Certificate has failed. This raises several
questions:

   1. Suppose the Primary Certificate has expired.


   - How should clients handle this situation? Should they continue
   attempting to use the Primary Certificate until a renewed version becomes
   available, or should they permanently switch to the Secondary Certificate?
   - After the initial validation failure and a successful switch to the
   Secondary Certificate, what behavior is expected for subsequent
   connections? Should the client remember that the Primary Certificate has
   already failed and immediately use the Secondary Certificate, or should it
   repeat the entire process for every connection?
   - The behavior may differ from the case where only a CA certificate has
   expired, since the end-entity certificate remains valid and may become
   usable again once the CA issue has been resolved.


   2. Revocation handling could also benefit from additional clarification.
   For example:


   - What happens when the Primary Certificate is revoked?
   - Should the client automatically switch to the Secondary Certificate?
   - What happens when it is the CA that is revoked?

Best regards,
Suzanne