[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] CKA_PUBLIC_KEY_INFO
"Burns, Robert"
<Robert.Burns@thalesesec.com> writes:
>Sorry for the late response -- traveling.
Ditto. (But I bet I'm travelling further than you :-).
>I'm having difficulty imagining other use cases where a user
will only have
>access to the private key, yet needs access to the public bits
as well. I do
>understand your experiences with tokens which fit this mold,
but the error
>(it seems) is in the fact that the token distributors were not
also including
>the public key object as well?
The problem is that this is a sizeable organisation, and it's not
the only one
that's doing it. Two days ago I had a discussion with someone
who's resorted
to trial-signing (enumerate every key on the token and generate a
signature
with it) to identify which private key an incoming certificate
corresponds to,
because they can't read the public-key components from the token in
order to
match the key to the cert. This just seems an unneccessarily
painful way to
have to do things.
>So is the problem really that there are definite cryptographic
reasons for
>needing the public key attributes on a private key, or is this
just a
>convenient way to solve the problem that token vendors have
introduced by not
>providing enough objects on their tokens?
Well, you can't really blame the vendors and leave it at that,
"just redeploy
a million tokens and get it right this time round", not being able
to recreate
a public key from a private-key object is something that's going to
keep
biting people again and again, it's just the universality of RSA
that's
currently masking the problem.
Peter.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]