Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Note that the IANA registry involved here was renamed since the latest draft was written :) Notify Message Type -> Notify Message Status Type "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message Status Type I wonder if it would make sense to somewhere explain that the authentication method refers to the AUTH payload, but that a separate peer ID check with its X.509 identity might need to be done, for which the CA cert that signed the EE cert could be using a different signature method? For example, the EE-cert could be using RSA-v1.5 while the AUTH payload could be using RSA-PSS. Or in some other way explain that peer ID proof checking is not "authentication" as used in this document? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
