From nmav at gnutls.org Sat Mar 2 12:38:06 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Mar 2013 12:38:06 +0100 Subject: [gnutls-devel] cerbero Message-ID: <5131E49E.2060903@gnutls.org> Hello, I was trying cerbero [0,1], and it looks quite a handy framework. Under that I was able to build gnutls binaries for android (ARM), without going into the Android.mk idiocy. For the interested, I've cloned the repository and added recipes for gnutls-bin and openconnect client at: https://gitorious.org/gnutls/cerbero regards, Nikos [0]. http://docs.gstreamer.com/display/GstSDK/Building+from+source+using+Cerbero [1]. http://lists.gnu.org/archive/html/help-libtasn1/2013-01/msg00002.html From dokumentarfilme at hotmail.com Mon Mar 4 23:39:53 2013 From: dokumentarfilme at hotmail.com (.uservorname .usernachname) Date: Mon, 4 Mar 2013 22:39:53 +0000 Subject: [gnutls-devel] x509: common.c:51:66: error: 'ASN1_ETYPE_INVALID' undeclared here (not in a function) Message-ID: Greetings, when trying to compile gnutls-3.1.7 with make it breaks with:fes-a120d19nas:/backup/fes-a120d19nas/zarafa/gnutls-3.1.7# make 2>&1 | tee build-log.txtmake all-recursivemake[1]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7'Making all in glmake[2]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl'make all-recursivemake[3]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl'Making all in testsmake[4]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl/tests'make all-recursivemake[5]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl/tests'Making all in .make[6]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl/tests'make[6]: Nothing to be done for `all-am'.make[6]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl/tests'make[5]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl/tests'make[4]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl/tests'make[4]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl'make[4]: Nothing to be done for `all-am'.make[4]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl'make[3]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl'make[2]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/gl'Making all in libmake[2]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/lib'Making all in includesmake[3]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/lib/includes'make[3]: Nothing to be done for `all'.make[3]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/lib/includes'Making all in x509make[3]: Entering directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/lib/x509' CC common.locommon.c:51:66: error: 'ASN1_ETYPE_INVALID' undeclared here (not in a function)common.c:52:41: error: 'ASN1_ETYPE_PRINTABLE_STRING' undeclared here (not in a function)common.c:77:46: error: 'ASN1_ETYPE_IA5_STRING' undeclared here (not in a function)common.c:96:41: error: 'ASN1_ETYPE_BMP_STRING' undeclared here (not in a function)common.c:98:41: error: 'ASN1_ETYPE_OCTET_STRING' undeclared here (not in a function)common.c:101:43: error: 'ASN1_ETYPE_UTF8_STRING' undeclared here (not in a function)common.c: In function 'make_printable_string':common.c:208:13: warning: comparison between pointer and integer [enabled by default]common.c:219:21: error: 'ASN1_ETYPE_TELETEX_STRING' undeclared (first use in this function)common.c:219:21: note: each undeclared identifier is reported only once for each function it appears incommon.c:219:18: warning: comparison between pointer and integer [enabled by default]common.c:243:21: error: 'ASN1_ETYPE_UNIVERSAL_STRING' undeclared (first use in this function)common.c:243:18: warning: comparison between pointer and integer [enabled by default]common.c: In function 'decode_complex_string':common.c:277:17: error: 'ASN1_MAX_ERROR_DESCRIPTION_SIZE' undeclared (first use in this function)common.c:297:27: warning: passing argument 4 of 'asn1_der_decoding' from incompatible pointer type [enabled by default]/usr/include/libtasn1.h:162:14: note: expected 'char *' but argument is of type 'const struct oid_to_string *'common.c:321:13: error: 'ASN1_ETYPE_TELETEX_STRING' undeclared (first use in this function)common.c:321:11: warning: assignment makes integer from pointer without a cast [enabled by default]common.c:323:11: warning: assignment makes integer from pointer without a cast [enabled by default]common.c:325:13: error: 'ASN1_ETYPE_UNIVERSAL_STRING' undeclared (first use in this function)common.c:325:11: warning: assignment makes integer from pointer without a cast [enabled by default]common.c:326:14: warning: assignment makes integer from pointer without a cast [enabled by default]common.c:335:13: warning: comparison between pointer and integer [enabled by default]common.c: In function '_gnutls_x509_decode_string':common.c:915:3: warning: implicit declaration of function 'asn1_decode_simple_der' [-Wimplicit-function-declaration]common.c:944:13: warning: comparison between pointer and integer [enabled by default]common.c: In function '_gnutls_x509_read_value':common.c:971:3: warning: implicit declaration of function 'asn1_read_value_type' [-Wimplicit-function-declaration]common.c:979:16: error: 'ASN1_ETYPE_BIT_STRING' undeclared (first use in this function)common.c:979:13: warning: comparison between pointer and integer [enabled by default]common.c:1001:13: warning: comparison between pointer and integer [enabled by default]common.c: In function '_gnutls_x509_read_string':common.c:1041:16: error: 'ASN1_ETYPE_BIT_STRING' undeclared (first use in this function)common.c:1041:13: warning: comparison between pointer and integer [enabled by default]common.c:1060:13: warning: comparison between pointer and integer [enabled by default]common.c: In function '_gnutls_x509_encode_string':common.c:1088:14: error: 'ASN1_MAX_TL_SIZE' undeclared (first use in this function)common.c:1092:11: warning: assignment makes integer from pointer without a cast [enabled by default]common.c:1093:3: warning: implicit declaration of function 'asn1_encode_simple_der' [-Wimplicit-function-declaration]make[3]: *** [common.lo] Error 1make[3]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/lib/x509'make[2]: *** [all-recursive] Error 1make[2]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7/lib'make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/c/backup/fes-a120d19nas/zarafa/gnutls-3.1.7'make: *** [all] Error 2I configured it with /configure --enable-shared --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --bindir=/usr --sysconfdir=/etc --sbindir=/usr/sbin/The content of configure.log can be viewed here: https://gist.github.com/mfe-/5086320 If you need more information, let me know.I appreciate any help. Best regardsmartin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Mar 5 01:00:36 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 05 Mar 2013 01:00:36 +0100 Subject: [gnutls-devel] x509: common.c:51:66: error: 'ASN1_ETYPE_INVALID' undeclared here (not in a function) In-Reply-To: References: Message-ID: <513535A4.1010900@gnutls.org> On 03/04/2013 11:39 PM, .uservorname .usernachname wrote: > Greetings, when trying to compile gnutls-3.1.7 with make it breaks with:fes-a120d19nas:/backup/fes-a120d19nas/zarafa/gnutls-3.1.7# m Please configure your mailer to send sensible (not html) mails. I see your whole mail in a single line. In any case, it seems that you have installed an old version of libtasn1 which conflicts with the included in gnutls. Either upgrade your libtasn1 or remove its development files. regards, Nikos From dkg at fifthhorseman.net Tue Mar 5 10:04:04 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Mar 2013 04:04:04 -0500 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS Message-ID: <87vc96qku3.fsf@alice.fifthhorseman.net> I'm trying to understand the specification of X.509 Key Identifiers (e.g. subjectKeyIdentifier and issuerKeyIdentifier). It looks to me like GnuTLS diverges from the "common method" for generating these identifiers, but i don't see any documentation that explains the divergence. I understand that there is no official requirement that these strings are formed in any specific way. However, the canonical RFC for PKIX https://tools.ietf.org/html/rfc5280#section-4.2.1.2 suggests that the "common method" involves an SHA-1 digest of the contents of the BIT STRING subjectPublicKey field. However, GnuTLS appears to calculate the SHA-1 digest over the entire DER-encoded subjectPublicKeyInfo object (that is, over the sequence of the algorithmIdentifier and subjectPublicKey together). 0 dkg at alice:~$ certtool --generate-privkey --bits=1024 > x.key ** Note: Please use the --sec-param instead of --bits Generating a 1024 bit RSA private key... 0 dkg at alice:~$ certtool --key-info < x.key | grep 'Public Key ID:' Public Key ID: 46:F6:84:5B:9E:25:69:0C:85:17:32:F7:08:9A:F0:EF:D3:61:76:94 0 dkg at alice:~$ certtool --pubkey-info --outder --load-privkey x.key | sha1sum 46f6845b9e25690c851732f7089af0efd3617694 - 0 dkg at alice:~$ certtool --pubkey-info --outder --load-privkey x.key | dumpasn1 -a - Warning: Input is non-seekable, some functionality has been disabled. 0 159: SEQUENCE { 3 13: SEQUENCE { 5 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 16 0: NULL : } 18 141: BIT STRING : 30 81 89 02 81 81 00 B9 1D 5D 74 11 FE 2B 99 F2 : 10 AF BC E7 E9 D4 8D 2E 84 30 15 FD AF 68 F9 34 : 1B 11 3F 9F 7B 6D 81 5F B2 AD FD 12 35 57 E6 12 : 7D 77 28 64 61 2F 02 AB DD 23 57 23 69 65 0E CC : D4 5C 51 39 57 01 F8 E4 DD 2E 77 94 D3 51 76 74 : 37 8C 5E F7 5C EE CC 4D 86 06 F4 CB 5D 2B 8B 6F : C5 FA 2E 10 B1 15 E7 48 63 A8 D5 C2 B2 48 F1 99 : 93 48 6B E6 FD 0E 8C E9 03 7C 24 76 04 56 AC 0F : 23 8A 35 26 19 92 7B 02 03 01 00 01 : } 0 warnings, 0 errors. 0 dkg at alice:~$ Here's a hacky implementation using the RFC's suggested common approach, followed by a demonstration that OpenSSL uses the "common method" when it generates certificates, while GnuTLS's certtool uses the whole subjectPublicKeyInfo: 0 dkg at alice:~$ certtool --pubkey-info --outder --load-privkey x.key | dumpasn1 -a - 2>/dev/null | grep '^\s*:\s*[0-9A-F ]*$' | tr -d ':\ \n' | perl -MDigest::SHA -e 'undef $/; my $x = ; printf("%s\n", Digest::SHA::sha1_hex(pack("H*", $x)));' 2750d2f7899c2f8e18be77af5d1d3522b7ada279 0 dkg at alice:~$ openssl req -nodes -text -new -key x.key -keyform PEM -subj '/CN=test.example.org/' -x509 | grep -A1 Identifier X509v3 Subject Key Identifier: 27:50:D2:F7:89:9C:2F:8E:18:BE:77:AF:5D:1D:35:22:B7:AD:A2:79 X509v3 Authority Key Identifier: keyid:27:50:D2:F7:89:9C:2F:8E:18:BE:77:AF:5D:1D:35:22:B7:AD:A2:79 0 dkg at alice:~$ echo cn=test.example.org > template.txt 0 dkg at alice:~$ certtool -s --load-privkey x.key --template template.txt 2>&1 | grep -A1 'Key Identifier' Subject Key Identifier (not critical): 46f6845b9e25690c851732f7089af0efd3617694 0 dkg at alice:~$ It appears that we could align GnuTLS with the "common method" PKIX keyID generation with the following change: diff --git a/lib/x509/x509.c b/lib/x509/x509.c index 57f540a..009f053 100644 --- a/lib/x509/x509.c +++ b/lib/x509/x509.c @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params, return GNUTLS_E_SHORT_MEMORY_BUFFER; } - ret = _gnutls_x509_encode_PKI_params(&der, pk, params); + ret = _gnutls_x509_write_pubkey (pk, params, &der); if (ret < 0) return gnutls_assert_val(ret); (the tests would also need to be updated because the key ID changes as does the "Random Art", since that is based on the key ID) The advantage of making this change would be increased interoperability in the future with other TLS implementations and X.509 search tools, and closer alignment to the documented "common method". A disadvantage, of course, is that older versions of GnuTLS and newer versions of GnuTLS will not produce the same Key IDs for any given key :/ I can see an argument for including the algorithm identifier in the material digested for the key ID: for DSA and ECC, the parameters for the specific algorithm are only stored in the algorithmIdentifier, not the subjectPublicKey. It seems possible that the same subjectPublicKey data could be used in two (or more) different parameterized algorithms, and the RFC 5280 suggestion wouldn't capture the distinction. the current GnuTLS implementation would capture the distinction in the digest. And i note that GnuTLS's choice of key ID seems to map precisely to the proposal outlined in the (not yet finalized) websec internet draft about key pinning: https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.4 The TACK proposal also looks at a digest of the whole subjectPublicKeyInfo, not just the subjectPublicKey: https://tools.ietf.org/html/draft-perrin-tls-tack-02#section-3.2.1 So that suggests that other people who are actively thinking about concisely identifying public keys have made the same tradeoff as GnuTLS currently makes. So i think my questions are: 0) do we want GnuTLS to use the RFC 5280 "common method" suggestion, or are we fine with the current implementation? 1) if we stay with the current implementation, can we improve the documentation explaining why we have chosen this mechanism instead of the "common method"? I'd be happy to try to write some documentation once i understand the background better. 2) if we stay with the current implementation, should we reach out to other free X.509 certificate generation tools (notably OpenSSL) and suggest that they reconsider? Any thoughts? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From home_pw at msn.com Tue Mar 5 19:40:10 2013 From: home_pw at msn.com (Peter Williams) Date: Tue, 5 Mar 2013 18:40:10 +0000 Subject: [gnutls-devel] =?utf-8?q?X=2E509_=22Key_Identifiers=22_in_GnuTLS?= Message-ID: Think of it as vendor-value add - where no one will agree on its value. Often patent or ?other? reasons are behind such inability to agree. For example, a hash value in the serial number of certs saved VeriSign from the md5 compromise, since it made it SO Much harder to predict a plaintext AND find a collision. To me it was elementary cryptanalysis; but try convincing generalists of it. Specialists in the know would accept the argument, but there would always be ?specious? reasons why not to make it a standardized element. We all know what lay behind those specious reasons, now. From: Daniel Kahn Gillmor Sent: ?March? ?5?, ?2013 ?1?:?05? ?AM To: GnuTLS development list Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS I'm trying to understand the specification of X.509 Key Identifiers (e.g. subjectKeyIdentifier and issuerKeyIdentifier). It looks to me like GnuTLS diverges from the "common method" for generating these identifiers, but i don't see any documentation that explains the divergence. I understand that there is no official requirement that these strings are formed in any specific way. However, the canonical RFC for PKIX https://tools.ietf.org/html/rfc5280#section-4.2.1.2 suggests that the "common method" involves an SHA-1 digest of the contents of the BIT STRING subjectPublicKey field. However, GnuTLS appears to calculate the SHA-1 digest over the entire DER-encoded subjectPublicKeyInfo object (that is, over the sequence of the algorithmIdentifier and subjectPublicKey together). 0 dkg at alice:~$ certtool --generate-privkey --bits=1024 > x.key ** Note: Please use the --sec-param instead of --bits Generating a 1024 bit RSA private key... 0 dkg at alice:~$ certtool --key-info < x.key | grep 'Public Key ID:' Public Key ID: 46:F6:84:5B:9E:25:69:0C:85:17:32:F7:08:9A:F0:EF:D3:61:76:94 0 dkg at alice:~$ certtool --pubkey-info --outder --load-privkey x.key | sha1sum 46f6845b9e25690c851732f7089af0efd3617694 - 0 dkg at alice:~$ certtool --pubkey-info --outder --load-privkey x.key | dumpasn1 -a - Warning: Input is non-seekable, some functionality has been disabled. 0 159: SEQUENCE { 3 13: SEQUENCE { 5 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 16 0: NULL : } 18 141: BIT STRING : 30 81 89 02 81 81 00 B9 1D 5D 74 11 FE 2B 99 F2 : 10 AF BC E7 E9 D4 8D 2E 84 30 15 FD AF 68 F9 34 : 1B 11 3F 9F 7B 6D 81 5F B2 AD FD 12 35 57 E6 12 : 7D 77 28 64 61 2F 02 AB DD 23 57 23 69 65 0E CC : D4 5C 51 39 57 01 F8 E4 DD 2E 77 94 D3 51 76 74 : 37 8C 5E F7 5C EE CC 4D 86 06 F4 CB 5D 2B 8B 6F : C5 FA 2E 10 B1 15 E7 48 63 A8 D5 C2 B2 48 F1 99 : 93 48 6B E6 FD 0E 8C E9 03 7C 24 76 04 56 AC 0F : 23 8A 35 26 19 92 7B 02 03 01 00 01 : } 0 warnings, 0 errors. 0 dkg at alice:~$ Here's a hacky implementation using the RFC's suggested common approach, followed by a demonstration that OpenSSL uses the "common method" when it generates certificates, while GnuTLS's certtool uses the whole subjectPublicKeyInfo: 0 dkg at alice:~$ certtool --pubkey-info --outder --load-privkey x.key | dumpasn1 -a - 2>/dev/null | grep '^\s*:\s*[0-9A-F ]*$' | tr -d ':\ \n' | perl -MDigest::SHA -e 'undef $/; my $x = ; printf("%s\n", Digest::SHA::sha1_hex(pack("H*", $x)));' 2750d2f7899c2f8e18be77af5d1d3522b7ada279 0 dkg at alice:~$ openssl req -nodes -text -new -key x.key -keyform PEM -subj '/CN=test.example.org/' -x509 | grep -A1 Identifier X509v3 Subject Key Identifier: 27:50:D2:F7:89:9C:2F:8E:18:BE:77:AF:5D:1D:35:22:B7:AD:A2:79 X509v3 Authority Key Identifier: keyid:27:50:D2:F7:89:9C:2F:8E:18:BE:77:AF:5D:1D:35:22:B7:AD:A2:79 0 dkg at alice:~$ echo cn=test.example.org > template.txt 0 dkg at alice:~$ certtool -s --load-privkey x.key --template template.txt 2>&1 | grep -A1 'Key Identifier' Subject Key Identifier (not critical): 46f6845b9e25690c851732f7089af0efd3617694 0 dkg at alice:~$ It appears that we could align GnuTLS with the "common method" PKIX keyID generation with the following change: diff --git a/lib/x509/x509.c b/lib/x509/x509.c index 57f540a..009f053 100644 --- a/lib/x509/x509.c +++ b/lib/x509/x509.c @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params, return GNUTLS_E_SHORT_MEMORY_BUFFER; } - ret = _gnutls_x509_encode_PKI_params(&der, pk, params); + ret = _gnutls_x509_write_pubkey (pk, params, &der); if (ret < 0) return gnutls_assert_val(ret); (the tests would also need to be updated because the key ID changes as does the "Random Art", since that is based on the key ID) The advantage of making this change would be increased interoperability in the future with other TLS implementations and X.509 search tools, and closer alignment to the documented "common method". A disadvantage, of course, is that older versions of GnuTLS and newer versions of GnuTLS will not produce the same Key IDs for any given key :/ I can see an argument for including the algorithm identifier in the material digested for the key ID: for DSA and ECC, the parameters for the specific algorithm are only stored in the algorithmIdentifier, not the subjectPublicKey. It seems possible that the same subjectPublicKey data could be used in two (or more) different parameterized algorithms, and the RFC 5280 suggestion wouldn't capture the distinction. the current GnuTLS implementation would capture the distinction in the digest. And i note that GnuTLS's choice of key ID seems to map precisely to the proposal outlined in the (not yet finalized) websec internet draft about key pinning: https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.4 The TACK proposal also looks at a digest of the whole subjectPublicKeyInfo, not just the subjectPublicKey: https://tools.ietf.org/html/draft-perrin-tls-tack-02#section-3.2.1 So that suggests that other people who are actively thinking about concisely identifying public keys have made the same tradeoff as GnuTLS currently makes. So i think my questions are: 0) do we want GnuTLS to use the RFC 5280 "common method" suggestion, or are we fine with the current implementation? 1) if we stay with the current implementation, can we improve the documentation explaining why we have chosen this mechanism instead of the "common method"? I'd be happy to try to write some documentation once i understand the background better. 2) if we stay with the current implementation, should we reach out to other free X.509 certificate generation tools (notably OpenSSL) and suggest that they reconsider? Any thoughts? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Mar 5 19:47:54 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Mar 2013 13:47:54 -0500 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: References: Message-ID: <51363DDA.3030705@fifthhorseman.net> On 03/05/2013 01:40 PM, Peter Williams wrote: > Think of it as vendor-value add - where no one will agree on its value. Often patent or ?other? reasons are behind such inability to agree. hm, i'm not inclined to think of this as something sinister. there actually *is* a documented "common method" recommendation. It's GnuTLS that is divergent from it. Are you implying that GnuTLS has some sort of patent or proprietary reason for its divergence? That seems implausible to me. > For example, a hash value in the serial number of certs saved VeriSign from the md5 compromise, since it made it SO Much harder to predict a plaintext AND find a collision. To me it was elementary cryptanalysis; but try convincing generalists of it. Specialists in the know would accept the argument, but there would always be ?specious? reasons why not to make it a standardized element. We all know what lay behind those specious reasons, now. Again, i'm not sure what you're implying here. I'm not talking about the serial number, but rather the key identifiers. If GnuTLS is doing something different from everyone else, and we have a good reason for doing it different, shouldn't we be encouraging other toolkits to at least offer their users the option of taking our improved approach? On the other hand, if GnuTLS has no reason for the divergence (e.g. if it was an accident) then shouldn't we try to reduce divergence to improve interoperability? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From home_pw at msn.com Tue Mar 5 19:59:48 2013 From: home_pw at msn.com (Peter Williams) Date: Tue, 5 Mar 2013 18:59:48 +0000 Subject: [gnutls-devel] =?utf-8?q?X=2E509_=22Key_Identifiers=22_in_GnuTLS?= Message-ID: there is unlikely to be anything sinister about GNU (except the usual rants about GNU?s mission and ulterior motives) What Im saying is that there is space for value-add, that someone might well have taken. But, I do assume that IETF standards are ?public policy? property; taking into full consideration all the hard politics that comes with key management. This includes biases and tradeoffs between what is forced to be a presumption for interworking (i.e. MUST statements). It comes down to this. When IESG ratifies a SHOULD, this does not mean you have to do it. You may well choose to NOT engender ?maximal? interworking - putting up with interworking (80% of the time). When one has a ratified SHOULD, It means partial reasons from some communities were convincing to avoid MUST, but those reasons are not relevant to the ?internet? - though they may be relevant to some military internet (milnet) for example. Stuff that goes into the milnet applicability statement is NOT put in the RFC, but codifies as SHOULD. Arguments about what the serial should be are long standing. One vendor, rather infamous, wanted the serial number to tie to the HSM, and its hierarchical identification scheme. In making a break with hardware ?cultured? crypto (back in 1990-1994), I didn't. One can look at the field you are interested as the more modern form of the serial number (and all the debates over how the field is to be used in security enforcing functions, both software chaining and hardware box referencing). Would be interesting to hear from the programmer though. One has heard (from me) why I/VeriSign did X, 20+ years ago - based on the desired culture shift to the expected 20-year reign of software CSPs. From: Daniel Kahn Gillmor Sent: ?March? ?5?, ?2013 ?10?:?48? ?AM To: Peter Williams CC: GnuTLS development list Subject: Re: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS On 03/05/2013 01:40 PM, Peter Williams wrote: > Think of it as vendor-value add - where no one will agree on its value. Often patent or ?other? reasons are behind such inability to agree. hm, i'm not inclined to think of this as something sinister. there actually *is* a documented "common method" recommendation. It's GnuTLS that is divergent from it. Are you implying that GnuTLS has some sort of patent or proprietary reason for its divergence? That seems implausible to me. > For example, a hash value in the serial number of certs saved VeriSign from the md5 compromise, since it made it SO Much harder to predict a plaintext AND find a collision. To me it was elementary cryptanalysis; but try convincing generalists of it. Specialists in the know would accept the argument, but there would always be ?specious? reasons why not to make it a standardized element. We all know what lay behind those specious reasons, now. Again, i'm not sure what you're implying here. I'm not talking about the serial number, but rather the key identifiers. If GnuTLS is doing something different from everyone else, and we have a good reason for doing it different, shouldn't we be encouraging other toolkits to at least offer their users the option of taking our improved approach? On the other hand, if GnuTLS has no reason for the divergence (e.g. if it was an accident) then shouldn't we try to reduce divergence to improve interoperability? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Mar 5 23:27:41 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 05 Mar 2013 23:27:41 +0100 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: <87vc96qku3.fsf@alice.fifthhorseman.net> References: <87vc96qku3.fsf@alice.fifthhorseman.net> Message-ID: <5136715D.1040103@gnutls.org> On 03/05/2013 10:04 AM, Daniel Kahn Gillmor wrote: > I'm trying to understand the specification of X.509 Key Identifiers > (e.g. subjectKeyIdentifier and issuerKeyIdentifier). It looks to me > like GnuTLS diverges from the "common method" for generating these > identifiers, but i don't see any documentation that explains the > divergence. > > I understand that there is no official requirement that these strings > are formed in any specific way. However, the canonical RFC for PKIX > > https://tools.ietf.org/html/rfc5280#section-4.2.1.2 > > suggests that the "common method" involves an SHA-1 digest of the > contents of the BIT STRING subjectPublicKey field. Hello Daniel, Indeed, it is a non-normative suggestion of the RFC that I didn't follow. That field could even be a counter, there is no advantage into implementing the rfc way. > However, GnuTLS appears to calculate the SHA-1 digest over the entire > DER-encoded subjectPublicKeyInfo object (that is, over the sequence of > the algorithmIdentifier and subjectPublicKey together). That is certtool. One may set other values to this field (though it will not be that easy to get the bit string). > Here's a hacky implementation using the RFC's suggested common approach, > followed by a demonstration that OpenSSL uses the "common method" when > it generates certificates, while GnuTLS's certtool uses the whole > subjectPublicKeyInfo: Is there any advantage on using the RFC suggested approach? The authority and subject key identifiers are implementation specific, so it would not make much difference whether you add something like that or not. > diff --git a/lib/x509/x509.c b/lib/x509/x509.c > index 57f540a..009f053 100644 > --- a/lib/x509/x509.c > +++ b/lib/x509/x509.c > @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params, > return GNUTLS_E_SHORT_MEMORY_BUFFER; > } A solution for what you describe cannot be at this function. This returns the key identifier which is IMO correctly set to be the hash of the SubjectPublicKeyInfo. If you'd really like that functionality you may add a new function that gets the rfc-xxx ID. Then maybe add an option to certtool to use it. > The advantage of making this change would be increased interoperability > in the future with other TLS implementations and X.509 search tools, and > closer alignment to the documented "common method". I don't really see why would this increase interoperability. The authority key ID field is transparently read by implementations and compared with the subject key ID of the CA certificate. There is no other action done. Could you elaborate? > 0) do we want GnuTLS to use the RFC 5280 "common method" suggestion, or > are we fine with the current implementation? Personally I am fine, but this isn't the point :) I really would like to see what advantages would that change provide. > 2) if we stay with the current implementation, should we reach out to > other free X.509 certificate generation tools (notably OpenSSL) and > suggest that they reconsider? Why? If one would like to use a counter to identify his certificates, that wouldn't be a problem and it would not cause any interoperability issues, as far as I understand. regards, Nikos From home_pw at msn.com Wed Mar 6 00:12:38 2013 From: home_pw at msn.com (peter williams) Date: Tue, 5 Mar 2013 15:12:38 -0800 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS Message-ID: Some ietf users (eg nsa) build upon the std, profiling and extending the places it intends such specialization to occur. For example, you would expect nsa key management culture to more hardened than the typical unix webserver running ssl. Signed key (vs cert) compromise message may flood suitable routing protocols intending to flash a key compromise notice (concerning some hsm for a ca, say). In that world kmid are used, that may go into the cert fields to assists cert/key loading by csps (not in pkix scope) or chain discovery (partly in pkix scope) or chain validation for pkix complying cert-using systems. Remember pkix is just a profile of x509, not a design of a key mgt system. Nikos Mavrogiannopoulos wrote: > > >On 03/05/2013 10:04 AM, Daniel Kahn Gillmor wrote: > >> I'm trying to understand the specification of X.509 Key Identifiers >> (e.g. subjectKeyIdentifier and issuerKeyIdentifier).? It looks to me >> like GnuTLS diverges from the "common method" for generating these >> identifiers, but i don't see any documentation that explains the >> divergence. >> >> I understand that there is no official requirement that these strings >> are formed in any specific way.? However, the canonical RFC for PKIX >> >>? https://tools.ietf.org/html/rfc5280#section-4.2.1.2 >> >> suggests that the "common method" involves an SHA-1 digest of the >> contents of the BIT STRING subjectPublicKey field. > > >Hello Daniel, >?Indeed, it is a non-normative suggestion of the RFC that I didn't >follow. That field could even be a counter, there is no advantage into >implementing the rfc way. > >> However, GnuTLS appears to calculate the SHA-1 digest over the entire >> DER-encoded subjectPublicKeyInfo object (that is, over the sequence of >> the algorithmIdentifier and subjectPublicKey together). > > >That is certtool. One may set other values to this field (though it will >not be that easy to get the bit string). > >> Here's a hacky implementation using the RFC's suggested common approach, >> followed by a demonstration that OpenSSL uses the "common method" when >> it generates certificates, while GnuTLS's certtool uses the whole >> subjectPublicKeyInfo: > > >Is there any advantage on using the RFC suggested approach? The >authority and subject key identifiers are implementation specific, so it >would not make much difference whether you add something like that or not. > >> diff --git a/lib/x509/x509.c b/lib/x509/x509.c >> index 57f540a..009f053 100644 >> --- a/lib/x509/x509.c >> +++ b/lib/x509/x509.c >> @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params, >>??????? return GNUTLS_E_SHORT_MEMORY_BUFFER; >>????? } > >A solution for what you describe cannot be at this function. This >returns the key identifier which is IMO correctly set to be the hash of >the SubjectPublicKeyInfo. > >If you'd really like that functionality you may add a new function that >gets the rfc-xxx ID. Then maybe add an option to certtool to use it. > >> The advantage of making this change would be increased interoperability >> in the future with other TLS implementations and X.509 search tools, and >> closer alignment to the documented "common method". > > >I don't really see why would this increase interoperability. The >authority key ID field is transparently read by implementations and >compared with the subject key ID of the CA certificate. There is no >other action done. Could you elaborate? > >>? 0) do we want GnuTLS to use the RFC 5280 "common method" suggestion, or > >>? are we fine with the current implementation? > > >Personally I am fine, but this isn't the point :) I really would like to >see what advantages would that change provide. > >>? 2) if we stay with the current implementation, should we reach out to >>? other free X.509 certificate generation tools (notably OpenSSL) and >>? suggest that they reconsider? > > >Why? If one would like to use a counter to identify his certificates, >that wouldn't be a problem and it would not cause any interoperability >issues, as far as I understand. > >regards, >Nikos > >_______________________________________________ >Gnutls-devel mailing list >Gnutls-devel at lists.gnutls.org >http://lists.gnupg.org/mailman/listinfo/gnutls-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Mar 6 23:17:09 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 06 Mar 2013 17:17:09 -0500 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: <5136715D.1040103@gnutls.org> References: <87vc96qku3.fsf@alice.fifthhorseman.net> <5136715D.1040103@gnutls.org> Message-ID: <5137C065.9040002@fifthhorseman.net> Thanks for helping me get my head around this, Nikos. On 03/05/2013 05:27 PM, Nikos Mavrogiannopoulos wrote: > That is certtool. One may set other values to this field (though it will > not be that easy to get the bit string). right, i should have said that i was describing certtool's default keyIdentifier implementation, not GnuTLS's as a whole. > Is there any advantage on using the RFC suggested approach? The > authority and subject key identifiers are implementation specific, so it > would not make much difference whether you add something like that or not. Well, if there were actually a standard mechanism for deriving a keyID from a pubkey (e.g. like an OpenPGP "fingerprint"), that could make path resolution more straightforward (e.g. you could ignore all keys that do not have the indicated keyID). But, of course, no such standard exists. :/ >> diff --git a/lib/x509/x509.c b/lib/x509/x509.c >> index 57f540a..009f053 100644 >> --- a/lib/x509/x509.c >> +++ b/lib/x509/x509.c >> @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params, >> return GNUTLS_E_SHORT_MEMORY_BUFFER; >> } > > A solution for what you describe cannot be at this function. This > returns the key identifier which is IMO correctly set to be the hash of > the SubjectPublicKeyInfo. > > If you'd really like that functionality you may add a new function that > gets the rfc-xxx ID. Then maybe add an option to certtool to use it. Ah, this is an interesting approach. The more i've thought about this, the more i think GnuTLS is doing the right thing, and the "common method" is actually misguided. One reason i'd want this is (for example) to implement some sort of pinning infrastructure for a tool that builds a table of pins indicated by keyID. However, since the two most acive pinning proposals actually use GnuTLS's style of KeyID derivation, i think this isn't a good reason to implement the "common method" in GnuTLS. > I don't really see why would this increase interoperability. The > authority key ID field is transparently read by implementations and > compared with the subject key ID of the CA certificate. There is no > other action done. Could you elaborate? given what i now understand about the state of the infrastructure, i think you're right that there isn't much of a win here. Given that the certificates in question can be given arbitrary subjectKeyIdentifiers, and that many TLS stacks (like browsers) keep a cache of previously-seen certs, i wonder if a malicious server could jam up the cert processing by feeding the browser a bunch of bogus certificates with colliding identifiers. This is probably not something we can resolve in GnuTLS, though. So i think the only thing that remains is to document why this is a divergence from the RFC's "Common Method" -- and i think we have several good reasons. Nikos, would you be averse to a changeset that adds a bit of documentation about how this distinction is made? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Thu Mar 7 01:05:44 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 07 Mar 2013 01:05:44 +0100 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: <5137C065.9040002@fifthhorseman.net> References: <87vc96qku3.fsf@alice.fifthhorseman.net> <5136715D.1040103@gnutls.org> <5137C065.9040002@fifthhorseman.net> Message-ID: <5137D9D8.2040608@gnutls.org> On 03/06/2013 11:17 PM, Daniel Kahn Gillmor wrote: > So i think the only thing that remains is to document why this is a > divergence from the RFC's "Common Method" -- and i think we have several > good reasons. > Nikos, would you be averse to a changeset that adds a bit of > documentation about how this distinction is made? This would be good. regards, Nikos From home_pw at msn.com Thu Mar 7 14:10:10 2013 From: home_pw at msn.com (peter williams) Date: Thu, 7 Mar 2013 05:10:10 -0800 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS Message-ID: Security of cert path discovery is distinct from path eval. Perhaps investigate the doctrine of key "loading" - an enforced correctness regime. Typically one uses a trusted agent, whose db is within a crypto boundary (and not just a tcb of a general purpose (ie b1) os. The us wants dns to play that role - since its a us military asset. Obviously, other nations dont see why the us should have such an advantage in the crypto/cyber warring. Daniel Kahn Gillmor wrote: > > >Thanks for helping me get my head around this, Nikos. > >On 03/05/2013 05:27 PM, Nikos Mavrogiannopoulos wrote: >> That is certtool. One may set other values to this field (though it will >> not be that easy to get the bit string). > >right, i should have said that i was describing certtool's default >keyIdentifier implementation, not GnuTLS's as a whole. > >> Is there any advantage on using the RFC suggested approach? The >> authority and subject key identifiers are implementation specific, so it >> would not make much difference whether you add something like that or not. > >Well, if there were actually a standard mechanism for deriving a keyID >from a pubkey (e.g. like an OpenPGP "fingerprint"), that could make path >resolution more straightforward (e.g. you could ignore all keys that do >not have the indicated keyID). But, of course, no such standard exists. :/ > >>> diff --git a/lib/x509/x509.c b/lib/x509/x509.c >>> index 57f540a..009f053 100644 >>> --- a/lib/x509/x509.c >>> +++ b/lib/x509/x509.c >>> @@ -2667,7 +2667,7 @@ _gnutls_get_key_id (gnutls_pk_algorithm_t pk, gnutls_pk_params_st * params, >>>??????? return GNUTLS_E_SHORT_MEMORY_BUFFER; >>>????? } >> >> A solution for what you describe cannot be at this function. This >> returns the key identifier which is IMO correctly set to be the hash of >> the SubjectPublicKeyInfo. >> >> If you'd really like that functionality you may add a new function that >> gets the rfc-xxx ID. Then maybe add an option to certtool to use it. > >Ah, this is an interesting approach.? The more i've thought about this, >the more i think GnuTLS is doing the right thing, and the "common >method" is actually misguided. > >One reason i'd want this is (for example) to implement some sort of >pinning infrastructure for a tool that builds a table of pins indicated >by keyID. > >However, since the two most acive pinning proposals actually use >GnuTLS's style of KeyID derivation, i think this isn't a good reason to >implement the "common method" in GnuTLS. > >> I don't really see why would this increase interoperability. The >> authority key ID field is transparently read by implementations and >> compared with the subject key ID of the CA certificate. There is no >> other action done. Could you elaborate? > >given what i now understand about the state of the infrastructure, i >think you're right that there isn't much of a win here. > >Given that the certificates in question can be given arbitrary >subjectKeyIdentifiers, and that many TLS stacks (like browsers) keep a >cache of previously-seen certs, i wonder if a malicious server could jam >up the cert processing by feeding the browser a bunch of bogus >certificates with colliding identifiers.? This is probably not something >we can resolve in GnuTLS, though. > >So i think the only thing that remains is to document why this is a >divergence from the RFC's "Common Method" -- and i think we have several >good reasons. > >Nikos, would you be averse to a changeset that adds a bit of >documentation about how this distinction is made? > >Regards, > >??????? --dkg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cloos at jhcloos.com Sat Mar 9 02:43:56 2013 From: cloos at jhcloos.com (James Cloos) Date: Fri, 08 Mar 2013 20:43:56 -0500 Subject: [gnutls-devel] gnutls-cli --dane vs --port names Message-ID: I just noticed that, when gnutls-cli is called with --dane and --port, using a port name rather than a port number, even though it resolves the port to a number for the socket, it fails to snprintf(3) that for creating the tlsa lookup. Eg, works find, but the equivilent fails. The connect(2) of course works fine, only the tlsa lookup is affected. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nmav at gnutls.org Sun Mar 10 10:45:57 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Mar 2013 10:45:57 +0100 Subject: [gnutls-devel] gnutls-cli --dane vs --port names In-Reply-To: References: Message-ID: <513C5655.5090204@gnutls.org> On 03/09/2013 02:43 AM, James Cloos wrote: > I just noticed that, when gnutls-cli is called with --dane and --port, > using a port name rather than a port number, even though it resolves > the port to a number for the socket, it fails to snprintf(3) that for > creating the tlsa lookup. > > Eg, works find, but the > equivilent fails. Indeed there is an issue there. I've committed a fix in the repository. Thank you for reporting that. regards, Nikos From dokumentarfilme at hotmail.com Mon Mar 11 20:48:52 2013 From: dokumentarfilme at hotmail.com (.uservorname .usernachname) Date: Mon, 11 Mar 2013 19:48:52 +0000 Subject: [gnutls-devel] x509: common.c:51:66: error: 'ASN1_ETYPE_INVALID' undeclared here (not in a function) In-Reply-To: <513535A4.1010900@gnutls.org> References: , <513535A4.1010900@gnutls.org> Message-ID: Hi, after reinstalling the new libtasn1 and removing the old one I was able to compile gnutls-3.1.7. Many thanks! regards, martin ---------------------------------------- > Date: Tue, 5 Mar 2013 01:00:36 +0100 > From: nmav at gnutls.org > To: dokumentarfilme at hotmail.com; bugs at gnutls.org > Subject: Re: [gnutls-devel] x509: common.c:51:66: error: 'ASN1_ETYPE_INVALID' undeclared here (not in a function) > > On 03/04/2013 11:39 PM, .uservorname .usernachname wrote: > > > Greetings, when trying to compile gnutls-3.1.7 with make it breaks with:fes-a120d19nas:/backup/fes-a120d19nas/zarafa/gnutls-3.1.7# m > > > Please configure your mailer to send sensible (not html) mails. I see > your whole mail in a single line. In any case, it seems that you have > installed an old version of libtasn1 which conflicts with the included > in gnutls. > > Either upgrade your libtasn1 or remove its development files. > > regards, > Nikos From dkg at fifthhorseman.net Wed Mar 13 00:23:18 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 12 Mar 2013 19:23:18 -0400 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: <5137D9D8.2040608@gnutls.org> References: <87vc96qku3.fsf@alice.fifthhorseman.net> <5136715D.1040103@gnutls.org> <5137C065.9040002@fifthhorseman.net> <5137D9D8.2040608@gnutls.org> Message-ID: <513FB8E6.3060105@fifthhorseman.net> On 03/06/2013 07:05 PM, Nikos Mavrogiannopoulos wrote: > On 03/06/2013 11:17 PM, Daniel Kahn Gillmor wrote: > >> So i think the only thing that remains is to document why this is a >> divergence from the RFC's "Common Method" -- and i think we have several >> good reasons. >> Nikos, would you be averse to a changeset that adds a bit of >> documentation about how this distinction is made? > > This would be good. I've just pushed 7381666 to the master branch with a concise summary of the difference between GnuTLS's method and the "Common Method" for choosing a key ID. Nikos, as always, please let me know if you think the commit is problematic in any way. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From home_pw at msn.com Wed Mar 13 00:40:57 2013 From: home_pw at msn.com (Peter Williams) Date: Tue, 12 Mar 2013 16:40:57 -0700 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: <513FB8E6.3060105@fifthhorseman.net> References: <87vc96qku3.fsf@alice.fifthhorseman.net> <5136715D.1040103@gnutls.org> <5137C065.9040002@fifthhorseman.net> <5137D9D8.2040608@gnutls.org> <513FB8E6.3060105@fifthhorseman.net> Message-ID: Can u say why this was so important. To me, on one level, it's the difference between binary vs denary. Ie. who cares (once you have a certain education level)? Sent from my iPhone On Mar 12, 2013, at 4:24 PM, "Daniel Kahn Gillmor" wrote: > On 03/06/2013 07:05 PM, Nikos Mavrogiannopoulos wrote: >> On 03/06/2013 11:17 PM, Daniel Kahn Gillmor wrote: >> >>> So i think the only thing that remains is to document why this is a >>> divergence from the RFC's "Common Method" -- and i think we have several >>> good reasons. >>> Nikos, would you be averse to a changeset that adds a bit of >>> documentation about how this distinction is made? >> >> This would be good. > > I've just pushed 7381666 to the master branch with a concise summary of > the difference between GnuTLS's method and the "Common Method" for > choosing a key ID. Nikos, as always, please let me know if you think > the commit is problematic in any way. > > Regards, > > --dkg > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From n.mavrogiannopoulos at gmail.com Wed Mar 13 19:46:17 2013 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 13 Mar 2013 19:46:17 +0100 Subject: [gnutls-devel] X.509 "Key Identifiers" in GnuTLS In-Reply-To: <513FB8E6.3060105@fifthhorseman.net> References: <87vc96qku3.fsf@alice.fifthhorseman.net> <5136715D.1040103@gnutls.org> <5137C065.9040002@fifthhorseman.net> <5137D9D8.2040608@gnutls.org> <513FB8E6.3060105@fifthhorseman.net> Message-ID: <5140C979.80403@gmail.com> On 03/13/2013 12:23 AM, Daniel Kahn Gillmor wrote: > On 03/06/2013 07:05 PM, Nikos Mavrogiannopoulos wrote: >> On 03/06/2013 11:17 PM, Daniel Kahn Gillmor wrote: >> >>> So i think the only thing that remains is to document why this is a >>> divergence from the RFC's "Common Method" -- and i think we have several >>> good reasons. >>> Nikos, would you be averse to a changeset that adds a bit of >>> documentation about how this distinction is made? >> >> This would be good. > > I've just pushed 7381666 to the master branch with a concise summary of > the difference between GnuTLS's method and the "Common Method" for > choosing a key ID. Nikos, as always, please let me know if you think > the commit is problematic in any way. Hello, Maybe it is better to add it as text to the corresponding functions, that have the behavior that you describe i.e. get_key_id(). I'd also form it like: "That function calculates a SHA1 digest of the public key as a DER-formatted, subjectPublicKeyInfo object. Other implementations use different approaches (some use the ``common method'' described by section 4.2.1.2 of RFC5280 which calculates a digest on a part of the subjectPublicKeyInfo object)." regards, Nikos From BHC at insight.dk Thu Mar 21 14:51:52 2013 From: BHC at insight.dk (=?iso-8859-1?Q?Bj=F8rn_H=2E_Christensen?=) Date: Thu, 21 Mar 2013 13:51:52 +0000 Subject: [gnutls-devel] Upgrade from 2.10.1 to 3.0.18 caused my external signing stop working. Message-ID: I know that the code have been depreciated, but I can see it is still there: I am using : gnutls_certificate_client_set_retrieve_function gnutls_sign_callback_set to use Certificates from the Microsoft Certificate Store. I am using version 3.0.18 and in gnutls_sig.c in the function sign_tls_hash on line 228. The use of pkey seems wrong. Make sure that pkey is null. Then pass null to gnutls_privkey_get_pk_algorithm, that again use the pkey as a pointer but if it is null it will fail. /* External signing. Deprecated. To be removed. */ if (!pkey) { int ret; if (!session->internals.sign_func) return gnutls_assert_val(GNUTLS_E_INSUFFICIENT_CREDENTIALS); if (!_gnutls_version_has_selectable_sighash (ver)) return (*session->internals.sign_func) (session, session->internals.sign_func_userdata, cert->type, &cert->cert, hash_concat, signature); else { gnutls_datum_t digest; ret = _gnutls_set_datum(&digest, hash_concat->data, hash_concat->size); if (ret < 0) return gnutls_assert_val(ret); ret = pk_prepare_hash (gnutls_privkey_get_pk_algorithm(pkey, NULL), hash_algo, &digest); if (ret < 0) { gnutls_assert (); goto es_cleanup; } ret = (*session->internals.sign_func) (session, session->internals.sign_func_userdata, cert->type, &cert->cert, &digest, signature); es_cleanup: gnutls_free(digest.data); return ret; } } PS: I have seen the function gnutls_privkey_import_ext2 Do you have examples on the function to pass. /bhc -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Mar 21 16:07:48 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 21 Mar 2013 16:07:48 +0100 Subject: [gnutls-devel] Upgrade from 2.10.1 to 3.0.18 caused my external signing stop working. In-Reply-To: References: Message-ID: On Thu, Mar 21, 2013 at 2:51 PM, Bj?rn H. Christensen wrote: > I know that the code have been depreciated, but I can see it is still there: > I am using : > gnutls_certificate_client_set_retrieve_function > gnutls_sign_callback_set > to use Certificates from the Microsoft Certificate Store. > I am using version 3.0.18 and in gnutls_sig.c in the function sign_tls_hash > on line 228. > The use of pkey seems wrong. Nice catch. Note however, that this issue should only occur if you use TLS 1.2. If you restrict to TLS 1.0 or 1.1 there should be no issues. I will see whether there can be a hack to solve that, or just return an error in case TLS 1.2 is mixed with the deprecated function. To use gnutls_privkey_import_ext2() check lib/tpm.c. regards, Nikos From BHC at insight.dk Thu Mar 21 16:11:22 2013 From: BHC at insight.dk (=?utf-8?B?QmrDuHJuIEguIENocmlzdGVuc2Vu?=) Date: Thu, 21 Mar 2013 15:11:22 +0000 Subject: [gnutls-devel] Upgrade from 2.10.1 to 3.0.18 caused my external signing stop working. In-Reply-To: References: Message-ID: Thanks for the prompt answer Nikos. /bhc -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: 21. marts 2013 16:08 To: Bj?rn H. Christensen Cc: bugs at gnutls.org Subject: Re: [gnutls-devel] Upgrade from 2.10.1 to 3.0.18 caused my external signing stop working. On Thu, Mar 21, 2013 at 2:51 PM, Bj?rn H. Christensen wrote: > I know that the code have been depreciated, but I can see it is still there: > I am using : > gnutls_certificate_client_set_retrieve_function > gnutls_sign_callback_set > to use Certificates from the Microsoft Certificate Store. > I am using version 3.0.18 and in gnutls_sig.c in the function > sign_tls_hash on line 228. > The use of pkey seems wrong. Nice catch. Note however, that this issue should only occur if you use TLS 1.2. If you restrict to TLS 1.0 or 1.1 there should be no issues. I will see whether there can be a hack to solve that, or just return an error in case TLS 1.2 is mixed with the deprecated function. To use gnutls_privkey_import_ext2() check lib/tpm.c. regards, Nikos From BHC at insight.dk Thu Mar 21 16:19:48 2013 From: BHC at insight.dk (=?utf-8?B?QmrDuHJuIEguIENocmlzdGVuc2Vu?=) Date: Thu, 21 Mar 2013 15:19:48 +0000 Subject: [gnutls-devel] Upgrade from 2.10.1 to 3.0.18 caused my external signing stop working. In-Reply-To: References: Message-ID: Hello Nikos, Excluding TLS1.2 worked. Checking patch tomorrow, will let you know the result, I saw a similar somewhere else in the code. /bhc -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: 21. marts 2013 16:08 To: Bj?rn H. Christensen Cc: bugs at gnutls.org Subject: Re: [gnutls-devel] Upgrade from 2.10.1 to 3.0.18 caused my external signing stop working. On Thu, Mar 21, 2013 at 2:51 PM, Bj?rn H. Christensen wrote: > I know that the code have been depreciated, but I can see it is still there: > I am using : > gnutls_certificate_client_set_retrieve_function > gnutls_sign_callback_set > to use Certificates from the Microsoft Certificate Store. > I am using version 3.0.18 and in gnutls_sig.c in the function > sign_tls_hash on line 228. > The use of pkey seems wrong. Nice catch. Note however, that this issue should only occur if you use TLS 1.2. If you restrict to TLS 1.0 or 1.1 there should be no issues. I will see whether there can be a hack to solve that, or just return an error in case TLS 1.2 is mixed with the deprecated function. To use gnutls_privkey_import_ext2() check lib/tpm.c. regards, Nikos From nmav at gnutls.org Fri Mar 22 19:10:37 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Mar 2013 19:10:37 +0100 Subject: [gnutls-devel] gnutls 3.0.29 Message-ID: <514C9E9D.5080807@gnutls.org> Hello, I've just released gnutls 3.0.29. This is a bug-fix release on the previous stable branch. That release also adds limited support for the android environment. * Version 3.0.29 (released 2013-03-22) ** certtool: When generating PKCS #12 files use by default the ARCFOUR (RC4) cipher to be compatible with devices that don't support AES with PKCS #12. ** libgnutls: Corrected issue in gnutls_pubkey_verify_data(). ** libgnutls: gnutls_pkcs11_reinit() will reinitialize all PKCS #11 modules, and not only the ones loaded via p11-kit. ** libgnutls: Load CA certificates in android 4.x systems. ** libgnutls: Corrected issue in the (deprecated) external key signing interface, when used with TLS 1.2. Reported by Bjorn H. Christensen. ** libgnutls: PKCS #11 slots are scanned only when needed, not on initialization. This speeds up gnutls initialization when smart cards are present. ** libgnutls: Fixes in openpgp handshake with fingerprints. Reported by Joke de Buhr. ** configure: Trust store file must be explicitly set or unset when cross compiling. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.29.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.29.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.29.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.29.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Mar 22 19:47:15 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Mar 2013 19:47:15 +0100 Subject: [gnutls-devel] gnutls 3.1.10 Message-ID: <514CA733.5080800@gnutls.org> Hello, I've just released gnutls 3.1.10. This release adds new features and fixed bugs on the current stable branch. It also adds support for the Android system (i.e., loading the trust store, but in a more efficient way than the 3.0.x branch). * Version 3.1.10 (released 2013-03-22) ** certtool: When generating PKCS #12 files use by default the ARCFOUR (RC4) cipher to be compatible with devices that don't support AES with PKCS #12. ** libgnutls: Load CA certificates in android 4.x systems. ** libgnutls: Optimized CA certificate loading. ** libgnutls: Private keys are overwritten on deinitialization. ** libgnutls: PKCS #11 slots are scanned only when needed, not on initialization. This speeds up gnutls initialization when smart cards are present. ** libgnutls: Corrected issue in the (deprecated) external key signing interface, when used with TLS 1.2. Reported by Bjorn H. Christensen. ** libgnutls: Fixes in openpgp handshake with fingerprints. Reported by Joke de Buhr. ** libgnutls-dane: Updated DANE verification options. ** configure: Trust store file must be explicitly set or unset when cross compiling. ** API and ABI modifications: gnutls_x509_crt_get_issuer_dn2: Added gnutls_x509_crt_get_dn2: Added gnutls_x509_crl_get_issuer_dn2: Added gnutls_x509_crq_get_dn2: Added gnutls_x509_trust_list_remove_trust_mem: Added gnutls_x509_trust_list_remove_trust_file: Added gnutls_x509_trust_list_remove_cas: Added gnutls_session_get_desc: Added gnutls_privkey_sign_raw_data: Added gnutls_privkey_status: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.10.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.10.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.10.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.10.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Mar 22 19:57:52 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Mar 2013 19:57:52 +0100 Subject: [gnutls-devel] gnutls 3.1.10 In-Reply-To: <514CA733.5080800@gnutls.org> References: <514CA733.5080800@gnutls.org> Message-ID: <514CA9B0.7050107@gnutls.org> On 03/22/2013 07:47 PM, Nikos Mavrogiannopoulos wrote: > I've just released gnutls 3.1.10. This release adds new features and > fixed bugs on the current stable branch. It also adds support for the > Android system (i.e., loading the trust store, but in a more efficient > way than the 3.0.x branch). btw. I forgot to mention that the license was changed to LGPLv2.1+. regards, Nikos From dmoncayo at gmail.com Sat Mar 23 11:20:36 2013 From: dmoncayo at gmail.com (Dani Moncayo) Date: Sat, 23 Mar 2013 11:20:36 +0100 Subject: [gnutls-devel] GnuTLS 3.1.9 for Windows Message-ID: Hello, Version 3.1.9 of GnuTLS was released on 2013-02-27, but I don't yet see a port for MS-Windows available at ftp://ftp.gnutls.org/gcrypt/gnutls/w32/. When do you plan to publish such a port? Thanks. -- Dani Moncayo From nmav at gnutls.org Sat Mar 23 13:46:00 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 23 Mar 2013 13:46:00 +0100 Subject: [gnutls-devel] GnuTLS 3.1.9 for Windows In-Reply-To: References: Message-ID: <514DA408.1030607@gnutls.org> On 03/23/2013 11:20 AM, Dani Moncayo wrote: > Hello, > > Version 3.1.9 of GnuTLS was released on 2013-02-27, but I don't yet > see a port for MS-Windows available at > ftp://ftp.gnutls.org/gcrypt/gnutls/w32/. > When do you plan to publish such a port? I don't update the windows binaries that often. You may generate them using the cross.mk in the distribution. Nevertheless, I've just put the 3.1.10 binaries. regards, Nikos From ametzler at downhill.at.eu.org Sun Mar 24 18:45:20 2013 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 24 Mar 2013 18:45:20 +0100 Subject: [gnutls-devel] gnutls 3.1.10 In-Reply-To: <514CA9B0.7050107@gnutls.org> References: <514CA733.5080800@gnutls.org> <514CA9B0.7050107@gnutls.org> Message-ID: <20130324174520.GA3310@downhill.g.la> On 2013-03-22 Nikos Mavrogiannopoulos wrote: > On 03/22/2013 07:47 PM, Nikos Mavrogiannopoulos wrote: > > I've just released gnutls 3.1.10. This release adds new features and > > fixed bugs on the current stable branch. It also adds support for the > > Android system (i.e., loading the trust store, but in a more efficient > > way than the 3.0.x branch). > btw. I forgot to mention that the license was changed to LGPLv2.1+. Hello, there are still a couple of old (v3) copyright headers around: ametzler at argenau:/tmp/GNUTLS$ grep -rl 'either version 3' gnutls-3.1.10/lib | grep -v Makefile gnutls-3.1.10/lib/ext/heartbeat.h gnutls-3.1.10/lib/ext/status_request.h gnutls-3.1.10/lib/ext/heartbeat.c gnutls-3.1.10/lib/libgnutls.map gnutls-3.1.10/lib/accelerated/x86/macosx/cpuid-x86-64-macosx.s gnutls-3.1.10/lib/accelerated/x86/macosx/cpuid-x86-macosx.s gnutls-3.1.10/lib/accelerated/x86/elf/cpuid-x86-64.s gnutls-3.1.10/lib/accelerated/x86/elf/cpuid-x86.s gnutls-3.1.10/lib/accelerated/x86/coff/cpuid-x86-64-coff.s gnutls-3.1.10/lib/accelerated/x86/coff/cpuid-x86-coff.s gnutls-3.1.10/lib/gnutlsxx.cpp gnutls-3.1.10/lib/x509/verify-high.h gnutls-3.1.10/lib/includes/gnutls/gnutls.h.in gnutls-3.1.10/lib/includes/gnutls/x509.h gnutls-3.1.10/lib/includes/gnutls/ocsp.h I guess for most of these (except for heartbeat.{h,c} and perhaps gnutlsxx.cpp) the header should switch to v2.1. (For .s this involves changing devel/perlasm/license-gnutls.txt and regenerating.) thanks, 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' From nmav at gnutls.org Sun Mar 24 20:14:22 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 24 Mar 2013 20:14:22 +0100 Subject: [gnutls-devel] gnutls 3.1.10 In-Reply-To: <20130324174520.GA3310@downhill.g.la> References: <514CA733.5080800@gnutls.org> <514CA9B0.7050107@gnutls.org> <20130324174520.GA3310@downhill.g.la> Message-ID: <514F508E.4010506@gnutls.org> On 03/24/2013 06:45 PM, Andreas Metzler wrote: > On 2013-03-22 Nikos Mavrogiannopoulos wrote: >> On 03/22/2013 07:47 PM, Nikos Mavrogiannopoulos wrote: > >>> I've just released gnutls 3.1.10. This release adds new features and >>> fixed bugs on the current stable branch. It also adds support for the >>> Android system (i.e., loading the trust store, but in a more efficient >>> way than the 3.0.x branch). >> btw. I forgot to mention that the license was changed to LGPLv2.1+. > Hello, > there are still a couple of old (v3) copyright headers around: Thanks. I've now updated them too (except for the heartbeat files). regards, Nikos From mike at vee.net Mon Mar 4 05:34:12 2013 From: mike at vee.net (Michael Gratton) Date: Mon, 04 Mar 2013 04:34:12 -0000 Subject: [gnutls-devel] SIGSEGV in _gnutls_ciphertext2compressed Message-ID: <51341D10.9010605@vee.net> Using Epiphany, loading a HTTP URL that redirects to a HTTPS URL, results in the attached stack trace. Ubuntu 12.10 libgnutls26:amd64 2.12.14-5ubuntu4.2 Cheers, //Mike -- ? Michael Gratton, Percept Wrangler. ? -------------- next part -------------- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff82418700 (LWP 29654)] 0x00007fffdd65bd56 in _gnutls_ciphertext2compressed (session=session at entry=0x19aea40, compress_data=compress_data at entry=0x7fff740046c0 "\001", compress_size=compress_size at entry=18432, ciphertext=..., type=, params=params at entry=0x7fff74001160) at gnutls_cipher.c:572 572 gnutls_cipher.c: No such file or directory. (gdb) bt #0 0x00007fffdd65bd56 in _gnutls_ciphertext2compressed (session=session at entry=0x19aea40, compress_data=compress_data at entry=0x7fff740046c0 "\001", compress_size=compress_size at entry=18432, ciphertext=..., type=, params=params at entry=0x7fff74001160) at gnutls_cipher.c:572 #1 0x00007fffdd65bf73 in _gnutls_decrypt (session=session at entry=0x19aea40, ciphertext=ciphertext at entry=0x7fff74003cd5 ";U\333:\231\331&X\\\273\213\203\263\230\363\222\324O\312'", ciphertext_size=ciphertext_size at entry=24, data=data at entry=0x7fff740046c0 "\001", max_data_size=18432, type=type at entry=GNUTLS_ALERT, params=0x7fff74001160) at gnutls_cipher.c:148 #2 0x00007fffdd6599db in _gnutls_recv_int (session=session at entry=0x19aea40, type=type at entry=GNUTLS_HANDSHAKE, htype=htype at entry=GNUTLS_HANDSHAKE_FINISHED, data=data at entry=0x19af020 "\016", sizeofdata=sizeofdata at entry=1) at gnutls_record.c:1068 #3 0x00007fffdd65d6fc in _gnutls_handshake_io_recv_int (session=session at entry=0x19aea40, type=type at entry=GNUTLS_HANDSHAKE, htype=htype at entry=GNUTLS_HANDSHAKE_FINISHED, iptr=iptr at entry=0x19af020, sizeOfPtr=sizeOfPtr at entry=1) at gnutls_buffers.c:889 #4 0x00007fffdd660815 in _gnutls_recv_handshake_header (recv_type=, type=GNUTLS_HANDSHAKE_FINISHED, session=0x19aea40) at gnutls_handshake.c:1285 #5 _gnutls_recv_handshake (session=session at entry=0x19aea40, data=data at entry=0x7fff82417aa8, datalen=datalen at entry=0x7fff82417aa4, type=type at entry=GNUTLS_HANDSHAKE_FINISHED, optional=optional at entry=MANDATORY_PACKET) at gnutls_handshake.c:1447 #6 0x00007fffdd66128f in _gnutls_recv_finished (session=0x19aea40) at gnutls_handshake.c:748 #7 _gnutls_recv_handshake_final (session=session at entry=0x19aea40, init=init at entry=0) at gnutls_handshake.c:2956 #8 0x00007fffdd661684 in _gnutls_handshake_common (session=session at entry=0x19aea40) at gnutls_handshake.c:3138 #9 0x00007fffdd662dea in gnutls_handshake (session=0x19aea40) at gnutls_handshake.c:2690 #10 0x00007fffdd92e5fd in ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so #11 0x00007ffff2c54e3e in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #12 0x00007ffff2c43236 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 ---Type to continue, or q to quit--- #13 0x00007ffff1eb2e62 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x00007ffff1eb2645 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x00007ffff1c31e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #16 0x00007ffff195ecbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #17 0x0000000000000000 in ?? () (gdb) quit -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: