pkinit updates

[Jeffrey Hutzelman]

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
> module:

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
Available slots:
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
Available slots:
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, 
other flags=0x80220
  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 
any plugin.

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...


-- Jeff