Stefan:
Thanks for your reply. I did understand that your proposal was optional and
need only be used by those interested in doing so. I also understand your
reluctance to allow the scope to get out of hand...
I was trying to make two main points:
1. The proposal offers one (optional) method to provide sMIMECapabilities: by
inserting them directly in the cert. I think it would be valuable to add the
ability to specify a location where sMIMECapabilities can be obtained (allow
dynamic methods to be specified). Zero, one or more of any of these methods
could be specified at the option of the organization issuing the certs.
2. If you do 1. above, the dynamic methods that can be specified should ideally
be similar/integrated with the general methods (that is, methods available even
if you do not have a cert) available to obtain certs and paths as well (and this
was Jim Shaads old proposal). And nowadays provisions for DNS + XKMS might be
included as noted by others in this list. The reason for this is that in many
cases when you need sMIMECapabilities, you also need the cert and path as well
(this was the point I was trying to make at the end of my previous e-mail), and
we should minimize the proliferation of methods.
The problem with having the data in the cert itself is that if an enterprise
updates their desktop software and needs to update any of the sMIMECapabilities
information, they will need to re-issue ALL of their certs and this is a VERY
big thing for large organizations. As far as using "silent" revocation/renewal
to limit CRL size, while this may be supported in some CA software, doing so
leads to other problems (e.g. having multiple apparently valid certs and
differentiating between them. Potential security holes if the sMIMECapabilities
change has a security impact...)
By using an sMIMECapabilities distribution point, the information itself is no
longer in the cert, avoiding the cert reissue issue. To take your point about
keeping it simple, the distribution point could return a null CMS message signed
by the CA or the end-entity (this provides additional options for the
enterprise); and to address other comments in the list, could point to a DNS SRV
for XKMS. Again, none of these would be mandatory; as you say, the originating
enterprise selects the method(s) they choose to support. There may be an issue
about securely binding the sMIMECapabilities to the instance of the cert - this
is discussed in Jim Schaads expired draft.
Somehow I wonder if a combination of your draft and an updated version of Jim's
(with less reliance on only the directory server method) would not be ideal??
Tony