jhutz at cmu.edu
Mon Dec 18 20:12:11 EST 2006
On Thursday, December 14, 2006 10:24:51 AM -0600 Nicolas Williams
<Nicolas.Williams at sun.com> wrote:
> First, generate a certificate request:
> % elfsign request -k private-keyfile -r certificate-request
> <interactive questionaire>
> then send the certreq to solaris-crypto-req at sun.com; when you get the
> cert back from Sun just place it in /etc/crypto/certs and sign the
Right, and Sun is just going to sign any code I send them?
If so, what's the point?
Why not let me set my own trust anchors?
Why not let me load any module I want?
It's bad enough that in order to test and debug my PAM module I have to
change its owner to 0 after every build, even though uid 0 already has
exclusive control over the PAM configuration and which files get loaded
(which, BTW, is also a pain - my test application should get to specify a
configuration source other than the files in /etc/). Now you want me to a
round trip with someone at Sun each time through the edit-compile-test
cycle? That's insane!
>> P.S. Who assigned the token label?
> Right, either I misunderstood the purpose of token labels or this is a
> bug -- I'm betting on the former.
Probably neither. The token label describes the particular token or
smartcard that is present in the slot. For example, on my Linux box:
[jhutz at sirius ~] 67> pkcs11-tool -I
Cryptoki version 2.11
Manufacturer OpenSC Project (www.opensc.org)
Library SmartCard PKCS#11 API (ver 1.0)
[jhutz at sirius ~] 67> pkcs11-tool -L
Slot 0 E-Gate 00 00
token label: SCS User Root CA (SCS User Root
token manuf: OpenSC Project
token model: PKCS #15 SCard
token flags: rng, login required, PIN initialized, token initialized
serial num : 00015550FFFF0200
[more slots elided]
Or, on a Solaris 10 system:
# pkcs11-tool --module /usr/lib/libpkcs11.so -I
Cryptoki version 2.11
Manufacturer Sun Microsystems, Inc.
Library Sun Crypto Softtoken (ver 1.4)
# pkcs11-tool --module /usr/lib/libpkcs11.so -L
Slot 1 Sun Crypto Softtoken
token label: Sun Software PKCS#11 softtoken
token manuf: Sun Microsystems, Inc.
token model: 1.0
token flags: rng, login required, PIN initialized, token initialized,
serial num :
According to the libpkcs11 man page:
... If more than one plug-in is
available, a meta slot is created that provides the mechan-
isms of all plug-ins in a single slot. When available, the
meta slot is always the first slot provided by libpkcs11.
The meta slot does not provide token-based objects.
So, the slot Doug is seeing is a "virtual" slot created by metaslot, whose
purpose is to provide a single slot which supports everything supported by
Incidentally, this behavior of Sun's library is an excellent example of why
"use the first slot with a token" may not be the best policy. The metaslot
token is _always_ the first slot, if it is present at all.
(*) BTW, this particular token is a CryptoFlex egate, which combines
smartcard and reader in a single USB device. The PKCS11 module in
this case comes from OpenSC, backed by pcsc-lite. PCSC reader ID's
(and this slot numbers) are assigned by pcscd as devices are added
and removed, so if you have two cards, it may not be possible for
the software to know which is which. This could be annoying for a
use who wants to authenticate to a remote site and can't because
the software is assuming slot zero and the card in that slot can't
be removed without triggering a logout...
More information about the krbdev