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

From: "Tony Capel" <[email-masked]>
Date: Wed, 1 Sep 2004 14:36:32 -0400

Stefan:

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. 

Tony

* 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: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Anders Rundgren
| Sent: August 12, 2004 4:35 AM
| To: [email-masked]
| 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.
| 
| Why?
| - 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 
| direction.
| 
| 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.
| 
| Anders
| 
|

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 3 Sep 2004 15:28:35 +0100

Denis,

In-line;

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 3 september 2004 15:51
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-santesson-smime-scext-00.txt
> 
> Stefan,
> 
> > 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.
> This is a nice summary.
[Stefan] Thanks, it makes the discussion easier :-)

> > 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).
> 
> It is your guess. I would have a different guess. :-)

[Stefan] Of course this is a guess. But it is based on experience. It is
at least more complex than the logotype extension which took over 2
years to complete :-)
> 
> > 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.
> 
> It may work nicely in small environnements.
> 

[Stefan] This works very well also in large organizations. And I know
this for a fact since I have it in my own S/MIME certificate and we are
50.000 users. It has been in use for a long time. It has proven to be
very useful and it has never caused any problems of the kind you
mention.

You can see it for your self in my certificate below:
(cut out and save as a file with .cer extension)

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

> However, there is currently insufficient text in the security
> considerations
> section to highlight the need of revocation, the document is using the
> word
> renew:
> 
>     Certification Authorities should therefore *renew* a certificate
>     including S/MIME Capabilities, if the subjects cryptographic
>     capabilities changes in a way that is no longer compatible with
the
>     current certificate.
> 
> The security considerations section should mention that:
> 
>   1) this extension is "adequate", if the same key is not used with
>      other encryption applications (and explain why),
> 
>   2) dynamic references would then be another solution to this
problem.
[Stefan] Thanks for the valuable input. I have no problem updating and
clarifying the security considerations section. I'm however not sure I
understand what you mean by 1) but I'm positive that we can sort it out.

I definitely agree to 2)

> Denis
> 
> > 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:[email-masked]]
> >>Sent: den 3 september 2004 11:05
> >>To: Stefan Santesson
> >>Cc: [email-masked]
> >>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
> >>>
> >>>
> >>>
> >>
> >
> >
>