ietf-smime
[Top] [All Lists]

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

2004-09-03 06:53:57

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.

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.

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