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

From: "Stefan Santesson" <[email-masked]>
Date: Sat, 4 Sep 2004 01:08:18 +0100

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:[email-masked]]
> Sent: den 3 september 2004 22:18
> To: Stefan Santesson; [email-masked]
> 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:[email-masked]]
> | Sent: September 3, 2004 1:58 PM
> | To: Tony Capel; [email-masked]
> | 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:[email-masked]]
> | > Sent: den 3 september 2004 17:42
> | > To: Stefan Santesson; [email-masked]
> | > 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.
> | >
> |
> |
>

---

From: "Sean P. Turner" <[email-masked]>
Date: Thu, 09 Sep 2004 09:30:08 -0400

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,

Maybe you are? :-)

Stefan Santesson

-----Original Message-----
From: Tony Capel [mailto:[email-masked]]
Sent: den 3 september 2004 22:18
To: Stefan Santesson; [email-masked]
Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt

Stefan:

of

scope.
Please bear with me.

and

it

that.

This

should

make

the

well

simple to

do

Those

guys

message

on a

CRL's

by

provide

it

will

The

server

is

the same

all

the

reaction.

If

the

more

Tony

and

| sign
| > the

used

| to

as

| well.
| >
| >
| > Tony
| >
| >

binding

| even
| > if

are

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 10 Sep 2004 09:43:01 -0400

Sean:
 
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. 
 
Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sean P. Turner
Sent: September 9, 2004 9:30 AM
To: Stefan Santesson; Tony Capel
Cc: [email-masked]
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,

oversimplify this issue.

the null signed message.

Maybe you are? :-)

Stefan Santesson

  

-----Original Message-----

Stefan:

of

scope.

Please bear with me.

and

it

that.

This

should

make

the

well

simple to

do

valuable.

complex as

you demonstrate.

Those

guys

SMTP, or

format was

message.

carried in a

message

on a

work

CRL's

by

provide

it

will

The

server

is

the same

that the

all

the

reaction.

If

efficient,

the

more

Tony

|

|

| Tony,

|

| sMIMECapabilities!

|

|

| ldap, ftp.

|

|

|

| would be if it is....

|

| make a bet:-)

|

|

| own project.

|

| /Stefan

|

| >

| > Stefan:

| >

| >

| > | complexity.

| > |

| framework for

| >

| data on-line,

| the

| end entity,

| or

| > an

| put in the

and

| sign

| > the

| item is then

| sMIMECapabilities

| > are

| >

| >

| Specification"

used

| to

| issue

| > of

| sMIMECapabilities

| > and the

| >

as

| well.

| >

| >

| > Tony

| >

| >

| moment.

| > I

binding

| even

| > if

| systems

| > is not

| specific

are

| > inherently

| securely

| > binds

| is a NICE

| > considerations

| are

| > needed

| >

|

|

---

From: "Sean P. Turner" <[email-masked]>
Date: Mon, 13 Sep 2004 20:46:39 -0400

If I'm not there at the pkiops BOF somebody make sure to bring this up!

Tony Capel wrote:

Sean:

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.

Tony

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sean P.
Turner

Cc: [email-masked]

All,

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

spt

Stefan Santesson wrote:

Tony,

Maybe you are? :-)

Stefan Santesson

-----Original Message-----
From: Tony Capel [mailto:[email-masked]]
Sent: den 3 september 2004 22:18
To: Stefan Santesson; [email-masked]
Subject: RE: I-D ACTION:draft-santesson-smime-scext-00.txt

Stefan:

of

scope.
Please bear with me.

and

it

that.

This

should

make

the

well

simple to

do

Those

guys

message

on a

CRL's

by

provide

it

will

The

server

is

the same

all

the

reaction.

If

the

more

Tony

and

| sign
| > the

used

| to

as

| well.
| >
| >
| > Tony
| >
| >

binding

| even
| > if

are