Debian Bug report logs - #514807
X.509v1 CA certs no longer trusted implicitly

version graph

Package: libgnutls13; Maintainer for libgnutls13 is (unknown);

Reported by: Edward Allcutt <emallcut@gleim.com>

Date: Wed, 11 Feb 2009 00:27:01 UTC

Severity: important

Tags: wontfix

Found in version 1.4.4-3+etch3

Fixed in versions gnutls26/2.4.2-6+lenny1, gnutls13/1.4.4-3+etch4

Done: Florian Weimer <fw@deneb.enyo.de>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 00:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
New Bug report received and forwarded. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 00:27:03 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Tue, 10 Feb 2009 19:21:26 -0500
Package: libgnutls13
Version: 1.4.4-3+etch3
Severity: important

After the upgrade all embedded uses of LDAP fail with connection errors.
On investigations these seem to be caused by certificate validation
problems.

This was first noticed with nss_ldap. After enabling debugging, running
`getent group` produced error messages like:
TLS certificate verification: depth: 0, err: 130, subject: <snip DN/>
TLS certificate verification: Error, Unknown error

Similar problems occur for pam_ldap and apache mod_authnz_ldap.
Strangely, gnutls-cli verifies the server certificate with no problems.

The error was first seen in a STARTTLS only configuration. I have since
enabled ldaps to ease testing with gnutls-cli and confirmed it still
affects nss_ldap and apache switched to ldaps.

The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd
expect gnutls-cli to complain if this were the issue.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-xen-amd64
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)

Versions of packages libgnutls13 depends on:
ii  libc6                  2.3.6.ds1-13etch8 GNU C Library: Shared libraries
ii  libgcrypt11            1.2.3-2           LGPL Crypto library - runtime libr
ii  libgpg-error0          1.4-1             library for common error values an
ii  liblzo1                1.08-3            data compression library (old vers
ii  libopencdk8            0.5.9-2           Open Crypto Development Kit (OpenC
ii  libtasn1-3             0.3.6-2           Manage ASN.1 structures (runtime)
ii  zlib1g                 1:1.2.3-13        compression library - runtime

libgnutls13 recommends no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 11:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 11:03:02 GMT) Full text and rfc822 format available.

Message #10 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Wed, 11 Feb 2009 12:01:18 +0100
Edward Allcutt <emallcut@gleim.com> writes:

> Package: libgnutls13
> Version: 1.4.4-3+etch3
> Severity: important
>
> After the upgrade all embedded uses of LDAP fail with connection errors.
> On investigations these seem to be caused by certificate validation
> problems.
>
> This was first noticed with nss_ldap. After enabling debugging, running
> `getent group` produced error messages like:
> TLS certificate verification: depth: 0, err: 130, subject: <snip DN/>
> TLS certificate verification: Error, Unknown error
>
> Similar problems occur for pam_ldap and apache mod_authnz_ldap.
> Strangely, gnutls-cli verifies the server certificate with no problems.
>
> The error was first seen in a STARTTLS only configuration. I have since
> enabled ldaps to ease testing with gnutls-cli and confirmed it still
> affects nss_ldap and apache switched to ldaps.
>
> The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd
> expect gnutls-cli to complain if this were the issue.

Please post output from 'gnutls-cli -p 663 your.ldap.server -d 4711
--print-cert' replacing your.ldap.server as appropriate.

I suspect the problem is that you have a RSA-MD5 signature somewhere in
the certificate chain.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 15:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 15:18:02 GMT) Full text and rfc822 format available.

Message #15 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Wed, 11 Feb 2009 10:14:29 -0500
[Message part 1 (text/plain, inline)]
Simon Josefsson wrote:
> Edward Allcutt <emallcut@gleim.com> writes:
> 
>> Package: libgnutls13
>> Version: 1.4.4-3+etch3
>> Severity: important
>>
>> After the upgrade all embedded uses of LDAP fail with connection errors.
>> On investigations these seem to be caused by certificate validation
>> problems.
>>
>> This was first noticed with nss_ldap. After enabling debugging, running
>> `getent group` produced error messages like:
>> TLS certificate verification: depth: 0, err: 130, subject: <snip DN/>
>> TLS certificate verification: Error, Unknown error
>>
>> Similar problems occur for pam_ldap and apache mod_authnz_ldap.
>> Strangely, gnutls-cli verifies the server certificate with no problems.
>>
>> The error was first seen in a STARTTLS only configuration. I have since
>> enabled ldaps to ease testing with gnutls-cli and confirmed it still
>> affects nss_ldap and apache switched to ldaps.
>>
>> The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd
>> expect gnutls-cli to complain if this were the issue.
> 
> Please post output from 'gnutls-cli -p 663 your.ldap.server -d 4711
> --print-cert' replacing your.ldap.server as appropriate.
Output of `gnutls-cli -p ldaps -d 4711 --print-cert ldap-3.teamgleim.com 
>out 2>&1` attached.

> I suspect the problem is that you have a RSA-MD5 signature somewhere in
> the certificate chain.
Nope, already checked that... gnutls-cli does work after all. It's the 
other modules linked to libgnutls that are failing.

