-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian
>> As far as X.509 certificates go, this point is correct, but using >> IP addresses in subjectAltName (lower case s) is a really bad idea anyway. >> We recommend against this in section 5.3.5 of >> draft-carpenter-renum-needs-work-03 >> (which is under AD review for Informational status). Yes. I agree. I did have doubts about focusing on subjectAltName as a common example, but I could not come up with a better one right now. I did think the verification problem that Heikki mentioned is important and can happen in other protocols so I might fix the wording to focus on the problem. Regards, Seiichi Brian E Carpenter wrote: > On 2009-08-27 15:55, Seiichi Kawamura wrote: > Hi Heikki > > Thanks for taking the time to review the document, > and your point is something that I think is worth > mentioning in the draft. How about we add a sub-section > like this > > 3.2.5 verification and validiation > > [RFC 5280] section 4.2.1.6 states that X.509 certificates may > contain IPv6 addresses in the SubjectAltName field. > When these fields are verified against actual connection status, if > verification was done with a simple text comparison, the certificate > may be mistakenly shown as being invalid. Similar problems can occur > in any protocol that embeds IPv6 addresses which have to be verified > or validated. > > I admit word smithing needs to be done, but does this seem reasonable? > >> As far as X.509 certificates go, this point is correct, but using >> IP addresses in subjectAltName (lower case s) is a really bad idea anyway. >> We recommend against this in section 5.3.5 of >> draft-carpenter-renum-needs-work-03 >> (which is under AD review for Informational status). > >> Brian >>>> Thanks for documenting these issues! > and thank you for your comments. > > Regards, > Seiichi > > > Heikki Vatiainen wrote: >>>> In case examples of problems with address presentation are useful, here >>>> is one more. >>>> >>>> RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and >>>> Certificate Revocation List (CRL) Profile" section 4.2.1.6. "Subject >>>> Alternative Name" says that IPv6 addresses can be contained in >>>> subjectAltName. No news there. >>>> >>>> When actually using a certificate that has an IPv6 address the following >>>> behaviour was seen with various SSL related components: >>>> >>>> Perl library Net::SSLeay returns the IPv6 subjectAltName in this format: >>>> fdf1:a315:9433:27:0:0:0:27 >>>> >>>> Perl Socket6 library contains inet_ntop that returns address in this >>>> format: fdf1:a315:9433:27::27 >>>> >>>> OpenSSL utility that dumps the certificate in text format shows the >>>> address like this: FDF1:A315:9433:27:0:0:0:27 >>>> >>>> Just recently I was debugging a perl program that had a problem with >>>> certificate verification. Certificate verification failed when the >>>> certificate presented by peer had subjectAltName with IPv6 address >>>> fdf1:a315:9433:27:0:0:0:27 and this did not match the address where the >>>> connection came from: fdf1:a315:9433:27::27. >>>> >>>> Same address but different presentation was the cause here too since the >>>> comparison was done using text strings. >>>> >>>> Thanks for documenting these issues! >>>> - -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 - -------------------------------------------------------------------- >> - -- ================================================ NEC BIGLOBE Ltd. Seiichi Kawamura <[email protected]> +81 3 3798 6085 (FAX: +81 3 3798 6029) +81 90 1547 4791 (mobile) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkqWEBsACgkQcrhTYfxyMkJYEwCfWoAsHGkE5h6HHEQEDpUJWTcb I4IAn1qYK6FwK9YmaD1y1NLVglPxYQPO =PioL -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
