Steve,
I put the wording in on the matching so that I could do something along the
lines of I use this certificate for signing and it contains my email name.
The certificate I want to use for encrytion does not have my email address.
Since I had done a "match" and it was signed by the matching certificate
then it seems to me that I should be able to accept the lack of match on the
encryption certificate.
I can understand what you are saying about always wanting to check this,
however I don't think this should be disallowed. Do you really think this
is a big problem?
jim
-----Original Message-----
From: Dr Stephen Henson [mailto:shenson(_at_)bigfoot(_dot_)com]
Sent: Friday, June 05, 1998 3:04 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Certificate Distribution Specification comments.
This spec seems to cover most of the points. Many thanks to Jim for
producing it.
A few comments:
"3.4 Signing Certificate
1. Verify that the SMimeCertificatePublish object contains
a valid signature and the certificate used to sign the
message can be validated.
2. Does the certificate used to sign the
SMimeCertificatePublish object "match" the intended
recipient of the encryption object. If so proceed to step 6
else step 3.
.....
6. Locate the encryption certificate using the
SMimeEncryptionKeyPreference attribute in the signed
attributes of the SMimeCertificatePublish object."
It appears that if the "match" occurs in step 2. then the
SMIMEEncryptionKeyPreference certificate is not validated. IMHO the
encryption certificate must always be validated.
Re the issue of multiple SignerInfos. I'm personally in favour of this
because there may be times when several certificates need to be
published for the same recipient. They may have different policies or
indeed different algorithms: a sending agent can then decide which (if
any) to use. IMHO this is best handled with a single
SMimeCertificatePublish object to allow flexibility if the object is
being distributed over HTTP/FTP and there is no technique to
obtain the
"next object" if the one retrieved is not acceptable.
Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)bigfoot(_dot_)com
PGP key: via homepage.