Rickard Bellgrim wrote:
> Definately my recommendation. I'm also working with all the big HSM
> vendors and you don't have to save space on any of them, at a minimum
> you can store about one hundred objects in a single slot. So for PKI
> purposes there is vast space available. None of the big HSM
On 03/18/2010 09:07 AM, Martin Paljak wrote:
> On Mar 17, 2010, at 08:31 , Tomas Gustavsson wrote:
>> None of the big HSM vendors
>> license per storage, it's simple one-time purchase price of the HSM
>> hardware (+ support costs that are a percentage of the price).
>
> Just curious: what does the
Rickard Bellgrim wrote:
>>
>> Definately my recommendation. I'm also working with all the big HSM
>> vendors and you don't have to save space on any of them, at a minimum
>> you can store about one hundred objects in a single slot. So for PKI
>> purposes there is vast space available. None of the
Definately my recommendation. I'm also working with all the big HSM
vendors and you don't have to save space on any of them, at a minimum
you can store about one hundred objects in a single slot. So for PKI
purposes there is vast space available. None of the big HSM vendors
license per storage, it
On Mar 17, 2010, at 08:31 , Tomas Gustavsson wrote:
> None of the big HSM vendors
> license per storage, it's simple one-time purchase price of the HSM
> hardware (+ support costs that are a percentage of the price).
Just curious: what does the support cost include and am I disallowed to use the
On 03/16/2010 11:16 PM, Rickard Bellgrim wrote:
> On 16 mar 2010, at 13.50, Tomas Gustavsson wrote:
>
>
>> If using PKCS#11 I would personally not go down a path that is not
>> commonly used. The common usage of smart cards and hardware security
>> modules always stores both the private (as a s
On Mar 16, 2010, at 15:31 , Tomas Gustavsson wrote:
>
> If using PKCS#11 I would personally not go down a path that is not
> commonly used. The common usage of smart cards and hardware security
> modules always stores both the private (as a sensitive object) and the
> public key (either as a pu
On 16 mar 2010, at 13.50, Tomas Gustavsson wrote:
>
> If using PKCS#11 I would personally not go down a path that is not
> commonly used. The common usage of smart cards and hardware security
> modules always stores both the private (as a sensitive object) and the
> public key (either as a pu
If using PKCS#11 I would personally not go down a path that is not
commonly used. The common usage of smart cards and hardware security
modules always stores both the private (as a sensitive object) and the
public key (either as a public key or as an x.509 certificate).
This works and is well t
If using PKCS#11 I would personally not go down a path that is not
commonly used. The common usage of smart cards and hardware security
modules always stores both the private (as a sensitive object) and the
public key (either as a public key or as an x.509 certificate).
This works and is well t
But you still have access to the "public parts" of the private key.
16 mar 2010 kl. 08.10 skrev "Andreas Jellinghaus" :
> Am Dienstag 16 März 2010 07:20:31 schrieb Rickard Bellgrim:
>> Hi
>>
>> A quick comment is that OpenDNSSEC will, probably in May, only need
>> the
>> private part of the key
Hi
A quick comment is that OpenDNSSEC will, probably in May, only need the private
part of the key. Since you can derive the public part from the private object.
This will save space in the HSM and make our code faster.
// Rickard
On 15 mar 2010, at 21.39, Andreas Jellinghaus wrote:
> Hello,
Andreas Jellinghaus wrote:
> hmm. my vague memory tells me with some cards you generate a private key,
> and only then - right after generating - you get the public key as response.
> so it needs to be saved right away as rsa public key object or a certificate
> signing requests needs to be gener
hmm. my vague memory tells me with some cards you generate a private key,
and only then - right after generating - you get the public key as response.
so it needs to be saved right away as rsa public key object or a certificate
signing requests needs to be generated, else you can't download the pub
On 16 mar 2010, at 09.15, Andreas Jellinghaus wrote:
> Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim:
>> But you still have access to the "public parts" of the private key.
>
> ok, I'm no expert here, so I can't say yes or know.
>
> But I know that some cards hide their private key
On Mar 16, 2010, at 10:18 , Andreas Jellinghaus wrote:
> Am Montag 15 März 2010 22:08:28 schrieb Douglas E. Engert:
>> Andreas Jellinghaus wrote:
>>> Hi everyone,
>>>
>>> here is a bug report with a patch for pkcs11-tool.
>>>
>>> I'm no expert on this subject, so feedback is very welcome.
>>> it
On Mar 16, 2010, at 09:09 , Andreas Jellinghaus wrote:
> Am Dienstag 16 März 2010 07:20:31 schrieb Rickard Bellgrim:
>> Hi
>>
>> A quick comment is that OpenDNSSEC will, probably in May, only need the
>> private part of the key. Since you can derive the public part from the
>> private object. This
Am Montag 15 März 2010 22:08:28 schrieb Douglas E. Engert:
> Andreas Jellinghaus wrote:
> > Hi everyone,
> >
> > here is a bug report with a patch for pkcs11-tool.
> >
> > I'm no expert on this subject, so feedback is very welcome.
> > it looks good in general, except maybe more return codes/
> > e
Am Dienstag 16 März 2010 08:28:32 schrieb Rickard Bellgrim:
> But you still have access to the "public parts" of the private key.
ok, I'm no expert here, so I can't say yes or know.
But I know that some cards hide their private keys, so you need
to login first, to see if some private key is on th
Am Dienstag 16 März 2010 07:20:31 schrieb Rickard Bellgrim:
> Hi
>
> A quick comment is that OpenDNSSEC will, probably in May, only need the
> private part of the key. Since you can derive the public part from the
> private object. This will save space in the HSM and make our code faster.
hu? a
Andreas Jellinghaus wrote:
> Hi everyone,
>
> here is a bug report with a patch for pkcs11-tool.
>
> I'm no expert on this subject, so feedback is very welcome.
> it looks good in general, except maybe more return codes/
> error checking etc., and a different code path if
> pkcs11-tool is compi
Hi everyone,
here is a bug report with a patch for pkcs11-tool.
I'm no expert on this subject, so feedback is very welcome.
it looks good in general, except maybe more return codes/
error checking etc., and a different code path if
pkcs11-tool is compiled without openssl.
the author asks about t
22 matches
Mail list logo
