RE: I-D ACTION:draft-santesson-smime-scext-00.txt

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

In-line;

> -----Original Message-----
> From: Tony Capel [mailto:capel@xxxxxxxxxxx]
> Sent: den 2 september 2004 18:54
> To: Stefan Santesson; ietf-smime@xxxxxxx
> 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
>