-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

> 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!
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkqWA6gACgkQcrhTYfxyMkKhxACfbOUzBkSO4D4iSkOHeNf+sTrb
rqYAoIdRo/69HU6tA/l1lDQI35JriE+3
=EkIU
-----END PGP SIGNATURE-----
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to