M
To: Daniel Van Geest
Cc: Blumenthal, Uri - 0553 - MITLL ; Scott Fluhrer
; ipsec@ietf.org
Subject: [IPsec] Re: [EXT] Re: draft-hu-ipsecme-pqt-hybrid-auth
Type-2 cannot be used with other protocols like TLS without protocol changes,
assuming a network function uses both TLS and IPSec protocols, it
Type-2 cannot be used with other protocols like TLS without protocol
changes, assuming a network function uses both TLS and IPSec protocols, it
will have to support both Type-1 and Type-2. Hence, the preference for
Type-1.
On Tue, 5 Nov 2024 at 22:51, Daniel Van Geest <
daniel.vange...@cryptonext-
...@gmail.com>>
Cc:Scott Fluhrer
mailto:sfluhrer=40cisco@dmarc.ietf.org>>;ipsec
mailto:ipsec@ietf.org>>
Date:2024-11-05 17:22:41
Subject:[IPsec] Re: [EXT] Re: draft-hu-ipsecme-pqt-hybrid-auth
I don't think Type-1 precludes Type-2 or vice-versa and there are use cases for
eit
I don't think Type-1 precludes Type-2 or vice-versa and there are use cases for
either.
In both cases, assuming that hybridization is not permanent and not a flag-day,
during the transition period two certificate chains will need to be managed,
always a traditional one and either a composite on
@ietf.org
Subject: [IPsec] Re: [EXT] Re: draft-hu-ipsecme-pqt-hybrid-auth
I don't think Type-1 precludes Type-2 or vice-versa and there are use cases for
either.
In both cases, assuming that hybridization is not permanent and not a flag-day,
during the transition period two certificate c
I prefer Type-2, as it seems a more straightforward approach overall, with fewer chances of “cross-interruptions”.—Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Nov 5, 2024, at 09:28, tirumal reddy wrote:
I prefer Type-1 over Type-2, it seems more compl
