[kmf-discuss] PSARC 2006/283 Certificate & PKCS#11 PAM, module

Garrett D'Amore gdamore at sun.com
Thu Apr 3 11:22:19 PDT 2008


As promised at yesterday's meeting, I've reviewed the materials.

I have to admit, I independently came to many of the same conclusions as 
Gary, even before I got to the point of Gary's mail when reading the 
mail log.

I believe that this case *again* underscores the FOSS-induced 
schizophrenia we seem to be suffering from in ARC.  I've noted that 
separately in detail on arc-discuss, and fervently hope someone senior 
to take corrective action will do so.  But that's not a matter to solve 
for this case, I think.

Furthermore, I find the justification of a "single large customer wants 
X, and is happy with our implementation" to be a poor substitute for 
proper architecture.

This isn't the same as saying we should not ship the product.

We need a way to deliver the bits to the "large customer", without 
sacrificing on our architecture.  I think the project team *should* try 
to find out if there is a way to deliver bits to the requiring customer 
as either a "beta test", or "unbundled product", until such time as we 
are able to resolve the architectural issues and deliver a "first class" 
implementation.

Failing that, if this is to go into 
Solaris/Nevada/Indiana/whatever-we-are-calling-it-now, we need to way to 
identify that this solution is still under development, and probably not 
ready for prime-time use by most customers.  Marking everything in the 
case Volatile, may be a way to do that.  (Actually, it seems we need a 
new taxonomy, perhaps "Experimental" or somesuch...)  Cautions in the 
documentation that the product (or the Solaris integration of the 
product) is still evolving (along with perhaps known limitations, such 
as lack of auditable administration) could go a long way to help here.

I do *not* believe that it will be feasible to replace the existing 
smart card framework *until* the considerations that Gary has raised are 
addressed.  In particular, the product *must* have proper Sun-quality 
documentation, must support the various Big Rules (including auditable 
administration), and *should* address those fit-and-finish issues (e.g. 
the make_hash_links.sh script to configure this feels like an awful hack).

If the product can be unbundled for said large customer, or can be 
marked Volatile (with appropriate cautions in the docs), then I have no 
qualms about approving the project.  (I *greatly* prefer an unbundled or 
Value-Add package, with a reduced level of stability commitment.)

It will then be incumbent on the team integrating the smart card pkcs11 
module to address these issues required to provide "proper" architecture.

The other alternative is to derail the case so that we can issue TCRs or 
TCAs to this case.  I don't feel strongly enough to derail on my own 
here, although I would be supportive of such an action if another member 
decided that was appropriate.

    -- Garrett




More information about the kmf-discuss mailing list