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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Denis,

You basically repeat the same type of argumentation with I summarize as:

1) You confirm the need to in some way use information in a certificate
to help indicate capabilities of the subject

2) You point out that in some cases it is not suitable to put
capabilities directly in certificates since it may require too much
revocation and re-issuance of certificates.

3) You conclude that because of 2) we need to create an expanded work to
dynamically changeable capabilities structure. In addition to this you
suggest use of Attribute certificates to solve this expansion of scope.


My reply is the same again. I do not oppose the discussion of some kind
of dynamic solution for capabilities but it would be a magnitude more
complex to invent and specify and it would probably take years to
complete (my guess).

That should not stop us from doing the simple stuff when the simple
stuff is an adequate response to the need. Putting the current
sMIMECapabilities attribute in the cert is a well tested method that
works for the majority of cases.

My ambition and time commitment on this is only to complete that task
that was agreed at last IETF and added to the charter. If the S/MIME WG
whish to design an expanded solution for dynamic references to
sMIMECApabilities then I suggest that the WG discuss that in the context
of another new work item with another editor.

/Stefan
 
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: den 3 september 2004 11:05
> To: Stefan Santesson
> Cc: ietf-smime@xxxxxxx
> Subject: Re: I-D ACTION:draft-santesson-smime-scext-00.txt
> 
> Stefan,
> 
> I am re-using the e-mail from Tony to comment.
> 
> > 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.
> 
> I also believe that placing the sMIMECapabilities directly within the
> certificate is a bad idea. The same encryption key may be used with
other
> applications (e.g a virtual safe, a market place). If any of these
> applications is changing we would need to revoke the public key
> certificate.
> Attributes certificates have been invented to solve this issue.
> 
> It would be better to include INSTEAD (and thus not in ADDITION) a
pointer
> to these sMIMECapabilities (and also vitualSafeCapabilities,
> marketPlaceCapabilities, etc ...)
> 
> > 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.
> 
> Yes. This is the main idea.
> 
> Of course the next question is how to make sure that the
sMIMECapabilities
> placed at that pointer are correct. They could be signed using a
> certificate
> indicated in the sMIMECapabilitiesDP (i.e. sMIMECapabilities
Distribution
> Point). The signer of that structure could be the CA issuing the
> certificate, but does not need to be so.
> 
> The signed structure of the sMIMECapabilities would look like a
special
> kind
> of Attribute Certificate, rather than a CMS signed message.
> 
> Denis
> 
>  > 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
> >
> >
> >
>