-- 
Edward Allcutt
Network Operations
[out (text/plain, inline)]
|<2>| ASSERT: gnutls_psk.c:101
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: RSA_EXPORT_ARCFOUR_40_MD5
|<3>| HSK[815ba90]: Keeping ciphersuite: ANON_DH_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: ANON_DH_AES_128_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: ANON_DH_3DES_EDE_CBC_SHA1
|<3>| HSK[815ba90]: Keeping ciphersuite: ANON_DH_ARCFOUR_MD5
|<2>| EXT[815ba90]: Sending extension CERT_TYPE
|<2>| EXT[815ba90]: Sending extension SERVER_NAME
|<3>| HSK[815ba90]: CLIENT HELLO was send [142 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[815ba90]: Sending Packet[0] Handshake(22) with length: 142
|<7>| WRITE: Will write 147 bytes to 4.
|<7>| WRITE: wrote 147 bytes to 4. Left 0 bytes. Total 147 bytes.
|<7>| 0000 - 16 03 02 00 8e 01 00 00 8a 03 02 49 92 ea 74 5a 
|<7>| 0001 - 21 3d 49 3d cd aa 32 ef 8e 58 13 9c 97 df 5c 50 
|<7>| 0002 - 81 52 0d 09 00 23 10 de b1 41 24 00 00 3c 00 39 
|<7>| 0003 - 00 33 00 16 00 38 00 32 00 13 00 66 00 35 00 2f 
|<7>| 0004 - 00 0a 00 05 00 04 00 57 00 54 00 51 00 58 00 55 
|<7>| 0005 - 00 52 00 56 00 53 00 50 00 8d 00 8c 00 8b 00 8a 
|<7>| 0006 - 00 03 00 3a 00 34 00 1b 00 18 02 01 00 00 24 00 
|<7>| 0007 - 09 00 03 02 00 01 00 00 00 19 00 17 00 00 14 6c 
|<7>| 0008 - 64 61 70 2d 33 2e 74 65 61 6d 67 6c 65 69 6d 2e 
|<7>| 0009 - 63 6f 6d 
|<4>| REC[815ba90]: Sent Packet[1] Handshake(22) with length: 147
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 4a 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[815ba90]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[815ba90]: Received Packet[0] Handshake(22) with length: 74
|<7>| READ: Got 74 bytes from 4
|<7>| READ: read 74 bytes from 4
|<7>| 0000 - 02 00 00 46 03 01 49 92 ea 74 b5 c0 1d 0d e6 22 
|<7>| 0001 - fe b3 e7 e8 47 84 fd 4b d7 d5 fa 26 16 2f 9f fb 
|<7>| 0002 - 84 b2 03 1e ff dd 20 3f 25 5d eb b1 dd f6 17 fb 
|<7>| 0003 - 8a 95 88 64 8a 07 12 38 b3 28 95 87 66 30 87 f5 
|<7>| 0004 - 0a e9 82 22 55 f2 e8 00 35 01 
|<7>| RB: Have 5 bytes into buffer. Adding 74 bytes.
|<7>| RB: Requested 79 bytes
|<4>| REC[815ba90]: Decrypted Packet[0] Handshake(22) with length: 74
|<6>| BUF[HSK]: Inserted 74 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[815ba90]: SERVER HELLO was received [74 bytes]
|<6>| BUF[REC][HD]: Read 70 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 70 bytes of Data
|<3>| HSK[815ba90]: Server's version: 3.1
|<3>| HSK[815ba90]: SessionID length: 32
|<3>| HSK[815ba90]: SessionID: 3f255debb1ddf617fb8a9588648a071238b3289587663087f50ae9822255f2e8
|<3>| HSK[815ba90]: Selected cipher suite: RSA_AES_256_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:153
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 11 bc 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[815ba90]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[815ba90]: Received Packet[1] Handshake(22) with length: 4540
|<7>| READ: Got 2812 bytes from 4
|<7>| READ: Got 1728 bytes from 4
|<7>| READ: read 4540 bytes from 4
|<7>| 0000 - 0b 00 11 b8 00 11 b5 00 04 dd 30 82 04 d9 30 82 
|<7>| 0001 - 03 c1 a0 03 02 01 02 02 04 00 e1 58 c0 30 0d 06 
|<7>| 0002 - 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 ca 31 
|<7>| 0003 - 0b 30 09 06 03 55 04 06 13 02 55 53 31 10 30 0e 
|<7>| 0004 - 06 03 55 04 08 13 07 41 72 69 7a 6f 6e 61 31 13 
|<7>| 0005 - 30 11 06 03 55 04 07 13 0a 53 63 6f 74 74 73 64 
|<7>| 0006 - 61 6c 65 31 1a 30 18 06 03 55 04 0a 13 11 47 6f 
|<7>| 0007 - 44 61 64 64 79 2e 63 6f 6d 2c 20 49 6e 63 2e 31 
|<7>| 0008 - 33 30 31 06 03 55 04 0b 13 2a 68 74 74 70 3a 2f 
|<7>| 0009 - 2f 63 65 72 74 69 66 69 63 61 74 65 73 2e 67 6f 
|<7>| 000a - 64 61 64 64 79 2e 63 6f 6d 2f 72 65 70 6f 73 69 
|<7>| 000b - 74 6f 72 79 31 30 30 2e 06 03 55 04 03 13 27 47 
|<7>| 000c - 6f 20 44 61 64 64 79 20 53 65 63 75 72 65 20 43 
|<7>| 000d - 65 72 74 69 66 69 63 61 74 69 6f 6e 20 41 75 74 
|<7>| 000e - 68 6f 72 69 74 79 31 11 30 0f 06 03 55 04 05 13 
|<7>| 000f - 08 30 37 39 36 39 32 38 37 30 1e 17 0d 30 38 31 
|<7>| 0010 - 32 30 31 32 31 35 39 32 39 5a 17 0d 31 30 30 31 
|<7>| 0011 - 31 31 31 38 35 39 33 39 5a 30 57 31 18 30 16 06 
|<7>| 0012 - 03 55 04 0a 13 0f 2a 2e 74 65 61 6d 67 6c 65 69 
|<7>| 0013 - 6d 2e 63 6f 6d 31 18 30 16 06 03 55 04 03 13 0f 
|<7>| 0014 - 2a 2e 74 65 61 6d 67 6c 65 69 6d 2e 63 6f 6d 31 
|<7>| 0015 - 21 30 1f 06 03 55 04 0b 13 18 44 6f 6d 61 69 6e 
|<7>| 0016 - 20 43 6f 6e 74 72 6f 6c 20 56 61 6c 69 64 61 74 
|<7>| 0017 - 65 64 30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 
|<7>| 0018 - 01 01 05 00 03 81 8d 00 30 81 89 02 81 81 00 ad 
|<7>| 0019 - 0e 67 60 da 1c 5e 8a e0 e3 27 49 1d fa 14 77 db 
|<7>| 001a - d8 3c 74 1f 2d 77 a3 24 b8 3b 85 f5 fa b2 5f ca 
|<7>| 001b - 05 c7 43 4d da d2 56 38 46 5c 2a 78 c4 09 61 0c 
|<7>| 001c - af b8 50 01 a9 fa 22 fe 1c 07 f5 b1 6a 62 f1 52 
|<7>| 001d - aa d1 b6 46 df 4e 52 e4 ce 69 08 e2 e0 c8 77 a6 
|<7>| 001e - 69 8f b7 2d 48 9b 8c 34 bb 8b c4 8a f5 a0 6c 09 
|<7>| 001f - 5d a3 43 05 1a 3d 98 90 44 23 96 7c 60 64 b8 d0 
|<7>| 0020 - 28 90 cf 0e 60 d5 98 f8 f1 c5 85 b7 97 96 4d 02 
|<7>| 0021 - 03 01 00 01 a3 82 01 bb 30 82 01 b7 30 0f 06 03 
|<7>| 0022 - 55 1d 13 01 01 ff 04 05 30 03 01 01 00 30 1d 06 
|<7>| 0023 - 03 55 1d 25 04 16 30 14 06 08 2b 06 01 05 05 07 
|<7>| 0024 - 03 01 06 08 2b 06 01 05 05 07 03 02 30 0e 06 03 
|<7>| 0025 - 55 1d 0f 01 01 ff 04 04 03 02 05 a0 30 32 06 03 
|<7>| 0026 - 55 1d 1f 04 2b 30 29 30 27 a0 25 a0 23 86 21 68 
|<7>| 0027 - 74 74 70 3a 2f 2f 63 72 6c 2e 67 6f 64 61 64 64 
|<7>| 0028 - 79 2e 63 6f 6d 2f 67 64 73 31 2d 30 2e 63 72 6c 
|<7>| 0029 - 30 53 06 03 55 1d 20 04 4c 30 4a 30 48 06 0b 60 
|<7>| 002a - 86 48 01 86 fd 6d 01 07 17 01 30 39 30 37 06 08 
|<7>| 002b - 2b 06 01 05 05 07 02 01 16 2b 68 74 74 70 3a 2f 
|<7>| 002c - 2f 63 65 72 74 69 66 69 63 61 74 65 73 2e 67 6f 
|<7>| 002d - 64 61 64 64 79 2e 63 6f 6d 2f 72 65 70 6f 73 69 
|<7>| 002e - 74 6f 72 79 2f 30 81 80 06 08 2b 06 01 05 05 07 
|<7>| 002f - 01 01 04 74 30 72 30 24 06 08 2b 06 01 05 05 07 
|<7>| 0030 - 30 01 86 18 68 74 74 70 3a 2f 2f 6f 63 73 70 2e 
|<7>| 0031 - 67 6f 64 61 64 64 79 2e 63 6f 6d 2f 30 4a 06 08 
|<7>| 0032 - 2b 06 01 05 05 07 30 02 86 3e 68 74 74 70 3a 2f 
|<7>| 0033 - 2f 63 65 72 74 69 66 69 63 61 74 65 73 2e 67 6f 
|<7>| 0034 - 64 61 64 64 79 2e 63 6f 6d 2f 72 65 70 6f 73 69 
|<7>| 0035 - 74 6f 72 79 2f 67 64 5f 69 6e 74 65 72 6d 65 64 
|<7>| 0036 - 69 61 74 65 2e 63 72 74 30 1f 06 03 55 1d 23 04 
|<7>| 0037 - 18 30 16 80 14 fd ac 61 32 93 6c 45 d6 e2 ee 85 
|<7>| 0038 - 5f 9a ba e7 76 99 68 cc e7 30 29 06 03 55 1d 11 
|<7>| 0039 - 04 22 30 20 82 0f 2a 2e 74 65 61 6d 67 6c 65 69 
|<7>| 003a - 6d 2e 63 6f 6d 82 0d 74 65 61 6d 67 6c 65 69 6d 
|<7>| 003b - 2e 63 6f 6d 30 1d 06 03 55 1d 0e 04 16 04 14 7e 
|<7>| 003c - 24 56 0e fb ec f3 1d b1 6c 32 31 7c d4 58 f9 63 
|<7>| 003d - e3 59 33 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 
|<7>| 003e - 05 00 03 82 01 01 00 5c c8 d2 b9 6a 2d 32 25 ed 
|<7>| 003f - ab d5 b3 f0 cc 50 06 82 6f f4 08 ff b0 54 02 05 
|<7>| 0040 - 50 e2 ef 95 e1 7a 68 29 f4 12 28 87 00 e3 c5 f1 
|<7>| 0041 - 31 88 17 4a e4 4a 56 fc 5e f6 3d 8e 8c 8c 72 3b 
|<7>| 0042 - 0f d7 66 10 23 41 40 ae fb e5 8f 03 85 74 12 bd 
|<7>| 0043 - b5 53 71 a1 6e e6 31 95 96 28 e3 42 d9 90 45 86 
|<7>| 0044 - 51 06 5d 95 b9 b6 09 e0 c8 48 c0 76 0f 94 b5 50 
|<7>| 0045 - 33 1a f1 05 12 72 e6 1d 11 c4 85 2a 1d de 72 76 
|<7>| 0046 - 64 69 c0 46 e8 75 4c 9d b5 11 f3 08 9e 04 77 e0 
|<7>| 0047 - 0f 36 40 1a c6 63 de c6 e6 d5 ce 0e d1 3c 7f 54 
|<7>| 0048 - e3 1e f6 87 a1 ad 36 13 52 71 a6 38 9e 1f 82 9f 
|<7>| 0049 - 05 64 2c 89 ae 47 20 f0 d5 b0 9e d0 14 12 11 f7 
|<7>| 004a - e3 4b a5 f5 13 5d 5f 86 ef ec 68 66 fb bc 4e de 
|<7>| 004b - 26 df ef 82 31 c8 cc 3b 9d 78 e7 bb 9a 31 27 2b 
|<7>| 004c - 2a 0f a7 a8 34 ae 68 05 50 ca 21 57 ac 6b 52 17 
|<7>| 004d - 12 8f 9c af 1a 34 f0 2c a8 50 80 84 84 cb 94 69 
|<7>| 004e - 2b 5d 24 f7 2c ae 97 00 04 e2 30 82 04 de 30 82 
|<7>| 004f - 03 c6 a0 03 02 01 02 02 02 03 01 30 0d 06 09 2a 
|<7>| 0050 - 86 48 86 f7 0d 01 01 05 05 00 30 63 31 0b 30 09 
|<7>| 0051 - 06 03 55 04 06 13 02 55 53 31 21 30 1f 06 03 55 
|<7>| 0052 - 04 0a 13 18 54 68 65 20 47 6f 20 44 61 64 64 79 
|<7>| 0053 - 20 47 72 6f 75 70 2c 20 49 6e 63 2e 31 31 30 2f 
|<7>| 0054 - 06 03 55 04 0b 13 28 47 6f 20 44 61 64 64 79 20 
|<7>| 0055 - 43 6c 61 73 73 20 32 20 43 65 72 74 69 66 69 63 
|<7>| 0056 - 61 74 69 6f 6e 20 41 75 74 68 6f 72 69 74 79 30 
|<7>| 0057 - 1e 17 0d 30 36 31 31 31 36 30 31 35 34 33 37 5a 
|<7>| 0058 - 17 0d 32 36 31 31 31 36 30 31 35 34 33 37 5a 30 
|<7>| 0059 - 81 ca 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 
|<7>| 005a - 10 30 0e 06 03 55 04 08 13 07 41 72 69 7a 6f 6e 
|<7>| 005b - 61 31 13 30 11 06 03 55 04 07 13 0a 53 63 6f 74 
|<7>| 005c - 74 73 64 61 6c 65 31 1a 30 18 06 03 55 04 0a 13 
|<7>| 005d - 11 47 6f 44 61 64 64 79 2e 63 6f 6d 2c 20 49 6e 
|<7>| 005e - 63 2e 31 33 30 31 06 03 55 04 0b 13 2a 68 74 74 
|<7>| 005f - 70 3a 2f 2f 63 65 72 74 69 66 69 63 61 74 65 73 
|<7>| 0060 - 2e 67 6f 64 61 64 64 79 2e 63 6f 6d 2f 72 65 70 
|<7>| 0061 - 6f 73 69 74 6f 72 79 31 30 30 2e 06 03 55 04 03 
|<7>| 0062 - 13 27 47 6f 20 44 61 64 64 79 20 53 65 63 75 72 
|<7>| 0063 - 65 20 43 65 72 74 69 66 69 63 61 74 69 6f 6e 20 
|<7>| 0064 - 41 75 74 68 6f 72 69 74 79 31 11 30 0f 06 03 55 
|<7>| 0065 - 04 05 13 08 30 37 39 36 39 32 38 37 30 82 01 22 
|<7>| 0066 - 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 
|<7>| 0067 - 82 01 0f 00 30 82 01 0a 02 82 01 01 00 c4 2d d5 
|<7>| 0068 - 15 8c 9c 26 4c ec 32 35 eb 5f b8 59 01 5a a6 61 
|<7>| 0069 - 81 59 3b 70 63 ab e3 dc 3d c7 2a b8 c9 33 d3 79 
|<7>| 006a - e4 3a ed 3c 30 23 84 8e b3 30 14 b6 b2 87 c3 3d 
|<7>| 006b - 95 54 04 9e df 99 dd 0b 25 1e 21 de 65 29 7e 35 
|<7>| 006c - a8 a9 54 eb f6 f7 32 39 d4 26 55 95 ad ef fb fe 
|<7>| 006d - 58 86 d7 9e f4 00 8d 8c 2a 0c bd 42 04 ce a7 3f 
|<7>| 006e - 04 f6 ee 80 f2 aa ef 52 a1 69 66 da be 1a ad 5d 
|<7>| 006f - da 2c 66 ea 1a 6b bb e5 1a 51 4a 00 2f 48 c7 98 
|<7>| 0070 - 75 d8 b9 29 c8 ee f8 66 6d 0a 9c b3 f3 fc 78 7c 
|<7>| 0071 - a2 f8 a3 f2 b5 c3 f3 b9 7a 91 c1 a7 e6 25 2e 9c 
|<7>| 0072 - a8 ed 12 65 6e 6a f6 12 44 53 70 30 95 c3 9c 2b 
|<7>| 0073 - 58 2b 3d 08 74 4a f2 be 51 b0 bf 87 d0 4c 27 58 
|<7>| 0074 - 6b b5 35 c5 9d af 17 31 f8 0b 8f ee ad 81 36 05 
|<7>| 0075 - 89 08 98 cf 3a af 25 87 c0 49 ea a7 fd 67 f7 45 
|<7>| 0076 - 8e 97 cc 14 39 e2 36 85 b5 7e 1a 37 fd 16 f6 71 
|<7>| 0077 - 11 9a 74 30 16 fe 13 94 a3 3f 84 0d 4f 02 03 01 
|<7>| 0078 - 00 01 a3 82 01 32 30 82 01 2e 30 1d 06 03 55 1d 
|<7>| 0079 - 0e 04 16 04 14 fd ac 61 32 93 6c 45 d6 e2 ee 85 
|<7>| 007a - 5f 9a ba e7 76 99 68 cc e7 30 1f 06 03 55 1d 23 
|<7>| 007b - 04 18 30 16 80 14 d2 c4 b0 d2 91 d4 4c 11 71 b3 
|<7>| 007c - 61 cb 3d a1 fe dd a8 6a d4 e3 30 12 06 03 55 1d 
|<7>| 007d - 13 01 01 ff 04 08 30 06 01 01 ff 02 01 00 30 33 
|<7>| 007e - 06 08 2b 06 01 05 05 07 01 01 04 27 30 25 30 23 
|<7>| 007f - 06 08 2b 06 01 05 05 07 30 01 86 17 68 74 74 70 
|<7>| 0080 - 3a 2f 2f 6f 63 73 70 2e 67 6f 64 61 64 64 79 2e 
|<7>| 0081 - 63 6f 6d 30 46 06 03 55 1d 1f 04 3f 30 3d 30 3b 
|<7>| 0082 - a0 39 a0 37 86 35 68 74 74 70 3a 2f 2f 63 65 72 
|<7>| 0083 - 74 69 66 69 63 61 74 65 73 2e 67 6f 64 61 64 64 
|<7>| 0084 - 79 2e 63 6f 6d 2f 72 65 70 6f 73 69 74 6f 72 79 
|<7>| 0085 - 2f 67 64 72 6f 6f 74 2e 63 72 6c 30 4b 06 03 55 
|<7>| 0086 - 1d 20 04 44 30 42 30 40 06 04 55 1d 20 00 30 38 
|<7>| 0087 - 30 36 06 08 2b 06 01 05 05 07 02 01 16 2a 68 74 
|<7>| 0088 - 74 70 3a 2f 2f 63 65 72 74 69 66 69 63 61 74 65 
|<7>| 0089 - 73 2e 67 6f 64 61 64 64 79 2e 63 6f 6d 2f 72 65 
|<7>| 008a - 70 6f 73 69 74 6f 72 79 30 0e 06 03 55 1d 0f 01 
|<7>| 008b - 01 ff 04 04 03 02 01 06 30 0d 06 09 2a 86 48 86 
|<7>| 008c - f7 0d 01 01 05 05 00 03 82 01 01 00 d2 86 c0 ec 
|<7>| 008d - bd f9 a1 b6 67 ee 66 0b a2 06 3a 04 50 8e 15 72 
|<7>| 008e - ac 4a 74 95 53 cb 37 cb 44 49 ef 07 90 6b 33 d9 
|<7>| 008f - 96 f0 94 56 a5 13 30 05 3c 85 32 21 7b c9 c7 0a 
|<7>| 0090 - a8 24 a4 90 de 46 d3 25 23 14 03 67 c2 10 d6 6f 
|<7>| 0091 - 0f 5d 7b 7a cc 9f c5 58 2a c1 c4 9e 21 a8 5a f3 
|<7>| 0092 - ac a4 46 f3 9e e4 63 cb 2f 90 a4 29 29 01 d9 72 
|<7>| 0093 - 2c 29 df 37 01 27 bc 4f ee 68 d3 21 8f c0 b3 e4 
|<7>| 0094 - f5 09 ed d2 10 aa 53 b4 be f0 cc 59 0b d6 3b 96 
|<7>| 0095 - 1c 95 24 49 df ce ec fd a7 48 91 14 45 0e 3a 36 
|<7>| 0096 - 6f da 45 b3 45 a2 41 c9 d4 d7 44 4e 3e b9 74 76 
|<7>| 0097 - d5 a2 13 55 2c c6 87 a3 b5 99 ac 06 84 87 7f 75 
|<7>| 0098 - 06 fc bf 14 4c 0e cc 6e c4 df 3d b7 12 71 f4 e8 
|<7>| 0099 - f1 51 40 22 28 49 e0 1d 4b 87 a8 34 cc 06 a2 dd 
|<7>| 009a - 12 5a d1 86 36 64 03 35 6f 6f 77 6e eb f2 85 50 
|<7>| 009b - 98 5e ab 03 53 ad 91 23 63 1f 16 9c cd b9 b2 05 
|<7>| 009c - 63 3a e1 f4 68 1b 17 05 35 95 53 ee 00 04 ff 30 
|<7>| 009d - 82 04 fb 30 82 04 64 a0 03 02 01 02 02 02 01 0d 
|<7>| 009e - 30 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 
|<7>| 009f - 81 bb 31 24 30 22 06 03 55 04 07 13 1b 56 61 6c 
|<7>| 00a0 - 69 43 65 72 74 20 56 61 6c 69 64 61 74 69 6f 6e 
|<7>| 00a1 - 20 4e 65 74 77 6f 72 6b 31 17 30 15 06 03 55 04 
|<7>| 00a2 - 0a 13 0e 56 61 6c 69 43 65 72 74 2c 20 49 6e 63 
|<7>| 00a3 - 2e 31 35 30 33 06 03 55 04 0b 13 2c 56 61 6c 69 
|<7>| 00a4 - 43 65 72 74 20 43 6c 61 73 73 20 32 20 50 6f 6c 
|<7>| 00a5 - 69 63 79 20 56 61 6c 69 64 61 74 69 6f 6e 20 41 
|<7>| 00a6 - 75 74 68 6f 72 69 74 79 31 21 30 1f 06 03 55 04 
|<7>| 00a7 - 03 13 18 68 74 74 70 3a 2f 2f 77 77 77 2e 76 61 
|<7>| 00a8 - 6c 69 63 65 72 74 2e 63 6f 6d 2f 31 20 30 1e 06 
|<7>| 00a9 - 09 2a 86 48 86 f7 0d 01 09 01 16 11 69 6e 66 6f 
|<7>| 00aa - 40 76 61 6c 69 63 65 72 74 2e 63 6f 6d 30 1e 17 
|<7>| 00ab - 0d 30 34 30 36 32 39 31 37 30 36 32 30 5a 17 0d 
|<7>| 00ac - 32 34 30 36 32 39 31 37 30 36 32 30 5a 30 63 31 
|<7>| 00ad - 0b 30 09 06 03 55 04 06 13 02 55 53 31 21 30 1f 
|<7>| 00ae - 06 03 55 04 0a 13 18 54 68 65 20 47 6f 20 44 61 
|<7>| 00af - 64 64 79 20 47 72 6f 75 70 2c 20 49 6e 63 2e 31 
|<7>| 00b0 - 31 30 2f 06 03 55 04 0b 13 28 47 6f 20 44 61 64 
|<7>| 00b1 - 64 79 20 43 6c 61 73 73 20 32 20 43 65 72 74 69 
|<7>| 00b2 - 66 69 63 61 74 69 6f 6e 20 41 75 74 68 6f 72 69 
|<7>| 00b3 - 74 79 30 82 01 20 30 0d 06 09 2a 86 48 86 f7 0d 
|<7>| 00b4 - 01 01 01 05 00 03 82 01 0d 00 30 82 01 08 02 82 
|<7>| 00b5 - 01 01 00 de 9d d7 ea 57 18 49 a1 5b eb d7 5f 48 
|<7>| 00b6 - 86 ea be dd ff e4 ef 67 1c f4 65 68 b3 57 71 a0 
|<7>| 00b7 - 5e 77 bb ed 9b 49 e9 70 80 3d 56 18 63 08 6f da 
|<7>| 00b8 - f2 cc d0 3f 7f 02 54 22 54 10 d8 b2 81 d4 c0 75 
|<7>| 00b9 - 3d 4b 7f c7 77 c3 3e 78 ab 1a 03 b5 20 6b 2f 6a 
|<7>| 00ba - 2b b1 c5 88 7e c4 bb 1e b0 c1 d8 45 27 6f aa 37 
|<7>| 00bb - 58 f7 87 26 d7 d8 2d f6 a9 17 b7 1f 72 36 4e a6 
|<7>| 00bc - 17 3f 65 98 92 db 2a 6e 5d a2 fe 88 e0 0b de 7f 
|<7>| 00bd - e5 8d 15 e1 eb cb 3a d5 e2 12 a2 13 2d d8 8e af 
|<7>| 00be - 5f 12 3d a0 08 05 08 b6 5c a5 65 38 04 45 99 1e 
|<7>| 00bf - a3 60 60 74 c5 41 a5 72 62 1b 62 c5 1f 6f 5f 1a 
|<7>| 00c0 - 42 be 02 51 65 a8 ae 23 18 6a fc 78 03 a9 4d 7f 
|<7>| 00c1 - 80 c3 fa ab 5a fc a1 40 a4 ca 19 16 fe b2 c8 ef 
|<7>| 00c2 - 5e 73 0d ee 77 bd 9a f6 79 98 bc b1 07 67 a2 15 
|<7>| 00c3 - 0d dd a0 58 c6 44 7b 0a 3e 62 28 5f ba 41 07 53 
|<7>| 00c4 - 58 cf 11 7e 38 74 c5 f8 ff b5 69 90 8f 84 74 ea 
|<7>| 00c5 - 97 1b af 02 01 03 a3 82 01 e1 30 82 01 dd 30 1d 
|<7>| 00c6 - 06 03 55 1d 0e 04 16 04 14 d2 c4 b0 d2 91 d4 4c 
|<7>| 00c7 - 11 71 b3 61 cb 3d a1 fe dd a8 6a d4 e3 30 81 d2 
|<7>| 00c8 - 06 03 55 1d 23 04 81 ca 30 81 c7 a1 81 c1 a4 81 
|<7>| 00c9 - be 30 81 bb 31 24 30 22 06 03 55 04 07 13 1b 56 
|<7>| 00ca - 61 6c 69 43 65 72 74 20 56 61 6c 69 64 61 74 69 
|<7>| 00cb - 6f 6e 20 4e 65 74 77 6f 72 6b 31 17 30 15 06 03 
|<7>| 00cc - 55 04 0a 13 0e 56 61 6c 69 43 65 72 74 2c 20 49 
|<7>| 00cd - 6e 63 2e 31 35 30 33 06 03 55 04 0b 13 2c 56 61 
|<7>| 00ce - 6c 69 43 65 72 74 20 43 6c 61 73 73 20 32 20 50 
|<7>| 00cf - 6f 6c 69 63 79 20 56 61 6c 69 64 61 74 69 6f 6e 
|<7>| 00d0 - 20 41 75 74 68 6f 72 69 74 79 31 21 30 1f 06 03 
|<7>| 00d1 - 55 04 03 13 18 68 74 74 70 3a 2f 2f 77 77 77 2e 
|<7>| 00d2 - 76 61 6c 69 63 65 72 74 2e 63 6f 6d 2f 31 20 30 
|<7>| 00d3 - 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 69 6e 
|<7>| 00d4 - 66 6f 40 76 61 6c 69 63 65 72 74 2e 63 6f 6d 82 
|<7>| 00d5 - 01 01 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 
|<7>| 00d6 - 01 01 ff 30 33 06 08 2b 06 01 05 05 07 01 01 04 
|<7>| 00d7 - 27 30 25 30 23 06 08 2b 06 01 05 05 07 30 01 86 
|<7>| 00d8 - 17 68 74 74 70 3a 2f 2f 6f 63 73 70 2e 67 6f 64 
|<7>| 00d9 - 61 64 64 79 2e 63 6f 6d 30 44 06 03 55 1d 1f 04 
|<7>| 00da - 3d 30 3b 30 39 a0 37 a0 35 86 33 68 74 74 70 3a 
|<7>| 00db - 2f 2f 63 65 72 74 69 66 69 63 61 74 65 73 2e 67 
|<7>| 00dc - 6f 64 61 64 64 79 2e 63 6f 6d 2f 72 65 70 6f 73 
|<7>| 00dd - 69 74 6f 72 79 2f 72 6f 6f 74 2e 63 72 6c 30 4b 
|<7>| 00de - 06 03 55 1d 20 04 44 30 42 30 40 06 04 55 1d 20 
|<7>| 00df - 00 30 38 30 36 06 08 2b 06 01 05 05 07 02 01 16 
|<7>| 00e0 - 2a 68 74 74 70 3a 2f 2f 63 65 72 74 69 66 69 63 
|<7>| 00e1 - 61 74 65 73 2e 67 6f 64 61 64 64 79 2e 63 6f 6d 
|<7>| 00e2 - 2f 72 65 70 6f 73 69 74 6f 72 79 30 0e 06 03 55 
|<7>| 00e3 - 1d 0f 01 01 ff 04 04 03 02 01 06 30 0d 06 09 2a 
|<7>| 00e4 - 86 48 86 f7 0d 01 01 05 05 00 03 81 81 00 b5 40 
|<7>| 00e5 - f9 a7 1d f6 ea fe a4 1a 42 5a 44 f7 15 d4 85 46 
|<7>| 00e6 - 89 c0 be 9e e3 e3 eb c5 e3 58 89 8f 92 9f 57 a8 
|<7>| 00e7 - 71 2c 48 d1 81 b2 79 1f ac 06 35 19 b0 4e 0e 58 
|<7>| 00e8 - 1b 14 b3 98 81 d1 04 1e c8 07 c9 83 9f 78 44 0a 
|<7>| 00e9 - 18 0b 98 dc 76 7a 65 0d 0d 6d 80 c4 0b 01 1c cb 
|<7>| 00ea - ad 47 3e 71 be 77 4b cc 06 77 d0 f4 56 6b 1f 4b 
|<7>| 00eb - 13 9a 14 8a 88 23 a8 51 f0 83 4c ab 35 bf 46 7e 
|<7>| 00ec - 39 dc 75 a4 ae e8 29 fb ef 39 8f 4f 55 67 00 02 
|<7>| 00ed - eb 30 82 02 e7 30 82 02 50 02 01 01 30 0d 06 09 
|<7>| 00ee - 2a 86 48 86 f7 0d 01 01 05 05 00 30 81 bb 31 24 
|<7>| 00ef - 30 22 06 03 55 04 07 13 1b 56 61 6c 69 43 65 72 
|<7>| 00f0 - 74 20 56 61 6c 69 64 61 74 69 6f 6e 20 4e 65 74 
|<7>| 00f1 - 77 6f 72 6b 31 17 30 15 06 03 55 04 0a 13 0e 56 
|<7>| 00f2 - 61 6c 69 43 65 72 74 2c 20 49 6e 63 2e 31 35 30 
|<7>| 00f3 - 33 06 03 55 04 0b 13 2c 56 61 6c 69 43 65 72 74 
|<7>| 00f4 - 20 43 6c 61 73 73 20 32 20 50 6f 6c 69 63 79 20 
|<7>| 00f5 - 56 61 6c 69 64 61 74 69 6f 6e 20 41 75 74 68 6f 
|<7>| 00f6 - 72 69 74 79 31 21 30 1f 06 03 55 04 03 13 18 68 
|<7>| 00f7 - 74 74 70 3a 2f 2f 77 77 77 2e 76 61 6c 69 63 65 
|<7>| 00f8 - 72 74 2e 63 6f 6d 2f 31 20 30 1e 06 09 2a 86 48 
|<7>| 00f9 - 86 f7 0d 01 09 01 16 11 69 6e 66 6f 40 76 61 6c 
|<7>| 00fa - 69 63 65 72 74 2e 63 6f 6d 30 1e 17 0d 39 39 30 
|<7>| 00fb - 36 32 36 30 30 31 39 35 34 5a 17 0d 31 39 30 36 
|<7>| 00fc - 32 36 30 30 31 39 35 34 5a 30 81 bb 31 24 30 22 
|<7>| 00fd - 06 03 55 04 07 13 1b 56 61 6c 69 43 65 72 74 20 
|<7>| 00fe - 56 61 6c 69 64 61 74 69 6f 6e 20 4e 65 74 77 6f 
|<7>| 00ff - 72 6b 31 17 30 15 06 03 55 04 0a 13 0e 56 61 6c 
|<7>| 0100 - 69 43 65 72 74 2c 20 49 6e 63 2e 31 35 30 33 06 
|<7>| 0101 - 03 55 04 0b 13 2c 56 61 6c 69 43 65 72 74 20 43 
|<7>| 0102 - 6c 61 73 73 20 32 20 50 6f 6c 69 63 79 20 56 61 
|<7>| 0103 - 6c 69 64 61 74 69 6f 6e 20 41 75 74 68 6f 72 69 
|<7>| 0104 - 74 79 31 21 30 1f 06 03 55 04 03 13 18 68 74 74 
|<7>| 0105 - 70 3a 2f 2f 77 77 77 2e 76 61 6c 69 63 65 72 74 
|<7>| 0106 - 2e 63 6f 6d 2f 31 20 30 1e 06 09 2a 86 48 86 f7 
|<7>| 0107 - 0d 01 09 01 16 11 69 6e 66 6f 40 76 61 6c 69 63 
|<7>| 0108 - 65 72 74 2e 63 6f 6d 30 81 9f 30 0d 06 09 2a 86 
|<7>| 0109 - 48 86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 
|<7>| 010a - 02 81 81 00 ce 3a 71 ca e5 ab c8 59 92 55 d7 ab 
|<7>| 010b - d8 74 0e f9 ee d9 f6 55 47 59 65 47 0e 05 55 dc 
|<7>| 010c - eb 98 36 3c 5c 53 5d d3 30 cf 38 ec bd 41 89 ed 
|<7>| 010d - 25 42 09 24 6b 0a 5e b3 7c dd 52 2d 4c e6 d4 d6 
|<7>| 010e - 7d 5a 59 a9 65 d4 49 13 2d 24 4d 1c 50 6f b5 c1 
|<7>| 010f - 85 54 3b fe 71 e4 d3 5c 42 f9 80 e0 91 1a 0a 5b 
|<7>| 0110 - 39 36 67 f3 3f 55 7c 1b 3f b4 5f 64 73 34 e3 b4 
|<7>| 0111 - 12 bf 87 64 f8 da 12 ff 37 27 c1 b3 43 bb ef 7b 
|<7>| 0112 - 6e 2e 69 f7 02 03 01 00 01 30 0d 06 09 2a 86 48 
|<7>| 0113 - 86 f7 0d 01 01 05 05 00 03 81 81 00 3b 7f 50 6f 
|<7>| 0114 - 6f 50 94 99 49 62 38 38 1f 4b f8 a5 c8 3e a7 82 
|<7>| 0115 - 81 f6 2b c7 e8 c5 ce e8 3a 10 82 cb 18 00 8e 4d 
|<7>| 0116 - bd a8 58 7f a1 79 00 b5 bb e9 8d af 41 d9 0f 34 
|<7>| 0117 - ee 21 81 19 a0 32 49 28 f4 c4 8e 56 d5 52 33 fd 
|<7>| 0118 - 50 d5 7e 99 6c 03 e4 c9 4c fc cb 6c ab 66 b3 4a 
|<7>| 0119 - 21 8c e5 b5 0c 32 3e 10 b2 cc 6c a1 dc 9a 98 4c 
|<7>| 011a - 02 5b f3 ce b9 9e a5 72 0e 4a b7 3f 3c e6 16 68 
|<7>| 011b - f8 be ed 74 4c bc 5b d5 62 1f 43 dd 
|<7>| RB: Have 5 bytes into buffer. Adding 4540 bytes.
|<7>| RB: Requested 4545 bytes
|<4>| REC[815ba90]: Decrypted Packet[1] Handshake(22) with length: 4540
|<6>| BUF[HSK]: Inserted 4540 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[815ba90]: CERTIFICATE was received [4540 bytes]
|<6>| BUF[REC][HD]: Read 4536 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 74 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 4536 bytes of Data
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 02 04 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[815ba90]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[815ba90]: Received Packet[2] Handshake(22) with length: 516
|<7>| READ: Got 516 bytes from 4
|<7>| READ: read 516 bytes from 4
|<7>| 0000 - 0d 00 01 fc 03 01 02 40 01 f6 00 cd 30 81 ca 31 
|<7>| 0001 - 0b 30 09 06 03 55 04 06 13 02 55 53 31 10 30 0e 
|<7>| 0002 - 06 03 55 04 08 13 07 41 72 69 7a 6f 6e 61 31 13 
|<7>| 0003 - 30 11 06 03 55 04 07 13 0a 53 63 6f 74 74 73 64 
|<7>| 0004 - 61 6c 65 31 1a 30 18 06 03 55 04 0a 13 11 47 6f 
|<7>| 0005 - 44 61 64 64 79 2e 63 6f 6d 2c 20 49 6e 63 2e 31 
|<7>| 0006 - 33 30 31 06 03 55 04 0b 13 2a 68 74 74 70 3a 2f 
|<7>| 0007 - 2f 63 65 72 74 69 66 69 63 61 74 65 73 2e 67 6f 
|<7>| 0008 - 64 61 64 64 79 2e 63 6f 6d 2f 72 65 70 6f 73 69 
|<7>| 0009 - 74 6f 72 79 31 30 30 2e 06 03 55 04 03 13 27 47 
|<7>| 000a - 6f 20 44 61 64 64 79 20 53 65 63 75 72 65 20 43 
|<7>| 000b - 65 72 74 69 66 69 63 61 74 69 6f 6e 20 41 75 74 
|<7>| 000c - 68 6f 72 69 74 79 31 11 30 0f 06 03 55 04 05 13 
|<7>| 000d - 08 30 37 39 36 39 32 38 37 00 65 30 63 31 0b 30 
|<7>| 000e - 09 06 03 55 04 06 13 02 55 53 31 21 30 1f 06 03 
|<7>| 000f - 55 04 0a 13 18 54 68 65 20 47 6f 20 44 61 64 64 
|<7>| 0010 - 79 20 47 72 6f 75 70 2c 20 49 6e 63 2e 31 31 30 
|<7>| 0011 - 2f 06 03 55 04 0b 13 28 47 6f 20 44 61 64 64 79 
|<7>| 0012 - 20 43 6c 61 73 73 20 32 20 43 65 72 74 69 66 69 
|<7>| 0013 - 63 61 74 69 6f 6e 20 41 75 74 68 6f 72 69 74 79 
|<7>| 0014 - 00 be 30 81 bb 31 24 30 22 06 03 55 04 07 13 1b 
|<7>| 0015 - 56 61 6c 69 43 65 72 74 20 56 61 6c 69 64 61 74 
|<7>| 0016 - 69 6f 6e 20 4e 65 74 77 6f 72 6b 31 17 30 15 06 
|<7>| 0017 - 03 55 04 0a 13 0e 56 61 6c 69 43 65 72 74 2c 20 
|<7>| 0018 - 49 6e 63 2e 31 35 30 33 06 03 55 04 0b 13 2c 56 
|<7>| 0019 - 61 6c 69 43 65 72 74 20 43 6c 61 73 73 20 32 20 
|<7>| 001a - 50 6f 6c 69 63 79 20 56 61 6c 69 64 61 74 69 6f 
|<7>| 001b - 6e 20 41 75 74 68 6f 72 69 74 79 31 21 30 1f 06 
|<7>| 001c - 03 55 04 03 13 18 68 74 74 70 3a 2f 2f 77 77 77 
|<7>| 001d - 2e 76 61 6c 69 63 65 72 74 2e 63 6f 6d 2f 31 20 
|<7>| 001e - 30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 69 
|<7>| 001f - 6e 66 6f 40 76 61 6c 69 63 65 72 74 2e 63 6f 6d 
|<7>| 0020 - 0e 00 00 00 
|<7>| RB: Have 5 bytes into buffer. Adding 516 bytes.
|<7>| RB: Requested 521 bytes
|<4>| REC[815ba90]: Decrypted Packet[2] Handshake(22) with length: 516
|<6>| BUF[HSK]: Inserted 516 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[815ba90]: CERTIFICATE REQUEST was received [512 bytes]
|<6>| BUF[REC][HD]: Read 508 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 4540 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 508 bytes of Data
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[815ba90]: SERVER HELLO DONE was received [4 bytes]
|<6>| BUF[HSK]: Peeked 512 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<3>| HSK[815ba90]: CERTIFICATE was send [7 bytes]
|<6>| BUF[HSK]: Peeked 4 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[815ba90]: Sending Packet[1] Handshake(22) with length: 7
|<7>| WRITE: Will write 12 bytes to 4.
|<7>| WRITE: wrote 12 bytes to 4. Left 0 bytes. Total 12 bytes.
|<7>| 0000 - 16 03 01 00 07 0b 00 00 03 00 00 00 
|<4>| REC[815ba90]: Sent Packet[2] Handshake(22) with length: 12
|<3>| HSK[815ba90]: CLIENT KEY EXCHANGE was send [134 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[815ba90]: Sending Packet[2] Handshake(22) with length: 134
|<7>| WRITE: Will write 139 bytes to 4.
|<7>| WRITE: wrote 139 bytes to 4. Left 0 bytes. Total 139 bytes.
|<7>| 0000 - 16 03 01 00 86 10 00 00 82 00 80 99 40 36 b5 18 
|<7>| 0001 - ca 1c 32 fc be 0f 29 57 04 35 8c 16 bf 1d 12 63 
|<7>| 0002 - 93 0d 0b 33 3d 9b c4 f5 c6 15 32 c8 2c c1 18 e8 
|<7>| 0003 - 60 c9 6c 9f a3 8b 4a 49 ed 8e 0e 8b 8b 6f 10 96 
|<7>| 0004 - fd a9 e4 41 3f c6 d4 1f 2b b1 5d 95 4e 9a ac 0b 
|<7>| 0005 - 50 af 76 0b 02 dc b9 20 06 83 26 7d dc 4d b8 10 
|<7>| 0006 - cf c2 5b 92 f1 59 3e ff 79 06 da a3 4b 97 b7 05 
|<7>| 0007 - 59 4b 44 d3 56 df f4 e4 e9 2a e2 6f 14 a1 06 90 
|<7>| 0008 - bd a4 0a e2 a8 c7 67 a9 5f 41 3c 
|<4>| REC[815ba90]: Sent Packet[3] Handshake(22) with length: 139
|<3>| REC[815ba90]: Sent ChangeCipherSpec
|<4>| REC[815ba90]: Sending Packet[3] Change Cipher Spec(20) with length: 1
|<7>| WRITE: Will write 6 bytes to 4.
|<7>| WRITE: wrote 6 bytes to 4. Left 0 bytes. Total 6 bytes.
|<7>| 0000 - 14 03 01 00 01 01 
|<4>| REC[815ba90]: Sent Packet[4] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[48]: 03027c48f48c7a8bd6c5ac1f18ec08ebdb7eb719403ef3b2e0b2b83d89ca65521be37da3b3f4d374d961318c83625b7d
|<9>| INT: CLIENT RANDOM[32]: 4992ea745a213d493dcdaa32ef8e58139c97df5c5081520d09002310deb14124
|<9>| INT: SERVER RANDOM[32]: 4992ea74b5c01d0de622feb3e7e84784fd4bd7d5fa26162f9ffb84b2031effdd
|<9>| INT: MASTER SECRET: af11f73bb70392c8016263ee4a1c9c805798c5adc6e054ccd2013a6cdf086259d7c1bf5ddf9434070eb1cd6a051fdb2c
|<9>| INT: KEY BLOCK[136]: 27a6661aae4dcec078decaf0d3e2a52971e251478eca8ff874c9297e38f5bccb
|<9>| INT: CLIENT WRITE KEY [32]: 37cc6e64550c3a2bce02e4e0b9ec89b1c36f8f3fb6b2a44707d6cf1636318fd5
|<9>| INT: SERVER WRITE KEY [32]: ebd8514d893f8a79650376687e487f2028e7c943004c44530c3a2450405c5c1a
|<3>| HSK[815ba90]: Cipher Suite: RSA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Initializing internal [write] cipher sessions
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<3>| HSK[815ba90]: FINISHED was send [16 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[815ba90]: Sending Packet[0] Handshake(22) with length: 16
|<7>| WRITE: Will write 181 bytes to 4.
|<7>| WRITE: wrote 181 bytes to 4. Left 0 bytes. Total 181 bytes.
|<7>| 0000 - 16 03 01 00 b0 42 06 c3 a0 b7 2b 37 b9 bc d4 a4 
|<7>| 0001 - dc 9b 7e 99 a6 be db 6a e0 ad db fc 27 f7 cd c4 
|<7>| 0002 - af f0 cd 66 61 1b 02 19 30 d4 d3 4d a5 52 ea c8 
|<7>| 0003 - 39 8e 81 54 fa 1b 6d b3 52 ac 63 55 a6 2d 8b ab 
|<7>| 0004 - 20 b7 e2 8f 04 fc 30 ea eb ff 32 9f b4 c1 07 3d 
|<7>| 0005 - 0b 8c 8c ea 9a c2 cd 0f c2 03 20 24 6e ec 47 2f 
|<7>| 0006 - 65 e7 36 5d 1e 6c 3d 5a be 3f d6 00 7d 94 d0 c7 
|<7>| 0007 - 15 04 b4 ca 0f e2 f5 1e b6 68 46 98 c6 c4 d4 59 
|<7>| 0008 - e0 88 fc 45 3a 2b a1 9c f8 7a 1b 6e ce 62 dd 9f 
|<7>| 0009 - 6d d0 91 da 03 a1 93 9f e0 46 7a 7e 53 b4 20 d6 
|<7>| 000a - 57 a8 1e 27 48 80 21 14 6f fd 96 13 6b 84 99 05 
|<7>| 000b - 9b 48 42 20 c2 
|<4>| REC[815ba90]: Sent Packet[1] Handshake(22) with length: 181
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 14 03 01 00 01 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[815ba90]: Expected Packet[3] Change Cipher Spec(20) with length: 1
|<4>| REC[815ba90]: Received Packet[3] Change Cipher Spec(20) with length: 1
|<7>| READ: Got 1 bytes from 4
|<7>| READ: read 1 bytes from 4
|<7>| 0000 - 01 
|<7>| RB: Have 5 bytes into buffer. Adding 1 bytes.
|<7>| RB: Requested 6 bytes
|<4>| REC[815ba90]: ChangeCipherSpec Packet was received
|<3>| HSK[815ba90]: Cipher Suite: RSA_AES_256_CBC_SHA1
|<3>| HSK[815ba90]: Initializing internal [read] cipher sessions
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 30 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[815ba90]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[815ba90]: Received Packet[0] Handshake(22) with length: 48
|<7>| READ: Got 48 bytes from 4
|<7>| READ: read 48 bytes from 4
|<7>| 0000 - 9f 8d 3e 39 92 a7 e3 56 3a fd fb df ae 13 36 ec 
|<7>| 0001 - b8 7e 1d 09 6b c8 50 57 de de 1f ce e8 6a b9 d2 
|<7>| 0002 - f2 56 89 47 d0 08 9d 0f d5 94 5a f9 6d 3a 7a fc 
|<7>| 0003 - 
|<7>| RB: Have 5 bytes into buffer. Adding 48 bytes.
|<7>| RB: Requested 53 bytes
|<4>| REC[815ba90]: Decrypted Packet[0] Handshake(22) with length: 16
|<6>| BUF[HSK]: Inserted 16 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[815ba90]: FINISHED was received [16 bytes]
|<6>| BUF[REC][HD]: Read 12 bytes of Data(22)
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 12 bytes of Data
|<6>| BUF[HSK]: Cleared Data from buffer
|<2>| ASSERT: ext_server_name.c:257
Processed 102 CA certificate(s).
Resolving 'ldap-3.teamgleim.com'...
Connecting to '172.17.1.13:636'...
- Successfully sent 0 certificate(s) to server.
- Certificate type: X.509
 - Got a certificate list of 4 certificates.

 - Certificate[0] info:

-----BEGIN CERTIFICATE-----
MIIE2TCCA8GgAwIBAgIEAOFYwDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMC
VVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNV
BAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlmaWNh
dGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5IFNl
Y3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5NjkyODcw
HhcNMDgxMjAxMjE1OTI5WhcNMTAwMTExMTg1OTM5WjBXMRgwFgYDVQQKEw8qLnRl
YW1nbGVpbS5jb20xGDAWBgNVBAMTDyoudGVhbWdsZWltLmNvbTEhMB8GA1UECxMY
RG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCtDmdg2hxeiuDjJ0kd+hR329g8dB8td6MkuDuF9fqyX8oFx0NN2tJWOEZc
KnjECWEMr7hQAan6Iv4cB/WxamLxUqrRtkbfTlLkzmkI4uDId6Zpj7ctSJuMNLuL
xIr1oGwJXaNDBRo9mJBEI5Z8YGS40CiQzw5g1Zj48cWFt5eWTQIDAQABo4IBuzCC
AbcwDwYDVR0TAQH/BAUwAwEBADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwDgYDVR0PAQH/BAQDAgWgMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwu
Z29kYWRkeS5jb20vZ2RzMS0wLmNybDBTBgNVHSAETDBKMEgGC2CGSAGG/W0BBxcB
MDkwNwYIKwYBBQUHAgEWK2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20v
cmVwb3NpdG9yeS8wgYAGCCsGAQUFBwEBBHQwcjAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuZ29kYWRkeS5jb20vMEoGCCsGAQUFBzAChj5odHRwOi8vY2VydGlmaWNh
dGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvZ2RfaW50ZXJtZWRpYXRlLmNydDAf
BgNVHSMEGDAWgBT9rGEyk2xF1uLuhV+auud2mWjM5zApBgNVHREEIjAggg8qLnRl
YW1nbGVpbS5jb22CDXRlYW1nbGVpbS5jb20wHQYDVR0OBBYEFH4kVg777PMdsWwy
MXzUWPlj41kzMA0GCSqGSIb3DQEBBQUAA4IBAQBcyNK5ai0yJe2r1bPwzFAGgm/0
CP+wVAIFUOLvleF6aCn0EiiHAOPF8TGIF0rkSlb8XvY9joyMcjsP12YQI0FArvvl
jwOFdBK9tVNxoW7mMZWWKONC2ZBFhlEGXZW5tgngyEjAdg+UtVAzGvEFEnLmHRHE
hSod3nJ2ZGnARuh1TJ21EfMIngR34A82QBrGY97G5tXODtE8f1TjHvaHoa02E1Jx
pjieH4KfBWQsia5HIPDVsJ7QFBIR9+NLpfUTXV+G7+xoZvu8Tt4m3++CMcjMO514
57uaMScrKg+nqDSuaAVQyiFXrGtSFxKPnK8aNPAsqFCAhITLlGkrXST3LK6X
-----END CERTIFICATE-----

 # The hostname in the certificate matches 'ldap-3.teamgleim.com'.
 # valid since: Mon Dec  1 16:59:29 EST 2008
 # expires at: Mon Jan 11 13:59:39 EST 2010
 # fingerprint: 61:9A:C8:DF:86:EA:C7:89:D7:90:2C:23:8E:E9:0A:B2
 # Subject's DN: O=*.teamgleim.com,CN=*.teamgleim.com,OU=Domain Control Validated
 # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287

 - Certificate[1] info:

-----BEGIN CERTIFICATE-----
MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVMx
ITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28g
RGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExMTYw
MTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
QXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWRkeS5j
b20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
b20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTtwY6vj3D3H
KrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqVTr9vcyOdQm
VZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aLGbqGmu75RpR
SgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo7RJlbmr2EkRT
cDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgWJCJjPOq8lh8BJ
6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAwEAAaOCATIwggEu
MB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVHSMEGDAWgBTSxLDS
kdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEB
BCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wRgYDVR0f
BD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBv
c2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVHSAAMDgwNgYIKwYBBQUH
AgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTAO
BgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBANKGwOy9+aG2Z+5mC6IG
OgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPIUyIXvJxwqoJKSQ3kbTJSMU
A2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL5CkKSkB2XIsKd83ASe8T+5o
0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9p0iRFEUOOjZv2kWzRaJBydTX
RE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsxuxN89txJx9OjxUUAiKEngHUuH
qDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZEjYx8WnM25sgVjOuH0aBsXBTWV
U+4=
-----END CERTIFICATE-----

 # valid since: Wed Nov 15 20:54:37 EST 2006
 # expires at: Sun Nov 15 20:54:37 EST 2026
 # fingerprint: D5:DF:85:B7:9A:52:87:D1:8C:D5:0F:90:23:2D:B5:34
 # Subject's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
 # Issuer's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority

 - Certificate[2] info:

-----BEGIN CERTIFICATE-----
MIIE+zCCBGSgAwIBAgICAQ0wDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1Zh
bGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIElu
Yy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24g
QXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAe
BgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTA0MDYyOTE3MDYyMFoX
DTI0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRoZSBHbyBE
YWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3MgMiBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgC
ggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCAPVYYYwhv
2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6wwdhFJ2+q
N1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXiEqITLdiO
r18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMYavx4A6lN
f4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+YihfukEH
U1jPEX44dMX4/7VpkI+EdOqXG68CAQOjggHhMIIB3TAdBgNVHQ4EFgQU0sSw0pHU
TBFxs2HLPaH+3ahq1OMwgdIGA1UdIwSByjCBx6GBwaSBvjCBuzEkMCIGA1UEBxMb
VmFsaUNlcnQgVmFsaWRhdGlvbiBOZXR3b3JrMRcwFQYDVQQKEw5WYWxpQ2VydCwg
SW5jLjE1MDMGA1UECxMsVmFsaUNlcnQgQ2xhc3MgMiBQb2xpY3kgVmFsaWRhdGlv
biBBdXRob3JpdHkxITAfBgNVBAMTGGh0dHA6Ly93d3cudmFsaWNlcnQuY29tLzEg
MB4GCSqGSIb3DQEJARYRaW5mb0B2YWxpY2VydC5jb22CAQEwDwYDVR0TAQH/BAUw
AwEB/zAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmdv
ZGFkZHkuY29tMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jZXJ0aWZpY2F0ZXMu
Z29kYWRkeS5jb20vcmVwb3NpdG9yeS9yb290LmNybDBLBgNVHSAERDBCMEAGBFUd
IAAwODA2BggrBgEFBQcCARYqaHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNv
bS9yZXBvc2l0b3J5MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOBgQC1
QPmnHfbq/qQaQlpE9xXUhUaJwL6e4+PrxeNYiY+Sn1eocSxI0YGyeR+sBjUZsE4O
WBsUs5iB0QQeyAfJg594RAoYC5jcdnplDQ1tgMQLARzLrUc+cb53S8wGd9D0Vmsf
SxOaFIqII6hR8INMqzW/Rn453HWkrugp++85j09VZw==
-----END CERTIFICATE-----

 # valid since: Tue Jun 29 13:06:20 EDT 2004
 # expires at: Sat Jun 29 13:06:20 EDT 2024
 # fingerprint: 82:BD:9A:0B:82:6A:0E:3E:91:AD:3E:27:04:2B:3F:45
 # Subject's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
 # Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info@valicert.com

 - Certificate[3] info:

-----BEGIN CERTIFICATE-----
MIIC5zCCAlACAQEwDQYJKoZIhvcNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0
IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAz
BgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9y
aXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG
9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE5MDYy
NjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29y
azEXMBUGA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENs
YXNzIDIgUG9saWN5IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRw
Oi8vd3d3LnZhbGljZXJ0LmNvbS8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNl
cnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOOnHK5avIWZJV16vY
dA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SVCCSRrCl6zfN1SLUzm1NZ9
WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwbP7RfZHM047QS
v4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADt/UG9v
UJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQC1u+mNr0HZDzTu
IYEZoDJJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMMj4QssxsodyamEwC
W/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0Pd
-----END CERTIFICATE-----

 # valid since: Fri Jun 25 20:19:54 EDT 1999
 # expires at: Tue Jun 25 20:19:54 EDT 2019
 # fingerprint: A9:23:75:9B:BA:49:36:6E:31:C2:DB:F2:E7:66:BA:87
 # Subject's DN: L=ValiCert Validation Network,O=V|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1127
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1127
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
aliCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info@valicert.com
 # Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info@valicert.com


- Peer's certificate is trusted
- Version: TLS 1.0
- Key Exchange: RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: DEFLATE
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1127
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1127
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
|<2>| ASSERT: dn.c:1122
- Handshake was completed

- Simple Client Mode:

|<4>| REC: Sending Alert[1|0] - Close notify
|<4>| REC[815ba90]: Sending Packet[1] Alert(21) with length: 2
|<7>| WRITE: Will write 101 bytes to 4.
|<7>| WRITE: wrote 101 bytes to 4. Left 0 bytes. Total 101 bytes.
|<7>| 0000 - 15 03 01 00 60 81 da 18 f5 5e 31 3b e1 1f 07 67 
|<7>| 0001 - 3e ff 18 88 7d ec 15 c6 ba 71 95 57 33 58 61 04 
|<7>| 0002 - 9d 2f 43 23 e0 30 97 3f 44 57 15 d5 fc 28 07 6e 
|<7>| 0003 - 9b 96 f2 28 fc 93 cc c0 1a 09 f4 fb 26 7c 9f 94 
|<7>| 0004 - 1c 7e c3 e6 df fc 1e cd bd f7 fd 43 d7 9d 8d 7f 
|<7>| 0005 - f9 33 23 e3 9b 1b c5 9c 3c 99 46 c9 61 29 02 98 
|<7>| 0006 - 3e 99 94 47 af 
|<4>| REC[815ba90]: Sent Packet[2] Alert(21) with length: 101
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 15 03 01 00 20 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[815ba90]: Expected Packet[1] Alert(21) with length: 0
|<4>| REC[815ba90]: Received Packet[1] Alert(21) with length: 32
|<7>| READ: Got 32 bytes from 4
|<7>| READ: read 32 bytes from 4
|<7>| 0000 - 97 33 c1 8e 41 fd 73 b3 48 86 21 10 44 22 e8 26 
|<7>| 0001 - 9f f3 81 eb 21 e3 68 5b 4b 30 71 d9 d1 e6 90 01 
|<7>| 0002 - 
|<7>| RB: Have 5 bytes into buffer. Adding 32 bytes.
|<7>| RB: Requested 37 bytes
|<4>| REC[815ba90]: Decrypted Packet[1] Alert(21) with length: 2
|<4>| REC[815ba90]: Alert[1|0] - Close notify - was received

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 15:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 15:36:14 GMT) Full text and rfc822 format available.

Message #20 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Wed, 11 Feb 2009 16:34:52 +0100
tags 514807 wontfix
thanks

Edward Allcutt <emallcut@gleim.com> writes:

> Simon Josefsson wrote:
>> Edward Allcutt <emallcut@gleim.com> writes:
>>
>>> Package: libgnutls13
>>> Version: 1.4.4-3+etch3
>>> Severity: important
>>>
>>> After the upgrade all embedded uses of LDAP fail with connection errors.
>>> On investigations these seem to be caused by certificate validation
>>> problems.
>>>
>>> This was first noticed with nss_ldap. After enabling debugging, running
>>> `getent group` produced error messages like:
>>> TLS certificate verification: depth: 0, err: 130, subject: <snip DN/>
>>> TLS certificate verification: Error, Unknown error
>>>
>>> Similar problems occur for pam_ldap and apache mod_authnz_ldap.
>>> Strangely, gnutls-cli verifies the server certificate with no problems.
>>>
>>> The error was first seen in a STARTTLS only configuration. I have since
>>> enabled ldaps to ease testing with gnutls-cli and confirmed it still
>>> affects nss_ldap and apache switched to ldaps.
>>>
>>> The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd
>>> expect gnutls-cli to complain if this were the issue.
>>
>> Please post output from 'gnutls-cli -p 663 your.ldap.server -d 4711
>> --print-cert' replacing your.ldap.server as appropriate.
> Output of `gnutls-cli -p ldaps -d 4711 --print-cert
> ldap-3.teamgleim.com 
>>out 2>&1` attached.
>
>> I suspect the problem is that you have a RSA-MD5 signature somewhere in
>> the certificate chain.
> Nope, already checked that... gnutls-cli does work after all. It's the
> other modules linked to libgnutls that are failing.

I believe the problem is that you have a V1 CA, which isn't permitted by
default by libgnutls.

The reason gnutls-cli doesn't complain is because it contains this code:

  /* there are some CAs that have a v1 certificate *%&@#*%&
   */
  gnutls_certificate_set_verify_flags (xcred,
				       GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);

I don't recommend doing the same in other applications, and we should
probably remove it from gnutls-cli too.  It may be useful to create a
parameter in other tools to enable the flag on a per-case basis, though.

For explanation of why V1 CA's are bad, see:

http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3365

I'm tagging this as wontfix since this is the documented and intended
behaviour.  I am sorry you had to notice it through an upgrade --
however the reason for the upgrade was to close this hole.

/Simon




Tags added: wontfix Request was from Simon Josefsson <simon@josefsson.org> to control@bugs.debian.org. (Wed, 11 Feb 2009 15:36:18 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 16:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 16:45:02 GMT) Full text and rfc822 format available.

Message #27 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: 514807@bugs.debian.org
Cc: Edward Allcutt <emallcut@gleim.com>
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Wed, 11 Feb 2009 17:42:21 +0100
Simon Josefsson <simon@josefsson.org> writes:

> The reason gnutls-cli doesn't complain is because it contains this code:
>
>   /* there are some CAs that have a v1 certificate *%&@#*%&
>    */
>   gnutls_certificate_set_verify_flags (xcred,
> 				       GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
>
> I don't recommend doing the same in other applications, and we should
> probably remove it from gnutls-cli too.  It may be useful to create a
> parameter in other tools to enable the flag on a per-case basis, though.

FWIW, I've worked on this in the gnutls 2.7.x branch.  gnutls-cli no
longer accepts V1 CAs by default, and there is a new --priority token
%VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it.  The
priority string approach is what we recommend applications expose to
their users for configuring GnuTLS internal details.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 16:54:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 16:54:07 GMT) Full text and rfc822 format available.

Message #32 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Wed, 11 Feb 2009 11:50:55 -0500
Simon Josefsson wrote:
> Simon Josefsson <simon@josefsson.org> writes:
> 
>> The reason gnutls-cli doesn't complain is because it contains this code:
>>
>>   /* there are some CAs that have a v1 certificate *%&@#*%&
>>    */
>>   gnutls_certificate_set_verify_flags (xcred,
>> 				       GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
>>
>> I don't recommend doing the same in other applications, and we should
>> probably remove it from gnutls-cli too.  It may be useful to create a
>> parameter in other tools to enable the flag on a per-case basis, though.
> 
> FWIW, I've worked on this in the gnutls 2.7.x branch.  gnutls-cli no
> longer accepts V1 CAs by default, and there is a new --priority token
> %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it.  The
> priority string approach is what we recommend applications expose to
> their users for configuring GnuTLS internal details.
That's all very well, but it's a rather big change in functionality for 
stable. I doubt it would be acceptable to patch all the relevant apps 
which assume that their list of trusted CAs will actually be used as such.

I can see the same change has been made in libgnutls26 in lenny. Should 
I file several RC bugs against the various modules affected? Bear in 
mind that their documented semantics are "a list of trusted CAs" so I 
think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be entirely appropriate 
in those cases.

Are there any apps which provide a list of trusted certs which should 
not all be considered trusted CAs? If not then perhaps 
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default.


-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 17:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 17:03:02 GMT) Full text and rfc822 format available.

Message #37 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Wed, 11 Feb 2009 12:00:59 -0500
retitle 514807 X.509v1 CA certs no longer trusted implicitly
thanks

Simon Josefsson wrote:
> Edward Allcutt <emallcut@gleim.com> writes:
>> Simon Josefsson wrote:
>>> I suspect the problem is that you have a RSA-MD5 signature somewhere in
>>> the certificate chain.
>> Nope, already checked that... gnutls-cli does work after all. It's the
>> other modules linked to libgnutls that are failing.
> 
> I believe the problem is that you have a V1 CA, which isn't permitted by
> default by libgnutls.
Only since this security update. I'm not saying that not trusting VA CAs 
shouldn't be the correct ideal behavior but it does seem very 
impractical right now. At the very least, can you postpone this change 
in functionality until lenny?

> I don't recommend doing the same in other applications, and we should
> probably remove it from gnutls-cli too.  It may be useful to create a
> parameter in other tools to enable the flag on a per-case basis, though.
Those applications which need to change their flags should of course be 
patched to do so, but not in stable. This seems like a change in the API 
of libgnutls. A change towards what is documented, granted, but a change 
nonetheless and away from what most applications seem to expect.

> For explanation of why V1 CA's are bad, see:
I understand that. The argument against 
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the argument 
against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak, especially 
given most applications give a list of trusted CAs, not non-CAs.

In addition, at least one very popular CA still seems to use a v1 cert 
as their root. They have new v3 root certs however these aren't included 
in ca-certificates until lenny.

> I'm tagging this as wontfix since this is the documented and intended
> behaviour.  I am sorry you had to notice it through an upgrade --
> however the reason for the upgrade was to close this hole.
Hmm, I thought the reason for the upgrade was to close this hole:
CVE-2008-4989. Fixing this deviation from documentation was just a 
side-effect.


-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 17:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 17:27:02 GMT) Full text and rfc822 format available.

Message #42 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: team@security.debian.org
Cc: 514807@bugs.debian.org
Subject: Regression in libgnutls security update
Date: Wed, 11 Feb 2009 12:26:23 -0500
Dear team,

The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at 
least in my opinion) this also subtly changed the semantics of trusted 
certificate lists. Version 1 X509 certificates in the list are no longer 
trusted as CAs unless an extra flag is set.

