Hello,
On Apr 27, 2011, at 02:57 , Juan Antonio Martinez wrote:
> El mar, 26-04-2011 a las 22:53 +0200, Juan Antonio Martinez escribió:
> [...]
>>> One option would be to remove public key files from emulation
>>> (like the Estonian eID),
>> Perhaps I'll need some help: pkcs15-dnie.c just parses
El mar, 26-04-2011 a las 22:53 +0200, Juan Antonio Martinez escribió:
[...]
> > One option would be to remove public key files from emulation
> > (like the Estonian eID),
> Perhaps I'll need some help: pkcs15-dnie.c just parses pkcs15 data
> from card, and patches some file paths and ID's... no cl
Frank Morgner wrote:
> > > But you can also accept the overhead and use standardized
> > > interfaces. This approach gives you support for a wide variety of
> > > applications and (existent) hardware/software.
> >
> > The *only* interface that matters is p11.
>
> This is not true in many regards.
On Tuesday, April 26 at 09:07PM, Peter Stuge wrote:
> Frank Morgner wrote:
> > But you can also accept the overhead and use standardized
> > interfaces. This approach gives you support for a wide variety of
> > applications and (existent) hardware/software.
>
> The *only* interface that matters is
On 26/04/2011 19:16, Anders Rundgren wrote:
> As far as I know not a single HSM (even those who cost $20 000)
> out there is able to certify that keys actually were created
> inside of the HSM!!! A $10-$20 SKS always attests the origin
> of created keys using a built-in device key and certificate
On 26/04/2011 15:19, Alon Bar-Lev wrote:
> Just wanted to note that exposing such device to IP stack makes it a
> target to hack,
That's why I'm quite reluctant to enable Ethernet port on such a dongle.
> packaging is much more difficult.
I don't want to compete with $20k HSM. They use dedicated H
Le mardi 26 avril 2011 à 22:28 +0300, Martin Paljak a écrit :
>
>
> Anyway, I see what you're referring to and some of the practical
> possibilities are:
> a) Better documentation (in pkcs15-tool man page, wiki, etc) about
> what is going on in the context of pkcs15-tool and different options.
>
El mar, 26-04-2011 a las 22:37 +0300, Martin Paljak escribió:
> Hello,
> On Apr 26, 2011, at 18:21 , Juan Antonio Martinez wrote:
> > As you can see in wiki [1] DNIe pkcs15 stores same DF in EF(PubK) and
> > EF(PrivK). So pkcs15-tool --read-public-keys fails with an "access
> > denied" when trying
Hello,
On Apr 26, 2011, at 17:25 , Jean-Michel Pouré - GOOZE wrote:
> Le mardi 26 avril 2011 à 16:38 +0300, Martin Paljak a écrit :
>> For the sake of purity, I don^t think that --list-public-keys should
>> display a fake public key object, which does NOT exist on the card in
>> relevant PKCS#15 s
Frank Morgner wrote:
> But you can also accept the overhead and use standardized
> interfaces. This approach gives you support for a wide variety of
> applications and (existent) hardware/software.
The *only* interface that matters is p11. All the other crap is 30
year old legacy that the world wo
On Tuesday, April 26 at 08:34PM, NdK wrote:
>
> On 26/04/2011 18:51, Frank Morgner wrote:
>
> > You forgot to mention Virtual Smart Card Architecture
> Already seen that, but always "wrappers wrapped in other wrappers" :(
Well, it IS what you requested: CCID+virtual token.
> The architecture ca
On 26/04/2011 18:51, Frank Morgner wrote:
> You forgot to mention Virtual Smart Card Architecture
Already seen that, but always "wrappers wrapped in other wrappers" :(
The architecture can be greatly simplified: no need for APDUs
encoding/decoding, no need to handle card insertion/extraction, no
On 2011-04-26 14:55, NdK wrote:
> Il 26/04/2011 12:41, Anders Rundgren ha scritto:
>> An unusual (unique?) aspect of the mentioned project is that
>> it is designed to be integrated in browsers.
> It aims at "client" security. My target is server security, so I don't
> have to leave .key files ar
On Tuesday, April 26 at 12:41PM, Anders Rundgren wrote:
>
> I don't know what you had in mind with an "USB P11 token"
> but in case you would like to participate in an effort
> making sort of a USB P11 token there is already a project
> to dig in to:
>
> http://webpki.org/auth-token-4-the-cloud.h
On 4/26/2011 8:10 AM, Jean-Michel Pouré - GOOZE wrote:
> Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit :
>> pkcs15-tool is a (G)UI as well. And to my knowledge it does what it
>> advertises.
>
> After a short discussion with Martin, I post the steps to reproduce:
>
> Initialize the
On 4/26/2011 2:25 AM, Jean-Michel Pouré - GOOZE wrote:
> Le lundi 25 avril 2011 à 22:53 +0200, NdK a écrit :
>> pkcs15-tool -D
>> should list 'em all, or not?
>
> A dump, oh sure, in hexadecimal or better binary.
> :)
>
> On the same vein:
>
> --list-public-keys
> does not read public keys derive
El mar, 26-04-2011 a las 16:25 +0200, Jean-Michel Pouré - GOOZE
escribió:
> Le mardi 26 avril 2011 à 16:38 +0300, Martin Paljak a écrit :
> > For the sake of purity, I don^t think that --list-public-keys should
> > display a fake public key object, which does NOT exist on the card in
> > relevant P
Jean-Michel Pouré - GOOZE wrote:
> > For the sake of purity, I don^t think that --list-public-keys should
> > display a fake public key object, which does NOT exist on the card in
> > relevant PKCS#15 structures. but patches for documentation are most
> > welcome.
>
> I understand your point of v
Le mardi 26 avril 2011 à 16:38 +0300, Martin Paljak a écrit :
> For the sake of purity, I don^t think that --list-public-keys should
> display a fake public key object, which does NOT exist on the card in
> relevant PKCS#15 structures. but patches for documentation are most
> welcome.
I understan
For example:
What should happen when trying to delete such (nont existing) public key object?
On Tue, Apr 26, 2011 at 16:38, Martin Paljak wrote:
> Hello,
>
> 2011/4/26 Jean-Michel Pouré - GOOZE :
>> Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit :
>>> pkcs15-tool is a (G)UI as well
Hello,
2011/4/26 Jean-Michel Pouré - GOOZE :
> Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit :
>> pkcs15-tool is a (G)UI as well. And to my knowledge it does what it
>> advertises.
> Now, we come to the point:
> * pkcs15-tool --list-public-keys
> returns nothing
>
> * pkcs15-tool --r
Just wanted to note that exposing such device to IP stack makes it a
target to hack, packaging is much more difficult.
Also, that in crypto caching is not a problem as 99.99% of time
the content of the crypto device is constant.
About using USB directly, well, I disagree... I see this much li
Le mardi 26 avril 2011 à 08:23 +0300, Martin Paljak a écrit :
> pkcs15-tool is a (G)UI as well. And to my knowledge it does what it
> advertises.
After a short discussion with Martin, I post the steps to reproduce:
Initialize the Feitian PKI:
* pkcs15-init -E
* pkcs15-init --create-pkcs15 --prof
Il 26/04/2011 12:26, Peter Stuge ha scritto:
> NdK wrote:
>> Fox Board ( http://acmesystems.com/ ).
> .it
Good catch :)
> I will probably get a gumstix board for another couple of projects,
> and might prototype on that. I'm not sure the final system should run
> Linux because it's a whole lot of
Il 26/04/2011 12:41, Anders Rundgren ha scritto:
> I don't know what you had in mind with an "USB P11 token"
> but in case you would like to participate in an effort
> making sort of a USB P11 token there is already a project
> to dig in to:
> http://webpki.org/auth-token-4-the-cloud.html
Interest
Il 26/04/2011 11:28, Alon Bar-Lev ha scritto:
>> Since speed is quite critical, I was thinking to use something like G20
>> Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it
>> can be WAY cheaper than other solutions), but it's tiny, fast (400MHz
>> ARM9), can work as USB dev
Il 26/04/2011 13:47, Peter Stuge ha scritto:
> "forces local communications" makes no sense. If the device is
> connected via USB then it will be local regardless of which interface
> class it uses.
And you can even use UsbIP stack if you want...
> Maybe you will argue that it should implement CD
Le 22/04/2011 18:46, Viktor TARASOV a écrit :
> Well, this weekend I will look how far we can go with the Oberthur's IAS/ECC
> card and with actual trunk .
Oberthur's card supports SDO creation and deletion. That's not in the IAS/ECC
standard, but extremely useful for development.
These features
Le 26/04/2011 08:56, Martin Paljak a écrit :
> 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
Alon Bar-Lev wrote:
> >> it would be better to emulate some standard interface, such as
> >> serial over USB.
> >
> > Absolutely not.
>
> I would not dismiss this entirely...
Yes, entirely. It is incredibly silly to create a protocol on top of
stream emulation on top of a protocol which is *ALREA
On Tue, Apr 26, 2011 at 1:23 PM, Peter Stuge wrote:
> Alon Bar-Lev wrote:
>> it would be better to emulate some standard interface, such as
>> serial over USB.
>
> Absolutely not.
I would not dismiss this entirely...
>> Serial over USB has the advantage to work on all modern operating
>> systems
I don't know what you had in mind with an "USB P11 token"
but in case you would like to participate in an effort
making sort of a USB P11 token there is already a project
to dig in to:
http://webpki.org/auth-token-4-the-cloud.html
If you take a deep peek in the extensive documentation
you will no
NdK wrote:
> Fox Board ( http://acmesystems.com/ ).
.it
> It's surely not cheap
I will probably get a gumstix board for another couple of projects,
and might prototype on that. I'm not sure the final system should run
Linux because it's a whole lot of code for a simple device and
because it does
Alon Bar-Lev wrote:
> it would be better to emulate some standard interface, such as
> serial over USB.
Absolutely not.
> Serial over USB has the advantage to work on all modern operating
> systems, including Windows (PKCS#11 only not mini CSP). While
> implementing all logic within userspace.
On Tue, Apr 26, 2011 at 11:45 AM, NdK wrote:
>> I was thinking microcontroller size, but if you're using a more
>> powerful USB device hardware that can run Linux then it could be
>> realized pretty quickly using softhsm.
> Since speed is quite critical, I was thinking to use something like G20
>
Il 26/04/2011 09:51, Peter Stuge ha scritto:
> NdK wrote:
>> One of the projects on my TODO list (quite a long list :( ) is to
>> implement a suitable interface (CCID+virtual token? Could be better to
>> opt for something that doesn't require APDUs...) on an embedded system
>> w/ USB device interfa
NdK wrote:
> One of the projects on my TODO list (quite a long list :( ) is to
> implement a suitable interface (CCID+virtual token? Could be better to
> opt for something that doesn't require APDUs...) on an embedded system
> w/ USB device interface...
Right. This is the idea for a USB p11 token
Le lundi 25 avril 2011 à 22:53 +0200, NdK a écrit :
> pkcs15-tool -D
> should list 'em all, or not?
A dump, oh sure, in hexadecimal or better binary.
:)
On the same vein:
--list-public-keys
does not read public keys derived from RSA private keys.
--read-public-key
reads public keys derived f
Il 26/04/2011 08:41, Martin Paljak ha scritto:
>> 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 where
> th
39 matches
Mail list logo
