In-line;
-----Original Message-----
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com]
Sent: den 2 september 2004 18:54
To: Stefan Santesson; ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt
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.
[Stefan] I can see the benefits from that. This is however not a
marginal expansion of scope. It is huge multiplication of complexity.
sMIMECapabilities need to be authenticated. So if you introduce storage
of dynamic data, then you need to specify the framework for how that
data would be authenticated. That is NOT a small thing.
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).
[Stefan] That is not how I read Jim's document. After a quick glance I
read Jim's document as a way to specify effectively in an S/MIME
message, what certificates can be used to encrypt to it's sender and
what sMIMECapabilities are tied to each listed certificate (represented
by a hash). It also touches on how you could include pointers in the
S/MIME message, pointing to the storage location of certificates.
So this does NOT solve how you would access dynamic authenticated data
PRIOR to the first S/MIME exchange between the parties.
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.
[Stefan] This makes it clear to me that we try to solve different
problems. The problem how to find certificates and their path is
important but it is definitely out of the scope of this work. I don't
say that I oppose work in that problem space but it is not part of what
this work item is set to accomplish. Tying sMIMECapabilities to other
specific key management protocols would IMO be a bad thing that would
lower the value and usability of this work.
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...)
[Stefan] Revocation and re-issuance might be a problem for some
environments but will not be a problem for others. So potential problems
in some environments should not stop its use in the many cases where it
is useful.
I can whiteness from real life experience that sMIMECapabilities in
certificates has been widely and successfully deployed without causing
any major problems. So we know that it works and that it brings value to
the use of S/MIME. It is a provable fact.
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??
[Stefan] I'm not saying that dynamic storage of sMIMECapabilities must
be bad. I can definitely see benefits, but it should not be mixed with
the simple task to specify use of a single attribute in certificates
that is already well established and defined.
Going for dynamic storage is a major work that needs a careful thought
process to determine whether it is worth the efforts and whether it is a
proper response to real problems of S/MIME users.
Unless I got it totally wrong, I don't believe that Jim's draft will
provide the solution you are after here. But I could be wrong.
Tony