Several users of libgnutls (I've had the problem with nss_ldap, pam_ldap 
and apache2 mod_authnz_ldap) assume that all certificates in the list 
will be implicitly trusted. See #514807.

This change actually brings gnutls in line with its documentation, 
however it is still a change in behavior that I think is unsuitable for 
a stable security update.

I believe this is a significant regression in stable because at least 
one widely used CA (godaddy) still issues certificates with a chain 
ending in a v1 root (ValiCert Class 2). Godaddy appears to have a newer 
v3 root but I don't know how widely deployed this is. It is not in the 
etch ca-certificates package for example.

This also affects the same set of packages in lenny. I suppose the 
"right" way to solve it in lenny would be to patch all the libgnutls 
users which assume v1 CAs should be trusted. However I'm not sure of the 
reaction to filing several possibly RC bugs at this point.

-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 21:30:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 21:30:08 GMT) Full text and rfc822 format available.

Message #47 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 11 Feb 2009 22:27:13 +0100
Edward Allcutt <emallcut@gleim.com> writes:

> Dear team,
>
> The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at 
> least in my opinion) this also subtly changed the semantics of trusted 
> certificate lists. Version 1 X509 certificates in the list are no longer 
> trusted as CAs unless an extra flag is set.

The CVE-2008-4989 problem was that parts of the chain validation
algorithm was not executed properly.  Rejecting V1 CA's is one of those
parts, so I believe this is the intended consequence of the
CVE-2008-4989 fix.

