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

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

Denis,

In-line;


> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: den 3 september 2004 15:51
> To: Stefan Santesson
> Cc: ietf-smime@xxxxxxx
> 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.Pinkas@xxxxxxxx]
> >>Sent: den 3 september 2004 11:05
> >>To: Stefan Santesson
> >>Cc: ietf-smime@xxxxxxx
> >>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
> >>>
> >>>
> >>>
> >>
> >
> >
>