Hello,
On Fri, Apr 22, 2011 at 11:13, Viktor TARASOV
wrote:
>> ... the other 'warnings' should not happen with 'READ BINARY' when data
>> are returned,
>> with exception of 6281 'Part of the returned data may be corrupted'.
>> I guess that this 'warning' is an error and cannot be ignored.
>> An a
Hello,
On Mon, Apr 25, 2011 at 12:01, Viktor TARASOV
wrote:
> Personally, I'm ready to remove at all 'insecure' option -- never used it.
> All the stuff can be defined in the card profile. But let us wait for the
> other opinions.
I've used it and I find it a generally useful option, for cases w
Hello,
On Mon, Apr 25, 2011 at 15:33, jons...@terra.es wrote:
>> About "User Consent" AKA "popping up notice windows about what the
>> user is about to do" as well as ticket #232 [1].
>
>> I still believe that it is mostly politics to delegate responsibility
>> :) What it tries to "protect" from
2011/4/25 Jean-Michel Pouré - GOOZE :
> Le lundi 25 avril 2011 à 13:51 -0500, Douglas E. Engert a écrit :
>> But part of the derivation process may include additional parameters.
>> Thus the derivation may may not have been done when pkcs15-tool is run
>> or the key is only good why the card is pow
Hello,
2011/4/25 Jean-Michel Pouré - GOOZE :
> pkcs15-tool --list-public-keys seems to return the list of available
> public keys being registered on card as public keys. It does not include
> the list of private keys. But some public keys can be derived from
> private keys and thus are not listed
> Yes and no. It's not bad to have low-level tools which are useless
> for end users. Those tools are very useful for developers.
>
> [...]
>
> Agree that end-user GUIs need more sophisticated functionality than
> may be offered by most or even all existing OpenSC tools. But that
> does not mea
Jean-Michel Pouré - GOOZE wrote:
> It took me some time to understand that pkcs15-tool --list-public-keys
> did not return all public keys. So I expect users to be lost.
>
> We need one simple command returning precise information.
Yes and no. It's not bad to have low-level tools which are useles
On 25/04/2011 21:05, Jean-Michel Pouré - GOOZE wrote:
> We need one simple command returning precise information. This is needed
> for future GUIs.
pkcs15-tool -D
should list 'em all, or not?
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@li
On 25/04/2011 14:33, jons...@terra.es wrote:
> > I can figure out at least these different popups:
[...]
> 7 - "You'are about to emit a digital signature. Please confirm operation"
And, anyway, you expose yourself to malicious apps that ask for a crypto
pin and use it to sign a document... As lo
Le lundi 25 avril 2011 à 13:51 -0500, Douglas E. Engert a écrit :
> But part of the derivation process may include additional parameters.
> Thus the derivation may may not have been done when pkcs15-tool is run
> or the key is only good why the card is powered. i.e. an ephemeral key
> or a PKCS#11
On 4/25/2011 12:40 PM, Jean-Michel Pouré - GOOZE wrote:
> Dear friends,
>
> pkcs15-tool --list-public-keys seems to return the list of available
> public keys being registered on card as public keys. It does not include
> the list of private keys. But some public keys can be derived from
> privat
Dear friends,
pkcs15-tool --list-public-keys seems to return the list of available
public keys being registered on card as public keys. It does not include
the list of private keys. But some public keys can be derived from
private keys and thus are not listed.
Are there plans to modify pkcs15-too
(oops: forgot to CC to list :-)
Mensaje original
De: jons...@terra.es
Fecha: 25/04/2011 14:30
Para:
Asunto: Re: [opensc-devel] OpenDNIe project is now ready for public test
> About "User Consent" AKA "popping up notice windows about what the
> user is about to do" as well as tic
I think this scheme has a long way to go before it becomes
generally useful. An obvious shortcoming in the app-powered
world we live in is that an issuer has no way restricting keys
to certain trusted apps.
Such a scheme will probably be included in future versions of
Windows, iPhone and Android.
Hello,
On Thu, Feb 10, 2011 at 20:46, Juan Antonio Martinez wrote:
> As you know, I've been working last 4 month with people at Cenatic[1]
> in two areas:
> * Specific DNIe user-interface requirements (i18n,user consent)
> * Porting some common code from dnie files to opensc
> * DNIe "particul
Applied.
Thanks.
On Mon, Apr 25, 2011 at 12:39 PM, jons...@terra.es wrote:
> Seems that "make maintainer-clean" forgets to delete
> "trunk/MacOSX/Makefile.in" file
>
> This patch does the work:
> --- ../trunk/MacOSX/Makefile.am 2011-04-21 11:33:09.0 +0200
> +++ mine/MacOSX/Makefile.am
Seems that "make maintainer-clean" forgets to delete "trunk/MacOSX/Makefile.in"
file
This patch does the work:
--- ../trunk/MacOSX/Makefile.am2011-04-21 11:33:09.0 +0200
+++ mine/MacOSX/Makefile.am2011-04-25 11:26:32.0 +0200
@@ -1,3 +1,4 @@
+MAINTAINERCLEANFILES = $(srcdir
Although I am in favor of improving openct, I agree with Martin in this case.
The most CCID compliant library we have is libccid, first work out the
problem with libccid.
It may be that openct's CCID implementation works for you as it much
simpler and use smaller set of features.
On Mon, Apr 25, 2
On 04/25/11 10:20, Martin Paljak wrote:
> Hello, On Apr 25, 2011, at 11:09 , Stef Walter wrote:
>
>> I've heard that openct may not be that relevant any more, but in
>> any case here's an OpenCT patch to add support for the smart card
>> reader in my laptop.
>>
>> Should I put this in the opensc
Le 24/04/2011 23:45, NdK a écrit :
> On 24/04/2011 14:18, Viktor TARASOV wrote:
>
>>> It seems the root of the problem lies in the profile: changing
>>> CRYPTO=$PIN to CRYPTO=NONE works around it, but it's surely sub-optimal.
> What I wanted to say: shouldn't --insecure replace $PIN with NONE ?
> F
Hello,
On Apr 25, 2011, at 11:09 , Stef Walter wrote:
> I've heard that openct may not be that relevant any more, but in any
> case here's an OpenCT patch to add support for the smart card reader in
> my laptop.
>
> Should I put this in the opensc trac, or does it go somewhere else?
The device yo
I've heard that openct may not be that relevant any more, but in any
case here's an OpenCT patch to add support for the smart card reader in
my laptop.
Should I put this in the opensc trac, or does it go somewhere else?
Cheers,
Stef
Index: etc/openct.conf.in
=
22 matches
Mail list logo