> Several users of libgnutls (I've had the problem with nss_ldap, pam_ldap 
> and apache2 mod_authnz_ldap) assume that all certificates in the list 
> will be implicitly trusted. See #514807.
>
> This change actually brings gnutls in line with its documentation, 
> however it is still a change in behavior that I think is unsuitable for 
> a stable security update.
>
> I believe this is a significant regression in stable because at least 
> one widely used CA (godaddy) still issues certificates with a chain 
> ending in a v1 root (ValiCert Class 2). Godaddy appears to have a newer 
> v3 root but I don't know how widely deployed this is. It is not in the 
> etch ca-certificates package for example.
>
> This also affects the same set of packages in lenny. I suppose the 
> "right" way to solve it in lenny would be to patch all the libgnutls 
> users which assume v1 CAs should be trusted. However I'm not sure of the 
> reaction to filing several possibly RC bugs at this point.

This would leave users exposed to the security problems inherent with V1
CAs, which seems like a bad thing.  The proper fix is for users to move
away from all V1 CAs.

What can be done here is to produce better documentation, perhaps in
release notes.  People must be aware that trusting X.509 certificate
chains containing RSA-MD5 signatures or V1 CAs is insecure.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 21:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 21:57:02 GMT) Full text and rfc822 format available.

Message #52 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 11 Feb 2009 16:54:13 -0500
Simon Josefsson wrote:
> The CVE-2008-4989 problem was that parts of the chain validation
> algorithm was not executed properly.  Rejecting V1 CA's is one of those
> parts, so I believe this is the intended consequence of the
> CVE-2008-4989 fix.
I understood the primary problem to be that if the last (root) cert was 
self-signed then its signature of the next-to-last cert would not be 
checked. The other checks on the last cert would also not occur but 
these were relatively minor.

>> This change actually brings gnutls in line with its documentation, 
>> however it is still a change in behavior that I think is unsuitable for 
>> a stable security update.
This is my main emphasis. Whatever happens with lenny, changing this 
behavior in etch breaks existing setups.

>> This also affects the same set of packages in lenny. I suppose the 
>> "right" way to solve it in lenny would be to patch all the libgnutls 
>> users which assume v1 CAs should be trusted. However I'm not sure of the 
>> reaction to filing several possibly RC bugs at this point.
> 
> This would leave users exposed to the security problems inherent with V1
> CAs, which seems like a bad thing.  The proper fix is for users to move
> away from all V1 CAs.
What are the other significant problems with v1 CAs? Trusting a CA in a 
list of certs which is provided with the understanding that they are to 
be trusted doesn't seem a huge problem. (That being my interpretation of 
the semantics of the configuration of nss_ldap etc.)

> What can be done here is to produce better documentation, perhaps in
> release notes.  People must be aware that trusting X.509 certificate
> chains containing RSA-MD5 signatures or V1 CAs is insecure.
I don't disagree, but breaking working configurations, not all of which 
are as insecure as you fear, doesn't seem like the best plan, especially 
since there was no advance warning.

-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 23:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 23:03:04 GMT) Full text and rfc822 format available.

Message #57 received at 514807@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 00:01:13 +0100
* Edward Allcutt:

> I believe this is a significant regression in stable because at least
> one widely used CA (godaddy) still issues certificates with a chain
> ending in a v1 root (ValiCert Class 2).

Are we talking about this certificate?

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
        Validity
            Not Before: Jun 26 00:19:54 1999 GMT
            Not After : Jun 26 00:19:54 2019 GMT
        Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ce:3a:71:ca:e5:ab:c8:59:92:55:d7:ab:d8:74:
                    0e:f9:ee:d9:f6:55:47:59:65:47:0e:05:55:dc:eb:
                    98:36:3c:5c:53:5d:d3:30:cf:38:ec:bd:41:89:ed:
                    25:42:09:24:6b:0a:5e:b3:7c:dd:52:2d:4c:e6:d4:
                    d6:7d:5a:59:a9:65:d4:49:13:2d:24:4d:1c:50:6f:
                    b5:c1:85:54:3b:fe:71:e4:d3:5c:42:f9:80:e0:91:
                    1a:0a:5b:39:36:67:f3:3f:55:7c:1b:3f:b4:5f:64:
                    73:34:e3:b4:12:bf:87:64:f8:da:12:ff:37:27:c1:
                    b3:43:bb:ef:7b:6e:2e:69:f7
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption
        3b:7f:50:6f:6f:50:94:99:49:62:38:38:1f:4b:f8:a5:c8:3e:
        a7:82:81:f6:2b:c7:e8:c5:ce:e8:3a:10:82:cb:18:00:8e:4d:
        bd:a8:58:7f:a1:79:00:b5:bb:e9:8d:af:41:d9:0f:34:ee:21:
        81:19:a0:32:49:28:f4:c4:8e:56:d5:52:33:fd:50:d5:7e:99:
        6c:03:e4:c9:4c:fc:cb:6c:ab:66:b3:4a:21:8c:e5:b5:0c:32:
        3e:10:b2:cc:6c:a1:dc:9a:98:4c:02:5b:f3:ce:b9:9e:a5:72:
        0e:4a:b7:3f:3c:e6:16:68:f8:be:ed:74:4c:bc:5b:d5:62:1f:
        43:dd

It's not just a X.509v1 certificate.  It's ten years old, it's just
1024 bits, and ValiCert does not exist anymore as an organization
(thus the DN is invalid).

So while I understand that there is a problem (and we knew that there
was a trade-off to be made when releasing the update), I think this
particular root certificate is a bad example if you want to make a
point.

Simon, could we make the harmless variant (X.509v1 certificate set as
trusted is accepted as a root CA, but intermediate X.509v1
certificates aren't accepted) the default in etch?

> Godaddy appears to have a newer v3 root but I don't know how widely
> deployed this is. It is not in the etch ca-certificates package for
> example.

Which root are you referring to?




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 11 Feb 2009 23:06:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 11 Feb 2009 23:06:09 GMT) Full text and rfc822 format available.

Message #62 received at 514807@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: Simon Josefsson <simon@josefsson.org>
Cc: Edward Allcutt <emallcut@gleim.com>, 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 00:05:31 +0100
* Simon Josefsson:

> What can be done here is to produce better documentation, perhaps in
> release notes.  People must be aware that trusting X.509 certificate
> chains containing RSA-MD5 signatures or V1 CAs is insecure.

I think it is somewhat debatable if this also applies to the root CA
container, where the X.509 structure is just use as a transport for
key material.  The RSA-MD5 signature does not hurt there, and the DN
doesn't really matter, either.  The risk I see is that someone adds a
v1 *server* certificate to the trusted list, without realizing that it
will act as a *CA* certificate in this place.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 01:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 01:30:02 GMT) Full text and rfc822 format available.

Message #67 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Florian Weimer <fw@deneb.enyo.de>, 514807@bugs.debian.org
Cc: Simon Josefsson <simon@josefsson.org>, team@security.debian.org, Edward Allcutt <emallcut@gleim.com>
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 11 Feb 2009 20:27:57 -0500
[Message part 1 (text/plain, inline)]
On 02/11/2009 06:05 PM, Florian Weimer wrote:
> I think it is somewhat debatable if this also applies to the root CA
> container, where the X.509 structure is just use as a transport for
> key material.  The RSA-MD5 signature does not hurt there, and the DN
> doesn't really matter, either.  The risk I see is that someone adds a
> v1 *server* certificate to the trusted list, without realizing that it
> will act as a *CA* certificate in this place.

if the trusted certificate list were simply a "root CA container", then
i'd agree with you that V1 certificates are acceptable there.  But
that's not how the list is treated (or has ever been treated, to my
knowledge) in GnuTLS.

I think your last sentence makes it clear what the risks are.  GnuTLS
declares that the trusted certificate list is for holding *any type of*
trusted certificate.  If a given trusted certificate is a server
(end-entity) cert, then the remote party will be validated if it offers
that exact certificate (and if its name matches, and it can prove
possession of the corresponding secret key, presumably).  If a given
trusted certificate is a CA cert, then any certificate chain where the
end entity certificate matches the name of the remote party, and which
is rooted in the trusted CA cert will be accepted.

These are two different ways to use the trusted certificate list, and
they are distinguished by the *type* of certificate added to the list.
IIUC, Nikos' post indicates that there is no way to distinguish a V1 CA
certificate from an end-entity certificate.  So adding one to any
trusted store is inherently a risky activity, particularly if you're
adding a certificate that you expect to be an end-entity instead of a
CA.  GnuTLS has no way of knowing what the user's intent is here.

One option, of course, is to change the interface of GnuTLS to cleanly
separate out trusted peer certificates from trusted CA certificates in
the API.  This would permit users to specify how they intend to use a
given V1 cert.  Of course, this would also require an API change,
potentially an soname bump, etc.  In the absence of such a change, i
think it's safer to strongly deprecate V1 certificates (as has been
documented for years, if not enforcced), and let applications which
choose to treat the trusted certificate list solely as a CA store
specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

Regards,

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 09:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 09:33:02 GMT) Full text and rfc822 format available.

Message #72 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Edward Allcutt <emallcut@gleim.com>, 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 10:32:07 +0100
Florian Weimer <fw@deneb.enyo.de> writes:

> * Simon Josefsson:
>
>> What can be done here is to produce better documentation, perhaps in
>> release notes.  People must be aware that trusting X.509 certificate
>> chains containing RSA-MD5 signatures or V1 CAs is insecure.
>
> I think it is somewhat debatable if this also applies to the root CA
> container, where the X.509 structure is just use as a transport for
> key material.  The RSA-MD5 signature does not hurt there

