Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
Hi Viktor, After more testing, it appears that the issue cannot be reproduced with all my certificates but only some of them. I put attached details about the cert I use most of the time. Thanks William -Message d'origine- De : Viktor Tarasov [mailto:viktor.tara...@gmail.com] Envoyé : vendredi 3 juin 2011 16:53 À : Viktor Tarasov Cc : HOURY William; opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1 Le 03/06/2011 09:21, Viktor Tarasov a écrit : Le 03/06/2011 09:06, HOURY William a écrit : Hi Viktor, I have other middlewares installed but I have disabled all the proprietary certificate propagation tools and only activated the windows one (the sccertprop registry value is well set). Ok, once more it hasn't worked. Thank you. Will try to reproduce. For a while I cannot reproduce. The test was done with the card: Athena ASEPCOS atr: 3b:d6:18:00:81:b1:80:7d:1f:03:80:51:00:61:10:30:8f. Card initialized with the following commands: # pkcs15-init -E # pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin --puk Pkcs#12 with the 'SmartcardLogon' + 'Client Authentication' certificate is imported by : # pkcs15-init -a 53434D --label basic user smartcard logon -S basic_user.p12 -f pkcs12 --passphrase coucou --so-pin 12345678 --pin --key-usage digitalSignature,dataEncipherment --cert-label basic user smartcard logon (Don't know why with the key usage derived from the certificate extensions it's not worked.) The first login to AD on the XP platform is OK . Also works the sequence 'clean-up personal key store' log-off log-in. Kind regards, Viktor. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Certificate: Data: Version: 3 (0x2) Serial Number: 71:7e:23:21:00:00:00:00:02:68 Signature Algorithm: sha1WithRSAEncryption Issuer: commonName= AOFR37621 domainComponent = pmtdom domainComponent = local Validity Not Before: Jun 1 08:08:19 2011 GMT Not After : May 31 08:08:19 2012 GMT Subject: emailAddress = commonName= Benoit BL. Lotito organizationalUnitName= organizationName = localityName = MDS stateOrProvinceName = countryName = Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c2:d6:f7:99:2d:60:e2:02:1b:91:e4:c2:79:99: a4:9c:93:0d:ec:4f:92:db:35:57:a6:9b:91:4a:31: 5b:4b:5e:b6:41:65:df:2f:6b:b9:2f:dc:33:ee:8d: 34:8d:32:63:f3:86:85:f9:86:6d:83:15:c6:dd:8f: 93:06:d3:6e:d0:76:d9:9b:51:1c:cc:9c:22:8a:af: 1b:68:68:0a:ad:8f:3f:5f:2d:81:51:ec:9b:7f:ec: f8:10:f1:87:62:0f:8f:62:c1:ed:f4:8a:f9:5c:a8: ea:c2:29:07:4f:d5:6a:d6:f7:9e:53:81:9b:af:9d: 8b:a6:4a:8f:dd:a1:bd:3e:9f Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.7: 0-.%+.7.j..d... X509v3 Subject Alternative Name: othername:unsupported X509v3 Subject Key Identifier: 57:DE:4F:71:10:4C:94:D1:89:C4:AB:F7:6F:D4:AB:44:CD:A2:48:9C X509v3 Authority Key Identifier:
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
Le 06/06/2011 09:46, HOURY William a écrit : Hi Viktor, After more testing, it appears that the issue cannot be reproduced with all my certificates but only some of them. I put attached details about the cert I use most of the time. Does there any difference between this certificate and the ones that are going well for you? I have no deep insight into the smartcard logon. Here attached the certificate that works for me with Athena ASEPCOS card, maybe I'll find a crucial difference with your test certificate. Thanks William Kind wishes, Viktor. -Message d'origine- De : Viktor Tarasov [mailto:viktor.tara...@gmail.com] Envoyé : vendredi 3 juin 2011 16:53 À : Viktor Tarasov Cc : HOURY William; opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1 Le 03/06/2011 09:21, Viktor Tarasov a écrit : Le 03/06/2011 09:06, HOURY William a écrit : Hi Viktor, I have other middlewares installed but I have disabled all the proprietary certificate propagation tools and only activated the windows one (the sccertprop registry value is well set). Ok, once more it hasn't worked. Thank you. Will try to reproduce. For a while I cannot reproduce. The test was done with the card: Athena ASEPCOS atr: 3b:d6:18:00:81:b1:80:7d:1f:03:80:51:00:61:10:30:8f. Card initialized with the following commands: # pkcs15-init -E # pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin --puk Pkcs#12 with the 'SmartcardLogon' + 'Client Authentication' certificate is imported by : # pkcs15-init -a 53434D --label basic user smartcard logon -S basic_user.p12 -f pkcs12 --passphrase coucou --so-pin 12345678 --pin --key-usage digitalSignature,dataEncipherment --cert-label basic user smartcard logon (Don't know why with the key usage derived from the certificate extensions it's not worked.) The first login to AD on the XP platform is OK . Also works the sequence 'clean-up personal key store' log-off log-in. Kind regards, Viktor. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. subject=/O=OpenTrust/OU=SCM/CN=basic_user issuer=/C=FR/O=MONENTREPRISE/CN=MONENTREPRISE AUTH CA -BEGIN CERTIFICATE- MIIDjTCCAnWgAwIBAgICCp8wDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCRlIx FjAUBgNVBAoMDU1PTkVOVFJFUFJJU0UxHjAcBgNVBAMMFU1PTkVOVFJFUFJJU0Ug QVVUSCBDQTAeFw0xMTA2MDMxMzI5MDZaFw0xMjA2MDMxMzI5MDZaMDcxEjAQBgNV BAoMCU9wZW5UcnVzdDEMMAoGA1UECwwDU0NNMRMwEQYDVQQDDApiYXNpY191c2Vy MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDiOuJUoBuCZbgUt7YEY0U/JDpB b9pxSpo/fAohZaA17BbC5Z2DMC7t8Z6SToNUO8TuO5i2WwWXt29mRMs3XxD8Y/PE 3DdpQGYOZZDSA2Uk50kVfhffx1LqU9nFsZTNSttPIEQAATnhIaFu5Ufi8Ol4TCLU Ns14HAXuUUfPWaJacwIDAQABo4IBFzCCARMwHQYDVR0OBBYEFEF599EgHekT2u5V 6fXMqa0iQaBwMB8GA1UdIwQYMBaAFEOvAJuqlUhOiLggJ9waS6RT14+qMB8GA1Ud JQQYMBYGCCsGAQUFBwMCBgorBgEEAYI3FAICMA4GA1UdDwEB/wQEAwIHgDBGBgNV HREEPzA9oDsGCisGAQQBgjcUAgOgLQwrYmFzaWNfdXNlckBzZWNyZXRkZWZlbnNl Lm1vbmVudHJlcHJpc2UudGVzdDBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vbW9u ZW50cmVwcmlzZS1wa2kucWEub3BlbnRydXN0LmNvbS9yZXBsYWNlLXdpdGgtQ1JM LWZpbGVuYW1lLmNybDANBgkqhkiG9w0BAQUFAAOCAQEASfZP0CxfqYhL8elR6uLc 9plYTuL+iY/AZBSUQmddAHEt7Zc/kHIGtxGMY2wVT3s9Xg05gbLbqccFaFulQau4 SwoAwOExvfgkwUIVnh1hEN2MX4Ggn9xdrM9S99fRdj7lR2dw/KyXS3++Xuyviqio 3lKX1zhYNJw31tSPtcqtxlYndiGug09hnO5BSq4z8x2/Z8ZzbnxRQYuSR4W7600L b3TnTyR+bGj5G96L8xrqc2W+q+WkR2WKD+hvRhIm6iliLG6vU1kOqT6nWo8rmTHI wU9Z5kbAu0u/4CXDG7jKo29zMRuVDRuSti7abZI2+bpw9I9NLhsvXSGQC2r/eNWe 1g== -END CERTIFICATE- ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
Hello, Just a quick notice that a section about certificate compatibility seems justified somewhere in documentation. I recently debugged an issue where OpenSC.tokend did not seem to work (no certificates visible in Keychain.app) yet logs and everything else seemed to suggest that everything is OK. Indeed, replacing the certificate with a known good one (in fact from my eID card) made Keychain.app work and display the certificate (without any differences in logs) This mostly concerns people who create CA profiles or depend on a fixed CA scheme and try to use OpenSC but fail on some interface (like Minidriver or Tokend) Best, Martin On Mon, Jun 6, 2011 at 11:23, Viktor Tarasov viktor.tara...@gmail.com wrote: Le 06/06/2011 09:46, HOURY William a écrit : Hi Viktor, After more testing, it appears that the issue cannot be reproduced with all my certificates but only some of them. I put attached details about the cert I use most of the time. Does there any difference between this certificate and the ones that are going well for you? I have no deep insight into the smartcard logon. Here attached the certificate that works for me with Athena ASEPCOS card, maybe I'll find a crucial difference with your test certificate. Thanks William Kind wishes, Viktor. -Message d'origine- De : Viktor Tarasov [mailto:viktor.tara...@gmail.com] Envoyé : vendredi 3 juin 2011 16:53 À : Viktor Tarasov Cc : HOURY William; opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1 Le 03/06/2011 09:21, Viktor Tarasov a écrit : Le 03/06/2011 09:06, HOURY William a écrit : Hi Viktor, I have other middlewares installed but I have disabled all the proprietary certificate propagation tools and only activated the windows one (the sccertprop registry value is well set). Ok, once more it hasn't worked. Thank you. Will try to reproduce. For a while I cannot reproduce. The test was done with the card: Athena ASEPCOS atr: 3b:d6:18:00:81:b1:80:7d:1f:03:80:51:00:61:10:30:8f. Card initialized with the following commands: # pkcs15-init -E # pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin --puk Pkcs#12 with the 'SmartcardLogon' + 'Client Authentication' certificate is imported by : # pkcs15-init -a 53434D --label basic user smartcard logon -S basic_user.p12 -f pkcs12 --passphrase coucou --so-pin 12345678 --pin --key-usage digitalSignature,dataEncipherment --cert-label basic user smartcard logon (Don't know why with the key usage derived from the certificate extensions it's not worked.) The first login to AD on the XP platform is OK . Also works the sequence 'clean-up personal key store' log-off log-in. Kind regards, Viktor. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SVN-Git move.
On Jun 4, 2011, at 00:36 , Juan Antonio Martinez wrote: El jue, 02-06-2011 a las 20:34 +0200, Ludovic Rousseau escribió: 2011/6/2 Martin Paljak mar...@martinpaljak.net: A question: how many current commiters don't yet use Git (and/or git-svn) for OpenSC development? I :-) But I don't mind changing for Git. Current SVN commiters would have a Git repository each on opensc-project.org? Or only the official OpenSC version will be hosted at opensc-project.org? And you would pull from Git repositories hosted elsewhere? I've noticed that OpenSC is already at github.com [1], but not sure if github is ready to be used as OpenSC master for clonefork our own branches (Seems that svn contents is newer than github's) I deliberately did not set up automatic syncing from SVN to Github as I usually push to github after I've done some work (compiled, tried a card, something similar) with the state of SVN trunk. Best, -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SVN-Git move.
Hello, On Jun 2, 2011, at 21:34 , Ludovic Rousseau wrote: 2011/6/2 Martin Paljak mar...@martinpaljak.net: A question: how many current commiters don't yet use Git (and/or git-svn) for OpenSC development? I :-) But I don't mind changing for Git. Current SVN commiters would have a Git repository each on opensc-project.org? Or only the official OpenSC version will be hosted at opensc-project.org? And you would pull from Git repositories hosted elsewhere? I would not mind going for a 100% hosted solution in Github, as they do a nice job and have a lot of features not easily available elsewhere, with close to zero maintenance cost for projects. But to keep the content of the Trac in place, having a master which is a synced mirror of Github master on opensc-devel.org is needed, to be able to reference commits in tickets and wiki (or read it as having a mirror of the master on opensc-devel.org synced to github.com if you like) Git has a decentralized nature, so reaping the fruits of it is easy. My proposal is as follows: - master on opensc-project.org - for references in Trac - for independent backup, should something happen to github or they turn evil or ... - to have the fullest flexibility of scripting hooks for synchronization and whatnot - synced master on github.com - for easy to use communication features, like comments on commits with line level granularity - ease of forking and generic social coding - all of this with almost no maintenance costs. It makes it possible to convert commit accounts into git clone url-s. Choose whatever you like, be it github or some other public/free Git site or your own. Or on opensc-project.org if required, but I'd avoid the setup hassle if possible. The tricky question is how to set up additional autobuilders, which I consider essential for testing and releasing purposes. There are two options: - on request, for every developer's master branch, for all platforms, published to opensc-project.org/downloads/nightly/yourname/ - based on some agreed upon feature sets, either from specific trees or from agreed upon branches in the master repostirory, published to opensc-project.org/downloads/nightly/feature/ Ideally there could be three levels of builders: - master (mostly idle) which gets constructed every week or so from pulls from feature branches - feature branches (maintained by several people), along the lines of minidriver, mac, pkcs#11, bugfixes etc - developer builds (for every developer, for whatever he/she decides to keep in master) Building such feature branches nightly is essential for testing, so that meaningful changes can be tested and developed to a mature state separately from a release, where the availability of testable binary pre-releases or RC-s for a feature is continuous. This is of course all doable with SVN as well, but a lot easier with Git IMHO. Not to mention the added sweetness from converting to Git of course ;) Cheers, -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Change 5421 breaks MIT Kerberos login
Hello, On Jun 2, 2011, at 01:07 , Douglas E. Engert wrote: The change #5421 introduced between 0.12.1-rc1 and 0.12.1 on 5/4/11 by vtarasov breaks the MIT Kerberos login. A spy output is attached. The code calls C_GetSlotList with tokenPresent=1 which in the past has only returned slots with tokens. But #5421 returns 2 slots, the 0x virtual slot which does NOT have a token, and slot 1 which has a token. The code then tries C_OpenSession to the virtual slot which does not have a token and fails. This is also a place for improvement in the Kerberos software, as it should try to intelligently recover from the problem: Any Cryptoki function that uses a particular token (i.e., any Cryptoki function except for C_Initialize,C_Finalize, C_GetInfo, C_GetFunctionList, C_GetSlotList, C_GetSlotInfo, or C_WaitForSlotEvent) can return any of the following values: CKR_TOKEN_NOT_PRESENT: The token was not present in its slot at the time that the function was invoked. I don't know hot the configuration for Kerberos login works or how it locates the suitable slot, but this looks like a valid situation nevertheless. I don't understand why this change was made. If the virtual slot does not have a token, it should not be returned if tokenPresent=1. True. Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
Le 06/06/2011 11:22, Martin Paljak a écrit : Hello, Just a quick notice that a section about certificate compatibility seems justified somewhere in documentation. Yes, it would be very useful. I imagine that subtle expert knowledge of the subject is needed, for example when it's going about BaseCSP, minidriver, SmartcardLogon, ... I recently debugged an issue where OpenSC.tokend did not seem to work (no certificates visible in Keychain.app) yet logs and everything else seemed to suggest that everything is OK. Indeed, replacing the certificate with a known good one (in fact from my eID card) made Keychain.app work and display the certificate (without any differences in logs) This mostly concerns people who create CA profiles or depend on a fixed CA scheme and try to use OpenSC but fail on some interface (like Minidriver or Tokend) Best, Martin Kind regards, Viktor. On Mon, Jun 6, 2011 at 11:23, Viktor Tarasovviktor.tara...@gmail.com wrote: Le 06/06/2011 09:46, HOURY William a écrit : Hi Viktor, After more testing, it appears that the issue cannot be reproduced with all my certificates but only some of them. I put attached details about the cert I use most of the time. Does there any difference between this certificate and the ones that are going well for you? I have no deep insight into the smartcard logon. Here attached the certificate that works for me with Athena ASEPCOS card, maybe I'll find a crucial difference with your test certificate. Thanks William Kind wishes, Viktor. -Message d'origine- De : Viktor Tarasov [mailto:viktor.tara...@gmail.com] Envoyé : vendredi 3 juin 2011 16:53 À : Viktor Tarasov Cc : HOURY William; opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1 Le 03/06/2011 09:21, Viktor Tarasov a écrit : Le 03/06/2011 09:06, HOURY William a écrit : Hi Viktor, I have other middlewares installed but I have disabled all the proprietary certificate propagation tools and only activated the windows one (the sccertprop registry value is well set). Ok, once more it hasn't worked. Thank you. Will try to reproduce. For a while I cannot reproduce. The test was done with the card: Athena ASEPCOS atr: 3b:d6:18:00:81:b1:80:7d:1f:03:80:51:00:61:10:30:8f. Card initialized with the following commands: # pkcs15-init -E # pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin --puk Pkcs#12 with the 'SmartcardLogon' + 'Client Authentication' certificate is imported by : # pkcs15-init -a 53434D --label basic user smartcard logon -S basic_user.p12 -f pkcs12 --passphrase coucou --so-pin 12345678 --pin --key-usage digitalSignature,dataEncipherment --cert-label basic user smartcard logon (Don't know why with the key usage derived from the certificate extensions it's not worked.) The first login to AD on the XP platform is OK . Also works the sequence 'clean-up personal key store'log-off log-in. Kind regards, Viktor. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
On Jun 6, 2011, at 15:01 , Viktor Tarasov wrote: Le 06/06/2011 11:22, Martin Paljak a écrit : Hello, Just a quick notice that a section about certificate compatibility seems justified somewhere in documentation. Yes, it would be very useful. I imagine that subtle expert knowledge of the subject is needed, for example when it's going about BaseCSP, minidriver, SmartcardLogon, ... Maybe we can re-use the knowledge of EJBCA folks here, maybe their documentation even already includes necessary bits and pieces of information, I have not checked. Also PKIX docs are useful, but to get certificates right requires some time and effort. That's why setting up a really CA is not the same as running some OpenSSL commands... Root key secrecy, policies, certificate profiles etc require a lot of work to get right for a setup. Cheers, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Hello, On May 29, 2011, at 10:05 , Viktor Tarasov wrote: I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Why not? What is the custom xulrunner application anyway? Given it is custom, any set of customizations should be possible? Adding a separate build step to the default makefiles for *building* static binaries in parallel with current ones would be nice and OK. Ok. But the MSI script of the installer should be tailored for most appropriate delivery method for 80% use cases/users where the current dependency on a central libopensc.dll seems justified to me at least. Afaiu, for the customer of PKCS#11 module there is no (beside the size) difference if this module is static or not . The other dependent libraries are actually statically linked -- OpenSSL, zlib, ... Correct. Because for several reasons (like users of minidriver, mostly), it is good to install relevant DLL-s into System folder. Having OpenSSL (or zlib) DLL-s in System folder is a Very Bad Idea to my knowledge, but having a single OpenSC DLL should be manageable and a reasonable choice. Thus the current model of separate DLL-s for interfaces (minidriver, pkcs11), a central DLL for The Core (opensc.dll) and utilities using the core. Having a slim installer is IMHO desirable, as is having a minimal set of installed files (I really wish the onepin PKCS#11 module could be removed, hopefully Firefox/NSS folks will realize what's going on one day, I gave up explaining or trying to come up with a patch, it also requires GUI changes to be effective). Changing the installer is also possible, but it should follow some reasonable and consistent style. Just bundling more files does not seem like one. Possible options could be: A: current situation B: blend between static and dynamic linking inside OpenSC package - static PKCS#11 - static Minidriver - opensc.dll for tools only, in tools folder C: another blend between static and dynamic linking: - static PKCS#11 - opensc.dll used by everything else D: fully static compilation (not reasonable) E: other options? But it's not so important -- the second static version of PKCS#11 module included into MSI will be sufficient. Into OpenSC.msi? I don't think that's a good idea. Changing the setup plan for OpenSC would be reasonable though. Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Change 5421 breaks MIT Kerberos login
Hello, On Jun 2, 2011, at 18:32 , Douglas E. Engert wrote: On 6/2/2011 9:22 AM, Martin Paljak wrote: On Jun 2, 2011, at 16:39 , Douglas E. Engert wrote: Yes, the patch fixes the problem. Please commit it. Eric, Since Debian is in the process of accepting 1.12.1, (I saw your note from 02 Jun 2011 06:33:03 + 7 hours ago) and this bug will affect the use of OpenSC with Kerberos/PKINIT with login or kinit, (and maybe other applications) I would like to make sure that this patch also gets in to Debian somehow. This is a generic messup by me, but I'm not entirely sure it was *not* intentional, read below. OpenSC 0.12.2 will be released 10.06.2011. I guess that would be similarly OK ? Not sure. There appears to be a circumvention, (I need to try it) and Debian and Ubuntu add patches between releases. So does RedHat and I assume others. I would like to suggest that for future releases, we discuss more about how we test release candidates. Agreed. Some more formal planning of what gets released when would also do good. That's in theory the roadmap in Trac but maintaining Trac has shown to require some work and input from people, which does not happen so often and easily. So the roadmap has turned up to be more like a very rough plan of what could be in the pipeline. Maybe agitation to turn attention to it would be necessary every now and then on the list ? On 4/29/2011 0.12.1-RC1 was based on #5409 On 5/17/2011 0.12.1 was based on #5451 ... So 42 changes were added, with no new RC. I would like to suggest that if a RC has problems we fix these and come out with a new RC, and we all test it again. The final release should have only have one change from the last RC to change the name by dropping the -rc* in the name. The branch based development in OpenSC has not turned out to be very successful. Even if development is easy, delivering it for testing is cumbersome and tracking merges in SVN not only requires adequate (documented) processes, it even requires special software (think: svnmerge.py) to be effective. Also, even though smart cards related software is often very inert and for example even buggy cards need to be supported for several years (until certificates expire or new cards are issued or similar), it is a client-side software that should ideally be distributed like Google Chrome - with transparent continuous updates, if all succeeding versions are mostly functionally equivalent with previous versions. Thus I personally actually like the linear development/release cycle which ideally with SVN with the ever-increasing revision number. But the trunk centric development with release branches is IMHO not very effective. I'd prefer more granular merges with Git instead. I am not sure what is in the 42 changes since RC1, but there should only be fixes needed for the RC, and not improvements. I am not sure how #5421 fits in to this, or if other changes were also introduced that may have introduced other problems. I think we all (me included) can do a better job of testing. True. One of the steps is adding automatic tests, which in cases like this can be run against an empty PKCS#11 module as a smoke test. My personal goal for 0.12.1 was a fluid transition to nightly builds and automatic binary installers to the extent possible (only OS X lags behind because lack of resources, namely a dedicated OS X machine). Around the same time Debian packaging caught up so one way of interpreting 0.12.1 release is as a release candidate for the next version, which release date was intentionally fixed and set close to 0.12.1 release (10th of June, in 4 days). This means that all interesting parties should be prepared to catch up with the more smoothly rolling and more predictable (in terms of time) OpenSC release cycle, even though the period is set for a slow and easy summer and vacations period for the northern hemisphere. The next logical step is the transition to Git in the nearest future with staging builds or the feature branches which will be the base for release candidates and a step to a different direction from the trunk based evolution. You could take the release mess-up as a (not so nice) method of triggering discussion on the topic ;) But I'll try to be more careful in the nearest future to avoid such mishaps. As always - any input in the mailing list, which could be transferred to documented approaches on Wiki, are most welcome. Best, Martin -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
On 6/6/2011 2:46 AM, HOURY William wrote: Hi Viktor, After more testing, it appears that the issue cannot be reproduced with all my certificates but only some of them. I put attached details about the cert I use most of the time. You say that you use the same certificate on multiple cards, This would imply that you copy the cert and the key? But the cert you sent was generated on Jun 1, 2011, last week. So you must be generating new ones. Can you explain? Can you use different usernames in the different certs to test if the problems are related to some confusion in the client as to what certificate is on what smartcard. AD has a propagation delay, and if you are creating new certificates and trying to use them, a DC may not see the new certificate. Is the CA a Microsoft enterprise CA and part of the domain? There might be an issue with with NotBefore for a new cert if the client is not converting to local time, but comparing only the date. You had said that you were using Windows AD, and were using the smartcard to login to AD. For smartcard login to AD the msUPN should match the userPrincipalName attribute in the user's account in AD. openssl asn1parse -i -in BL_CertDetails.txt -strparse 489 -dump shows the msUPN to be blotito@pmtdom The userPrincipalName usually has the username@REALM, where REALM is the Kerberos Realm name that is upper case, and is fully qualified. The AD domain is usually lower case and is often used with out being qualified. So based on other info in the cert, it appears that the domain name is pmtdom.local. So the msUPN should be blotito@PMTDOM.LOCAL Windows 2003 relaxed the restrictions, and the userPrincipalName still needs to match the msUPN, by may be something else, for example in our case something like: 123456...@xx.gov (Windows 2008 and the Vista and W7 with the CNG, can go further and don't require the msUPN, but AFAIK, XP still does.) Is the CA certificate trusted by both the client, and the AD? Are clocks in sync. The subject has C, ST, O, OU and emailAddress as NULL. Usually these would have a value, or not be present at all. Thanks William -Message d'origine- De : Viktor Tarasov [mailto:viktor.tara...@gmail.com] Envoyé : vendredi 3 juin 2011 16:53 À : Viktor Tarasov Cc : HOURY William; opensc-devel@lists.opensc-project.org Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1 Le 03/06/2011 09:21, Viktor Tarasov a écrit : Le 03/06/2011 09:06, HOURY William a écrit : Hi Viktor, I have other middlewares installed but I have disabled all the proprietary certificate propagation tools and only activated the windows one (the sccertprop registry value is well set). Ok, once more it hasn't worked. Thank you. Will try to reproduce. For a while I cannot reproduce. The test was done with the card: Athena ASEPCOS atr: 3b:d6:18:00:81:b1:80:7d:1f:03:80:51:00:61:10:30:8f. Card initialized with the following commands: # pkcs15-init -E # pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin --puk Pkcs#12 with the 'SmartcardLogon' + 'Client Authentication' certificate is imported by : # pkcs15-init -a 53434D --label basic user smartcard logon -S basic_user.p12 -f pkcs12 --passphrase coucou --so-pin 12345678 --pin --key-usage digitalSignature,dataEncipherment --cert-label basic user smartcard logon (Don't know why with the key usage derived from the certificate extensions it's not worked.) The first login to AD on the XP platform is OK . Also works the sequence 'clean-up personal key store' log-off log-in. Kind regards, Viktor. Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
Re: [opensc-devel] Change 5421 breaks MIT Kerberos login
On 6/6/2011 6:50 AM, Martin Paljak wrote: Hello, On Jun 2, 2011, at 01:07 , Douglas E. Engert wrote: The change #5421 introduced between 0.12.1-rc1 and 0.12.1 on 5/4/11 by vtarasov breaks the MIT Kerberos login. A spy output is attached. The code calls C_GetSlotList with tokenPresent=1 which in the past has only returned slots with tokens. But #5421 returns 2 slots, the 0x virtual slot which does NOT have a token, and slot 1 which has a token. The code then tries C_OpenSession to the virtual slot which does not have a token and fails. This is also a place for improvement in the Kerberos software, as it should try to intelligently recover from the problem: True. But this would naturally occur only if the user pulled the card between the call to the C_GetSlotsList with tokenPresent=1 and the call to C_OpenSession, a very unlikely situation. The code could intelligently recover by assuming the user pulled the card to stop the login. If it was by accident, the user would recover by inserting the card and trying again. Any Cryptoki function that uses a particular token (i.e., any Cryptoki function except for C_Initialize, C_Finalize, C_GetInfo, C_GetFunctionList, C_GetSlotList, C_GetSlotInfo, or C_WaitForSlotEvent) can return any of the following values: CKR_TOKEN_NOT_PRESENT: The token was not present in its slot at the time that the function was invoked. I don't know hot the configuration for Kerberos login works or how it locates the suitable slot, but this looks like a valid situation nevertheless. I don't understand why this change was made. If the virtual slot does not have a token, it should not be returned if tokenPresent=1. True. Best, Martin -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC 12.1
On 6/6/2011 7:19 AM, Martin Paljak wrote: On Jun 6, 2011, at 15:01 , Viktor Tarasov wrote: Le 06/06/2011 11:22, Martin Paljak a écrit : Hello, Just a quick notice that a section about certificate compatibility seems justified somewhere in documentation. Yes, it would be very useful. I imagine that subtle expert knowledge of the subject is needed, for example when it's going about BaseCSP, minidriver, SmartcardLogon, ... Maybe we can re-use the knowledge of EJBCA folks here, maybe their documentation even already includes necessary bits and pieces of information, I have not checked. Also PKIX docs are useful, but to get certificates right requires some time and effort. That's why setting up a really CA is not the same as running some OpenSSL commands... Root key secrecy, policies, certificate profiles etc require a lot of work to get right for a setup. What is in a certificate is not really OpenSC's concern, but the concern of the CA, and since we are talking login, and usually to Windows AD the concern of the DC or Kerberos KDC administrators. This is a good starting point: http://support.microsoft.com/kb/281245 Or: http://blogs.msdn.com/b/shivaram/ Google for: AD smartcard login Under the covers, AD is using the Kerberos PKINIT protocol, so much of this applies to Linux with pam_krb5 to AD or to a MIT or Heimdal KDC, and krb5.conf has many parameters used by the PKINIT code. Google for: pam_krb5 PKINIT Cheers, Martin -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Change 5421 breaks MIT Kerberos login
On 6/6/2011 8:52 AM, Martin Paljak wrote: Hello, On Jun 2, 2011, at 18:32 , Douglas E. Engert wrote: On 6/2/2011 9:22 AM, Martin Paljak wrote: On Jun 2, 2011, at 16:39 , Douglas E. Engert wrote: Yes, the patch fixes the problem. Please commit it. Eric, Since Debian is in the process of accepting 1.12.1, (I saw your note from 02 Jun 2011 06:33:03 + 7 hours ago) and this bug will affect the use of OpenSC with Kerberos/PKINIT with login or kinit, (and maybe other applications) I would like to make sure that this patch also gets in to Debian somehow. This is a generic messup by me, but I'm not entirely sure it was *not* intentional, read below. I agree, it is what OpenSC has been doing since I got involved, basically take what was in the trunk and produce a release. What I am trying to point out is that OpenSC has become the defacto open source smartcard provider and we need to treat it as such. Its more then a just package for smartcard hackers to try and add their own card for their personal use. As such we need to have better testing on what gets released. This is especially true, as no one developer has all the cards that are supported, and thus testing relies on all of us to test our part before a release. OpenSC 0.12.2 will be released 10.06.2011. I guess that would be similarly OK ? Not sure. There appears to be a circumvention, (I need to try it) and Debian and Ubuntu add patches between releases. So does RedHat and I assume others. I would like to suggest that for future releases, we discuss more about how we test release candidates. Agreed. Some more formal planning of what gets released when would also do good. That's in theory the roadmap in Trac but maintaining Trac has shown to require some work and input from people, which does not happen so often and easily. So the roadmap has turned up to be more like a very rough plan of what could be in the pipeline. Maybe agitation to turn attention to it would be necessary every now and then on the list ? On 4/29/2011 0.12.1-RC1 was based on #5409 On 5/17/2011 0.12.1 was based on #5451 ... So 42 changes were added, with no new RC. I would like to suggest that if a RC has problems we fix these and come out with a new RC, and we all test it again. The final release should have only have one change from the last RC to change the name by dropping the -rc* in the name. The branch based development in OpenSC has not turned out to be very successful. Even if development is easy, delivering it for testing is cumbersome and tracking merges in SVN not only requires adequate (documented) processes, it even requires special software (think: svnmerge.py) to be effective. Also, even though smart cards related software is often very inert and for example even buggy cards need to be supported for several years (until certificates expire or new cards are issued or similar), it is a client-side software that should ideally be distributed like Google Chrome - with transparent continuous updates, if all succeeding versions are mostly functionally equivalent with previous versions. Thus I personally actually like the linear development/release cycle which ideally with SVN with the ever-increasing revision number. But the trunk centric development with release branches is IMHO not very effective. I'd prefer more granular merges with Git instead. That is fine too. It requires developers to hold off on new features while a release is being prepared. The group of developers is small enough that this could be done. I am not sure what is in the 42 changes since RC1, but there should only be fixes needed for the RC, and not improvements. I am not sure how #5421 fits in to this, or if other changes were also introduced that may have introduced other problems. I think we all (me included) can do a better job of testing. True. One of the steps is adding automatic tests, which in cases like this can be run against an empty PKCS#11 module as a smoke test. My personal goal for 0.12.1 was a fluid transition to nightly builds and automatic binary installers to the extent possible (only OS X lags behind because lack of resources, namely a dedicated OS X machine). Around the same time Debian packaging caught up so one way of interpreting 0.12.1 release is as a release candidate for the next version, which release date was intentionally fixed and set close to 0.12.1 release (10th of June, in 4 days). This means that all interesting parties should be prepared to catch up with the more smoothly rolling and more predictable (in terms of time) OpenSC release cycle, even though the period is set for a slow and easy summer and vacations period for the northern hemisphere. The next logical step is the transition to Git in the nearest future with staging builds or the feature branches which will be the base for release candidates and a step to a different direction
Re: [opensc-devel] Static link for opensc-pkcs11.dll
Le 06/06/2011 15:31, Martin Paljak a écrit : Hello, On May 29, 2011, at 10:05 , Viktor Tarasov wrote: I have a xulrunner application that uses the old modified version of opensc.dll and that needs to be used with the actual OpenSC PKCS#11 module . Static linking will allow the peaceful cohabitation. I would suggest statically compiling the custom version and using it however you find necessary or combining It's not actually possible. Why not? What is the custom xulrunner application anyway? Given it is custom, any set of customizations should be possible? The reasons are mostly 'internals'. The build application procedure is quite complicated, subject of the intense QA testing, and finally is not easy to change. Adding a separate build step to the default makefiles for *building* static binaries in parallel with current ones would be nice and OK. Ok. But the MSI script of the installer should be tailored for most appropriate delivery method for 80% use cases/users where the current dependency on a central libopensc.dll seems justified to me at least. Afaiu, for the customer of PKCS#11 module there is no (beside the size) difference if this module is static or not . The other dependent libraries are actually statically linked -- OpenSSL, zlib, ... Correct. Because for several reasons (like users of minidriver, mostly), it is good to install relevant DLL-s into System folder. Having OpenSSL (or zlib) DLL-s in System folder is a Very Bad Idea to my knowledge, but having a single OpenSC DLL should be manageable and a reasonable choice. Thus the current model of separate DLL-s for interfaces (minidriver, pkcs11), a central DLL for The Core (opensc.dll) and utilities using the core. Having a slim installer is IMHO desirable, as is having a minimal set of installed files (I really wish the onepin PKCS#11 module could be removed, hopefully Firefox/NSS folks will realize what's going on one day, I gave up explaining or trying to come up with a patch, it also requires GUI changes to be effective). Changing the installer is also possible, but it should follow some reasonable and consistent style. Just bundling more files does not seem like one. Possible options could be: A: current situation B: blend between static and dynamic linking inside OpenSC package - static PKCS#11 - static Minidriver - opensc.dll for tools only, in tools folder This would be perfect for me. Can this scheme be adopted as a general and replace the current one ? C: another blend between static and dynamic linking: - static PKCS#11 - opensc.dll used by everything else D: fully static compilation (not reasonable) E: other options? But it's not so important -- the second static version of PKCS#11 module included into MSI will be sufficient. Into OpenSC.msi? I don't think that's a good idea. Changing the setup plan for OpenSC would be reasonable though. Best, Martin Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
