From: Arnaud E. <tro...@gm...> - 2006-03-08 15:55:40
Attachments:
PGP.sig
|
Hello, First, keep the good work, VPN with racoon is a pleasure ;-). Now, sorry if this issue has already been raised; I didn't found anything on that topic in last months ML traffic. When setting up racoon in PKI environments that include certificates having UTF8 encoded RDN, peer identifier matching of 'remote' section can't be used because comparison ends the following way : expected RDN list (including wildcard one's) are compared with peer certificate's RDNs, one by one, but string type being different, they are declared as non matching. For instance, when using : remote anonymous { ... peers_identifier asn1dn "C=FR, ST=Paris, L=Paris, O=TOTO, OU=IPsec VPN Division, CN=*" ; verify_identifier on; ... } racoon converts given string (including wildcard) in DER and stored it in internal structures till a peer certificate is considered and DN is verified. After some calls (ipsecdoi_checkid1() in ipsec_doi.c, followed by eay_cmp_asn1dn() in crypto_openssl.c), the following function (always in crypto_openssl.c) is called with peer's DN and expected one, both DER encoded : static int X509_NAME_wildcmp(const X509_NAME *a, const X509_NAME *b) As a matter of fact, in this function, the comparison of an UTF8 encoded string element (say 'Paris') will be made binary against non- UTF8 encoded version (in fact, only binary string lengths are compared, which differs). More generally, only V_ASN1_PRINTABLESTRING and V_ASN1_IA5STRING encoding are specifically supported in previous function, other type being binary compared with expected DER-encoded version. Questions : - Can something be done in previous function to support that case (UTF8) and probably others (*) ? (I imagine the problem is not so easy, implying charset conversion) - If not, could a note on that point be put in racoon.conf man page ? - should the code in previous function look for a wildcard in RDN only for _expected_ ID, not peer certificate's DN ? i.e. should eay_cmp_asn1dn() function (implying the same for X509_NAME_wildcmp()) be made explicitly non-symmetrical in its process ? If I missed something in the code, don't hesitate. Also, sorry if I do not provide a patch : understand I have limited ideas of potential impacts associated with modifying previous functions. A+ (*) from a theoretical standpoint, sections 4.1.2.4 (Issuer) and 4.1.2.6 (Subject) of RFC3280 mandates UTF8 encoding support of DN after December 31, 2003. Even if my example does not require UTF8 encoding, there must be some that will. |