On Sep 24, 2013, at 3:04 PM, Valery Smyslov <sva...@gmail.com> wrote:
>>> I just reread the introduction of RFC 4945 and I don't understand its >>> purpose. So I'm not sure it should be referenced from 5996bis. >> >> Ok, if there is any disagreement about it, then I think it is better >> to leave it out from 5996bis. > > If we leave it out, than original Yoav's question "is there anywhere in the > RFC > description of how to match ID to certificates" will arise from implementers. > And not all of them will be able to find RFC4945 without reference. > So, what's wrong in referencing it, at least as informative reference? It's really worse than just implementers asking questions. As long as there's no definitive profile, any implementer and often any administrator can stuff whatever they want in the certificate, and the other implementations have to deal with it. For example, my implementation by default stuffs some internal name into the subject common name, and an IP address of the gateway into an alternate name. For interop with other gateways, we have this dialog box called "Certificate Matching Criteria" for each peer gateway, where the administrator can specify the subject DN, the IP address (as an alternate name), or an RFC822 name (as an alternate name, not an RDN). And because there is no standard way to map ID payloads to certificate fields, we just ignore them (and have a way to configure what we send for interop). For the purposes of ADVPN we (different "we" this time) will create our own profile, which is actually a reverse profile - we're not specifying what a certificate should hold, but what the ID payload should hold, given an existing certificate. I don't think we have an answer for the general IKEv2 question, though. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
