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.
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. :-)
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.
However, there is currently insufficient text in the security considerations
section to highlight the need of revocation, the document is using the word
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
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.
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.
From: Denis Pinkas [mailto:Denis(_dot_)Pinkas(_at_)bull(_dot_)net]
Sent: den 3 september 2004 11:05
To: Stefan Santesson
Subject: Re: I-D ACTION:draft-santesson-smime-scext-00.txt
I am re-using the e-mail from Tony to comment.
Thanks for your reply. I did understand that your proposal was
need only be used by those interested in doing so. I also
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
inserting them directly in the cert. I think it would be valuable
ability to specify a location where sMIMECapabilities can be
dynamic methods to be specified). Zero, one or more of any of these
could be specified at the option of the organization issuing the
I also believe that placing the sMIMECapabilities directly within the
certificate is a bad idea. The same encryption key may be used with
applications (e.g a virtual safe, a market place). If any of these
applications is changing we would need to revoke the public key
Attributes certificates have been invented to solve this issue.
It would be better to include INSTEAD (and thus not in ADDITION) a
to these sMIMECapabilities (and also vitualSafeCapabilities,
marketPlaceCapabilities, etc ...)
2. If you do 1. above, the dynamic methods that can be specified
be similar/integrated with the general methods (that is, methods
if you do not have a cert) available to obtain certs and paths as
was Jim Shaads old proposal). And nowadays provisions for DNS +
included as noted by others in this list. The reason for this is
cases when you need sMIMECapabilities, you also need the cert and
(this was the point I was trying to make at the end of my previous
we should minimize the proliferation of methods.
The problem with having the data in the cert itself is that if an
updates their desktop software and needs to update any of the
information, they will need to re-issue ALL of their certs and this
big thing for large organizations. As far as using "silent"
to limit CRL size, while this may be supported in some CA software,
leads to other problems (e.g. having multiple apparently valid certs
differentiating between them. Potential security holes if the
change has a security impact...)
By using an sMIMECapabilities distribution point, the information
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
placed at that pointer are correct. They could be signed using a
indicated in the sMIMECapabilitiesDP (i.e. sMIMECapabilities
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
of Attribute Certificate, rather than a CMS signed message.
> To take your point about
keeping it simple, the distribution point could return a null CMS
by the CA or the end-entity (this provides additional options for
enterprise); and to address other comments in the list, could point
for XKMS. Again, none of these would be mandatory; as you say, the
enterprise selects the method(s) they choose to support. There may
about securely binding the sMIMECapabilities to the instance of the
is discussed in Jim Schaads expired draft.
Somehow I wonder if a combination of your draft and an updated
(with less reliance on only the directory server method) would not