Denis,
In-line;
-----Original Message-----
From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
Sent: den 3 september 2004 15:51
To: Stefan Santesson
Cc: ietf-smime(_at_)imc(_dot_)org
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-----
MIIFwzCCBKugAwIBAgIKE/lfpwABAAFNjjANBgkqhkiG9w0BAQUFADAvMS0wKwYD
VQQDEyRNaWNyb3NvZnQgSW50cmFuZXQgTGV2ZWwgMiBVc2VyIENBIDIwHhcNMDQw
NTEzMDk0MTI2WhcNMDUwNTEzMDk0MTI2WjCBiTETMBEGCgmSJomT8ixkARkWA2Nv
bTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNv
cnAxFjAUBgoJkiaJk/IsZAEZFgZldXJvcGUxDjAMBgNVBAMTBVVzZXJzMRkwFwYD
VQQDExBTdGVmYW4gU2FudGVzc29uMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDJ0aSfbuPMZOP/liMfopMXIUtaOmClzXCulOhfp3V6CcimCmGbvNzfGYfirmE3
0rH/+uT6e/CB5lo4rXFLqufvDV++bEWQJsIIS6KG4Bn0Cib1G4ebp8wrED2oJDx3
E2WeI40/jQALjcyp3OYmrNX4535Nq9SOMglY2/W3lr+E+QIDAQABo4IDCDCCAwQw
CwYDVR0PBAQDAgeAMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4G
CCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzArBgNVHSUEJDAiBgor
BgEEAYI3KgIBBgorBgEEAYI3FAICBggrBgEFBQcDAjA/BgkrBgEEAYI3FQcEMjAw
BigrBgEEAYI3FQiDz4lNrfIChaGfDIL6yn2B4ft0gU+J9vG2YYHbk8USAgFkAgEM
MDcGCSsGAQQBgjcVCgQqMCgwDAYKKwYBBAGCNyoCATAMBgorBgEEAYI3FAICMAoG
CCsGAQUFBwMCMDAGA1UdEQQpMCegJQYKKwYBBAGCNxQCA6AXDBVzdGVmYW5zQG1p
Y3Jvc29mdC5jb20wHQYDVR0OBBYEFPCxFTnSeoK5luwmPmXdS4u+EeEcMB8GA1Ud
IwQYMBaAFJPA18nU2Ss3YUqCdd0M/GqnUpx1MIHBBgNVHR8EgbkwgbYwgbOggbCg
ga2GSmh0dHA6Ly9jb3JwcGtpL2NybC9NaWNyb3NvZnQlMjBJbnRyYW5ldCUyMExl
dmVsJTIwMiUyMFVzZXIlMjBDQSUyMDIoMSkuY3Jshl9odHRwOi8vY3JsLm1pY3Jv
c29mdC5jb20vcGtpL21zY29ycC9jcmwvTWljcm9zb2Z0JTIwSW50cmFuZXQlMjBM
ZXZlbCUyMDIlMjBVc2VyJTIwQ0ElMjAyKDEpLmNybDCB0QYIKwYBBQUHAQEEgcQw
gcEwVgYIKwYBBQUHMAKGSmh0dHA6Ly9jb3JwcGtpL2FpYS9NaWNyb3NvZnQlMjBJ
bnRyYW5ldCUyMExldmVsJTIwMiUyMFVzZXIlMjBDQSUyMDIoMSkuY3J0MGcGCCsG
AQUFBzAChltodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9NaWNy
b3NvZnQlMjBJbnRyYW5ldCUyMExldmVsJTIwMiUyMFVzZXIlMjBDQSUyMDIoMSku
Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCifqY1BQk7if7RnSHV8545pZkSKKn5QPjQ
jIcc2JwISRu57Y+B9DOTdtI3ECEh73smz5DDUtTYcfebE7KC5Vt3J0zON8XWiAFl
lPwxEsWdl+/XX2UkOZSOwZ1GIa/BtUOR76P9kRuxvRcfaejriHYupbsxHq2CuT6d
fA32iWi/uAu6r9QzR9BPuYi4ht97s1xJ3UproChH+aPFXfPyyFNedkgVdI6vOV0J
yZSm9tXBuMa1IP4WNjDFnz8j3YXbMmK8x225vqW308mtFtowbIHHcpVjrigMqpDm
MSwdE0UK3hjIllvmAMEfVX9Y5ixrBQFc9oW6tkoFC1/IVOoID0tJ
-----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:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
Sent: den 3 september 2004 11:05
To: Stefan Santesson
Cc: ietf-smime(_at_)imc(_dot_)org
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