Agreed.  That is how GnuTLS works now; it doesn't validate signatures in
trusted CA certificates.

> and the DN doesn't really matter, either.

The SubjectDN of the CA needs to match the IssuerDN of the next cert in
the chain.

> The risk I see is that someone adds a v1 *server* certificate to the
> trusted list, without realizing that it will act as a *CA* certificate
> in this place.

Exactly.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 09:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 09:42:04 GMT) Full text and rfc822 format available.

Message #77 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Florian Weimer <fw@deneb.enyo.de>, 514807@bugs.debian.org, team@security.debian.org, Edward Allcutt <emallcut@gleim.com>
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 10:37:44 +0100
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> One option, of course, is to change the interface of GnuTLS to cleanly
> separate out trusted peer certificates from trusted CA certificates in
> the API.  This would permit users to specify how they intend to use a
> given V1 cert.  Of course, this would also require an API change,
> potentially an soname bump, etc.  In the absence of such a change, i
> think it's safer to strongly deprecate V1 certificates (as has been
> documented for years, if not enforcced), and let applications which
> choose to treat the trusted certificate list solely as a CA store
> specify so explicitly with GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

Agreed.  V1 certificates should be deprecated.  I believe the best we
can achieve is to have a flag that allows callers to ignore the security
problem and accept V1 CAs.  But we have that, and have had it for a long
time.  The defaults should be secure.

I just added in GnuTLS v2.7.x a priority string flag for this, so if
applications are enhanced to use the priority string functionality (not
many do yet), users will be able to set the flag easily.  See NEWS:

** gnutls-cli: No longer accepts V1 CAs by default during X.509 chain verify.
Use --priority NORMAL:%VERIFY_ALLOW_X509_V1_CA_CRT to permit V1 CAs to
be used for chain verification.
...
** libgnutls: New priority strings %VERIFY_ALLOW_SIGN_RSA_MD5
** and %VERIFY_ALLOW_X509_V1_CA_CRT.
They can be used to override the default certificate chain validation
behaviour.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 09:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 09:54:03 GMT) Full text and rfc822 format available.

Message #82 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Thu, 12 Feb 2009 10:51:02 +0100
Edward Allcutt <emallcut@gleim.com> writes:

> retitle 514807 X.509v1 CA certs no longer trusted implicitly
> thanks
>
> Simon Josefsson wrote:
>> Edward Allcutt <emallcut@gleim.com> writes:
>>> Simon Josefsson wrote:
>>>> I suspect the problem is that you have a RSA-MD5 signature somewhere in
>>>> the certificate chain.
>>> Nope, already checked that... gnutls-cli does work after all. It's the
>>> other modules linked to libgnutls that are failing.
>>
>> I believe the problem is that you have a V1 CA, which isn't permitted by
>> default by libgnutls.
> Only since this security update. I'm not saying that not trusting VA
> CAs shouldn't be the correct ideal behavior but it does seem very
> impractical right now. At the very least, can you postpone this change
> in functionality until lenny?

That's not my call to make, but haven't this fixed been rolled out for
etch already?  Anyway, I believe it is the right fix too: otherwise etch
users are left vulnerable.

>> I don't recommend doing the same in other applications, and we should
>> probably remove it from gnutls-cli too.  It may be useful to create a
>> parameter in other tools to enable the flag on a per-case basis, though.
> Those applications which need to change their flags should of course
> be patched to do so, but not in stable. This seems like a change in
> the API of libgnutls. A change towards what is documented, granted,
> but a change nonetheless and away from what most applications seem to
> expect.

The behaviour you have been seeing has always been the documented and
intended behaviour.  The _implementation_ had a security bug, which
caused these certificate chains to be accepted anyway.

I agree that whether this is a ABI change or not is a rather subtle
issue.  The patch does change what the user is seeing, so there is some
externally visible change.  Usually that means the ABI version has to be
incremented.  On the other hand, _any_ security patch is in the same
situation.  When you close a security hole, you change how users can
interact with the software.  However I don't think a security patch is a
valid reason to bump the ABI version.  Debian etc need to be able to fix
security problems without bumping the ABI version of a library and
re-linking every application.

>> For explanation of why V1 CA's are bad, see:
> I understand that. The argument against
> GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the
> argument against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak,
> especially given most applications give a list of trusted CAs, not
> non-CAs.

I think the argument applies equally strong to both flags.  What
difference do you see?

I think we should not second guess that "most applications" only put CAs
in the trusted cert list when it is allowed to put EE certs there too.
It seems better to close the security holes.

> In addition, at least one very popular CA still seems to use a v1 cert
> as their root. They have new v3 root certs however these aren't
> included in ca-certificates until lenny.

These users are at risk regardless of what GnuTLS does, so I believe
some effort needs to go into fixing that.

>> I'm tagging this as wontfix since this is the documented and intended
>> behaviour.  I am sorry you had to notice it through an upgrade --
>> however the reason for the upgrade was to close this hole.
> Hmm, I thought the reason for the upgrade was to close this hole:
> CVE-2008-4989. Fixing this deviation from documentation was just a
> side-effect.

The CVE-2008-4989 problem was that the implementation deviated from the
documentation and intended behaviour: certificate chains weren't
validated properly enough.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 10:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 10:03:05 GMT) Full text and rfc822 format available.

Message #87 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Thu, 12 Feb 2009 11:01:19 +0100
Edward Allcutt <emallcut@gleim.com> writes:

> Simon Josefsson wrote:
>> Simon Josefsson <simon@josefsson.org> writes:
>>
>>> The reason gnutls-cli doesn't complain is because it contains this code:
>>>
>>>   /* there are some CAs that have a v1 certificate *%&@#*%&
>>>    */
>>>   gnutls_certificate_set_verify_flags (xcred,
>>> 				       GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
>>>
>>> I don't recommend doing the same in other applications, and we should
>>> probably remove it from gnutls-cli too.  It may be useful to create a
>>> parameter in other tools to enable the flag on a per-case basis, though.
>>
>> FWIW, I've worked on this in the gnutls 2.7.x branch.  gnutls-cli no
>> longer accepts V1 CAs by default, and there is a new --priority token
>> %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it.  The
>> priority string approach is what we recommend applications expose to
>> their users for configuring GnuTLS internal details.
> That's all very well, but it's a rather big change in functionality
> for stable. I doubt it would be acceptable to patch all the relevant
> apps which assume that their list of trusted CAs will actually be used
> as such.

Right, and I don't think these applications should be patched for two
reasons:

 1) That would open up for security problems.

 2) The GnuTLS documentation and API has a flag to enable V1 CAs to be
    valid as a CA root, and another flag to enable V1 CAs to be valid as
    an intermediate CA cert.  This implies the default is that the certs
    are intended to be disallowed.

> I can see the same change has been made in libgnutls26 in
> lenny. Should I file several RC bugs against the various modules
> affected? Bear in mind that their documented semantics are "a list of
> trusted CAs" so I think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be
> entirely appropriate in those cases.

The documentation should be updated for these applications, to clarify
that V1 CAs are not permitted by default.  Alternatively, the
application documentation could just refer to the GnuTLS manual for more
technical discussions like this.

To patch the applications to use the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
would expose users to security problems, so I don't think that is a good
idea.

> Are there any apps which provide a list of trusted certs which should
> not all be considered trusted CAs? If not then perhaps
> GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default.

Good question, I think this should be discussed with application
authors.  My hope is that we can convince them that V1 certificates
should not be trusted by default even if the user provided such a
certificate in their trust list, due to the security problem with V1
certs.

(Another hope is that application writers extend their code to call the
GnuTLS gnutls_priority_* functions, then users can supply a GnuTLS
priority string to the application to set the flag that will make it
possible to use a V1 CA again.  This provides a way to work-around the
problem. It also makes it possible for GnuTLS to introduce new flags to
work around future similar problems, without a need to patch
applications.)

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 10:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 10:30:06 GMT) Full text and rfc822 format available.

Message #92 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Edward Allcutt <emallcut@gleim.com>
Cc: 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 11:10:53 +0100
Edward Allcutt <emallcut@gleim.com> writes:

>> What can be done here is to produce better documentation, perhaps in
>> release notes.  People must be aware that trusting X.509 certificate
>> chains containing RSA-MD5 signatures or V1 CAs is insecure.
> I don't disagree, but breaking working configurations, not all of
> which are as insecure as you fear, doesn't seem like the best plan,
> especially since there was no advance warning.

I agree here that advance warning would have been good.  It was not
clear that the security problem that was fixed would have the
consequence you reported.  Now that you report it, and we analyze it, it
is clear that it is the intended consequence.

What are the possible channels to communicate to etch users that they
will get (intentional) errors from gnutls if they have 1) a V1
certificate in their certificate chains, or 2) have a RSA-MD2/MD5
signature in non-trusted certificates in their chain?  Perhaps a wiki
page will help to explain the issue better than this bug report e-mail
thread can do.

Hm.... possibly we could reconsider the default regarding V1 CAs for
etch: maybe you are right that the security problem is less problematic
than the solution.  Anyway, not my call to make, and I hope others can
use this discussion to evaluate what the best outcome is.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 10:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 10:42:02 GMT) Full text and rfc822 format available.

Message #97 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: 514807@bugs.debian.org, Edward Allcutt <emallcut@gleim.com>, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 11:40:28 +0100
Florian Weimer <fw@deneb.enyo.de> writes:

> Simon, could we make the harmless variant (X.509v1 certificate set as
> trusted is accepted as a root CA, but intermediate X.509v1
> certificates aren't accepted) the default in etch?

It is possible to allow V1 certs to be used as roots when validating
certificates by default, see untested patch below.  I wouldn't agree
that it is harmless: if there is a V1 end-entity certificate in the
trusted cert list, it will be usable as a CA certificate as well.

It may be that the practical problems are more important than the
potential security problem here, which would argue for using the patch.
I'm not the best person to judge that.  If the patch is used, some
documentation is needed to alert users that they should not put V1 end
entity certificates in their trusted ca list.  I wouldn't want to see
security incidents because of this trade-off.

RFC 5280 has discussion about this:

      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)

GnuTLS has no way to provide this out-of-band knowledge that a V1
certificate is a CA or not.

/Simon

diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
index 7872f20..fe7ad22 100644
--- a/lib/gnutls_cert.c
+++ b/lib/gnutls_cert.c
@@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t *
 
   (*res)->verify_bits = DEFAULT_VERIFY_BITS;
   (*res)->verify_depth = DEFAULT_VERIFY_DEPTH;
+  (*res)->verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
 
   return 0;
 }




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 12:18:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 12:18:13 GMT) Full text and rfc822 format available.

Message #102 received at 514807@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: Simon Josefsson <simon@josefsson.org>
Cc: Edward Allcutt <emallcut@gleim.com>, 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 13:16:07 +0100
* Simon Josefsson:

>> and the DN doesn't really matter, either.
>
> The SubjectDN of the CA needs to match the IssuerDN of the next cert in
> the chain.

I meant it in the sense that no root certificates are revoked after
the DN has become invalid because the denoted legal entity has ceased
to exist, or someone else has gained access to (or full control over)
the key material.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 15:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 15:03:02 GMT) Full text and rfc822 format available.

Message #107 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Thu, 12 Feb 2009 10:00:06 -0500
Florian Weimer wrote:
> * Edward Allcutt:
> 
>> I believe this is a significant regression in stable because at least
>> one widely used CA (godaddy) still issues certificates with a chain
>> ending in a v1 root (ValiCert Class 2).
> 
> Are we talking about this certificate?
> 
>         Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailAddress=info@valicert.com
That's the one.

> It's not just a X.509v1 certificate.  It's ten years old, it's just
> 1024 bits, and ValiCert does not exist anymore as an organization
> (thus the DN is invalid).
I'm not any happier about it than you are, but it seems godaddy are 
still issuing certs using that root.

> Simon, could we make the harmless variant (X.509v1 certificate set as
> trusted is accepted as a root CA, but intermediate X.509v1
> certificates aren't accepted) the default in etch?
> 
>> Godaddy appears to have a newer v3 root but I don't know how widely
>> deployed this is. It is not in the etch ca-certificates package for
>> example.
> 
> Which root are you referring to?
They're all available at https://certs.godaddy.com/Repository.go.

The main new one seems to be "Go Daddy Class 2 CA" which is in lenny 
ca-certificates as 
/usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt

The other new one is "Starfield Services" which is in lenny 
ca-certificates as 
/usr/share/ca-certificates/mozilla/Starfield_Class_2_CA.crt

Neither of these are in etch, and in fact neither of them seem to have 
the critical flag set for their "X509v3 Basic Constraints", which I've 
seen mentioned as an issue in other bug reports.

-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 15:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 15:18:02 GMT) Full text and rfc822 format available.

Message #112 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Thu, 12 Feb 2009 10:15:11 -0500
Simon Josefsson wrote:
> Edward Allcutt <emallcut@gleim.com> writes:
> 
>> retitle 514807 X.509v1 CA certs no longer trusted implicitly
>> thanks
This didn't appear to work for me. Would someone mind pointing out my 
mistake?

>> Simon Josefsson wrote:
>>> I believe the problem is that you have a V1 CA, which isn't permitted by
>>> default by libgnutls.
>> Only since this security update. I'm not saying that not trusting VA
>> CAs shouldn't be the correct ideal behavior but it does seem very
>> impractical right now. At the very least, can you postpone this change
>> in functionality until lenny?
> 
> That's not my call to make, but haven't this fixed been rolled out for
> etch already?  Anyway, I believe it is the right fix too: otherwise etch
> users are left vulnerable.
It has been release for etch, that's the main cause of my problems right 
now.

>>> I don't recommend doing the same in other applications, and we should
>>> probably remove it from gnutls-cli too.  It may be useful to create a
>>> parameter in other tools to enable the flag on a per-case basis, though.
>> Those applications which need to change their flags should of course
>> be patched to do so, but not in stable. This seems like a change in
>> the API of libgnutls. A change towards what is documented, granted,
>> but a change nonetheless and away from what most applications seem to
>> expect.
> 
> The behaviour you have been seeing has always been the documented and
> intended behaviour.  The _implementation_ had a security bug, which
> caused these certificate chains to be accepted anyway.
And several applications depended on this bug. If there are other 
applications which are actually more secure because of the change should 
we instead release security updates for the apps which were depending on 
 the bug? That seems acceptable to me. What does the security team 
think of this approach?

> I agree that whether this is a ABI change or not is a rather subtle
> issue.  The patch does change what the user is seeing, so there is some
> externally visible change.  Usually that means the ABI version has to be
> incremented.  On the other hand, _any_ security patch is in the same
> situation.  When you close a security hole, you change how users can
> interact with the software.  However I don't think a security patch is a
> valid reason to bump the ABI version.  Debian etc need to be able to fix
> security problems without bumping the ABI version of a library and
> re-linking every application.
I believe the ideal goal is that security patches don't have side 
effects that alter behavior unexpectedly (and hence no ABI/API change 
etc.). That constraint doesn't seem to have been met in this case, which 
is why I'm asking either for the patch to be modified (which seems 
simpler) or additional patches for all the affected apps.

I'm willing to try and produce patches for nss_ldap, pam_ldap and 
possibly apache but not to go hunting for other apps that might be affected.

>>> For explanation of why V1 CA's are bad, see:
>> I understand that. The argument against
>> GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the
>> argument against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak,
>> especially given most applications give a list of trusted CAs, not
>> non-CAs.
> 
> I think the argument applies equally strong to both flags.  What
> difference do you see?
In the applications I'm concerned with, the trusted list is explicitly 
used only for CA certs. Arguably they should be using 
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 12 Feb 2009 15:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 12 Feb 2009 15:24:02 GMT) Full text and rfc822 format available.

Message #117 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"
Date: Thu, 12 Feb 2009 10:21:07 -0500
Simon Josefsson wrote:
> Edward Allcutt <emallcut@gleim.com> writes:
>> That's all very well, but it's a rather big change in functionality
>> for stable. I doubt it would be acceptable to patch all the relevant
>> apps which assume that their list of trusted CAs will actually be used
>> as such.
> 
> Right, and I don't think these applications should be patched for two
> reasons:
> 
>  1) That would open up for security problems.
Are there any problems other than trusting the V1 certs as CAs? Because 
that's what the apps seem to expect.

>  2) The GnuTLS documentation and API has a flag to enable V1 CAs to be
>     valid as a CA root, and another flag to enable V1 CAs to be valid as
>     an intermediate CA cert.  This implies the default is that the certs
>     are intended to be disallowed.
I see that as a reason to patch, not a reason not to patch.

-- 
Edward Allcutt
Network Operations




Changed Bug title to `X.509v1 CA certs no longer trusted implicitly' from `libgnutls13: Security update causes "TLS certificate verification: Error, Unknown error"'. Request was from Florian Weimer <fw@deneb.enyo.de> to control@bugs.debian.org. (Thu, 12 Feb 2009 17:42:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Fri, 13 Feb 2009 19:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dominic Hargreaves <dom@earth.li>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 13 Feb 2009 19:03:05 GMT) Full text and rfc822 format available.

Message #124 received at 514807@bugs.debian.org (full text, mbox):

From: Dominic Hargreaves <dom@earth.li>
To: 514807@bugs.debian.org
Subject: Common root CA affected
Date: Fri, 13 Feb 2009 18:59:38 +0000
Since it hasn't been noted on the ticket (although there were mentions
of godaddy) the GTE Cybertrust Global Root CA is v1. and certificates
being still issued by at least one intermediate CA
("Cybertrust Educational CA") signed by this root.

This would appear to add weight to the argument that this is a serious
regression (in both etch and lenny).

Cheers,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Sat, 14 Feb 2009 21:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 14 Feb 2009 21:21:02 GMT) Full text and rfc822 format available.

Message #129 received at 514807@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org, Edward Allcutt <emallcut@gleim.com>, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Sat, 14 Feb 2009 22:19:00 +0100
* Simon Josefsson:

> What are the possible channels to communicate to etch users that they
> will get (intentional) errors from gnutls if they have 1) a V1
> certificate in their certificate chains, or 2) have a RSA-MD2/MD5
> signature in non-trusted certificates in their chain?  Perhaps a wiki
> page will help to explain the issue better than this bug report e-mail
> thread can do.

There doesn't seem to be industry consensus that X.509v1 root
certificates are a bad idea.  This means that users have little
leverage against CAs and server operators when confronted with
problematic certificates.

Furthermore, arguments based on the age of those certificates and the
resulting deficiencies are not that convincing because most root
certificates share one or more of those flaws.  The whole system is a
mess and has little to do with security (whatever it is).  The lack of
accountability and transparency (who owns which root certificates?)
and the disregard for cryptographic best practices (on key sizes and
rollovers) is quite stunning.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Mon, 16 Feb 2009 09:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 16 Feb 2009 09:51:03 GMT) Full text and rfc822 format available.

Message #134 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: 514807@bugs.debian.org, Edward Allcutt <emallcut@gleim.com>, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Mon, 16 Feb 2009 10:49:28 +0100
Florian Weimer <fw@deneb.enyo.de> writes:

> * Simon Josefsson:
>
>> What are the possible channels to communicate to etch users that they
>> will get (intentional) errors from gnutls if they have 1) a V1
>> certificate in their certificate chains, or 2) have a RSA-MD2/MD5
>> signature in non-trusted certificates in their chain?  Perhaps a wiki
>> page will help to explain the issue better than this bug report e-mail
>> thread can do.
>
> There doesn't seem to be industry consensus that X.509v1 root
> certificates are a bad idea.  This means that users have little
> leverage against CAs and server operators when confronted with
> problematic certificates.

Doesn't the same hold for RSA-MD5 signatures?  I'm not sure industry
consensus is a good measure here.  What we are relying on here is this
part of RFC 5280:

      (k)  If certificate i is a version 3 certificate, verify that the
           basicConstraints extension is present and that cA is set to
           TRUE.  (If certificate i is a version 1 or version 2
           certificate, then the application MUST either verify that
           certificate i is a CA certificate through out-of-band means
           or reject the certificate.  Conforming implementations may
           choose to reject all version 1 and version 2 intermediate
           certificates.)

GnuTLS doesn't have any API to provide this out-of-band information, so
we simply reject version 1 certificates (unless a flag is set).

Hm.  It is interesting that it says 'intermediate certificates' in the
last sentence.  I think this is mistaken, the part of the algorithm
applies to root certificates as well as end-entity certificates too.

> Furthermore, arguments based on the age of those certificates and the
> resulting deficiencies are not that convincing because most root
> certificates share one or more of those flaws.  The whole system is a
> mess and has little to do with security (whatever it is).  The lack of
> accountability and transparency (who owns which root certificates?)
> and the disregard for cryptographic best practices (on key sizes and
> rollovers) is quite stunning.

