I am also concerned about requiring that the sMIMECapabilities be in the
certificate itself, although I agree that something to help get initial
sMIMECapabilities is required.
Jim Schaad's "Certificate Distribution Specification" expired draft
(draft-ietf-smime-certdist-05.txt) touched on this as well.
If sMIMECapabilities is bound to the certificate, certificates may need to be
re-issued more frequently (when capabilities information is changed). This will
create additional work for the CA, and CRLs will inevitably increase in size
(these are bad things). (Correct me if I am wrong: If the capabilities for an
organization changes, all of the certs will need to be reissued!)
Also since the certificate is signed by the CA, sMIMECapabilities in this
proposal is signed by the CA and not the end-entity (as in existing method).
This may sometimes be beneficial since it allows the CA to have added control
over the use of algorithms and key lengths. The change from the end-user
signing to the CA signing has security implications and should be noted*
(possibly in the security section).
Some of the issues could be addressed by allowing the use of a dynamic method as
well. One or more methods could be specified, XKMS + DNS, LDAP, and/or HTTP for
example. One available method could be an "immediate" method, allowing those
CAs who do not mind putting sMIMECapabilities within their certificates to do so
(as currently proposed).
I also wonder how many cases there are when only the sMIMECapabilities is
required (and not certificates & paths as well). If you don't have a
certificate, an extension won't help (you need certificates and
sMIMECapabilities both). If you have a certificate from a previous message you
likely also received the sMIMECapabilities in a SignerInfo. If you obtained the
certificate using LDAP or some other means you might logically but arguably
expect to access the sMIMECapabilities the same way. If your software threw
away the S/MIME capabilities (rather than caching them like the certificate)
adding them to the certificate is a peculiar way to fix the software! Also of
course for dual keypair systems, there may be situations where you have the
signing certificate but not the encryption one, in which case you want both
sMIMECapabilities and the encryption cert - and I hope the proposal is not to
embed the encryption cert inside the signing cert!!!
So maybe the method used to get sMIMECapabilities should also be able to return
the certificates & paths - to make it more generally useful - in which case Jim
Schaad's proposal - and allowing any dynamic access method including XKMS + DNS,
LDAP, HTTP, . - may be worth another look.
Sorry for the long winded reply. But an easier method to get certs, paths and
sMIMECapabilities is needed.
* This may also include a discussion about using values provided in certificates
in preference to values obtained by other means (e.g. when both a certificate
and the SignerInfo contain sMIMECapabilities). For example, the first paragraph
of Section 3 in the current proposal may not always be correct: the
sMIMECapabilities list signed by the CA (e.g. provided in a certificate) may be
more trusted than the list provided in a message even if it appears the message
was more recent. In some applications the increased trust (or more correctly,
the increased authority of the signor) may take preference.
| -----Original Message-----
| From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Anders
| Sent: August 12, 2004 4:35 AM
| To: ietf-smime(_at_)imc(_dot_)org
| Subject: Re: I-D ACTION:draft-santesson-smime-scext-00.txt
| I have no comments on the "design" in this draft.
| However, I seriously question the idea to put client software
| capabilities in certificates.
| - because issuers may not have this information
| - because users may have multiple clients
| - because static solutions are limiting
| If we begin to use dynamic methods like XKMS + DNS to find
| public keys of recipients, SCEXT represents a step in another
| Due to the limited utility of true end-to-end encryption in
| corporate environments (the DOMSEC RFC shows a few good
| reasons to that), as well as the de-facto use of the web as a
| distribution medium for e-government purposes (which is a
| much easier solution than S/MIME), I believe that Microsoft
| should focus on making a gateway e-mail standard a reality
| rather than patching a system that never will play a major
| role and actually mostly creates problems for end-users and
| system administrators.