[Top] [All Lists]

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

2004-09-03 10:57:53


Yes it looks like a small cute thing doesn't it. Dynamic

Well, I'm damaged by experience and I can really see this take off in a
million directions.

First you will have the issue to sort out in what format and structure
you want to handle the data, meta data, signatures etc for the dynamic
capabilities, then you need to sort out how you will structure the
extension referring to this data in certificates, and then also sort out
what schemas can and cannot be used to obtain the data, whether it is
http, https, ldap, ftp.

Then we have already heard voices that we might need to distinguish
between capabilities for different applications and then we need to
define how we identify applications. Why not then argue about how this
data should be signed and if there might be a reason to let different
entities sign different parts of the capabilities data.

Then we can discuss how we would refer to the certificates used to
validate signatures on these signatures and what we must do to allow
dynamic linking to certificates in case some certificates gets revoked
or renewed.

And I have yet not even touched the aspect of attribute certificates
whether they will be or not be, and how that would be if it is.... 

I can't prove that this will take time but I'm willing to make a bet:-)

What I say is that we should not hold back the simple and straight
forward use of an existing, well defined data structure.

If this WG whish to solve dynamic access to authenticated application
oriented sMIMECapabilities, then it deserves it own project.


-----Original Message-----
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com]
Sent: den 3 september 2004 17:42
To: Stefan Santesson; ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt


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,
returned data can be static (i.e. pre-signed by the CA or end entity,
attribute cert as suggested by Denis).  There is no difference in
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
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
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
distribute certificates AND sMIMECapabilities.  It also raises the
whether there needs to be a secure binding between the
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


* I don't believe this is done in CMS/MSG implementations at the
don't believe implementers have been told to retain any such binding
they had it - I suspect the sMIMECapabilities when cached by end
is not
retained in signed form - and there is no cert hash to bind it to
cert(s) (more complicated for dual keypair).  sMIMECapabilities are
cached under subjectName (???).  Your proposed method inherently
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
for indirect methods if they are added as suggested.