The attached message was sent earlier this year to oss-security, implying that gnutls does not properly honor pathLenConstraint:
http://openwall.com/lists/oss-security/2012/06/27/5 I'm unable to replicate the reported results with GnuTLS 2.8.6 (debian squeeze), 3.0.22 (debian sid) or 3.1 (debian experimental). What i see is (sid and experimental): 0 dkg@pip:/tmp/certtest$ cat local-cert.pem Mengsk.pem sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e Loaded 5 certificates, 1 CAs and 0 CRLs Subject: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001 Issuer: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA Output: Not verified. Chain verification output: Not verified. 1 dkg@pip:/tmp/certtest$ or (squeeze): 0 dkg@stable:~/certtest$ cat local-cert.pem Mengsk.pem sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e Certificate[0]: C=KR,O=Tanaris,CN=localhost Issued by: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk Certificate Authority Verifying against certificate[1]. Verification output: Verified. Certificate[1]: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk Certificate Authority Issued by: C=KR,O=Government of Korea,OU=Group of Server,OU=교육과학기 술부,CN=sms.hallym.ac.kr Verifying against certificate[2]. Verification output: Verified. Certificate[2]: C=KR,O=Government of Korea,OU=Group of Server,OU=교육과 학기술부,CN=sms.hallym.ac.kr Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001 Verifying against certificate[3]. Verification output: Verified. Certificate[3]: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001 Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA Verifying against certificate[4]. Verification output: Not verified. Certificate[4]: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=GPKIRootCA Verification output: Verified. Chain verification output: Not verified. 0 dkg@stable:~/certtest$ I'm happy to follow up to the original reporter, but i want to be sure that i understand what's going on. any pointers or suggestions? --dkg
--- Begin Message ---List, just an FYI, I've noticed a Korean CA appears to always set the cA bit in the X.509 basicContraints, then uses pathLenConstraint and keyUsage bits to restrict the results. I have no idea what crazy software they're using that generates these certificates, but they're in the Microsoft trusted certificate store on all Windows machines, and are therefore possibly (probably?) cross-signed from other CAs. Maybe someone can check the EFF corpus if there is interest. While arguably the X.509 specifications permit this, I find it hard to believe that these bits are checked consistently by all implementations. AFAICT, GnuTLS does not check these constraints, but OpenSSL does. I've produced an example from one of the weaker certificates, hopefully you can use this to check whatever implementation you're using handles this correctly. If you get an error about pathLen exceeded, or improper usage, then it's probably good. If you get a message about revokation or some other error about canonicalization*, then you might have a problem. $ cat local-cert.pem Mengsk.pem sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e Certificate[0]: C=KR,O=Tanaris,CN=localhost Issued by: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk Certificate Authority Verifying against certificate[1]. Verification output: Verified. Certificate[1]: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk Certificate Authority Issued by: C=KR,O=Government of Korea,OU=Group of Server,OU=,CN=sms.hallym.ac.kr Verifying against certificate[2]. Verification output: Verified. Certificate[2]: C=KR,O=Government of Korea,OU=Group of Server,OU=,CN=sms.hallym.ac.kr Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001 Verifying against certificate[3]. Verification output: Verified. Microsoft asked them to revoke these certificates earlier this month, but they publish CRL via ldap, so I don't know if these are really visible. Regardless, I think it's important to verify that implementations handle these combinations of constraints. Tavis. * The problem with canonicalization is the subjectName/issuerName DN should be canonicalized, but this isnt always implemented. In this case the PrintableString doesnt match the UTF8String. If this is the only problem with the chain reported, then there is a bug. -- ------------------------------------- tav...@cmpxchg8b.com | pgp encrypted mail preferred -------------------------------------------------------
CA134040001.pem
Description: Binary data
GPKIRootCA.pem
Description: Binary data
local-cert.pem
Description: Binary data
Mengsk.pem
Description: Binary data
sms.hallym.ac.kr.pem
Description: Binary data
--- End Message ---
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help-gnutls mailing list Help-gnutls@gnu.org https://lists.gnu.org/mailman/listinfo/help-gnutls