Tony,
In-line;
-----Original Message-----
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com]
Sent: den 1 september 2004 20:37
To: ietf-smime(_at_)imc(_dot_)org; 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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
| [mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Anders
Rundgren
| Sent: August 12, 2004 4:35 AM
| To: ietf-smime(_at_)imc(_dot_)org
| 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
|
|