I completely agree.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Mon, 16 Feb 2009 18:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Benoit Branciard <Benoit.Branciard@univ-paris1.fr>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 16 Feb 2009 18:18:03 GMT) Full text and rfc822 format available.

Message #139 received at 514807@bugs.debian.org (full text, mbox):

From: Benoit Branciard <Benoit.Branciard@univ-paris1.fr>
To: 514807@bugs.debian.org
Subject: Re: Regression in libgnutls security update
Date: Mon, 16 Feb 2009 19:16:28 +0100
"GTE CyberTrust Global Root", which we happen to use widely in our 
institution, also is a version *1* x509 certificate.

So the libgnutls13 update broke several of our apps.

A quick search among the files in "ca-certificates" package shows up to 
20 version-1 certificates over a total of 102.

This is about 20% now-untrusted trustworthy root certificates, how could 
one regard this as being a harmless routine security update ?



-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 18 Feb 2009 00:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 18 Feb 2009 00:54:02 GMT) Full text and rfc822 format available.

Message #144 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: Florian Weimer <fw@deneb.enyo.de>, 514807@bugs.debian.org, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Tue, 17 Feb 2009 19:50:01 -0500
Simon Josefsson wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
>> There doesn't seem to be industry consensus that X.509v1 root
>> certificates are a bad idea.  This means that users have little
>> leverage against CAs and server operators when confronted with
>> problematic certificates.
> 
> Doesn't the same hold for RSA-MD5 signatures?  I'm not sure industry
> consensus is a good measure here.  What we are relying on here is this
> part of RFC 5280:
Considering that gnutls is aiming to interoperate with software and 
certificates produced by this "industry" (including OpenSSL and yaSSL) 
I'd say consensus is of the utmost importance. Despite what we may wish 
about conformance with published standards, the de facto standards don't 
exclude v1 certs or RSA-MD5, although the latter is certainly on the way 
out.

>       (k)  If certificate i is a version 3 certificate, verify that the
>            basicConstraints extension is present and that cA is set to
>            TRUE.  (If certificate i is a version 1 or version 2
>            certificate, then the application MUST either verify that
>            certificate i is a CA certificate through out-of-band means
>            or reject the certificate.  Conforming implementations may
>            choose to reject all version 1 and version 2 intermediate
>            certificates.)
> 
> GnuTLS doesn't have any API to provide this out-of-band information, so
> we simply reject version 1 certificates (unless a flag is set).
That seems like a good enough API to me. If the application is providing 
a list of CA certs then it should set the flag. That is, however 
unintentionally, an API change that shouldn't get pushed out silently as 
a stable security update.

> Hm.  It is interesting that it says 'intermediate certificates' in the
> last sentence.  I think this is mistaken, the part of the algorithm
> applies to root certificates as well as end-entity certificates too.
I think it is not mistaken. To me it looks precise: Intermediate 
certificates MAY be rejected but out-of-band-verified root certificates 
MAY NOT be.


I've tested the previously posted patch which adds 
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT to verify_flags. This restores the 
previous behavior of trusting v1 certs on the trusted list. I tested for 
the versions in etch (1.4.4-3+etch3) and lenny (2.6.4-1). Both nss_ldap 
and apache mod_ldap began working again with the patched libgnutls 
installed.

Is there anything else I can do to get this regression fixed at least in 
etch? I'd rather not maintain my own patched version of gnutls.

-- 
Edward Allcutt
Network Operations




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 18 Feb 2009 18:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Benoit Branciard <Benoit.Branciard@univ-paris1.fr>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 18 Feb 2009 18:54:02 GMT) Full text and rfc822 format available.

Message #149 received at 514807@bugs.debian.org (full text, mbox):

From: Benoit Branciard <Benoit.Branciard@univ-paris1.fr>
To: 514807@bugs.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 18 Feb 2009 19:50:42 +0100
I don't know if there is any hope you may reconsider your decision of 
not fixing this bug (from my point of view it make sense since it breaks 
20% of the certification authorities and introduces a significative 
change in application behaviour), but in case you do, here are my 
suggestions:

- maintain the ability to refuse v3 certs as AC if they do not have the 
"AC=TRUE" attribute, as the current fix does;

- but tolerate v1 certs as root ACs (which the current fix doesn't);

- refuse v1 certs as intermediate AC chains elements, since this appears 
to be the most dangerous threat: if an attacker gains access to an 
AC-validated v1 server cert, he could generate any AC-validated forged 
certs he wants using the robbed cert as an AC intermediate, and dupe 
many clients...

- put somewhere in the doc (maybe a debconf popup ?) that trusting (and 
using) v1 server certs is dangerous because they could be hijacked for 
use as ACs.

And let the API and clients change go for a further Debian release.


Regards,
Benoit Branciard

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 18 Feb 2009 21:15:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 18 Feb 2009 21:15:14 GMT) Full text and rfc822 format available.

Message #154 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Benoit Branciard <Benoit.Branciard@univ-paris1.fr>, 514807@bugs.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 18 Feb 2009 16:08:35 -0500
[Message part 1 (text/plain, inline)]
On 02/18/2009 01:50 PM, Benoit Branciard wrote:
> - maintain the ability to refuse v3 certs as AC if they do not have the 
> "AC=TRUE" attribute, as the current fix does;

I'm assuming you mean "CA" where you have "AC" here, right?  This is an
abbreviation for "Certificate Authority"

> - but tolerate v1 certs as root ACs (which the current fix doesn't);

This seems to be the only proposed change in functionality; basically
you're suggesting that GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set by
default.  This has the side effect that storing an out-of-band-verified
V1 peer (end-entity) certificate in the list of trusted certificates
would grant that end entity the ability to act as a CA.

> - refuse v1 certs as intermediate AC chains elements, since this appears 
> to be the most dangerous threat: if an attacker gains access to an 
> AC-validated v1 server cert, he could generate any AC-validated forged 
> certs he wants using the robbed cert as an AC intermediate, and dupe 
> many clients...

Agreed!

> - put somewhere in the doc (maybe a debconf popup ?) that trusting (and 
> using) v1 server certs is dangerous because they could be hijacked for 
> use as ACs.

I think this would be an abuse of debconf, particularly because the
warning would make more sense coming from the programs which are relying
on undocumented behavior of GnuTLS.

That is, programs which believe they are only storing trusted *CA*
certificates (and no peer certificates) in the list of trusted certs
should already be setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT in order to
indicate that preference to the library.  If they expect users to store
end entity certificates in the trusted list as well, then it would be
wise to alert those users, but this is a group that gnutls (as a
library) would have a hard time targetting.

I'm still torn about how to resolve this, fwiw, because i understand the
arguments from both sides.

Regards,

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 19 Feb 2009 01:15:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 19 Feb 2009 01:15:02 GMT) Full text and rfc822 format available.

Message #159 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Subject: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Wed, 18 Feb 2009 20:12:06 -0500
[Message part 1 (text/plain, inline)]
I've done a bit of research on this bug (dealing with V1 CA certificates
for gnutls in etch and/or lenny), and i do think that it is potentially
quite serious.

For example, the certificate used by https://mail.google.com/ appears to
be rooted in a v1 CA certificate:

0 dkg@pip:~$ echo | gnutls-cli --print-cert -p https mail.google.com |
> certtool -i | egrep '(Issuer|Subject):' | tr -d '\t'
Issuer: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
Subject: C=US,ST=California,L=Mountain View,O=Google Inc,CN=mail.google.com
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification
Authority
Subject: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
0 dkg@pip:~$ cd /usr/share/ca-certificates/mozilla/
0 dkg@pip:.../mozilla$ for foo in Verisign_Class_3_*.crt; do
>  printf "%s %d\n" $foo \
>  $(certtool -i <$foo | grep Version: | tr -d -c '13')
> done
Verisign_Class_3_Public_Primary_Certification_Authority.crt 1
Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt 1
Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt 1
0 dkg@pip:.../mozilla$


I have two alternate proposals that could be considered for etch and/or
Lenny.  So including the current state of the package and a full revert,
i see 4 options, and i'd be really happy to get feedback:

---------------

 0) Leave the library as it is; tools must use GnuTLS in the documented
way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
trust V1 certificates as certificate authorities.

 1) same as 0, but we special-case the limited set of publically-known
V1 CA certificates shipped in the ca-certificates package: if any of
those exact certificates are included in the trusted certificates list,
they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
is not set.

 2) same as 1, but rather than test exact matches against the specific
V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
if they meet the following requirements:

 a) The V1 certificate must not have any SubjectAltName extensions (i
think extensions in general require X.509v3, so this may be moot)

 b) If the V1 certificate Subject has a CN, the CN must not be a
syntactically-valid hostname.  For example, it should have spaces or
slashes or some other character that is forbidden A RR labels in DNS.

3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set (this may
mean that there is *no way* to turn this flag off -- hopefully people
who know gnutls better than myself can say if this is the case)

---------------

2a and 2b are intended to weed out certificates that were originally
issued with the intent of being an end-entity certificate for a host or
public service.  I tried to come up with some limit 2c, to reject
certificates that had been issued to non-host end entities (usually end
user client certificates), or to come up with some other matching rule
(e.g. "the Subject should contain the string 'Authority'") but i haven't
come up with anything satisfactory.  Suggestions are welcome.

These are listed in the order that i personally prefer them (that is, i
prefer 0 to the others, 1 over 2 and 3, and 2 over 3).  Do other people
have opinions here?  I have no code ready to implement 1 or 2, but i
would be happy to try to help folks generate or assess such a patch if
there are people willing to advocate for it.

Also: maybe we want to use one approach for etch, and a different one
for lenny.  With a well-thought out transition strategy, we could
minimize some of the potential pain.

Thoughts?

	--dkg

PS i really don't like the monopolistic/money-grubbing/unethical
behavior of most of the dominant commercial CAs; i feel like their
general motives are at odds with my personal goals of having end-to-end
secure connections available for any netizen.  So explicitly
grandfathering these groups into gnutls X.509 verification (option 1)
irks me not a little bit.  However, newer CAs can (and do) use V3 root
certs, so i don't feel that we would be further entrenching the
800-pound gorillas.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 19 Feb 2009 01:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 19 Feb 2009 01:24:02 GMT) Full text and rfc822 format available.

Message #164 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Subject: statistics about V1 CA Certs / general assumptions about the state of the network
Date: Wed, 18 Feb 2009 20:22:44 -0500
[Message part 1 (text/plain, inline)]
Hey folks--

a bit of background on the proposals i just made, to explain where i was
coming from:

Of the certificate authorities included in ca-certificates in lenny, 20
of them (14.1%) are v1 certs:

0 dkg@pip:~$ for foo in /usr/share/ca-certificates/*/*.crt; do
> certtool -i < "$foo" 2>/dev/null | grep Version
> done | sort | uniq -c
     20 	Version: 1
    122 	Version: 3
0 dkg@pip:~$

(there are 141 certificate files, but
/usr/share/ca-certificates/cacert.org/cacert.org.crt appears to contain
two (Version 3) certificates)


My proposals were based on a few assumptions.  I hope people will
vocally disagree with any of them that they think are wrong:

 * no one that we want to support is actively making new V1 Certs
intended for use as Certificate Authorities

 * People using private Certificate Authorities (i.e. not one of the big
public ones) tend in general to have more immediate access to the people
who control the relevant CAs.

 * CA certificates do not make use of the SubjectAltName extension (i
think the use of extensions might be a V3 feature anyway)

 * When CA Certificates have a CN in their Subject, it is *not* a valid
hostname.

Here is the list of V1 certificates:

0 dkg@pip:~$ for foo in /usr/share/ca-certificates/*/*.crt; do
>     if [ $(certtool -i < "$foo" 2>/dev/null |
>            grep Version: | tr -d -c '13') = 1 ] ; then
>      echo "$foo" | sed 'sx/usr/share/ca-certificates/xx'
>     fi
> done
mozilla/Digital_Signature_Trust_Co._Global_CA_2.crt
mozilla/Digital_Signature_Trust_Co._Global_CA_4.crt
mozilla/GTE_CyberTrust_Global_Root.crt
mozilla/GTE_CyberTrust_Root_CA.crt
mozilla/IPS_Servidores_root.crt
mozilla/RSA_Root_Certificate_1.crt
mozilla/ValiCert_Class_1_VA.crt
mozilla/ValiCert_Class_2_VA.crt
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_Class_4_Public_Primary_Certification_Authority_-_G2.crt
mozilla/Verisign_Class_4_Public_Primary_Certification_Authority_-_G3.crt
mozilla/Verisign_RSA_Secure_Server_CA.crt
0 dkg@pip:~$


Note that they're all from mozilla -- perhaps Mozilla has updated V3
certificates available from some/all of these CAs?  Verisign in
particular seems like a common culprit, but i can't find a fresh
download on their site, only fingerprints:

 https://www.verisign.com/repository/root.html

(is it even possible to transform a self-signed V1 cert into a
self-signed V3 cert?)

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 19 Feb 2009 21:45:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 19 Feb 2009 21:45:02 GMT) Full text and rfc822 format available.

Message #169 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Subject: Re: Bug#514807: statistics about V1 CA Certs / general assumptions about the state of the network
Date: Thu, 19 Feb 2009 22:42:43 +0100
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> (is it even possible to transform a self-signed V1 cert into a
> self-signed V3 cert?)

Not without re-signing it, which requires that certificates under the V1
cert won't chain back to the V3 cert.  That's by design.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Thu, 19 Feb 2009 22:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 19 Feb 2009 22:03:02 GMT) Full text and rfc822 format available.

Message #174 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Subject: Re: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Thu, 19 Feb 2009 23:02:12 +0100
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> For example, the certificate used by https://mail.google.com/ appears to
> be rooted in a v1 CA certificate:

Sigh, one would have hoped they had more clue.

>  0) Leave the library as it is; tools must use GnuTLS in the documented
> way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
> trust V1 certificates as certificate authorities.

This appears to be the Right Thing in general, and happens to also be
the simplest for me as GnuTLS maintainer, so it is what the upstream
GnuTLS package will use.  Or rather, it is what upstream will continue
to use, nothing in the documentation or intended behaviour has changed
in the last few years here.

I realize 0) may not be ideal from a systems perspective, in particular
for etch, but I'm not the best person to judge that.

>  1) same as 0, but we special-case the limited set of publically-known
> V1 CA certificates shipped in the ca-certificates package: if any of
> those exact certificates are included in the trusted certificates list,
> they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
> is not set.

Sounds pragmatic to me, although somewhat complex and I suspect we'll
see increasing requests to add to that list of exceptions.  I won't
produce a patch for this, it seems somewhat messy.

>  2) same as 1, but rather than test exact matches against the specific
> V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
> if they meet the following requirements:
>
>  a) The V1 certificate must not have any SubjectAltName extensions (i
> think extensions in general require X.509v3, so this may be moot)

I think you are correct, extensions require V3.  If there are any
extensions in a V1 cert, the cert should be rejected as invalid.

>  b) If the V1 certificate Subject has a CN, the CN must not be a
> syntactically-valid hostname.  For example, it should have spaces or
> slashes or some other character that is forbidden A RR labels in DNS.

Nice idea.  Sounds like it could work.

> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set

This is essentially the (untested) patch I proposed earlier.

> (this may mean that there is *no way* to turn this flag off --
> hopefully people who know gnutls better than myself can say if this is
> the case)

Applications can still call gnutls_certificate_set_verify_flags to
override the default.

While I was negative initially, I think there are some arguments for
this solution: it only enables V1 CAs that the user has _explicitly_
marked as trusted.  So the user could be informed through documentation
that if he adds V1 CAs as a trusted certs, they may lead to the security
problems with V1 certs.  I don't think we'll make this change upstream,
the risks associated doesn't seem negligible and I think V1 certs should
just go away.

> These are listed in the order that i personally prefer them (that is, i
> prefer 0 to the others, 1 over 2 and 3, and 2 over 3).  Do other people
> have opinions here?  I have no code ready to implement 1 or 2, but i
> would be happy to try to help folks generate or assess such a patch if
> there are people willing to advocate for it.
>
> Also: maybe we want to use one approach for etch, and a different one
> for lenny.  With a well-thought out transition strategy, we could
> minimize some of the potential pain.

Yes, I am beginning to think that possibly 3) may be appropriate for
etch, although I'm not sure how large of a problem this actually is.  If
it is not a large problem, maybe the answer should just be that they
need to renew their certificates with a better CA (or set up their own
CA).

Personally, I don't have time to develop and maintain patches for 1) or
2), and prefer choosing between 0) and 3) -- however, that opinion is
biased because I'm a gnutls developer rather than a debian developer
with a focus on the behaviour of the entire distribution.

> PS i really don't like the monopolistic/money-grubbing/unethical
> behavior of most of the dominant commercial CAs; i feel like their
> general motives are at odds with my personal goals of having end-to-end
> secure connections available for any netizen.  So explicitly
> grandfathering these groups into gnutls X.509 verification (option 1)
> irks me not a little bit.  However, newer CAs can (and do) use V3 root
> certs, so i don't feel that we would be further entrenching the
> 800-pound gorillas.

This is one of the reasons why I am for option 0) in the official GnuTLS
package, and strongly against any other option in the official package.
However, I realize that Debian may chose to patch the etch version of
GnuTLS differently.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Fri, 20 Feb 2009 01:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 20 Feb 2009 01:45:05 GMT) Full text and rfc822 format available.

Message #179 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Subject: Re: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Thu, 19 Feb 2009 20:44:06 -0500
[Message part 1 (text/plain, inline)]
Thanks for the feedback, Simon.

On 02/19/2009 05:02 PM, Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>
> This is essentially the (untested) patch I proposed earlier.
>
>> (this may mean that there is *no way* to turn this flag off --
>> hopefully people who know gnutls better than myself can say if this is
>> the case)
> 
> Applications can still call gnutls_certificate_set_verify_flags to
> override the default.

Good point.  I appreciate the clarification.

> While I was negative initially, I think there are some arguments for
> this solution: it only enables V1 CAs that the user has _explicitly_
> marked as trusted.  So the user could be informed through documentation
> that if he adds V1 CAs as a trusted certs, they may lead to the security
> problems with V1 certs.

My understanding is that the security problem is with adding V1
*end-entity* certificates to the trusted certificate list.  If you do
so, and we go with option 3, those EE certificates would be able to act
as certificate authorities because GnuTLS is unable to distinguish the
two classes of certificate.  But this doesn't indicate any problems with
adding V1 CA certs, only EE certs, no?  Are there other security
problems with V1 certificates for CAs?  I certainly don't understand all
the issues here as well as i wish i did.

I've added Nikos to the Cc list here in case he can clarify.

> I don't think we'll make this change upstream,
> the risks associated doesn't seem negligible and I think V1 certs should
> just go away.

I agree that V1 certs should just go away, if only to avoid this sort of
confusion.

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Fri, 20 Feb 2009 04:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 20 Feb 2009 04:51:02 GMT) Full text and rfc822 format available.

Message #184 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Subject: Re: Bug#514807: statistics about V1 CA Certs / general assumptions about the state of the network
Date: Thu, 19 Feb 2009 23:47:45 -0500
[Message part 1 (text/plain, inline)]
On 02/19/2009 04:42 PM, Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> 
>> (is it even possible to transform a self-signed V1 cert into a
>> self-signed V3 cert?)
> 
> Not without re-signing it, which requires that certificates under the V1
> cert won't chain back to the V3 cert.  That's by design.

Thanks for the response!  Can you point me to a reference, Simon?  I'd
like to understand the details better, but don't know where to begin.

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Sat, 21 Feb 2009 09:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 21 Feb 2009 09:36:02 GMT) Full text and rfc822 format available.

Message #189 received at 514807@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 514807@bugs.debian.org
Subject: Re: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Sat, 21 Feb 2009 10:16:23 +0100
On 2009-02-19 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> I've done a bit of research on this bug (dealing with V1 CA certificates
> for gnutls in etch and/or lenny), and i do think that it is potentially
> quite serious.

> For example, the certificate used by https://mail.google.com/ appears to
> be rooted in a v1 CA certificate:
[...]

Shouldn't gnutls-cli mark the certificate as unverified in that case?

----------------------
ametzler@argenau:/etc/ssl/certs$ gnutls-cli --x509cafile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem  -p https mail.google.com
Processed 1 CA certificate(s).
Resolving 'mail.google.com'...
Connecting to '66.249.91.83:443'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'mail.google.com'.
 # valid since: Fri May  2 18:32:54 CEST 2008
 # expires at: Sat May  2 18:32:54 CEST 2009
 # fingerprint: C3:36:8D:8C:7F:27:45:78:E5:A5:08:40:D3:EF:16:67
 # Subject's DN: C=US,ST=California,L=Mountain View,O=Google Inc,CN=mail.google.com
 # Issuer's DN: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA

 - Certificate[1] info:
 # valid since: Thu May 13 02:00:00 CEST 2004
 # expires at: Tue May 13 01:59:59 CEST 2014
 # fingerprint: 84:84:03:56:10:85:53:ED:9A:CA:60:B5:FA:99:D3:31
 # Subject's DN: C=ZA,O=Thawte Consulting (Pty) Ltd.,CN=Thawte SGC CA
 # Issuer's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority


