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

["Stefan Santesson" <[e-mail]>]

Tony,

In-line;


> -----Original Message-----
> From: Tony Capel [mailto:[e-mail]]
> Sent: den 1 september 2004 20:37
> To: [e-mail]; 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: [e-mail]
> | [mailto:[e-mail]] On Behalf Of Anders Rundgren
> | Sent: August 12, 2004 4:35 AM
> | To: [e-mail]
> | 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
> |
> |
>