Questions

["Jonathan Schulze-Hewett" <schulze-hewett@infoseccorp.com>]

Hi All,
	The old test suite organized the folder structure so that each test
had its own folder of applicable certs, crls, etc. That folder structure was
quite helpful when running the tests. Would it be possible to have a similar
folder structure established for this test suite? There seems to be some
assumption that the test suite will be loaded into an LDAP server when most
of the tests don't require a server at all. Is it assumed that the
application will pull the entire chain from the LDAP server?
	This is more of a path building question but I'm a little concerned
that it's possible to confuse an end user into using the wrong CRL. By
allowing a CA to have a different key for signing CRLs there appears to be
no binding between the CA signing certificates and the CA signing CRLs. Is
there some requirement or extension that binds a CRL signed by one key to an
end user certificate signed by another key? The only tests I can find assume
that the certificate signing key and the CRL signing key share a common
ancestor (4.4.19, 4.4.20, 4.4.21). Is this a requirement (if so where is it
specified)? Are there tests coming for completely different paths (with no
common ancestors) for the certificate signing and CRL signing certificates?
	Is there a standard, proposed standard, or draft for inheriting
DSA/DSS/DH parameters from issuer certificates? Is it anticipated that this
will be a requirement for ECC certificates in the future?
	When dealing with CRL DPs that are directory name and thus don't
have a server address specified, what server should be used? Is this an end
user configuration option? Is it an end user option on a per certificate
basis or is it expected that one LDAP server will provide all CRLs specified
in DPs with directory name only? 
	The test suite provides a number of cross certificate pairs but no
tests use them; will they be used in the future?
	The "Path Validation Testing for PKI Client Protection Profiles"
draft says:
"In other words, it must be possible for the user to specify, by some means,
a set of policies and have path validation succeed only if the path is valid
under at least one of those policies." Why is the term user used here? It
seems much more likely that an administrator or tester would like to set
certain policies rather than let end users specify policies. Does user mean
tester or administrator in this case, or is it really intended that end
users will configure policies?

Thanks!!!
Jonathan