Hi Shuzhou, Thanks for your interest in the draft, following are my comments regarding your questions:
After reading your draft, I liked the idea behind this draft but at the same time have some questions. 1. Does Figure 2 defines a new Auth Method in the "IKEv2 Authentication Method"? Because it looks like using the RFC 9593 multi-octet mechanism, but not exactly the same. [HJ] yes, figure 2 defines a new format for SUPPORTED_AUTH_METHODS, which is indicated by a new IANA to-be-assigned "Auth Method" value, same value is used in "Auth Method" of the AUTH payload 2. From Section 4.2, I don't get the information about what messages are being signed. Maybe some pseudo-code will help. [HJ] this draft doesn't change message to be signed in IKEv2; so it is the InitiatorSignedOctets/ResponderSignedOctets defined in section 2.15 of RFC7296, then use InitiatorSignedOctets/ ResponderSignedOctets as the "Message" input in "Sign (sk, Message) -> (signature)" process specified in section 4.2 of draft-ietf-lamps-pq-composite-sigs-02; I will add some more text to clarify this in next revision 3. Section 4.4 said that the composite certificate maybe used. I was wondering that it is actually necessary to use a composite certificate with a traditional/composite certificate together. [HJ] I should have made it clear, if a composite cert is used, you indeed don't need to use another certificate, a single composite cert is enough. Will clarify this in next reversion
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