- Peer's certificate is trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:
----------------------
ametzler@argenau:/etc/ssl/certs$ certtool -i < /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem
X.509 Certificate Information:
        Version: 1
        Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf
        Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
        Validity:
                Not Before: Mon Jan 29 00:00:00 UTC 1996
                Not After: Tue Aug 01 23:59:59 UTC 2028
[...]
        Signature Algorithm: RSA-MD2
warning: signed using a broken signature algorithm that can be forged.
[...]
----------------------

cu and- mystified -reas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Sat, 21 Feb 2009 11:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Nikos Mavrogiannopoulos <nmav@gnutls.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 21 Feb 2009 11:39:02 GMT) Full text and rfc822 format available.

Message #194 received at 514807@bugs.debian.org (full text, mbox):

From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Simon Josefsson <simon@josefsson.org>, 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Subject: Re: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Sat, 21 Feb 2009 13:36:10 +0200
Daniel Kahn Gillmor wrote:
> Thanks for the feedback, Simon.
> 
> On 02/19/2009 05:02 PM, Simon Josefsson wrote:
>> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
>> This is essentially the (untested) patch I proposed earlier.
>>
>>> (this may mean that there is *no way* to turn this flag off --
>>> hopefully people who know gnutls better than myself can say if this is
>>> the case)
>> Applications can still call gnutls_certificate_set_verify_flags to
>> override the default.
> 
> Good point.  I appreciate the clarification.
> 
>> While I was negative initially, I think there are some arguments for
>> this solution: it only enables V1 CAs that the user has _explicitly_
>> marked as trusted.  So the user could be informed through documentation
>> that if he adds V1 CAs as a trusted certs, they may lead to the security
>> problems with V1 certs.
> 
> My understanding is that the security problem is with adding V1
> *end-entity* certificates to the trusted certificate list.  If you do
> so, and we go with option 3, those EE certificates would be able to act
> as certificate authorities because GnuTLS is unable to distinguish the
> two classes of certificate.  But this doesn't indicate any problems with
> adding V1 CA certs, only EE certs, no?  

Indeed it affects end entity certs. I missed the discussion though I
understand it is about V1 CAs and being disabled by default. To be
honest although V1 certificates have been deprecated for more than a
decade CAs still use the V1 format for their certificates
(ca-certificates contains more than 10 of these).

However allowing them by default will make applications that rely on
adding end-entity certificates to the trusted certificate list insecure.
Thus it might be better for applications to explicitly enable this flag
if they do not use end-entity certificates there.

regards,
Nikos







Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Sat, 21 Feb 2009 19:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 21 Feb 2009 19:09:02 GMT) Full text and rfc822 format available.

Message #199 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Andreas Metzler <ametzler@downhill.at.eu.org>, 514807@bugs.debian.org
Subject: Re: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Sat, 21 Feb 2009 14:05:07 -0500
[Message part 1 (text/plain, inline)]
On 02/21/2009 04:16 AM, Andreas Metzler wrote:
> On 2009-02-19 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
>> I've done a bit of research on this bug (dealing with V1 CA certificates
>> for gnutls in etch and/or lenny), and i do think that it is potentially
>> quite serious.
> 
>> For example, the certificate used by https://mail.google.com/ appears to
>> be rooted in a v1 CA certificate:
> [...]
> 
> Shouldn't gnutls-cli mark the certificate as unverified in that case?

I believe gnutls-cli (appropriately) sets
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, because the semantics of its
invocation indicate that the certificates passed to the trusted store
are explicitly limited to CA certificates, and cannot possibly be
end-entity certificates.

> ametzler@argenau:/etc/ssl/certs$ gnutls-cli --x509cafile /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem  -p https mail.google.com
> Processed 1 CA certificate(s).

Your invocation told gnutls-cli that the certificate *was* a CA, so it
didn't have to guess whether you'd intended to use the attached
certificate as an end-entity certificate or not.

> cu and- mystified -reas

Hope this helps de-mystify somewhat.  Frankly, the V1 vs. V3 business
seems to me to be as much a problem with the GnuTLS API as it does with
the crusty old X.509v1 specification.  If GnuTLS certificate validation
were to use two different user-provided lists of certificates: one of
explicit CAs and one of potential peers (End Entities), this whole
discussion would be moot.

But of course, that's not what it does: applications provide the
verification code with a single list of pre-verified "trusted"
certificates, and GnuTLS distinguishes between End Entities and CAs
based on attributes *within* each cert in the list (and apparently V1
certs have no such distinguishing attributes).  In practice, i suspect
that many software authors who use GnuTLS haven't been aware of this
subtle distinction.

hth,

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Mon, 23 Feb 2009 16:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Edward Allcutt <emallcut@gleim.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 23 Feb 2009 16:42:05 GMT) Full text and rfc822 format available.

Message #204 received at 514807@bugs.debian.org (full text, mbox):

From: Edward Allcutt <emallcut@gleim.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 514807@bugs.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>, team@security.debian.org
Subject: Re: Bug#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Date: Mon, 23 Feb 2009 11:39:57 -0500
Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> 
>>  0) Leave the library as it is; tools must use GnuTLS in the documented
>> way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to
>> trust V1 certificates as certificate authorities.
> 
> This appears to be the Right Thing in general, and happens to also be
> the simplest for me as GnuTLS maintainer, so it is what the upstream
> GnuTLS package will use.  Or rather, it is what upstream will continue
> to use, nothing in the documentation or intended behaviour has changed
> in the last few years here.
This seems like a reasonable approach for upstream. For etch I believe 
it's too disruptive a change. For lenny... well I'm not sure. It may be 
possible to patch all the relevant apps for the first point release but:
a) I don't know if this is an acceptable "fix" now that lenny is stable.
b) A number of systems will break on upgrade until the fixes get out.
c) This should probably be added to the release notes, is that still 
possible?

>>  1) same as 0, but we special-case the limited set of publically-known
>> V1 CA certificates shipped in the ca-certificates package: if any of
>> those exact certificates are included in the trusted certificates list,
>> they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>> is not set.
> 
> Sounds pragmatic to me, although somewhat complex and I suspect we'll
> see increasing requests to add to that list of exceptions.  I won't
> produce a patch for this, it seems somewhat messy.
Too messy to get into etch certainly. Probably too messy for lenny too.

>>  2) same as 1, but rather than test exact matches against the specific
>> V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs
>> if they meet the following requirements:
Sounds reasonable, but I'm suspicious that these special case rules 
won't turn out to match the exact set of certs that we'd wish. It also 
sounds less messy than 1) but still adding a big chunk of new code.

>> 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set
> 
> This is essentially the (untested) patch I proposed earlier.
I have tested it. See 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=144;bug=514807

I've had no issues in my (limited) testing. I'm going to deploy it to a 
more heavily used system and see if anything crops up.

>> Also: maybe we want to use one approach for etch, and a different one
>> for lenny.  With a well-thought out transition strategy, we could
>> minimize some of the potential pain.
> 
> Yes, I am beginning to think that possibly 3) may be appropriate for
> etch, although I'm not sure how large of a problem this actually is.  If
> it is not a large problem, maybe the answer should just be that they
> need to renew their certificates with a better CA (or set up their own
> CA).
I think my views for etch are clear. I should add that this is not 
simply an issue with checking my own organization's certificates. Some 
libgnutls-linked apps need to verify 3rd-party certificates which I (and 
other Debian users) have no control over. I think mail.google.com was 
mentioned as an example.

For lenny I'm far more flexible. So long as the issue gets resolved 
(soon) I don't particularly mind how. Whether 0) or 3) or some 
compromise is chosen will depend more on what changes are acceptable now 
that lenny is stable.

>> PS i really don't like the monopolistic/money-grubbing/unethical
>> behavior of most of the dominant commercial CAs; i feel like their
>> general motives are at odds with my personal goals of having end-to-end
>> secure connections available for any netizen.  So explicitly
>> grandfathering these groups into gnutls X.509 verification (option 1)
>> irks me not a little bit.  However, newer CAs can (and do) use V3 root
>> certs, so i don't feel that we would be further entrenching the
>> 800-pound gorillas.
I don't disagree with your views of the big players, however I think 
this is a red herring. There does seem to be an ongoing transition away 
from v1 certs but it appears to be rather a slow process. I don't think 
GnuTLS is really in a position to strong-arm the big players into 
hurrying things along.

-- 
Edward Allcutt




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Tue, 24 Feb 2009 19:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 24 Feb 2009 19:57:02 GMT) Full text and rfc822 format available.

Message #209 received at 514807@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: Simon Josefsson <simon@josefsson.org>
Cc: 514807@bugs.debian.org, Edward Allcutt <emallcut@gleim.com>, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Tue, 24 Feb 2009 20:54:11 +0100
* Simon Josefsson:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> Simon, could we make the harmless variant (X.509v1 certificate set as
>> trusted is accepted as a root CA, but intermediate X.509v1
>> certificates aren't accepted) the default in etch?

> It may be that the practical problems are more important than the
> potential security problem here, which would argue for using the patch.

This seems to be the case.

I would like to apply the following patch to etch and lenny.  Any
objections?

> diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
> index 7872f20..fe7ad22 100644
> --- a/lib/gnutls_cert.c
> +++ b/lib/gnutls_cert.c
> @@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t *
>  
>    (*res)->verify_bits = DEFAULT_VERIFY_BITS;
>    (*res)->verify_depth = DEFAULT_VERIFY_DEPTH;
> +  (*res)->verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
>  
>    return 0;
>  }




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Tue, 24 Feb 2009 21:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 24 Feb 2009 21:12:02 GMT) Full text and rfc822 format available.

Message #214 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: 514807@bugs.debian.org, Edward Allcutt <emallcut@gleim.com>, team@security.debian.org
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Tue, 24 Feb 2009 22:11:22 +0100
Florian Weimer <fw@deneb.enyo.de> writes:

> * Simon Josefsson:
>
>> Florian Weimer <fw@deneb.enyo.de> writes:
>>
>>> Simon, could we make the harmless variant (X.509v1 certificate set as
>>> trusted is accepted as a root CA, but intermediate X.509v1
>>> certificates aren't accepted) the default in etch?
>
>> It may be that the practical problems are more important than the
>> potential security problem here, which would argue for using the patch.
>
> This seems to be the case.
>
> I would like to apply the following patch to etch and lenny.  Any
> objections?

No, but please try to make sure documentation is clear about what this
modification means for users and developers, since you are deviating
from upstream code.  The GnuTLS manual will not be consistent with the
behaviour people will see with GnuTLS on Debian.  Maybe README.Debian or
similar is a good place to put this information in?  NEWS.Debian?
changelog.Debian?  Or all of them.  Maybe point to a wiki page, that
will allow us to provide more information to users in the future.

/Simon

>> diff --git a/lib/gnutls_cert.c b/lib/gnutls_cert.c
>> index 7872f20..fe7ad22 100644
>> --- a/lib/gnutls_cert.c
>> +++ b/lib/gnutls_cert.c
>> @@ -280,6 +280,7 @@ gnutls_certificate_allocate_credentials (gnutls_certificate_credentials_t *
>>  
>>    (*res)->verify_bits = DEFAULT_VERIFY_BITS;
>>    (*res)->verify_depth = DEFAULT_VERIFY_DEPTH;
>> +  (*res)->verify_flags = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
>>  
>>    return 0;
>>  }




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 25 Feb 2009 18:24:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 25 Feb 2009 18:24:05 GMT) Full text and rfc822 format available.

Message #219 received at 514807@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Florian Weimer <fw@deneb.enyo.de>, 514807@bugs.debian.org
Cc: Simon Josefsson <simon@josefsson.org>, team@security.debian.org, Edward Allcutt <emallcut@gleim.com>
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 25 Feb 2009 19:20:32 +0100
On 2009-02-24 Florian Weimer <fw@deneb.enyo.de> wrote:
> * Simon Josefsson:
>> Florian Weimer <fw@deneb.enyo.de> writes:

>>> Simon, could we make the harmless variant (X.509v1 certificate set as
>>> trusted is accepted as a root CA, but intermediate X.509v1
>>> certificates aren't accepted) the default in etch?

>> It may be that the practical problems are more important than the
>> potential security problem here, which would argue for using the patch.

> This seems to be the case.

> I would like to apply the following patch to etch and lenny.  Any
> objections?
[...]

Hello,

I have been watching this play out since other people participating in
this thread are more knowledgable than me. From what I have read I
also think this might the right thing to do. Do you intend to push
this through security or proposed updates?

sid and squeeze are probably better of with following upstream's policy
on that.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Wed, 25 Feb 2009 19:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Florian Weimer <fw@deneb.enyo.de>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Wed, 25 Feb 2009 19:33:08 GMT) Full text and rfc822 format available.

Message #224 received at 514807@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: Andreas Metzler <ametzler@downhill.at.eu.org>
Cc: 514807@bugs.debian.org, Simon Josefsson <simon@josefsson.org>, team@security.debian.org, Edward Allcutt <emallcut@gleim.com>
Subject: Re: Bug#514807: Regression in libgnutls security update
Date: Wed, 25 Feb 2009 20:29:47 +0100
* Andreas Metzler:

> I have been watching this play out since other people participating in
> this thread are more knowledgable than me. From what I have read I
> also think this might the right thing to do. Do you intend to push
> this through security or proposed updates?

I've uploaded changed packages to the security queue, but only
containing Simon's patch, without any documentation updates.  We still
lack a fair number of builds for etch, so it's still time to do
something about the documentation.  It's less an issue for etch
because I doubt that there is a 1.4.4 version with different behavior,
but I see that updated documentation would make sense for the lenny
version.  If you want me to go ahead with the security errata, we can
still provide updated documentation via stable-proposed-updates.

I've got no particular opinion on the behavior for squeeze yet.  If we
can implement a more appropriate API (or even just a system-wide
configuration option), this would be fine.




Reply sent to Florian Weimer <fw@deneb.enyo.de>:
You have taken responsibility. (Fri, 13 Mar 2009 21:57:28 GMT) Full text and rfc822 format available.

Notification sent to Edward Allcutt <emallcut@gleim.com>:
Bug acknowledged by developer. (Fri, 13 Mar 2009 21:57:28 GMT) Full text and rfc822 format available.

Message #229 received at 514807-close@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: 514807-close@bugs.debian.org
Subject: Bug#514807: fixed in gnutls26 2.4.2-6+lenny1
Date: Fri, 13 Mar 2009 20:00:48 +0000
Source: gnutls26
Source-Version: 2.4.2-6+lenny1

We believe that the bug you reported is fixed in the latest version of
gnutls26, which is due to be installed in the Debian FTP archive:

gnutls-bin_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/gnutls-bin_2.4.2-6+lenny1_amd64.deb
gnutls-doc_2.4.2-6+lenny1_all.deb
  to pool/main/g/gnutls26/gnutls-doc_2.4.2-6+lenny1_all.deb
gnutls26_2.4.2-6+lenny1.diff.gz
  to pool/main/g/gnutls26/gnutls26_2.4.2-6+lenny1.diff.gz
gnutls26_2.4.2-6+lenny1.dsc
  to pool/main/g/gnutls26/gnutls26_2.4.2-6+lenny1.dsc
