Re: Questions

["David A. Cooper" <david.cooper@nist.gov>]

Jonathan Schulze-Hewett wrote:

>	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?
>
None of the tests require that an LDAP server be used.  However, when 
testing implementations that are capable of using certificates and CRLs 
in LDAP servers to build paths, this will likely be the easiest way to 
use the test suite.  Since this test suite is designed to test path 
validation, and not path building, the method by which the path 
validation implementation obtains the certificates and CRLs that it 
needs are out-of-scope.

In the old test suite, certificates and CRLs were not re-used.  That is, 
other than the self-signed certificate used specify the trust anchor, no 
two tests shared any certificates and CRLs in common.  This made it 
simple to have separate folders for each test.

The PKITS test suite was designed to re-use certificates and CRLs as 
much as possible.  So, many of the intermediate certificates and CRLs 
are used to multiple tests.  Creating a separate folder for each test, 
each folder containing all the certificates and CRLs needed for that 
test, does not make as much sense as it did with the old test suite.  It 
is also not clear that the effort involved in creating such a structure 
would provide sufficient benefit to justify the effort.  Note, however, 
that there is a sample S/MIME message for each test and that these 
S/MIME messages include all of the certificates and CRLs needed for the 
corresponding test.

>	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?
>
The binding between the CA signing certificates and the CA signing CRLs 
is the CA's name.  If there are two different CAs within a PKI that both 
use the same issuer name, then there is a serious problem with that PKI.

When determining whether a certificate is covered by a CRL, the key(s) 
used to sign the certificate and CRL do not matter.  Only the issuer 
names and contents of the distribution points extensions are taken into 
account.

There is no requirement in X.509 or RFC 3280 for any relationship 
between the certification path for the certificate signing key and the 
CRL signing key.  Some people believe, however, that such a requirement 
should be imposed.  This topic is currently being discussed on the IETF 
PKIX mail list: http://www.imc.org/ietf-pkix/mail-archive/msg07020.html.

We do not plan to add any new tests to PKITS, or to make any other 
changes, at this time.  If mistakes are found in PKITS, we will fix 
them, but otherwise we intend to relabel the current draft as the 
official version 1.0 within the next month.  We anticipate that it will 
be necessary to expand the test suite at some point in the future, but I 
do not think that we would be including tests in which certificate and 
CRL signing keys are obtained via completely different paths unless such 
paths begin appearing in real-world implementations (something that I 
hope will not happen).

>	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?
>
In IETF PKIX, the rules for encoding public keys, including parameter 
inheritance rules for each algorithm for which this is a possibility, 
are specified in RFC 3279:  http://www.ietf.org/rfc/rfc3279.txt.

>	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?
>
This same issue applies to locating certificates as well as CRLs.  
Generally, the identity of the LDAP server to be queried would be a 
local configuration option, just as one may specify an LDAP server for 
the address book feature of an email client.  In a large PKI, there will 
not be a single server that contains all of the PKI information, but 
several servers can be connected together (either using X.500 DSP 
chaining or LDAP referrals) so that a client can obtain all necessary 
information even if only one server is specified in the local 
configuration.  All of this is a directory infrastructure issue, though, 
and so it out-of-scope for this test suite.

>	The test suite provides a number of cross certificate pairs but no
>tests use them; will they be used in the future?
>
Cross certificate pairs are simply structures that hold certificates 
that have been issued by one CA to another CA.  The cross certificate 
pairs simply hold the cross-certificates that are specified in the test 
suite.  They are included in the test data because there is a 
requirement to include them in the directory (see section 3.2 of RFC 
2587, http://www.ietf.org/rfc/rfc2587.txt).  If you are not using a 
directory to run the test suite, then you have no need for the cross 
certificate pairs.

>	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?
>
We simply meant that it must be configurable.  Whether the ability to 
configure this is provided to ordinary users or is restricted to 
administrators is left up to individual implementations.  Obviously the 
tester will need to be able to change this configuration setting, but 
this could be done by providing the tester with administrator privileges 
on the test system, if that is required.

Dave