Glenn Barry wrote:
>
> Attached are the PSARC fast-track case proposal and man pages.
>
> A few notes:
> * Sam said on the mitdev list that these interfaces are not fully
> stable yet so we've given them a Stability level of Volatile
> * Those interested in the pkcs11 slotid/certid issue pls take a close
> look at the note I added and make sure it gives both sides a decent
> summary
> * We've left the pkcs11 module_name keyword in for now but may remove
> it per the thread on this list last week.
We've finally got pkinit w/smartcard tested (thanks Doug, IainM, Sun-Ray
team, Val, Tony) so we need to finalize these interfaces asap and
submit the ARC case.
We've decided to remove the PKCS11 module_name opt for now and require
the PKCS11 module to be installed as a crypto provider via
libpkcs11(3LIB). Although we think we have the linker magic (thanks
Nico and
RodE) to make it happen directly the bigger issue is we need
more experience/discussion with the module(s) under libpkcs11(3LIB) to
see if it's necessary and a good idea (legal, technical, etc) to have
a direct option.
And I'm sure there will be more refinements to this base pkinit as we move
on to the pkinit pam_krb5 support.
Anyways, here's the ARC proposal diffs to remove module_name....thx, glenn:
*** mit163-pkinit-psarc.txt.old.module-name Tue Oct 7 20:28:07 2008
--- mit163-pkinit-psarc.txt Tue Oct 7 20:42:55 2008
***************
*** 4,10 ****
1.2. Name of Document Author/Supplier:
Author: Glenn Barry
1.3 Date of This Document:
! Sep, 2008
4. Technical Description
ABSTRACT
--- 4,10 ----
1.2. Name of Document Author/Supplier:
Author: Glenn Barry
1.3 Date of This Document:
! Oct, 2008
4. Technical Description
ABSTRACT
***************
*** 480,502 ****
pkcs12-file-name is the name of a `PKCS #12' format file,
containing the user's certificate and private key.
!
PKCS11:[module_name=]module-name[:slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label]
! All keyword/values are optional. module-name specifies the
! location of a library implementing `PKCS #11'. If a value is
! encountered with not keyword, it is assumed to be the module-name.
! If no module-name is specified, the default is
`/usr/lib/libpkcs11.so'.
! slotid= and/or token= may be specified to force the use of a
! particular smard card reader or token if there is more than one
! available. certid= and/or certlabel= may be specified to force
! the selection of a particular certificate on the device. See the
! `pkinit_cert_match' configuration option for more ways to select a
! particular certificate to use for pkinit.
! Note the slotid and certid keywords are controversial as some Sun
! Engineers believe they are a bad idea as there is no guarenteed
! ordering of slots returned from C_GetSlotList (for slotid). The
! MIT distro developers responded with (and I quote):
The problem with using slot labels is that some devices will
have multiple slots all with the same label but different
IDs. OpenSC does this for example. The only way to
--- 480,508 ----
pkcs12-file-name is the name of a `PKCS #12' format file,
containing the user's certificate and private key.
!
PKCS11:[slotid=slot-id][:token=token-label][:certid=cert-id][:certlabel=cert-label]
! All keyword/values are optional. PKCS11 modules (for example,
! opensc-pkcs11.so) must be installed as a crypto provider under
! libpkcs11(3LIB). slotid= and/or token= may be specified to force
! the use of a particular smard card reader or token if there is
! more than one available. certid= and/or certlabel= may be
! specified to force the selection of a particular certificate on
! the device. See the `pkinit_cert_match' configuration option for
! more ways to select a particular certificate to use for pkinit.
+ Notes:
+
+ * The MIT distro allows a module_name=path keyword/value to load the
+ PKCS11 module directly but Solaris has libpkcs11(3LIB) so we've
+ disabled that keyword and thus require the PKCS11 module to be
+ installed as a crypto provider (see cryptoadm(1M)).
+
+ * The slotid and certid keywords are controversial as some Sun
+ Engineers believe they are a bad idea as there is no guarenteed
+ ordering of slots returned from C_GetSlotList (for slotid). The
+ MIT distro developers responded with (and I quote):
+
The problem with using slot labels is that some devices will
have multiple slots all with the same label but different
IDs. OpenSC does this for example. The only way to
***************
*** 528,534 ****
* The MIT Kerberos plugin framework API will not be exposed at this time.
* pam_krb5(5) support for PKINIT will be added in a future project.
- * <gtb: add smartcard middlewhere status in OpenSol>
* RFC4557 (PKINIT with OCSP) is not in the MIT Kerberos PKINIT module and
won't be delivered with this project
--- 534,539 ----
