Norbert Veber wrote:
This
time it stopped here:
adding new entry "dnQualifier=CA,serialNumber=345,st=Maryland,dc=testcertificates,dc=gov,o=Test Certificates,c=US"
ldapadd: update failed: dnQualifier=CA,serialNumber=345,st=Maryland,dc=testcertificates,dc=gov,o=Test Certificates,c=US
ldap_add: Naming violation (64)
additional info: naming attribute 'dnQualifier' is not present in entry
Norbert,
I believe that I have discovered the source of the problem. According
to section 4.7 (Add Operation) of draft-ietf-ldapbis-protocol-18.txt
(see
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-18.txt):
Parameters of the Add Request are: ...
- attributes: the list of attributes that make up the content of the
entry being added. Clients MUST include distinguished values
(those forming the entry's own RDN) in this list, the objectClass
attribute, and values of any mandatory attributes of the listed
object classes. Clients MUST NOT supply NO-USER-MODIFICATION
attributes such as the createTimestamp or creatorsName attributes,
since the server maintains these automatically.
As I read this, LDAP requires that the entry contain an attribute of
"dnQualifier: CA" since the entry's RDN is "dnQualifier=CA". I was not
aware of this requirement and it appears that OpenLDAP only recently
added checks to ensure that the requirement is being met. I have been
using the version of OpenLDAP that came with Red Hat 9 (2.0.27) and
have had no problems.
Unfortunately, I don't know how to solve the problem. I looked in
OpenLDAP's schema directory, and while I found dnQualifier defined, it
was not listed as a MUST or MAY for any objectClass. So, I don't know
how to address this issue without changing adding a new objectClass
definition or changing a current one.
Fortunately, this only appears to be an issue for three entries in the
LDIF file:
1) dn:
dnQualifier=CA,serialNumber=345,st=Maryland,dc=testcertificates,dc=gov,o=Test
Certificates,c=US
2) dn:
title=M.D.,generationQualifier=III,sn=CA,2.5.4.65=Fictitious,initials=Q,givenName=John,l=Gaithersburg,o=Test
Certificates,c=US
3) dn: emailAddress=Test29EE@invalidcertificates.gov,CN=Invalid DN
and RFC822 nameConstraints EE Certificate
Test29,OU=permittedSubtree1,O=Test Certificates,C=US
I would recommend simply removing these three entries from the LDIF
file:
- Entry 1) is only used in test 4.3.7 (Valid RFC3280 Mandatory
Attribute Types Test7). This test was included to help demonstrate the
existence of two implementations that can process the included
attribute types, as is required to advance RFC 3280 to Draft Standard.
However, this test will not be required by the Protection Profile that
NIST is writing.
- Entry 2) is only used in test 4.3.8 (Valid RFC3280 Optional
Attribute Types Test8) and was included in the test suite for similar
reasons to test 4.3.7. Note, however, that in this case, it appears
that one could address the LDAP requirement by adding the
organizationalPerson objectClass to the entry which would in turn allow
the inclusion of the "title" attribute.
- Entry 3) contains the end certificate from test 4.13.29 (Invalid
DN and RFC822 nameConstraints Test29). In general, it should be
possible to run the tests even if the end certificate is not in the
directory.
There may be a better solution that would allow for all of these
entries to remain in the directory, but I am not an LDAP expert.
Perhaps someone who is more knowledgeable on the subject can provide an
alternative solution.
Please let me know if you discover any other problems.
Dave
|