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 structures. but patches for documentation are most
>> welcome.
>
> I understand your point of view.
>
> 1) IMHO the public key really exists on card as soon as it derives from
> the private key. This is the duality of asymmetric key encryption.
Are you sure you want to use the word "derive" here? As in mathematical terms?
Any derivation, even if theoretically possible, would be only imaginable by
having access to the raw key material (varies depending on whether the RSA key
is a plain or CRT key) which is generally speaking not available in the context
of smart cards (a good reason why they exist, they let you only do a limited
and well defined set of operations with the raw key material). And my humble
suggestion is to consult a real cryptographer about the triviality of this
"derivation".
What you observed is extracting the public key from a certificate, which has
*nothing* to do with "deriving public keys from private keys".
> 2) The discussion whether a public key should exist as an independent
> object to be listed is secondary. From a user point of view, we should
> be able to ask "What are all available public keys?". What is important
> is that users are going to use the public key.
>
> Telling users "No there is no public key" because of a technical issue X
> is nonsense from a usage point of view but also in crypto.
> The same happens with OpenSC. People are going to use OpenSSH or VPN X/Y
> and they need to know which public keys they are going to use, quickly.
> Thinking they can access OpenSC documentation and get education is not
> the right way to analyse the problem.
Keys can get to the card in two ways: either generated on the card (meaning
private key is usually not extractable), which in your case (a Feitian card)
generates private key object and public key object (for example, the PIV card
would do it differently and not create an object for public key, just emit it
after key generation). If you later import a certificate to the card, you would
have two public key "objects" on the card: one ("virtual") inside the
certificate byte blob, one inside the public key file.
Or if imported to the card, only those objects are created that are asked to be
imported by the user. If you import a private key, a certificate associated
with the private key and a CA certificate, you get exactly what you ask for: a
private key object and two certificate objects. pkcs15-tool works with PKCS#15
data. If you don't import a public key file, you don't create a relevant record
in public key directory and you don't see one when listing those objects. Quick
interpretation of PKCS#15 specification does not mandate having public key
files either.
OpenSC PKCS#11 module does the same trick as public key reading in pkcs15-tool
- it creates a public key object from a certificate. Some software cares about
certificates only - for example Java PKCS#11 requires a certificate for every
private key. OpenSC.tokend only cares about certificates (OS X takes care about
the rest) and Windows also presents users with certificates (and not public
keys).
People will most probably be *using* (as in doing operations with) private
keys. Or "certificates" in some jargon. The only time when you'd be interested
in "plain" public keys would probably be in the context of (Open)SSH.
I think that this is a good example why educating users about what is going on
with keys and certificates and so on is important, so that they would know what
to expect.
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.
d) Better documentation and adding something like "--list-all-public-keys" to
pkcs15-tool, to provide a combined list of "native" public keys and ones from
certificates.
c) Remove the "read public key from certificate" convenience function to
reduce such confusion
d) Moving the "create public key objects from certificates" routine to
libopensc core, creating public key objects on the fly (How to differentiate
them on PKCS#15 level?)
e) Improving pkcs15-init so that it would create a public key file when
importing certificates (what will happen with different certificates against
the same key? This would also waste EEPROM space)
I could do a) or c), maybe also b) myself, anything else would require a patch
from somebody else.
Best,
Martin
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
