RE: Questions
Dave,
Thanks for the answers. Following up on the LDAP requirement. Test
4.4.7 seems very directory related in that the product is supposed to pull
the correct CRL from the directory entry. This contradicts your statement
about none of the tests requiring an LDAP server in your reply to my
previous e-mail. Will this be corrected before the final draft? What about
the NIST profile that says that All products should run this test?
Thanks!!!
Jonathan
> -----Original Message-----
> From: pkits@nist.gov [mailto:pkits@nist.gov] On Behalf Of
> David A. Cooper
> Sent: Wednesday, December 03, 2003 2:20 PM
> To: Multiple recipients of list
> Subject: Re: Questions
>
>
>
> 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
>
>
>
>
>
>
Date Index |
Thread Index |
Problems or questions? Contact list-master@nist.gov