[Top] [All Lists]

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

2004-09-03 13:16:26


I fully understand your reluctance (which I share) for proliferation of scope.
Please bear with me.

Your proposal requires an extension to the X.509 certificate syntax, and it
seems you have preliminary agreement from PKIX that S/MIME WG can do that.  This
is very good (and I am humbled by your ability to do that!), but we should make
sure we exploit this opportunity well, so we do not have to return to the well
too often ;-).  To do that we need to consider what is quick and simple to do
today and also where we might go.  So I think this discussion now is valuable.

I cannot agree that this is complex, although I agree it CAN be made complex as
you demonstrate.

The model here is the CRLDistribution point (with all its warts).  Those guys
did not worry about whether the CRL would be available by LDAP, HTTP, SMTP, or
whatever when they defined it.  They only worried about what the CRL format was
to be.  In our case I propose we already have a format:  a null signed message.
Maybe Denis will suggest an attribute certificate - but that can be carried in a
null signed message too.  I suspect that if I posted a null signed message on a
website (and configured the HTTP content type correctly) it might even work
today (??).  And frankly, if an organization is already distributing CRL's by
whatever method, allowing the same infrastructure to be used to provide
sMIMECapabilities in a null signed message is not much more work (and it will
also provide the full cert path, attribute certs, etc. if needed!).  The server
just responds with a static null signed item.  Processing on receipt is the same
as the processing already implemented for incoming signed messages.

I think there is a danger if we only propose to PKIX (and X.509) folks that the
only way we can solve the sMIMECapabilities "problem" is just to stick all the
sMIMECapabilities into the cert.  I think we will get a negative reaction.  If
it is one option where there are other options which are a bit more efficient,
we have a better chance.  I have also mentioned that we should make the
extension more application-agnostic, I think this will also make it more
palatable, but that's another thread....


| -----Original Message-----
| From: Stefan Santesson [mailto:stefans(_at_)microsoft(_dot_)com] 
| Sent: September 3, 2004 1:58 PM
| To: Tony Capel; ietf-smime(_at_)imc(_dot_)org
| Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt
| Tony,
| Yes it looks like a small cute thing doesn't it. Dynamic 
| sMIMECapabilities!
| 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.
| /Stefan
| > -----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
| > 
| > 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.
| >