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

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 2 Sep 2004 01:13:28 +0100

Tony,

In-line;

> -----Original Message-----
> From: Tony Capel [mailto:[email-masked]]
> Sent: den 1 september 2004 20:37
> To: [email-masked]; Stefan Santesson
> Cc: 'Anders Rundgren'
> Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt
> 
> 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.

[Stefan] This is a fundamental misunderstanding. I do certainly not
propose that sMIMECapabilities should be REQUIRED in certs.

This is an option for the many cases where this is useful, makes sense
and is compatible with the organizational structure it is used.

So we don't need to prove that it is useful for all certificates and all
use cases. We only need to prove that it is useful enough and that its
use is not creating problems for those for which it doesn't make any
sense.

> 
> Jim Schaad's "Certificate Distribution Specification" expired draft
> (draft-ietf-smime-certdist-05.txt) touched on this as well.
> 
[Stefan] I'm sorry, I don't have this draft.

> 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!)

[Stefan] As you mention below, the act to put sMIMECapabilities is more
of a policy enforcement act and as such it doesn't differ from many
other aspects of certificates. You can compare with the case where the
certificate policy gets updated, changed or a new certificate policy
must be added to all certificates.

If your policy in this matter is subject to change on a frequent basis
in a way that needs to be immediately populated you need to handle and
plan for this. You may the conclude that you don't want to put
sMIMECapabilities in your certs. Renewal doesn't however necessarily
mean that old certificate must be revoked and some PKI implementations
actually allow enforced silent renewal of all certificate in an
organization to all users at the cost of just a few clicks in the
administrational GUI.

This must in the end be compared with the case where an initial exchange
takes place and the sender has NO knowledge about the recipient, then it
will need to fall back to the default configuration in the senders
application which in many cases is 40-bit encryption.

> 
> 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).

[Stefan] We agree here. It is important to clearly guide that user
signed sMIMECapabilities should have precedence over capabilities
carried in certs. The capabilities in certs are only meant to be the
last resource of guidance before falling back to the default
configuration in the sender's application.

> 
> 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).

[Stefan] I men that it is very important to use the same structure and
attribute format as when this same information is carried in a S/MIME
signed message. This way we can preserve the same logic for capabilities
in certificates and in signed messages and thus switch to the use of
capabilities in signed messages as soon as this is available for the
sender.

> 
> I also wonder how many cases there are when only the sMIMECapabilities
is
> required (and not certificates & paths as well).

[Stefan] S/MIME is based on the use of certificates. If you have any
case where you don't have a certificate then this feature does not apply
to you.

  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!

 [Stefan] I think this is a misunderstanding of the spec. You would use
the capabilities from the signed message if you have one. You only use
the capabilities in the certificate if you don't have any other data to
use.

> 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!!!

[Stefan] You are right, that is absolutely NOT the proposal.
sMIMECapabilities only makes sense in encryption certs to be used by the
sender of an encrypted message.

> 
> 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.
> 
[Stefan] I don't agree. We should not overload this function. Just
complement the use of the same attribute in signed messages.

> Sorry for the long winded reply.  But an easier method to get certs,
paths
> and
> sMIMECapabilities is needed.
> 

[Stefan] No problem. I hope my answers make sense.

> 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: "Tony Capel" <[email-masked]>
Date: Thu, 2 Sep 2004 12:54:27 -0400

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 03 Sep 2004 11:05:00 +0200

Stefan,

I am re-using the e-mail from Tony to comment.

> 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 ...)

> 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