[Top] [All Lists]

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

2004-09-03 06:53:57



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 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.


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.

-----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


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

sMIMECapabilities:  by

inserting them directly in the cert.  I think it would be valuable


add the

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

available even

if you do not have a cert) available to obtain certs and paths as


(and this

was Jim Shaads old proposal).  And nowadays provisions for DNS +


might be

included as noted by others in this list.  The reason for this is


in many

cases when you need sMIMECapabilities, you also need the cert and


as well

(this was the point I was trying to make at the end of my previous


mail), and

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

is a


big thing for large organizations.  As far as using "silent"


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


differentiating between them.  Potential security holes if the


change has a security impact...)

By using an sMIMECapabilities distribution point, the information


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


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

message signed

by the CA or the end-entity (this provides additional options for


enterprise); and to address other comments in the list, could point

to a


for XKMS.  Again, none of these would be mandatory; as you say, the


enterprise selects the method(s) they choose to support. There may

be an


about securely binding the sMIMECapabilities to the instance of the


- this

is discussed in Jim Schaads expired draft.

Somehow I wonder if a combination of your draft and an updated


of Jim's

(with less reliance on only the directory server method) would not