I prefer Type-1 over Type-2, it seems more complicated to manage multiple certificates and the possibility of a downgrade attack .
-Tiru On Tue, 5 Nov 2024 at 15:40, Scott Fluhrer (sfluhrer) <sfluhrer= 40cisco....@dmarc.ietf.org> wrote: > While I support the goals of this draft, I do not believe that the methods > proposed are the most effective. > > > > It tries to merge Type-1 (certificates that include both classical and PQ > keys) and Type-2 (two separate certificates) methods of providing public > keys, however I believe it would be cleaner to keep them separate. > > > > For Type-1, if we use the ietf-lamps-pq-composite-sigs certificate format, > then it is easy. That defines a new signature algorithm (which internally > consists of a classical signature and a PQ signature pasted together, but > we can ignore the internal details). We can use that as the signature > method within the Auth payload, and hence the only changes we need to make > to IKE is to recognize this new signature method. > > > > For Type-2 (multiple certificates), we need to request multiple > certificates (which you do with the current proposal). However, it would > be cleaner i(IMHO) if the other side just provided multiple CERT payloads > and multiple AUTH payloads (rather than try to combine them). Each AUTH > payload would contain the signature (based on the public key from the > corresponding CERT payload) of the same data which is being signed now. > The idea is that if we keep the fundamental structure of IKE authentication > (just having multiple payloads when necessary), it may be easier for an > existing IKE implementation to be extended. > > > > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
