Hi Paul, > On Mon, 8 Nov 2021, Tero Kivinen wrote: > > > draft-smyslov-ipsecme-ikev2-auth-announce > > > > This is the start of 2 week WG adoption call for this document, ending > > 2021-11-22. Please send your reply about whether you support adopting > > this document as WG document or not. > > I support working on the idea.
Thank you. > I am not sure if this document in its > current form, properly conveys the differences between supported, > accepted and unsupported, rejected. This is especially tricky in the > responder side that does not yet know the ID of the peer and cannot > lookup configuration details yet. The responder has already to deal with this problem - it sends CERTREQ in the IKE_SA_INIT with the list of CAs before it knows the initiator's ID. The same is true for the SIGNATURE_HASH_ALGORITHMS notify. So, the problem is not new and the draft doesn't make responder's choice of what to send more tricky than it is now. > Also, as we have been merging authentication methods into RFC 7427 > digital signature format, it is unclear to me how we can convey some > of these parameters using existing IANA registries, since the whole > point here was that we didnt need to create and maintain one. Eg if we > support or allow EDDSA or some new signature algorithm, we might not > have any IANA registry for it, and just stating "we support RFC 7427" > does not solve the actual problem. The draft relies on AlgorithmIdentifier ASN.1 objects, that must exist for any new signature algorithm. They are assigned and maintained outside IKEv2 IANA registries. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
