Sean,
I fully agree. I have no fear that these specifications will overlap since they
will specify entirely different type of certificate content and will represent
fully distinguishable options.
/Stefan
________________________________________
From: Sean P. Turner [mailto:turners(_at_)ieca(_dot_)com]
Sent: den 9 september 2004 15:30
To: Stefan Santesson; Tony Capel
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Static vs Dynamic sMIMECapabilities draft(s)
All,
After following the discussion, I think we ought to have two drafts: one for
the "static" capability and one for the "dynamic" capability. I base this on
the time frame necessary to complete the "static" draft, which is pretty much
documenting the security considerations (ala Dennis's comments), compared to
the "dynamic" draft, which is pretty much still on the white board. If another
draft is produced that documents the "dynamic" capability, the WG will discuss
it as we are discussing the "static" case. My only caution is that I don't
want the "dynamic" draft to define ways to distribute certificates that's
already covered by PKIX, LDAP, and DNS specifications. Further, if people think
that those specifications are too hard there's going to be pkiops BOF in
Washington that is supposed to start looking at "ways to make certificate use
and deployment easy." I hate to have two ways to do the same thing but they're
supporting different requirements (static vs dynamic) and they're both optional
to implement so I can see why it's okay to have them in separate drafts.
spt
Stefan Santesson wrote:
Tony,
I'm sorry, but I can't get away from the fact that I believe that you
oversimplify this issue.
Even if you do get passed the format issue by using a null signed
message I see an immediate problem in sorting out WHO is the signer of
the null signed message.
If you force the certified subject to be the signer (which you probably
need to if it is to work according to existing principles) then the
solution will be practically useless since you loose the ability to
automate the process to generate and distribute capabilities.
If you let the certificate issuer sign the null signed message on behalf
of the subject, then you probably need to define how you specify in the
message who's capabilities that are defined in the message and now we
have opened the can of worms for other options and variants as well.
And then you still need to define a new extension to point to this data.
Another problem is storage location and its automation. CRL is easily
configurable in a system because one CA has a limited set of CRLs to
produce (mostly only one) but here we have a concept where you store at
least one object per subject, and maybe many. And this makes
implementation far more complex than CRL storage and may include aspects
such as directory schema expansion and innovation to manage users with
renewed certs or multiple valid certs.
Comparing with CRLs are probably not that good to prove your point since
CRLs actually are enormously complex if you study all options with
segmented scope, indirect CRLs, delta CRLs, Revocation reasons,
revocation or hold status, invalidity dates and renewal frequencies,
etc..... A perfect example how the task to specify a signed list of
serial numbers expanded to Goliat's proportions.
The current draft doesn't require any new object identifiers; it is just
making use of an already defined data structure for sMIMECapabilities to
be used as certificate extension. Easy and simple!
I want to repeat that I'm NOT principally opposed towards discussing
good innovative solutions to solve dynamic capabilities expression, but
I still claim that it is too complex to mix with this simple spec, which
should be done before end of this year.
There is no reason why we need to cover dynamic capabilities in the same
RFC. You can't use the same extension format anyway since the format of
the current spec use the already established structure for the
sMIMECapabilities attribute. This can't be changed to include links to
dynamic data. You need to do that in a new extension anyway.
If this WG wants to do dynamic capabilities of certificates it is
perfectly OK to do that in a separate RFC.
And I'm not the guy to lead that effort.
Maybe you are? :-)
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
From: Tony Capel [mailto:capel(_at_)comgate(_dot_)com]
Sent: den 3 september 2004 22:18
To: Stefan Santesson; ietf-smime(_at_)imc(_dot_)org
Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt
Stefan:
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....
Tony
| -----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.
| >
|
|