ietf-smime
[Top] [All Lists]

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

2004-09-03 08:39:49

Stefan:

Thanks.  I don't think this is such a big suggestion.

| [Stefan] I can see the benefits from that. This is however 
| not a marginal expansion of scope. It is huge multiplication 
| of complexity.
| 
| sMIMECapabilities need to be authenticated. So if you 
| introduce storage of dynamic data, then you need to specify 
| the framework for how that data would be authenticated. That 
| is NOT a small thing.

This does not require the server to create authenticated data on-line, the
returned data can be static (i.e. pre-signed by the CA or end entity, or an
attribute cert as suggested by Denis).  There is no difference in authentication
framework complexity than if this data were put in the cert itself.  Whoever (CA
or end entity ...) agrees that this is the list, they can create and sign the
null message or attribute cert at that time.  This fixed item is then stored in
whatever server is used.  It is only changed when the sMIMECapabilities are
changed (or when the signing keys change of course).


I believe Jim's objective in "Certificate Distribution Specification"
draft-ietf-smime-certdist-05.txt, was to create something to be used to
distribute certificates AND sMIMECapabilities.  It also raises the issue of
whether there needs to be a secure binding between the sMIMECapabilities and the
specific certificate instance(s)* (and not just a binding between
sMIMECapabilities and the subjectName).

A bit more discussion of attribute certificates might be in order as well.


Tony

 
* I don't believe this is done in CMS/MSG implementations at the moment.  I
don't believe implementers have been told to retain any such binding even if
they had it - I suspect the sMIMECapabilities when cached by end systems is not
retained in signed form - and there is no cert hash to bind it to specific
cert(s) (more complicated for dual keypair).  sMIMECapabilities are probably
cached under subjectName (???).  Your proposed method inherently securely binds
the sMIMECapabilities to the instance of the cert and this is a NICE THING, but
I am not sure it is needed.  If it is, then additional considerations are needed
for indirect methods if they are added as suggested.