[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SRL_DatabaseFlush bug !!?



Paulo,

Thank you for your feedback regarding the CML.  We have the following
responses to your questions:

1) Problem/question of SRL_DatabaseFlush:  The SRL uses the initialization
settings to determine the directories in which to store the SRL certificate
and CRL database files.  The problem that you are encountering with the
flush of the data base is probably because you have set the SRL
initialization settings to indicate that the certificate database file
should be stored in a file pathname of "./certs.db" and the CRL database
file should be stored in a file pathname of "./crl.db".  Using such file
pathnames will cause the SRL to store the data base files in the current
working directory (".").  If you are not using the SRL initialization
settings, then the SRL config file cert and crl settings must include the
complete file pathnames to indicate the directories in which to store the
SRL database files.  We were able to duplicate the problem that are
reporting by setting the SRL initialization settings to indicate that the
certificate database file should be stored in a file pathname of
"./certs.db" and the CRL database file should be stored in a file pathname
of "./crl.db".  When we set these settings to complete file pathnames, then
the SRL database files are stored in the indicated directories and the
SRL_DatabaseFlush() function works as expected.  In summary, this is not a
bug.

2) The 2000 X.509 Recommendation, PKIX RFC 2459 and the latest draft
son-of-RFC2459 (new-part1-08.txt) all state that the AuthorityKeyIdentifier
and SubjectKeyIdentifier extensions are used as part of the certification
path building process to help identify the issuer's certificate.  None of
the these specifications require that the AuthorityKeyIdentifier and
SubjectKeyIdentifier extensions be checked as part of the certificate path
verification process.  The CygnaCom Certificate Path Building Library (CPDL)
(used in conjunction with the v1.9.2 CML) checks the proper chaining of the
AuthorityKeyIdentifier and SubjectKeyIdentifier extensions, if present, as
part of the certification path building process.  When loading a self-signed
X.509 v3 Trusted root certificate into the CML cache, the CML does not check
that the subjectKeyIdentifier and authorityKeyIdentifier extensions match,
because this check is not required and is not needed when verifying a
certificate.  When the CML is searching the cache to identify a trusted root
certificate required to verify an object, then the CML uses the
AuthorityKeyIdentifier and SubjectKeyIdentifier extensions, if present, to
help identify the correct trusted root certificate from which to obtain the
public key required to verify the object.  In summary, this is not a bug.

Please let us know if we can provide further info.

===========================================
John Pawling, John.Pawling@xxxxxxxxxxxxxxxx
Getronics Government Solutions, LLC
===========================================

 

-----Original Message-----
From: Paulo Araújo [mailto:pjaraujo@xxxxxx]
Sent: Thursday, September 06, 2001 9:47 AM
To: Imc-Cml
Cc: John. Pawling
Subject: SRL_DatabaseFlush bug !!?


Hello

problem/question of SRL_DatabaseFlush
------------------------------------

I found an unexpected behaviour in SRL_DatabaseFlush().
Certificates and SRL's database files are being created
in the current working directory, not in the one where
those file were initially located.  Is this a bug ?


Another problem/question of CM_RetrieveKey
------------------------------------------

X.509 v3 Trusted root certificate extensions subjectKeyIdentifier and
authorityKeyIdentifier are not being checked when present.
CM_RetrieveKey verifies the certificate signature, but if the issuer and
subject private key match then this verification passes.  Is this a bug ?


Thanks for Your help,

Paulo Araújo