Re: [opensc-devel] OpenSC 0.12.3 master plan
Hello Douglas, Le 09/09/2011 17:13, Viktor Tarasov a écrit : Le 09/09/2011 17:05, Douglas E. Engert a écrit : On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. I will try to merge your 'ECDH' into my 'SM' one, and so we'll see how big is the difference. It seems that 'algo_refs' member of pkcsk15_skey_info data is not used. Will you keep it for the future usage? https://github.com/dengert/OpenSC/blob/ecdh/src/libopensc/pkcs15.h#L413 The merge is painless, do you consider your ECDH branch as more or less finished? I will merge it into my SM branch. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
On 10/3/2011 12:50 PM, Viktor Tarasov wrote: Hello Douglas, Le 09/09/2011 17:13, Viktor Tarasov a écrit : Le 09/09/2011 17:05, Douglas E. Engert a écrit : On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. I will try to merge your 'ECDH' into my 'SM' one, and so we'll see how big is the difference. It seems that 'algo_refs' member of pkcsk15_skey_info data is not used. Will you keep it for the future usage? https://github.com/dengert/OpenSC/blob/ecdh/src/libopensc/pkcs15.h#L413 Sure. The merge is painless, do you consider your ECDH branch as more or less finished? I will merge it into my SM branch. Yes. The main issue remaining was compiling without OPENSSL, as the USE_PKCS15_INIT would test for OPENSSL and delete a lot of code needed to create PKCS$11 session objects. Although the ECDH and C_DeriveKey does did not depend on OPENSSL, it did depend on much of the USE_PKCS15_INIT code. Martin said: IMHO the following assumptions should be applied: - USE_PKCS15_INIT should disappear altogether So that was the last major issue I had. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 -- 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] OpenSC 0.12.3 master plan
On 9/21/2011 6:28 PM, Martin Paljak wrote: Hello, On 9/21/11 6:52 , Douglas E. Engert wrote: Back to the master plan. Yes. I was off for 5 days in Brussels for BruCON (which was great!), so back to things and plans. Would it help to for a developer to rebase their changes as you add other changes? Yes. Viktor said on 8/11/2011: I guess that we should have some intermediate branch with a more or less common commit access, that can be fed by more then one person and that could be used as a fresh code base for the patch/merge proposals. This branch could be considered as 'almost sure' and normally could be merged into the individual experimental branches without apprehension. This branch should be the only one to be checked for the conflicts by proposals authors. I was thinking about something like 'proposal' branch of the OpenSC github. A developer could rebase their changes against this 'proposal' branch so making it easier to pull in the developers changes. Yes. I was assuming that your https://github.com/martinpaljak/OpenSC.git 'proposed' branch was meant to be this 'proposal' branch, and so have been g=based of of it. If there will be a new branch,what and were would it be? I am willing to do a rebase for the ECDH code. Great! Just tell me the repository and branch. There is one area that still needs to be addressed. The ecdh/derive depends on much of the code that was introduced by the USE_PKCS15_INIT. But USE_PKCS15_INIT is only defined if ENABLE_OPENSSL is defined, and USE_PKCS_15_INIT ifdef's out much of the code that is needed by derive even though the derive code does not use OpenSSL. So I/we need a mode to change the #ifdefs for USE_PKCS15_INIT. This could be done against the 'proposed' branch, and then the ecdh code could be rebased on top of that. What do you suggest? This should be addressed. I agree. I've separated OpenSSL usage in src/libopensc to a softcrypto minimodule and am half way through with making sure that the interface would be sufficient by re-implementing used functionality with alternative libgcrypt backend as well. I have not looked at all the drivers, but it appears that the policy for OpenSC has been no crypto would be done in software. This include random number generation, hashes or encrypt/decrypt or verification. Most of the OpenSSL code I have seen in OpenSC was to use the BIO and ASN1 routines. But most of the ASN1 can now be done by internal OpenSC routines. Hashes and maybe GOST appear to be the issues. On the other hand, if a softcrypto back end is added, this opens up the possibility for OpenSC to use it to do actual crypto, for example using the OpenSSL FIPS version. Is this the intent? For ECC this would also open up the possibility to create ephemeral keys as PKCS#11 session objects. (Its not clear if this is needed, as when OpenSC is used from NSS, the NSS softoken creates the ephemeral keys and OpenSC does not need to.) In src/pkcs11 the use of OpenSSL is even more interwoven, so fixing this is more complicated. As soon as I am be done with the code in src/libopensc I'll push it out for review and additional help to get this into src/pkcs11 as well. Decoupling ENABLE_OPENSSL and USE_PKCS15_INIT beforehand would nevertheless make it even more straightforward. IMHO the following assumptions should be applied: - USE_PKCS15_INIT should disappear altogether - building with a softcrypto library (OpenSSL or libgcrypt or CrytpoAPI or maybe even something entirely different) shall be assumed I agree. - building *without* a software crypto back-end should also be possible, but this should not be accomplished by huge code blocks being made inaccessible. That is in effect what we have been doing with the current code, although I don't know a distro that builds without OpenSSL. I have done everything possible to make sure OpenSSL is not required for ordinary client usage of the card I am interested in, and test without it. (Thats how I found this USE_PKCS15_INIT issue.) In fact, there should be no #ifdef-s checking for OpenSSL or similar in common code, only in src/libopensc/softcrypto(-*.c|.h). sc_softcrypto_features() kind of machinery can be used to test for the presence of certain algorithms or ciphers if needed for advertising features. Sounds reasonable. - building without a software crypto back-end shall possibly result in undefined behavior and probably several SC_ERROR_NOT_SUPPORTED errors, if hit. Just need to make sure that they get reported appropriately. Best,ƒ´ƒ Mar tin -- 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] OpenSC 0.12.3 master plan
Back to the master plan.
Martin,
How do you plan on merging in the changes?
What assistance do you need to do this?
Would it help to for a developer to rebase their changes as you add other
changes?
Viktor said on 8/11/2011:
I guess that we should have some intermediate branch with a more or less common
commit access,
that can be fed by more then one person and that could be used as a fresh code
base for the patch/merge proposals.
This branch could be considered as 'almost sure' and normally could be merged
into the individual experimental branches without apprehension.
This branch should be the only one to be checked for the conflicts by proposals
authors.
I was thinking about something like 'proposal' branch of the OpenSC github.
A developer could rebase their changes against this 'proposal' branch
so making it easier to pull in the developers changes.
I am willing to do a rebase for the ECDH code.
There is one area that still needs to be addressed. The ecdh/derive
depends on much of the code that was introduced by the USE_PKCS15_INIT.
But USE_PKCS15_INIT is only defined if ENABLE_OPENSSL is defined,
and USE_PKCS_15_INIT ifdef's out much of the code that is needed by
derive even though the derive code does not use OpenSSL.
So I/we need a mode to change the #ifdefs for USE_PKCS15_INIT.
This could be done against the 'proposed' branch, and then
the ecdh code could be rebased on top of that.
What do you suggest?
See attachment with a first cut of the change that is based on
top of the ecdh code.
On 9/9/2011 3:07 AM, Viktor Tarasov wrote:
Le 09/09/2011 09:38, Martin Paljak a écrit :
Hello,
Autumn has started (at least in northern hemisphere) so it is time to
pull together next OpenSC release.
Things to do that should be cleaned up into hopefully self-contained
patches:
- secret key object signature (Viktor and Douglas have different
signatures) [1]
- secure messaging, at least in the minimal scope of what belongs to
apdu.c (card driver based wrap/unwrap?) [2]
- new drivers, that depend on secure messaging:
- DNIe [3]
- epass2k3 [4]
- ECDH support [5]
- Coverity fixes
- Minidriver updates [6]
- Proper reader detachments (only really affects PKCS#11) [8]
- Updates to installers
- Windows: incorporate automatic minidriver configuration for all (at
least select) cards
- Mac OS X: generic updates and settled 10.7 support (until further
information from Apple will be available)
- Separation of OpenSSL into a softcrypto mini-api with an alternative
backend (libgcrypt as it is LGPL for Debian) [7]
- Updates to the Git workflow that would make it more easy to
understand for brains, with a continuous staging branch (revertable).
But non-trivial changes should still go through separate branches...
Anything I missed? I'll put this to a wiki page as well with probably
more notes.
Coverity scan:
https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan
[1]
https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973
[2] http://www.opensc-project.org/opensc/wiki/SecureMessaging
For secure messaging it's rather:
https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging
[3] http://www.opensc-project.org/opensc/wiki/DNIe
[4] https://github.com/OpenSC/OpenSC/pull/1
[5] https://github.com/dengert/OpenSC/commits/ecdh
[6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode
[7]
http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html
[8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader
___
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
--
Douglas E. Engert deeng...@anl.gov
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
diff --git a/src/pkcs11/framework-pkcs15.c b/src/pkcs11/framework-pkcs15.c
index 6f21828..ecdedf6 100644
--- a/src/pkcs11/framework-pkcs15.c
+++ b/src/pkcs11/framework-pkcs15.c
@@ -25,9 +25,9 @@
#include string.h
#include sc-pkcs11.h
-#ifdef USE_PKCS15_INIT
+//DEE#ifdef USE_PKCS15_INIT
#include pkcs15init/pkcs15-init.h
-#endif
+//DEE#endif
extern int hack_enabled;
@@ -252,7 +252,7 @@ static void pkcs15_init_token_info(struct sc_pkcs15_card
*p15card, CK_TOKEN_INFO
pToken-firmwareVersion.minor = 0;
}
-#ifdef USE_PKCS15_INIT
+//DEE #ifdef USE_PKCS15_INIT
static char *
set_cka_label(CK_ATTRIBUTE_PTR attr, char *label)
{
@@ -265,7 +265,7 @@ set_cka_label(CK_ATTRIBUTE_PTR attr, char *label)
label[len] = '\0';
return label;
}
-#endif
Re: [opensc-devel] OpenSC 0.12.3 master plan
Hello, On 9/21/11 6:52 , Douglas E. Engert wrote: Back to the master plan. Yes. I was off for 5 days in Brussels for BruCON (which was great!), so back to things and plans. Would it help to for a developer to rebase their changes as you add other changes? Yes. Viktor said on 8/11/2011: I guess that we should have some intermediate branch with a more or less common commit access, that can be fed by more then one person and that could be used as a fresh code base for the patch/merge proposals. This branch could be considered as 'almost sure' and normally could be merged into the individual experimental branches without apprehension. This branch should be the only one to be checked for the conflicts by proposals authors. I was thinking about something like 'proposal' branch of the OpenSC github. A developer could rebase their changes against this 'proposal' branch so making it easier to pull in the developers changes. Yes. I am willing to do a rebase for the ECDH code. Great! There is one area that still needs to be addressed. The ecdh/derive depends on much of the code that was introduced by the USE_PKCS15_INIT. But USE_PKCS15_INIT is only defined if ENABLE_OPENSSL is defined, and USE_PKCS_15_INIT ifdef's out much of the code that is needed by derive even though the derive code does not use OpenSSL. So I/we need a mode to change the #ifdefs for USE_PKCS15_INIT. This could be done against the 'proposed' branch, and then the ecdh code could be rebased on top of that. What do you suggest? This should be addressed. I've separated OpenSSL usage in src/libopensc to a softcrypto minimodule and am half way through with making sure that the interface would be sufficient by re-implementing used functionality with alternative libgcrypt backend as well. In src/pkcs11 the use of OpenSSL is even more interwoven, so fixing this is more complicated. As soon as I am be done with the code in src/libopensc I'll push it out for review and additional help to get this into src/pkcs11 as well. Decoupling ENABLE_OPENSSL and USE_PKCS15_INIT beforehand would nevertheless make it even more straightforward. IMHO the following assumptions should be applied: - USE_PKCS15_INIT should disappear altogether - building with a softcrypto library (OpenSSL or libgcrypt or CrytpoAPI or maybe even something entirely different) shall be assumed - building *without* a software crypto back-end should also be possible, but this should not be accomplished by huge code blocks being made inaccessible. In fact, there should be no #ifdef-s checking for OpenSSL or similar in common code, only in src/libopensc/softcrypto(-*.c|.h). sc_softcrypto_features() kind of machinery can be used to test for the presence of certain algorithms or ciphers if needed for advertising features. - building without a software crypto back-end shall possibly result in undefined behavior and probably several SC_ERROR_NOT_SUPPORTED errors, if hit. Just need to make sure that they get reported appropriately. Best,ƒ´ƒ Mar tin -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC 0.12.3 master plan
Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scan https://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaging https://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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] OpenSC 0.12.3 master plan
On Fri, Sep 9, 2011 at 9:38 AM, Martin Paljak mar...@martinpaljak.net wrote: Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. - ECDH support [5] Out of curiosity, are the ECDH static keys used anywhere? They remind me of the DH static keys ciphersuites in TLS that although were defined I haven't seen them being used in practice (no certificates were ever issued with such keys). regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 -- 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] OpenSC 0.12.3 master plan
Le 09/09/2011 17:05, Douglas E. Engert a écrit : On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. I will try to merge your 'ECDH' into my 'SM' one, and so we'll see how big is the difference. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
On 9/9/2011 2:59 AM, Nikos Mavrogiannopoulos wrote: On Fri, Sep 9, 2011 at 9:38 AM, Martin Paljakmar...@martinpaljak.net wrote: Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. - ECDH support [5] Out of curiosity, are the ECDH static keys used anywhere? Yes they can be used as part of a key agreement scheme and the agreed upon key can be used for encryption. See: http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf Section 6. Key Agreement The PIV card only supports ECC CDH, with a static key, on the card, and the public key from the other party. This is just enough to use more complicated methods for example to encrypt e-mail. http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf In Table 2, the computation Compute Z by calling ECC CDH using de,U and Qs,V and Compute Z by calling ECC CDH using ds,V and Qe,U could be done on two different cards. OpenSC has made a decision to not support crypto in software, but only in hardware. Thus any method that need ephemeral keys needs to generate them outside of OpenSC. NSS has that capability. There is some working going on to get Thunderbird with NSS to use ECDH, so it can exchange encrypted e-mail with Outlook. They remind me of the DH static keys ciphersuites in TLS that although were defined I haven't seen them being used in practice (no certificates were ever issued with such keys). regards, Nikos ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- 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] OpenSC 0.12.3 master plan
On 9/9/2011 10:13 AM, Viktor Tarasov wrote: Le 09/09/2011 17:05, Douglas E. Engert a écrit : On 9/9/2011 3:07 AM, Viktor Tarasov wrote: Le 09/09/2011 09:38, Martin Paljak a écrit : Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] I don't think it is different signatures, its that our code changes some of the same routines, and defines a structure. We need to use the same structure. I will try to merge your 'ECDH' into my 'SM' one, and so we'll see how big is the difference. Thanks. - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. Coverity scan: https://github.com/viktorTarasov/OpenSC/tree/coverity-scanhttps://github.com/viktorTarasov/OpenSC/commits/coverity-scan [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging For secure messaging it's rather: https://github.com/viktorTarasov/OpenSC/tree/secure-messaginghttps://github.com/viktorTarasov/OpenSC/commits/secure-messaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 -- 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
