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.
From: Sean P. Turner [mailto:turners(_at_)ieca(_dot_)com]
Sent: den 9 september 2004 15:30
To: Stefan Santesson; Tony Capel
Subject: Static vs Dynamic sMIMECapabilities draft(s)
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.
Stefan Santesson wrote:
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? :-)
Microsoft Security Center of Excellence (SCOE)
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
I fully understand your reluctance (which I share) for proliferation
Please bear with me.
Your proposal requires an extension to the X.509 certificate syntax,
seems you have preliminary agreement from PKIX that S/MIME WG can do
is very good (and I am humbled by your ability to do that!), but we
sure we exploit this opportunity well, so we do not have to return to
too often ;-). To do that we need to consider what is quick and
today and also where we might go. So I think this discussion now is
I cannot agree that this is complex, although I agree it CAN be made
The model here is the CRLDistribution point (with all its warts).
did not worry about whether the CRL would be available by LDAP, HTTP,
whatever when they defined it. They only worried about what the CRL
to be. In our case I propose we already have a format: a null signed
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
website (and configured the HTTP content type correctly) it might even
today (??). And frankly, if an organization is already distributing
whatever method, allowing the same infrastructure to be used to
sMIMECapabilities in a null signed message is not much more work (and
also provide the full cert path, attribute certs, etc. if needed!).
just responds with a static null signed item. Processing on receipt
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
only way we can solve the sMIMECapabilities "problem" is just to stick
sMIMECapabilities into the cert. I think we will get a negative
it is one option where there are other options which are a bit more
we have a better chance. I have also mentioned that we should make
extension more application-agnostic, I think this will also make it
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
| 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
| > 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,
| > returned data can be static (i.e. pre-signed by the CA or
| end entity,
| > 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
| > 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
| > are
| > changed (or when the signing keys change of course).
| > I believe Jim's objective in "Certificate Distribution
| > draft-ietf-smime-certdist-05.txt, was to create something to be
| > distribute certificates AND sMIMECapabilities. It also raises the
| > of
| > 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
| > Tony
| > * I don't believe this is done in CMS/MSG implementations at the
| > I
| > don't believe implementers have been told to retain any such
| > if
| > 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
| > probably cached under subjectName (???). Your proposed method
| > inherently
| > 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
| > needed
| > for indirect methods if they are added as suggested.