guile-gnutls_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/guile-gnutls_2.4.2-6+lenny1_amd64.deb
libgnutls-dev_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/libgnutls-dev_2.4.2-6+lenny1_amd64.deb
libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
libgnutls26_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/libgnutls26_2.4.2-6+lenny1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 514807@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Weimer <fw@deneb.enyo.de> (supplier of updated gnutls26 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.8
Date: Mon, 23 Feb 2009 21:56:10 +0100
Source: gnutls26
Binary: libgnutls-dev libgnutls26 libgnutls26-dbg gnutls-bin gnutls-doc guile-gnutls
Architecture: source all amd64
Version: 2.4.2-6+lenny1
Distribution: stable-security
Urgency: high
Maintainer: Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Changed-By: Florian Weimer <fw@deneb.enyo.de>
Description: 
 gnutls-bin - the GNU TLS library - commandline utilities
 gnutls-doc - the GNU TLS library - documentation and examples
 guile-gnutls - the GNU TLS library - GNU Guile bindings
 libgnutls-dev - the GNU TLS library - development files
 libgnutls26 - the GNU TLS library - runtime library
 libgnutls26-dbg - GNU TLS library - debugger symbols
Closes: 514735 514807
Changes: 
 gnutls26 (2.4.2-6+lenny1) stable-security; urgency=high
 .
   * Add patch from Simon Josefsson to reenable X.509v1 support for root
     CAs.  Closes: #514807, #514735.
Checksums-Sha1: 
 37f83316cb8e928e03451cccaa7fe5396eb08d36 1904 gnutls26_2.4.2-6+lenny1.dsc
 e6df35963239c18cff3e5072f172898bb4400ca5 5984345 gnutls26_2.4.2.orig.tar.gz
 1528851268eb498e1a25522be696bcd76b038e66 20298 gnutls26_2.4.2-6+lenny1.diff.gz
 29f64bc9ff24e9ae115d92998171fed28d4b5c3d 2751582 gnutls-doc_2.4.2-6+lenny1_all.deb
 dd6ee2fe6d2fda09f0f76de7b3b70c2d83b673b7 586148 libgnutls-dev_2.4.2-6+lenny1_amd64.deb
 d8af7f1546c07c856efc532db2327411faa721a0 505908 libgnutls26_2.4.2-6+lenny1_amd64.deb
 d065535756478d9c50e4c00ed0e7acb4074af522 1136770 libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
 0f25817b4470f512b1a832c78f9380563cccd5e2 285624 gnutls-bin_2.4.2-6+lenny1_amd64.deb
 baf3bbbbf03fe236923c5376650d3c15f3507793 215802 guile-gnutls_2.4.2-6+lenny1_amd64.deb
Checksums-Sha256: 
 4f4adcac881b3f963d0f389bc317502c03f664b868521ef735d5bf60611cd79a 1904 gnutls26_2.4.2-6+lenny1.dsc
 ab3c3ef1a55ab0a4dbcd8a5013f9c2ddf0ba98081349bc8f64b53eb1720b3aca 5984345 gnutls26_2.4.2.orig.tar.gz
 96a7ad14052427c3100a6c71c7371f20ba9772a5e600fef70d8cd8687076de93 20298 gnutls26_2.4.2-6+lenny1.diff.gz
 96a9654f755e217694e0267e1552a96f5ae04eeb580396959c25319b65c852dd 2751582 gnutls-doc_2.4.2-6+lenny1_all.deb
 9d63f910ca6ca06510a4304604d821fd9dda16cd5791ad05aa68f70c1ae46f2c 586148 libgnutls-dev_2.4.2-6+lenny1_amd64.deb
 08ac583df22aa5decd8feb1e611381d0667d5603262161e78b77548c5d94353e 505908 libgnutls26_2.4.2-6+lenny1_amd64.deb
 80f9ca88143fe518d22315b1e4cfa0a6de10dd7fe9faff5d2a12699587067910 1136770 libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
 9439785c969807f12306db80f0a94434455e8c2dad6e0976e3f7d924754410d3 285624 gnutls-bin_2.4.2-6+lenny1_amd64.deb
 b00b53913b8bea1dd39457392814bd6783000369cbdb3f9609da9d6df63afae4 215802 guile-gnutls_2.4.2-6+lenny1_amd64.deb
Files: 
 3410a16fe6f7dcce25f1c55946357dc6 1904 devel optional gnutls26_2.4.2-6+lenny1.dsc
 8fea7c57f4badcafcd31eb0f981f169a 5984345 devel optional gnutls26_2.4.2.orig.tar.gz
 e6bb02c6522cf6b6842e0b38c633a087 20298 devel optional gnutls26_2.4.2-6+lenny1.diff.gz
 9c920495e79d03f377d96ed94915a378 2751582 doc optional gnutls-doc_2.4.2-6+lenny1_all.deb
 c95ef6b6b2af28fc7a8bfebe60703092 586148 libdevel optional libgnutls-dev_2.4.2-6+lenny1_amd64.deb
 e560d1c33d60f9b8c9748d6f70a2ccbc 505908 libs important libgnutls26_2.4.2-6+lenny1_amd64.deb
 db82f80deb858958e98ff3fd1422dd2c 1136770 devel extra libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
 48f7e580aed0f99e92eeee384c97cc21 285624 net optional gnutls-bin_2.4.2-6+lenny1_amd64.deb
 2ed45e368aabeb938f90fee4b3cf4668 215802 libs optional guile-gnutls_2.4.2-6+lenny1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJow/gAAoJEL97/wQC1SS+cCsH/2qdMKNtqSMfUHfPwZPtPDlv
7PeFbkqhUxXImZXGA28vlNzIlvLzuIg1GOKw3ksVUa/OFn2m/IUw5R4dC9qjBGta
FKXaXuVw3IM7wtGX3pfnl3rShCewDDGuRLXFcAtdYHly68nwQfN2Sg7xddx5jNw9
v8Egzov+0dI48t1LuERtVBSAMPUrqT3oBRQEscjLr5KdiqPKiFPpmvc6h/j8WvC2
xhXoKQQAtZGcS5wA0/nU2YSd5112daCqQtGyGk3mHEI3+qIlyJ4M+qdmroWt7r9z
G0NgMvaWQ01Py1fhDZ0wh9Ny0nhqdr7myySz0S8xs2UutkIxErPEw0CB6L9aHDI=
=JMKM
-----END PGP SIGNATURE-----





Reply sent to Florian Weimer <fw@deneb.enyo.de>:
You have taken responsibility. (Fri, 13 Mar 2009 21:57:29 GMT) Full text and rfc822 format available.

Notification sent to Edward Allcutt <emallcut@gleim.com>:
Bug acknowledged by developer. (Fri, 13 Mar 2009 21:57:30 GMT) Full text and rfc822 format available.

Message #234 received at 514807-close@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: 514807-close@bugs.debian.org
Subject: Bug#514807: fixed in gnutls13 1.4.4-3+etch4
Date: Fri, 13 Mar 2009 20:01:20 +0000
Source: gnutls13
Source-Version: 1.4.4-3+etch4

We believe that the bug you reported is fixed in the latest version of
gnutls13, which is due to be installed in the Debian FTP archive:

gnutls-bin_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/gnutls-bin_1.4.4-3+etch4_amd64.deb
gnutls-doc_1.4.4-3+etch4_all.deb
  to pool/main/g/gnutls13/gnutls-doc_1.4.4-3+etch4_all.deb
gnutls13_1.4.4-3+etch4.diff.gz
  to pool/main/g/gnutls13/gnutls13_1.4.4-3+etch4.diff.gz
gnutls13_1.4.4-3+etch4.dsc
  to pool/main/g/gnutls13/gnutls13_1.4.4-3+etch4.dsc
libgnutls-dev_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/libgnutls-dev_1.4.4-3+etch4_amd64.deb
libgnutls13-dbg_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/libgnutls13-dbg_1.4.4-3+etch4_amd64.deb
libgnutls13_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/libgnutls13_1.4.4-3+etch4_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 514807@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Weimer <fw@deneb.enyo.de> (supplier of updated gnutls13 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.7
Date: Mon, 23 Feb 2009 21:45:41 +0100
Source: gnutls13
Binary: libgnutls-dev libgnutls13 gnutls-bin gnutls-doc libgnutls13-dbg
Architecture: source amd64 all
Version: 1.4.4-3+etch4
Distribution: oldstable-security
Urgency: high
Maintainer: Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Changed-By: Florian Weimer <fw@deneb.enyo.de>
Description: 
 gnutls-bin - the GNU TLS library - commandline utilities
 gnutls-doc - the GNU TLS library - documentation and examples
 libgnutls-dev - the GNU TLS library - development files
 libgnutls13 - the GNU TLS library - runtime library
 libgnutls13-dbg - GNU TLS library - debugger symbols
Closes: 514735 514807
Changes: 
 gnutls13 (1.4.4-3+etch4) oldstable-security; urgency=high
 .
   * Add patch from Simon Josefsson to reenable X.509v1 support for root
     CAs.  Closes: #514807, #514735.
Files: 
 229287edc239349b5014f2d31890912a 1259 devel optional gnutls13_1.4.4-3+etch4.dsc
 fd8b423c5f4a11af2c60eda979df9b00 21337 devel optional gnutls13_1.4.4-3+etch4.diff.gz
 4809b5a15fa8554dbf0cc7331ed0128a 2305134 doc optional gnutls-doc_1.4.4-3+etch4_all.deb
 c6aa74857be44068f4e0d1f1322e30af 389308 libdevel optional libgnutls-dev_1.4.4-3+etch4_amd64.deb
 9ea77f3b9e6fb21d899786f0f14d714c 314864 libs important libgnutls13_1.4.4-3+etch4_amd64.deb
 223f5f50236b96400405a7c2ea4af3b9 539598 devel extra libgnutls13-dbg_1.4.4-3+etch4_amd64.deb
 8e1dae14f9ea57b112fe260b1b0d4133 183034 net optional gnutls-bin_1.4.4-3+etch4_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJow1dAAoJEL97/wQC1SS+lA0IAKVXDbwicFRiljle1NcCaMA2
q3QF0c7+EPsYHYSJIbh64HeyNybMZow+dgimuQlbU1UbGvzgDRMM1GdtD1SNz3Xo
EC6HJPv0ghtXNOAjHhCGChBddwtuQs2SVTy4QgvDsJ9w/jPO34Cj0iR4pJ4mVfG/
lcjUzBLDQQr8wjJAus1+yc7qKf2mfCH+zigY/V1Hwh/rjvuZ9rqJGQvqW+MakgXn
cww0Yptosnxq9q2XWZE6/RKJ8gmq0jwASgAcxzesStUot5mo1eSjFBMBJMf6hvI8
b7M7neci+3B530rP8icihp9eNNG3VGa5jZT7hmHjV8JuSkXicRo6J8LOR+bUi/0=
=gtGI
-----END PGP SIGNATURE-----





Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Mon, 23 Mar 2009 12:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Josefsson <simon@josefsson.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 23 Mar 2009 12:27:03 GMT) Full text and rfc822 format available.

Message #239 received at 514807@bugs.debian.org (full text, mbox):

From: Simon Josefsson <simon@josefsson.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: 514807@bugs.debian.org
Subject: Re: Bug#514807: statistics about V1 CA Certs / general assumptions about the state of the network
Date: Mon, 23 Mar 2009 13:24:42 +0100
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> On 02/19/2009 04:42 PM, Simon Josefsson wrote:
>> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>> 
>>> (is it even possible to transform a self-signed V1 cert into a
>>> self-signed V3 cert?)
>> 
>> Not without re-signing it, which requires that certificates under the V1
>> cert won't chain back to the V3 cert.  That's by design.
>
> Thanks for the response!  Can you point me to a reference, Simon?  I'd
> like to understand the details better, but don't know where to begin.

Check RFC 5280: the TBSCertificate structure contains the version, and
the structure is signed, so to change a V1 cert to V3 cert you'd have to
re-sign it.  That's possible of course, but you'll need the private key.
And in that case, you'd might as well generate a new V3 certificate
rather than converting information from an old one.

I'm not sure what I meant above though: if the public key is the same,
certs signed by the V1 cert may correctly chain back to the V3 cert.

/Simon




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#514807; Package libgnutls13. (Mon, 23 Mar 2009 14:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 23 Mar 2009 14:27:04 GMT) Full text and rfc822 format available.

Message #244 received at 514807@bugs.debian.org (full text, mbox):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Simon Josefsson <simon@josefsson.org>, 514807@bugs.debian.org
Subject: Re: Bug#514807: statistics about V1 CA Certs / general assumptions about the state of the network
Date: Mon, 23 Mar 2009 10:25:25 -0400
[Message part 1 (text/plain, inline)]
On 03/23/2009 08:24 AM, Simon Josefsson wrote:
> Check RFC 5280: the TBSCertificate structure contains the version, and
> the structure is signed, so to change a V1 cert to V3 cert you'd have to
> re-sign it.  That's possible of course, but you'll need the private key.
> And in that case, you'd might as well generate a new V3 certificate
> rather than converting information from an old one.

OK, that makes sense.  But the holder of the secret key corresponding to
a V1 certificate could very well create a matching V3 certificate...

> I'm not sure what I meant above though: if the public key is the same,
> certs signed by the V1 cert may correctly chain back to the V3 cert.

This is the interesting bit, i think.  If we could sort this out, test
it, and document how it, then we could provide a series of steps for CAs
to follow if they wanted to bring their root certificates into the
modern era.  (of course, convincing these particular CAs to transform
their root certificates is another story!)

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Reply sent to Florian Weimer <fw@deneb.enyo.de>:
You have taken responsibility. (Thu, 09 Apr 2009 16:51:10 GMT) Full text and rfc822 format available.

Notification sent to Edward Allcutt <emallcut@gleim.com>:
Bug acknowledged by developer. (Thu, 09 Apr 2009 16:51:10 GMT) Full text and rfc822 format available.

Message #249 received at 514807-close@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: 514807-close@bugs.debian.org
Subject: Bug#514807: fixed in gnutls13 1.4.4-3+etch4
Date: Thu, 09 Apr 2009 16:40:55 +0000
Source: gnutls13
Source-Version: 1.4.4-3+etch4

We believe that the bug you reported is fixed in the latest version of
gnutls13, which is due to be installed in the Debian FTP archive:

gnutls-bin_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/gnutls-bin_1.4.4-3+etch4_amd64.deb
gnutls-doc_1.4.4-3+etch4_all.deb
  to pool/main/g/gnutls13/gnutls-doc_1.4.4-3+etch4_all.deb
gnutls13_1.4.4-3+etch4.diff.gz
  to pool/main/g/gnutls13/gnutls13_1.4.4-3+etch4.diff.gz
gnutls13_1.4.4-3+etch4.dsc
  to pool/main/g/gnutls13/gnutls13_1.4.4-3+etch4.dsc
libgnutls-dev_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/libgnutls-dev_1.4.4-3+etch4_amd64.deb
libgnutls13-dbg_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/libgnutls13-dbg_1.4.4-3+etch4_amd64.deb
libgnutls13_1.4.4-3+etch4_amd64.deb
  to pool/main/g/gnutls13/libgnutls13_1.4.4-3+etch4_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 514807@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Weimer <fw@deneb.enyo.de> (supplier of updated gnutls13 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.7
Date: Mon, 23 Feb 2009 21:45:41 +0100
Source: gnutls13
Binary: libgnutls-dev libgnutls13 gnutls-bin gnutls-doc libgnutls13-dbg
Architecture: source amd64 all
Version: 1.4.4-3+etch4
Distribution: oldstable-security
Urgency: high
Maintainer: Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Changed-By: Florian Weimer <fw@deneb.enyo.de>
Description: 
 gnutls-bin - the GNU TLS library - commandline utilities
 gnutls-doc - the GNU TLS library - documentation and examples
 libgnutls-dev - the GNU TLS library - development files
 libgnutls13 - the GNU TLS library - runtime library
 libgnutls13-dbg - GNU TLS library - debugger symbols
Closes: 514735 514807
Changes: 
 gnutls13 (1.4.4-3+etch4) oldstable-security; urgency=high
 .
   * Add patch from Simon Josefsson to reenable X.509v1 support for root
     CAs.  Closes: #514807, #514735.
Files: 
 229287edc239349b5014f2d31890912a 1259 devel optional gnutls13_1.4.4-3+etch4.dsc
 fd8b423c5f4a11af2c60eda979df9b00 21337 devel optional gnutls13_1.4.4-3+etch4.diff.gz
 4809b5a15fa8554dbf0cc7331ed0128a 2305134 doc optional gnutls-doc_1.4.4-3+etch4_all.deb
 c6aa74857be44068f4e0d1f1322e30af 389308 libdevel optional libgnutls-dev_1.4.4-3+etch4_amd64.deb
 9ea77f3b9e6fb21d899786f0f14d714c 314864 libs important libgnutls13_1.4.4-3+etch4_amd64.deb
 223f5f50236b96400405a7c2ea4af3b9 539598 devel extra libgnutls13-dbg_1.4.4-3+etch4_amd64.deb
 8e1dae14f9ea57b112fe260b1b0d4133 183034 net optional gnutls-bin_1.4.4-3+etch4_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJow1dAAoJEL97/wQC1SS+lA0IAKVXDbwicFRiljle1NcCaMA2
q3QF0c7+EPsYHYSJIbh64HeyNybMZow+dgimuQlbU1UbGvzgDRMM1GdtD1SNz3Xo
EC6HJPv0ghtXNOAjHhCGChBddwtuQs2SVTy4QgvDsJ9w/jPO34Cj0iR4pJ4mVfG/
lcjUzBLDQQr8wjJAus1+yc7qKf2mfCH+zigY/V1Hwh/rjvuZ9rqJGQvqW+MakgXn
cww0Yptosnxq9q2XWZE6/RKJ8gmq0jwASgAcxzesStUot5mo1eSjFBMBJMf6hvI8
b7M7neci+3B530rP8icihp9eNNG3VGa5jZT7hmHjV8JuSkXicRo6J8LOR+bUi/0=
=gtGI
-----END PGP SIGNATURE-----





Reply sent to Florian Weimer <fw@deneb.enyo.de>:
You have taken responsibility. (Sat, 11 Apr 2009 17:36:08 GMT) Full text and rfc822 format available.

Notification sent to Edward Allcutt <emallcut@gleim.com>:
Bug acknowledged by developer. (Sat, 11 Apr 2009 17:36:08 GMT) Full text and rfc822 format available.

Message #254 received at 514807-close@bugs.debian.org (full text, mbox):

From: Florian Weimer <fw@deneb.enyo.de>
To: 514807-close@bugs.debian.org
Subject: Bug#514807: fixed in gnutls26 2.4.2-6+lenny1
Date: Sat, 11 Apr 2009 16:47:15 +0000
Source: gnutls26
Source-Version: 2.4.2-6+lenny1

We believe that the bug you reported is fixed in the latest version of
gnutls26, which is due to be installed in the Debian FTP archive:

gnutls-bin_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/gnutls-bin_2.4.2-6+lenny1_amd64.deb
gnutls-doc_2.4.2-6+lenny1_all.deb
  to pool/main/g/gnutls26/gnutls-doc_2.4.2-6+lenny1_all.deb
gnutls26_2.4.2-6+lenny1.diff.gz
  to pool/main/g/gnutls26/gnutls26_2.4.2-6+lenny1.diff.gz
gnutls26_2.4.2-6+lenny1.dsc
  to pool/main/g/gnutls26/gnutls26_2.4.2-6+lenny1.dsc
guile-gnutls_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/guile-gnutls_2.4.2-6+lenny1_amd64.deb
libgnutls-dev_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/libgnutls-dev_2.4.2-6+lenny1_amd64.deb
libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
libgnutls26_2.4.2-6+lenny1_amd64.deb
  to pool/main/g/gnutls26/libgnutls26_2.4.2-6+lenny1_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 514807@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Florian Weimer <fw@deneb.enyo.de> (supplier of updated gnutls26 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


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

Format: 1.8
Date: Mon, 23 Feb 2009 21:56:10 +0100
Source: gnutls26
Binary: libgnutls-dev libgnutls26 libgnutls26-dbg gnutls-bin gnutls-doc guile-gnutls
Architecture: source all amd64
Version: 2.4.2-6+lenny1
Distribution: stable-security
Urgency: high
Maintainer: Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>
Changed-By: Florian Weimer <fw@deneb.enyo.de>
Description: 
 gnutls-bin - the GNU TLS library - commandline utilities
 gnutls-doc - the GNU TLS library - documentation and examples
 guile-gnutls - the GNU TLS library - GNU Guile bindings
 libgnutls-dev - the GNU TLS library - development files
 libgnutls26 - the GNU TLS library - runtime library
 libgnutls26-dbg - GNU TLS library - debugger symbols
Closes: 514735 514807
Changes: 
 gnutls26 (2.4.2-6+lenny1) stable-security; urgency=high
 .
   * Add patch from Simon Josefsson to reenable X.509v1 support for root
     CAs.  Closes: #514807, #514735.
Checksums-Sha1: 
 37f83316cb8e928e03451cccaa7fe5396eb08d36 1904 gnutls26_2.4.2-6+lenny1.dsc
 e6df35963239c18cff3e5072f172898bb4400ca5 5984345 gnutls26_2.4.2.orig.tar.gz
 1528851268eb498e1a25522be696bcd76b038e66 20298 gnutls26_2.4.2-6+lenny1.diff.gz
 29f64bc9ff24e9ae115d92998171fed28d4b5c3d 2751582 gnutls-doc_2.4.2-6+lenny1_all.deb
 dd6ee2fe6d2fda09f0f76de7b3b70c2d83b673b7 586148 libgnutls-dev_2.4.2-6+lenny1_amd64.deb
 d8af7f1546c07c856efc532db2327411faa721a0 505908 libgnutls26_2.4.2-6+lenny1_amd64.deb
 d065535756478d9c50e4c00ed0e7acb4074af522 1136770 libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
 0f25817b4470f512b1a832c78f9380563cccd5e2 285624 gnutls-bin_2.4.2-6+lenny1_amd64.deb
 baf3bbbbf03fe236923c5376650d3c15f3507793 215802 guile-gnutls_2.4.2-6+lenny1_amd64.deb
Checksums-Sha256: 
 4f4adcac881b3f963d0f389bc317502c03f664b868521ef735d5bf60611cd79a 1904 gnutls26_2.4.2-6+lenny1.dsc
 ab3c3ef1a55ab0a4dbcd8a5013f9c2ddf0ba98081349bc8f64b53eb1720b3aca 5984345 gnutls26_2.4.2.orig.tar.gz
 96a7ad14052427c3100a6c71c7371f20ba9772a5e600fef70d8cd8687076de93 20298 gnutls26_2.4.2-6+lenny1.diff.gz
 96a9654f755e217694e0267e1552a96f5ae04eeb580396959c25319b65c852dd 2751582 gnutls-doc_2.4.2-6+lenny1_all.deb
 9d63f910ca6ca06510a4304604d821fd9dda16cd5791ad05aa68f70c1ae46f2c 586148 libgnutls-dev_2.4.2-6+lenny1_amd64.deb
 08ac583df22aa5decd8feb1e611381d0667d5603262161e78b77548c5d94353e 505908 libgnutls26_2.4.2-6+lenny1_amd64.deb
 80f9ca88143fe518d22315b1e4cfa0a6de10dd7fe9faff5d2a12699587067910 1136770 libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
 9439785c969807f12306db80f0a94434455e8c2dad6e0976e3f7d924754410d3 285624 gnutls-bin_2.4.2-6+lenny1_amd64.deb
 b00b53913b8bea1dd39457392814bd6783000369cbdb3f9609da9d6df63afae4 215802 guile-gnutls_2.4.2-6+lenny1_amd64.deb
Files: 
 3410a16fe6f7dcce25f1c55946357dc6 1904 devel optional gnutls26_2.4.2-6+lenny1.dsc
 8fea7c57f4badcafcd31eb0f981f169a 5984345 devel optional gnutls26_2.4.2.orig.tar.gz
 e6bb02c6522cf6b6842e0b38c633a087 20298 devel optional gnutls26_2.4.2-6+lenny1.diff.gz
 9c920495e79d03f377d96ed94915a378 2751582 doc optional gnutls-doc_2.4.2-6+lenny1_all.deb
 c95ef6b6b2af28fc7a8bfebe60703092 586148 libdevel optional libgnutls-dev_2.4.2-6+lenny1_amd64.deb
 e560d1c33d60f9b8c9748d6f70a2ccbc 505908 libs important libgnutls26_2.4.2-6+lenny1_amd64.deb
 db82f80deb858958e98ff3fd1422dd2c 1136770 devel extra libgnutls26-dbg_2.4.2-6+lenny1_amd64.deb
 48f7e580aed0f99e92eeee384c97cc21 285624 net optional gnutls-bin_2.4.2-6+lenny1_amd64.deb
 2ed45e368aabeb938f90fee4b3cf4668 215802 libs optional guile-gnutls_2.4.2-6+lenny1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJow/gAAoJEL97/wQC1SS+cCsH/2qdMKNtqSMfUHfPwZPtPDlv
7PeFbkqhUxXImZXGA28vlNzIlvLzuIg1GOKw3ksVUa/OFn2m/IUw5R4dC9qjBGta
FKXaXuVw3IM7wtGX3pfnl3rShCewDDGuRLXFcAtdYHly68nwQfN2Sg7xddx5jNw9
v8Egzov+0dI48t1LuERtVBSAMPUrqT3oBRQEscjLr5KdiqPKiFPpmvc6h/j8WvC2
xhXoKQQAtZGcS5wA0/nU2YSd5112daCqQtGyGk3mHEI3+qIlyJ4M+qdmroWt7r9z
G0NgMvaWQ01Py1fhDZ0wh9Ny0nhqdr7myySz0S8xs2UutkIxErPEw0CB6L9aHDI=
=JMKM
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 10 May 2009 07:26:22 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 02:47:39 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.