[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