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.
--
-------------------------------------
address@hidden | 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 ---
