The issue of providing a list of supported algorithms is quite
reasonable, and should be an request from this group to the PKIX
group, just as they agreed to defer to this group for a solution
to the problem of uniquely identifying of which particular
certificate should be used to validate a certificate.
Likewise, if it isn't there yet, we need an ability to upwards reference
a certificate chain (issuer cert) beginning with the digital signature
itself, and chaining back through all of the certs. It hink that the
revised format for authority KeyId is join to solve that problem within
the certificates, but I haven't followed this thread closely
enough to know that it is solved within the signature itself.
Bob
Marc Branchaud wrote:
Isn't PKIX doing this already? Does the stated goal ("maximizing...")
require more than what PKIX is doing?
Marc
The last time I looked at the PKIX stuff it didn't include a way to
state supported ciphers (someone please correct me if I'm wrong) e.g.
via some SMIMECapabilities variant.
If you just have the certificate via (e.g.) LDAP then you can't be sure
what ciphers are supported by the recipient: considering the SMIME v3/v2
differences in mandatory ciphers (3DES and RC2-40) this is important
IMHO.
Currently I think the only way to be sure is to send plaintext to the
recipient and get something signed in return including the capabilities.
This makes the directory certificate of little use: you could've done
that with just the email address.
--
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.
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman(_at_)novell(_dot_)com
"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."
"The most dangerous strategy is to cross a chasm in two jumps."