[Top] [All Lists]

RE: Static vs Dynamic sMIMECapabilities draft(s)

2004-09-10 06:40:56
I have no problem with this approach, (although even when specified as
"optional" many CA vendors may feel obliged to implement it - potentially
complete with "silent revocation/renewal").
I fully agree with your comments about potential "dynamic" approach(s).
Possibly one feedforward to the pkiops BOF is that whatever "ways to make
certificate use and deployment easy" should keep in mind (if not already) that
some applications (e.g. smime) may have other information (sMIMECapabilities)
that needs to be distributed (in attribute certs or otherwise) as well as just
the pki certs. 

-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On
Behalf Of Sean P. Turner
Sent: September 9, 2004 9:30 AM
To: Stefan Santesson; Tony Capel
Cc: ietf-smime(_at_)imc(_dot_)org
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? :-)

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


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


simple to



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

complex as

you demonstrate.

The model here is the CRLDistribution point (with all its warts).





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


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




on a

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




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





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



| 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




| 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




| 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




| 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




| 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




| > 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.

| >