All,
I have just posted new PKITS documentation and test data with very
minor modifications. If you have not been experiencing problems with
the test suite up until now, then these changes can probably be
ignored. With these minor changes, PKITS is now labeled version 1.0.
The changes are as follows:
-
In test 4.4.6, Wrong CRL CA has a CRL in its directory entry
that was actually issued by the Trust Anchor CA. The CRL in Wrong CRL
CA's directory entry (6.1.5.45) was supposed to be the same as the
"real" CRL of the Trust Anchor CA (6.1.5.2). However, the 6.1.5.45 CRL
previously did not include any revoked certificates whereas the 6.1.5.2
listed serial number 104 as revoked. Since both CRLs are valid CRLs
for the Trust Anchor CA, the 6.1.5.45 CRL could cause problems for test
4.4.21, which expects the Trust Anchor CRL to list serial number 104 as
revoked. CRLs 6.1.5.2 and 6.1.5.45 are now the same.
-
A problem was found with six of the S/MIME messages. When I
tried decoding these messages, the decoder output a "premature EOF"
warning, but decoded the messages anyway. The messages were OK, but
had one or two extra bytes at the end. I have corrected these
messages. The description of the problem that I provided is as follows:
-
While
going over the new PKITS test cases, I believe I found a
systematic problem in the base64 encoding of the following files:
smime/SignedDifferentPoliciesTest4.eml
smime/SignedInvalidBasicSelfIssuedOldWithNewTest2.eml
smime/SignedInvalidRFC822nameConstraintsTest22.eml
smime/SignedInvalidRFC822nameConstraintsTest26.eml
smime/SignedValidPolicyMappingTest3.eml
smime/SignedValidSelfIssuedinhibitPolicyMappingTest7.eml
Looking carefully at them, I realize they don't appear to contain
valid base64 data. Five of them have the same pattern:
smime/SignedDifferentPoliciesTest4.eml:
...
Ckdvb2Qgc3ViQ0ECAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBZtJEbCoUtyenYyyu5gd/A
Ek4TTcN0sg2NvIFLc37VLAxtWcv5iC5hoyiE4f0fXbYTd4G83SimqxsGVk9GIg0KT45wl4NgNJhr
maYOtxbRUF72ygH+rundE/BeJ7XnwDsDuvQRFFi/J0F/RQGJGS5lkkzS7l/8hgArXkZ3Xe3x5AAA==
smime/SignedInvalidBasicSelfIssuedOldWithNewTest2.eml:
...
IE5ldyBLZXkgQ0ECAQMwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCr3FvVdmJh2CFVoayeJFlN
BuAkhD3VQ+eu52+wWHKhivlTN+ZTkVVUB0XXtXLJujb5icVsIGFHuKLk0AxK0VV61cla8NFMBT1+
SSEUwtI9KzU/COBIsm0nTqwdmnpGL9ewPGrOyG9xlxyRWOD5yRfcZ1K7Ouom8cVmqZOQt+4suQAA==
smime/SignedInvalidRFC822nameConstraintsTest26.eml:
...
IFJGQzgyMiBDQTMCAQIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAa0s/qZXRqUKiX7bNyT4GG
YQhkU6Hxh+v0iEvtLH2j00ZqnitHQ+dopZT9ioQ4k8gZnsVmQUtAs6XGRgk9u9jc95rHx25UvUnF
D3WVvVfI8WPEcuoXLWSW0UecNSXeBR1FCqV50o100G4mWBxe4sQpJYJzviXX1K+TH2cXFMf6JgAA==
smime/SignedValidPolicyMappingTest3.eml:
...
bzMgc3Vic3ViQ0ECAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBv0VNZTogJWG4Y8F3S1ZJt
wo7fRVFZ1VM8bM761EmBgernXnYVjMAPbWi7j4thYao+Mct0/LsfBMiAJ0FlLVopXbHQk6AOuzsu
WlxwBYAGbS/XwPX6ZlJpA8mhG/lps6KaOaRZqLtNqcI7nEnhfKkqoN7VCNdCF42GsR3q/3JD3gAA==
smime/SignedValidSelfIssuedinhibitPolicyMappingTest7.eml:
...
ZzEgUDEgc3ViQ0ECAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBLP7PAXEAZmOqU4wjBMdEg
YSmq2uCSdM8rTXkHmnsNFFzF3kb631z3XIV0QnNxbf3tnPth1evO3czt7Vg75DA99eyRtAKMp14O
EyNOPY1erx7u/EVjqjuo8eJ36RQ/q+Cl3HpEtmMReKxWimbl1aRvdgEiKMXyX38Wc4NX6/S7QAAA==
If I replace 'AA==' with '==' they all work. You can verify that the
files doesn't contain valid base64 data, because base64 data ending
with '==' must always be of a specific length (see RFC 3548 or some
other base64 specification).
Perhaps your base64 encoder has problems when the data finish at the
line wrap position.
The sixth file smime/SignedInvalidRFC822nameConstraintsTest22.eml is
more complicated, but still similar. Here I use ^M to indicate CR:
cyBSRkM4MjIgQ0ExAgECMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAclFj1HCdFFFrmLLeVTnn^M
U1gINbB7LEpP0adbCR+EX+JfWfzWA5BXS0Gj33yFCrpw3FlfZtrQjG+jxr6kO/rlBrtxWyp9L8/l^M
7t01CHKSFMQ/pI+SGfzyufEOD2l+fgSS7WcGnGLsHBCj48b2y71KQ+zEr1EXXxV5/2MropWW4e0A^M=^M
Here you should replace 'A^M=^M' with '=^M'.
-
I made a few minor changes to the LDIF file to address the
problems that were described in a previous email:
http://cio.nist.gov/esd/emaildir/lists/pkits/msg00064.html. In order to
accommodate LDAP's requirements, I needed to use two object classes and
an attribute that were not in any of the schema files that came with
OpenLDAP. I have included these in a file called pkits.schema.
These are the only changes that have been made. No other changes have
been made to the test data since October 2003.
Note that while I have made most of the changes that I would like to
make to the LDIF file, I have not been able to add the following
directory entries to the directory:
- generationQualifier=III,sn=CA,pseudonym=Fictitious,initials=Q,
givenName=John,l=Gaithersburg,o=Test Certificates,c=US
- sn=CA,pseudonym=Fictitious,initials=Q,
givenName=John,l=Gaithersburg,o=Test Certificates,c=US
- pseudonym=Fictitious,initials=Q,
givenName=John,l=Gaithersburg,o=Test Certificates,c=US
- initials=Q, givenName=John,l=Gaithersburg,o=Test
Certificates,c=US
- givenName=John,l=Gaithersburg,o=Test Certificates,c=US
- l=Gaithersburg,o=Test Certificates,c=US
Public Key Interoperability Test Suite
These
directory entries should be added since there is a directory entry for
"title=M.D.,generationQualifier=III,sn=CA,pseudonym=Fictitious,initials=Q,
givenName=John,l=Gaithersburg,o=Test Certificates,c=US", which is used
in test 4.3.8 (Valid RFC3280 Optional Attribute Types Test8). I have
not been able to add these directory entries to the LDIF file since I
have been unable to find object classes that include
generationQualifier and pseudonym as MUST or MAY items. If you know of
any such object classes that I could use, please let me know.
I would like to thank those who discovered these problems in the test
suite.
Dave
|