Subject: Re: application/mime and binary data
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Date: Thu, 31 Jul 1997 12:43:05 -0700
Newsgroups: mcom.list.ietf-smime

James M. Galvin wrote:
> I should say that I'm not fundamentally opposed to application/{signed or
> mime}, I just want to make sure we agree on the facts and the reason why we
> need it.

That's similar to my position.  We need to understand that we have
mutually incompatible requirements here.  The usual method of obtaining
a specification through successive approximations made in response to
raised issues does not work well in this situation.  To obtain a good
solution, people need to keep in mind the entire problem set and keep
straight which modes of operation address which requirements.  This is
difficult to do in a typical list forum, where the group attention span
is rarely longer than two messages.

> So you're recognizing that in spite of the utility of application/{signed
> or mime} it has its own set of problems.

Absolutely.  This is a key point I'm trying to make.

> You're comparing apples and oranges.  PGP and PEM are secure email
> protocols.  Multipart/signed is not.  mp/signed works only in conjunction
> with a secure email protocol; it does NOTHING standalone, from a security
> point of view.
> 
> mp/signed is a framework, it's a wrapper, for conveying email that has been
> secured by a secure email protocol from here to there.

Multipart/signed is a framework for secure email protocols.  Plug any
valid specification for what goes into the second part and the result is
a secure email protocol, comparable to PGP or PEM, which has the
properties I describe.

Ok, so when I claim that multipart/signed has particular properties,
It's really shorthand for claiming that all systems which consist of the
combination of multipart/signed plus a valid specification for what goes
into the second part of multipart/signed have said properties.

Now, this longhand form doesn't add anythng to understanding the core
problems, it just makes things longer to type and harder to follow.  So
can we just use the shorthand from from here on out?

> Armoring or not is a transport, or MIME decision, not mp/signed.  mp/signed
> provides some explicit requirements about ensuring the 7bit nature of the
> object to be conveyed but that's as close it gets to a transport.

Since multipart/signed is a composite MIME type, it (or all systems
which consist of a combination of it plus a valid specification for what
goes into the second part of it) inherits the property from MIME that it
cannot itself be tranfer-encoded and it cannot be armored by an
enclosing type without losing its property of making the signed content
visible to existing MIME UA's.

It is not relevant whether these properties come from the
multipart/signed specification itself or whether they are inherited from
MIME.  Multipart/signed (or all systems which yada yada yada) has these
properties.

> When conveying text, mp/signed is blue if the object to be signed is C-T-E
> 7bit; it is red otherwise, since the object must encoded prior to signing.

The key phrase here is "prior to signing".  Red systems are capable of
encoding after signing, so arbitrary content can be signed.

> PGP, PEM, and S/MIME combine the decision of armoring with the secure email
> protocol.  mp/signed doesn't care where the decision is made about
> armoring, whether it be the secure email protocol or the MIME transport.

Again, multipart/signed cannot be armored at a higher layer without
losing its property of being blue (visible to existing MIME UAs).

> The issue, as I see it, is that MIME is fundamentally flawed from a
> security point of view: there is no way to guarantee the integrity of an
> object in all cases, i.e., you have to use MIME in a perverted way to
> achieve the goal of integrity.  More specifically, MIME neither permits
> nested encodings nor guarantees the opaqueness of composite objects.

I'll sort of agree with that.  MIME was developed without the input or
attention of the security community.  These are the tools we are given
to work with.

> Now that we have an installed base of a "broken" MIME and the motivation
> for backward compatibility is no longer present, application/{signed or
> mime} solves a problem in a way that is "compatible" with the installed
> base, however perverse when judged against the MIME philosophy.

I don't agree that the motivation for backward compatibility is no
longer present, nor do I agree that appication/{signed or mime} is
"compatible" with the installed base.  A cost of application/signed or
application/mime is incompatibility with the installed base.

Blake Ramsdell wrote:

> The big win is for people who value the signatures more than the
> content.  Some people might argue "What good is a signature if you can't
> verify it?"

It is clear that in a public forum, the content is considered to be more
important than the signature.

You make a good point that there are situations where the requirements
are different.

>  if it ain't signed, bounce it.

I find that level of service to be strange.  What good is a signature if
you don't know anything about the identity that has been proven? 
Anyway, this is a side issue.

> We have implemented our user interface in such a way that the user is
> isolated from this decision.  In the event that all of the recipients
> are "preferSignedData", then we send the message as signedData -- no
> problem.

In my opinion, you've still pushed the problem too far towards the
sending user.  If a signature is so vitally important to a receiver, it
is reasonable to require them to have the infrastructure to preserve the
signatures.  If deploying support for multipart/signed throughout their
infrastructure is impractical, then perhaps they should deploy an edge
gateway which converts multipart/signed into an appropriate armored type
along with the UAs which understand signatures.

> My hope was that the discussion of application/(signed or mime) would
> lead us to a suitable replacement for signedData since it could be a
> single MIME part that could encapsulate with transfer encoding a
> multipart/signed entity.  This would solve the problems that signedData
> solves (integrity during transmission and keeping the content and the
> signature together in a verifiable way), without the nasty side-effect
> of giving non-S/MIME clients a PKCS #7 encoded pile of junk with their
> MIME strewn about inside of it.

So instead of a PKCS #7 encoded pile of junk they get a MIME encoded
pile of junk.  This IS an improvement since MIME encoded piles of junk
are easier to add support for, but it needs to be understood that to the
installed base it is still just a pile of junk.

Paul Hoffman wrote:
> >Well, it appears to be a natural law that you can have "red" or "blue",
> >but not both.
> 
> You can allow both types to be sent and describe how recipients should
> handle each. That's what's in the S/MIME spec.

But what is specified in the S/MIME spec does not affect what the
installed base does.
 
> >Some people are saying that they have a need for "red"
> >properties.  I'm saying that if there is a sufficiently strong need for
> >something "red", then design something that is good at being "red" and
> >which can be easily converted from and to things which are "blue".
> 
> The latter part does not describe signedData since it cannot be easily
> converted by a human reader.

None of the proposed opaque types can be easily converted by a human
reader.  I was talking about conversion by intermediary programs.

> >Don't try to design something which is both sort of "red" and "blue" at
> >the same time, as you're going to end up with something which is
> >neither.  Drive on one side of the road or the other, don't drive on the
> >median.
> 
> I think you're missing the point in S/MIME: you can choose either.

My point is that application/mime in its proposed form of having
encoding restrictions is akin to trying to drive on the median.

> This is a conscious design decision to, if necessary, make messages more
> likely to be human readable than to be dispatchable by MIME-aware UAs that
> do not follow the S/MIME spec. Said a different way, app/mime will probably
> break the signature-verifying capabilities of a small number of non-S/MIME
> UAs but will let the large number of people with non-S/MIME UAs read the
> messages sent to them.

Application/mime will hinder the ability of the installed base of MIME
UAs to read the messages sent to them.  It shares this property with all
armored-signature systems.

> >So, people are therefore expected to
> >run around changing their installed base of UAs to be able to deal with
> >the shim,
> 
> They don't need to do this if they followed the S/MIME spec.

Well, if they followed the S/MIME spec, then by definition they are not
the pre-existing installed base of UAs.

> Also, it is unclear how many non-S/MIME UAs that can process
> multipart/signed X.509 signatures exist. I believe the number is
> vanishingly small. The few PGP/MIME UAs deployed can't handle X.509
> signatures, so they don't count. I think that leaves PEM clients. We are
> saying "those few PEM clients aren't as important as people who don't have
> S/MIME being able to read a signed message."

You're incorrectly equating "process the signature" with "read a signed
message".  Of course non-S/MIME UAs can't verify the signature.  But all
of the MIME UAs can read the content part of a multipart/signed, and
having them able to do so is an important requirement.

Date: Thu, 31 Jul 1997 12:15:54 -0400
To: [email-masked]
From: "James M. Galvin" <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

I should say that I'm not fundamentally opposed to application/{signed or
mime}, I just want to make sure we agree on the facts and the reason why we
need it.

At 9:55 PM -0400 7/30/97, John Gardiner Myers wrote:
>James M. Galvin wrote:
>Examples of "blue signing" are PGP's "-sta" mode and PEM's "MIC-CLEAR"
>mode.  Examples of "red signing" are PGP's "-sa" mode and PEM's
>"MIC-ONLY" mode.
>
>multipart/signed is a "blue signing" system.  It does not armor the
>signed data against the transport--witness the mangling taking place at
>gateways.  Thus, multipart/signed is not a "red signing" system.
>
>Ergo, multipart/signed takes care of the "blue signing" problem only.

You're comparing apples and oranges.  PGP and PEM are secure email
protocols.  Multipart/signed is not.  mp/signed works only in conjunction
with a secure email protocol; it does NOTHING standalone, from a security
point of view.

mp/signed is a framework, it's a wrapper, for conveying email that has been
secured by a secure email protocol from here to there.

Armoring or not is a transport, or MIME decision, not mp/signed.  mp/signed
provides some explicit requirements about ensuring the 7bit nature of the
object to be conveyed but that's as close it gets to a transport.

When conveying text, mp/signed is blue if the object to be signed is C-T-E
7bit; it is red otherwise, since the object must encoded prior to signing.

PGP, PEM, and S/MIME combine the decision of armoring with the secure email
protocol.  mp/signed doesn't care where the decision is made about
armoring, whether it be the secure email protocol or the MIME transport.

The issue, as I see it, is that MIME is fundamentally flawed from a
security point of view: there is no way to guarantee the integrity of an
object in all cases, i.e., you have to use MIME in a perverted way to
achieve the goal of integrity.  More specifically, MIME neither permits
nested encodings nor guarantees the opaqueness of composite objects.

What mp/signed does is ensure that integrity can be guaranteed.  It was not
made an absolute requirement principally for backward compatibility with
the installed base.

What application/{signed or mime} does is guarantee the integrity of an
object in all cases.

Now that we have an installed base of a "broken" MIME and the motivation
for backward compatibility is no longer present, application/{signed or
mime} solves a problem in a way that is "compatible" with the installed
base, however perverse when judged against the MIME philosophy.

>I've read all over the archives of pem-dev and I just don't understand
>the engineering logic behind the proposed form and use of
>application/mime.  We like multipart/signed because the signed content
>can be read by the installed base.  But the signature on a
>multipart/signed gets munged by some existing gateways, and some UAs
>can't dispatch on a multipart/signed.  So, we want to stick in a shim to
>make the multipart/signed opaque to said gateways and dispatchable to
>said UAs.  Except the shim also makes the multipart/signed opaque to the
>installed base of MIME-aware UAs.  So, people are therefore expected to
>run around changing their installed base of UAs to be able to deal with
>the shim, and we're kinda hoping that while they're doing this, they'll
>also bother to also change the installed base to correctly handle
>multipart/signed?  And the shim can only be applied to a subset of
>possible multipart/signed objects and can't protect against all known
>forms of transport munging?

So you're recognizing that in spite of the utility of application/{signed
or mime} it has its own set of problems.

Jim

----------------------------------------------------------------------------
James M. Galvin                                          [email-masked]
CommerceNet                                                  +1 410.203.2707
3209A Corporate Court                                    FAX +1 410.203.2709
Ellicott City, MD 21042                             http://www.commerce.net/

Date: Wed, 30 Jul 1997 19:36:38 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

At 6:55 PM -0700 7/30/97, John Gardiner Myers wrote:

[blues (clear signed) and reds (opaque signed) deleted...]

>And an apparent problem with multipart/signed is that it is sometimes
>transparent in contexts where it is desired to be opaque.

Exactly right.

>Well, it appears to be a natural law that you can have "red" or "blue",
>but not both.

You can allow both types to be sent and describe how recipients should
handle each. That's what's in the S/MIME spec.

>Some people are saying that they have a need for "red"
>properties.  I'm saying that if there is a sufficiently strong need for
>something "red", then design something that is good at being "red" and
>which can be easily converted from and to things which are "blue".

The latter part does not describe signedData since it cannot be easily
converted by a human reader.

>Don't try to design something which is both sort of "red" and "blue" at
>the same time, as you're going to end up with something which is
>neither.  Drive on one side of the road or the other, don't drive on the
>median.

I think you're missing the point in S/MIME: you can choose either.

>I've read all over the archives of pem-dev and I just don't understand
>the engineering logic behind the proposed form and use of
>application/mime.  We like multipart/signed because the signed content
>can be read by the installed base.  But the signature on a
>multipart/signed gets munged by some existing gateways, and some UAs
>can't dispatch on a multipart/signed.  So, we want to stick in a shim to
>make the multipart/signed opaque to said gateways and dispatchable to
>said UAs.  Except the shim also makes the multipart/signed opaque to the
>installed base of MIME-aware UAs.

This is a conscious design decision to, if necessary, make messages more
likely to be human readable than to be dispatchable by MIME-aware UAs that
do not follow the S/MIME spec. Said a different way, app/mime will probably
break the signature-verifying capabilities of a small number of non-S/MIME
UAs but will let the large number of people with non-S/MIME UAs read the
messages sent to them.

Yes, we are favoring the human over the legacy non-S/MIME MUAs. That's
purposeful.

>So, people are therefore expected to
>run around changing their installed base of UAs to be able to deal with
>the shim,

They don't need to do this if they followed the S/MIME spec.

Also, it is unclear how many non-S/MIME UAs that can process
multipart/signed X.509 signatures exist. I believe the number is
vanishingly small. The few PGP/MIME UAs deployed can't handle X.509
signatures, so they don't count. I think that leaves PEM clients. We are
saying "those few PEM clients aren't as important as people who don't have
S/MIME being able to read a signed message."

--Paul E. Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Wed, 30 Jul 1997 18:55:33 -0700
Organization: Netscape Communications Corporation
Lines: 107
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

James M. Galvin wrote:
> 
> At 5:10 PM -0400 7/28/97, John Gardiner Myers wrote:
> >multipart/signed
> >takes care of the "transparent signed" problem only.
> 
> Wrong.

Excuse me?  I describe the phenomenon that several message security
services (PEM and PGP to name two) each provide two distinct signature
services.  I describe the properties of each distinct signature service,
and attach the labels "opaque" and "transparent" to each set of
properties.

You then redefine the terms "opaque" and "transparent", and in the
context of those altered defintions assert that the above quoted
sentence is incorrect.  Well, if you change the definition of the terms
I was using, of course the statement can be shown to be incorrect.

Let's try again.

Many message security systems have two types of signed objects.

There are signed objects which have the property that the signed
data can be read without knowledge of the particular message security
system.  I will call such objects "blue signed objects".  An additional
property that is common to all "blue signed objects" is that they are
subject to transport mangling and encoding restrictions.

There are also signed objects where the signature system also armors the
signed data against the transport.  I will call such objects "red signed
objects".  An additional property that is common to all "red signed
objects" is that the signed data is unreadable to software not
implementing the particular message security system.

Examples of "blue signing" are PGP's "-sta" mode and PEM's "MIC-CLEAR"
mode.  Examples of "red signing" are PGP's "-sa" mode and PEM's
"MIC-ONLY" mode.

multipart/signed is a "blue signing" system.  It does not armor the
signed data against the transport--witness the mangling taking place at
gateways.  Thus, multipart/signed is not a "red signing" system.

Ergo, multipart/signed takes care of the "blue signing" problem only.

> Multipart/signed solves both problems.  It does this because it places no
> restrictions on the object that was signed.  It can be transparent or not,
> according to context.

Multipart/signed does place a restriction on the object being signed. 
Currently, the object being signed must itself conform to the
restrictions of the most restrictive transport it will ever be
succesfully transmitted over.

And an apparent problem with multipart/signed is that it is sometimes
transparent in contexts where it is desired to be opaque.

> Multipart/signed declares by fiat that its contents are opaque.  [...]
> In practice, however, we all know this doesn't work because
> multipart/signed objects are not treated as opaque by gateways.

So, we've learned that declaring something by fiat doesn't immediately
make it so.  Making something so requires engineering and deployment.

> Further, although application/(signed or mime) guaratees the opaqueness, I
> don't see it as a big win.  It seems to me it's more of a "the end
> justifies the means", if the end is actually accomplished.

Well, it appears to be a natural law that you can have "red" or "blue",
but not both.  Some people are saying that they have a need for "red"
properties.  I'm saying that if there is a sufficiently strong need for
something "red", then design something that is good at being "red" and
which can be easily converted from and to things which are "blue". 
Don't try to design something which is both sort of "red" and "blue" at
the same time, as you're going to end up with something which is
neither.  Drive on one side of the road or the other, don't drive on the
median.

I've read all over the archives of pem-dev and I just don't understand
the engineering logic behind the proposed form and use of
application/mime.  We like multipart/signed because the signed content
can be read by the installed base.  But the signature on a
multipart/signed gets munged by some existing gateways, and some UAs
can't dispatch on a multipart/signed.  So, we want to stick in a shim to
make the multipart/signed opaque to said gateways and dispatchable to
said UAs.  Except the shim also makes the multipart/signed opaque to the
installed base of MIME-aware UAs.  So, people are therefore expected to
run around changing their installed base of UAs to be able to deal with
the shim, and we're kinda hoping that while they're doing this, they'll
also bother to also change the installed base to correctly handle
multipart/signed?  And the shim can only be applied to a subset of
possible multipart/signed objects and can't protect against all known
forms of transport munging?

> I say this because with it we have two options where we used to have one
> and now we have to choose every time we send a message.  And don't even
> suggest that user agents are somehow going to decide for the user, except
> perhaps that they'll set a default (which will no doubt be application/*).

I see "red" systems being used by intermediaries which are unable to
forward something in original "blue" form.

On the other hand, as Ned has said multiple times in past months,
sometimes the right thing to do is to reach inside the multipart/signed
and muck with the signed content, thus destroying the signature.  This
is particularly attractive when the only alternatives will result in
destroying or making unreadable *both* the content and the signature.

From: Blake Ramsdell <[email-masked]>
To: "'James M. Galvin'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: application/mime and binary data
Date: Wed, 30 Jul 1997 17:11:05 -0700
Sender: [email-masked]

On Wednesday, July 30, 1997 12:01 PM, James M. Galvin
[SMTP:[email-masked]] wrote:
> Further, although application/(signed or mime) guaratees the opaqueness, I
> don't see it as a big win.  It seems to me it's more of a "the end
> justifies the means", if the end is actually accomplished.

The big win is for people who value the signatures more than the
content.  Some people might argue "What good is a signature if you can't
verify it?"  The current community of people playing with digital
signatures and "gee it's cool that I can digitally sign things" are
going to move closer to "if it ain't signed, or the signature isn't
valid, I don't want it".  We are introducing a mail gateway product with
extensive digital signature processing features (our marketing guys call
it an "email firewall" to emphasize the security aspect of it) that can
enforce that exact semantic by customer request:  if it ain't signed,
bounce it.

> I say this because with it we have two options where we used to have one
> and now we have to choose every time we send a message.  And don't even
> suggest that user agents are somehow going to decide for the user, except
> perhaps that they'll set a default (which will no doubt be application/*).
> So, while it may be a technical move forward, it's not making things any
> easier for the user.

Actually, the current spec with signedData vs. multipart/signed already
introduces this problem.  Because Netscape *absolutely will not* send
signedData means that someone on the receiving end that does not have
MIME preservation to the point where the signature is verified (read:
LAN email systems, AOL, CServe, etc.) will never, ever, ever be able to
verify a signed message from a Netscape user.  Likewise, because Secure
Messenger (WorldSecure Client) for Microsoft Exchange *absolutely can
not* send multipart/signed, someone on the receiving end that does not
have an S/MIME client will not be able to read the received message at
all (unless the user has something to mine his content out of the PKCS
#7 wrapper).  Depending on your point of view, each of us is wrong --
because Netscape can't send signedData, there are some cases where the
signature simply cannot be transmitted, so if signature preservation is
your top priority, you can't do it.  Because we can't send
multipart/signed from Exchange, there are some cases where the content
simply cannot be read, so if content preservation is your top priority,
you have a workaround which is to send it unsigned to the non S/MIME
recipients.

We have implemented our user interface in such a way that the user is
isolated from this decision.  In the event that all of the recipients
are "preferSignedData", then we send the message as signedData -- no
problem.  If any of the recipients do not have SMIMECapabilities (we
don't know if they can even receive S/MIME in this case), the user is
warned that this signed message may not be readable by some of the
recipients (since we can't send multipart/signed from Exchange).  The
user is presented with the option to remove recipients, or to send the
message anyway.  The bottom line is that we do everything we can to make
sure that a non-S/MIME recipient doesn't ever see signedData.

My hope was that the discussion of application/(signed or mime) would
lead us to a suitable replacement for signedData since it could be a
single MIME part that could encapsulate with transfer encoding a
multipart/signed entity.  This would solve the problems that signedData
solves (integrity during transmission and keeping the content and the
signature together in a verifiable way), without the nasty side-effect
of giving non-S/MIME clients a PKCS #7 encoded pile of junk with their
MIME strewn about inside of it.  At the very least, a client that
received application/signed that didn't know anything about S/MIME would
be able to take the contents and run it through a MIME viewer to get
something nice -- the additional step of removing the PKCS #7 wrapper
wouldn't need to happen.

Blake

Date: Wed, 30 Jul 1997 13:31:39
From: plipp <[email-masked]>
To: [email-masked], [email-masked], [email-masked]@imc.org, [email-masked], [email-masked], [email-masked], [email-masked], ICE-TEL public list <[email-masked]>
Subject: CFP: SEC '98
Sender: [email-masked]

Sorry if you get multiple copies.......

-----------------------------------------------------------------------
SEC '98: IFIP TC11 14th International Information Security Conference=20
August 31 - September 4 in Vienna and Budapest, Austria and Hungary

Sponsors:=20
IFIP TC11
Austrian Ministry of Science and Research

SEC '98 covers a wide range of security related topics. It comprises both=
 emphasis in technical as well as commercial aspects of information secur=
ity. The conference is held within the framework of the the IFIP World Co=
mputer Congress.=20

Important dates=20

-	Deadline for submission of papers: January 16, 1998=20
-	Notification on acceptance: March 27, 1998=20
-	Deadline for the final version: May 8, 1998

More Information:
http://www.ifip.tu-graz.ac.at/TC11/SEC98/index.html

Contact:=20
Prof. Dr. Reinhard Posch
IAIK Klosterwiesgasse 32/I A-8010 Graz, AUSTRIA=20
Tel: +43 316 8735510 Fax: +43 316 873520 e-mail: [email-masked]=
t=20

Dr. Gy=F6rgy Papp
Prime Minister's Office Republic of Hungary
Kossuth ter 4 Budapest HUNGARY=20
Tel: +36 1 269 4826 Fax: +36 1 269 0314 e-mail: [email-masked]=
=20

Dr. Peter Lipp, IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513
________________________________________________________________________
Was n=FCtzt die beste Erziehung, die Kinder machen uns ja doch alles nach.

Date: Wed, 30 Jul 1997 15:00:43 -0400
To: [email-masked]
From: "James M. Galvin" <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

At 5:10 PM -0400 7/28/97, John Gardiner Myers wrote:
>multipart/signed
>takes care of the "transparent signed" problem only.

Wrong.

Multipart/signed solves both problems.  It does this because it places no
restrictions on the object that was signed.  It can be transparent or not,
according to context.

Multipart/signed declares by fiat that its contents are opaque.  In theory,
this means the signed object can be left readable, i.e., unarmored, and
therefore even user agents that are not security aware can "process" the
object.  In practice, however, we all know this doesn't work because
multipart/signed objects are not treated as opaque by gateways.

=46urther, although application/(signed or mime) guaratees the opaqueness, I
don't see it as a big win.  It seems to me it's more of a "the end
justifies the means", if the end is actually accomplished.

I say this because with it we have two options where we used to have one
and now we have to choose every time we send a message.  And don't even
suggest that user agents are somehow going to decide for the user, except
perhaps that they'll set a default (which will no doubt be application/*).
So, while it may be a technical move forward, it's not making things any
easier for the user.

How can this be a win?

Jim

----------------------------------------------------------------------------
James M. Galvin                                          [email-masked]
CommerceNet                                                  +1 410.203.2707
3209A Corporate Court                                    FAX +1 410.203.2709
Ellicott City, MD 21042                             http://www.commerce.net/

Date: Wed, 30 Jul 1997 13:31:39
From: plipp <[email-masked]>
To: [email-masked], [email-masked], [email-masked]@imc.org, [email-masked], [email-masked], [email-masked], [email-masked], ICE-TEL public list <[email-masked]>
Subject: CFP: SEC '98
Sender: [email-masked]

Sorry if you get multiple copies.......

-----------------------------------------------------------------------
SEC '98: IFIP TC11 14th International Information Security Conference 
August 31 - September 4 in Vienna and Budapest, Austria and Hungary

Sponsors: 
IFIP TC11
Austrian Ministry of Science and Research

SEC '98 covers a wide range of security related topics. It comprises both=
 emphasis in technical as well as commercial aspects of information secur=
ity. The conference is held within the framework of the the IFIP World Co=
mputer Congress. 

Important dates 

-=09Deadline for submission of papers: January 16, 1998 
-=09Notification on acceptance: March 27, 1998 
-=09Deadline for the final version: May 8, 1998

More Information:
http://www.ifip.tu-graz.ac.at/TC11/SEC98/index.html

Contact: 
Prof. Dr. Reinhard Posch
IAIK Klosterwiesgasse 32/I A-8010 Graz, AUSTRIA 
Tel: +43 316 8735510 Fax: +43 316 873520 e-mail: [email-masked] 

Dr. Gy=F6rgy Papp
Prime Minister's Office Republic of Hungary
Kossuth ter 4 Budapest HUNGARY 
Tel: +36 1 269 4826 Fax: +36 1 269 0314 e-mail: [email-masked] 

Dr. Peter Lipp, IAIK, University of Technology, Graz
Institute for Applied Information Processing and Communications
Klosterwiesgasse 32/I, A-8010 Graz, +43 316 873 5513
________________________________________________________________________
Was n=FCtzt die beste Erziehung, die Kinder machen uns ja doch alles nach.

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Tue, 29 Jul 1997 16:13:39 -0700
Organization: Netscape Communications Corporation
Lines: 28
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Ned Freed wrote:
> If, on the other hand, the intent is for application/signed to be 100% opaque,
> then we're not talking about a composite object in the MIME sense. And then
> none of the MIME rules about composites apply. But the minute you do this the
> whole point of having application/signed and/or multipart/signed vanishes,
> since the only reason to use such a complex structure is so that extant
> processors can see the content for what it is. Once this is no longer an
> issue you might as well use signedData and be done with it.

In any case, use of multipart/signed is preferable, and multipart/signed
is the only reasonable thing to send to a public forum.

In cases where use of multipart/signed is not possible, the advantages
of using application/signed instead of signedData are:

* application/signed deals with the problem the same way for all
signature systems which make use of multipart/signed

* It is trivial for intermediaries to convert a multipart/signed into an
application/signed and vice versa.  Such intermediaries need not have
knowledge of the particular signature system being used (e.g. PKCS #7).

To UAs without explicit support for it,  application/signed is of course
100% opaque, same as for signedData.

The advantages of application/signed over signedData may well not be
worth the effort required to deploy application/signed.

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Tue, 29 Jul 1997 15:31:04 -0700
Organization: Netscape Communications Corporation
Lines: 50
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Ned Freed wrote:

> > Adding a sentence to the spec is not sufficient--many existing
> > transports and such will happily transfer-encode subtypes of application
> > that they don't know anything about.
> 
> This case does not arise in practice since the contents of an
> application/smime object are entirely 7bit. If there are lots of
> implementations
> out there that run around encoding purely 7bit data I certainly haven't
> run into them.

Paul's proposal was that they have the same encoding restrictions as
multipart/* and message/*.  Such restrictions still permit the contents
to be 8bit or binary.

You seem to be proposing an additional restriction that the contents
conform to the restrictions of 7bit data.  That would then leave us with
a tunneling mechanism which is incapable of carrying a significant
portion of the MIME entities that are out there.

> This was never the intent of the type. We get all the protection against
> gratuitous change of encoding by restricting the encodings used inside of
> multipart/signed to begin with.

A 7bit restriction on multipart/signed has about as much chance as being
followed as the 7bit restriction in SMTP.  It's real simple to
developers: follow this particular point of the specification and
overseas customers will drop your product like a hot potato.  The cost
of transfer-encoding everything is huge, and with the advent of such
things as UTF-8 it's going up.

> > Stuff encapsulated in this
> > type won't be readable by existing MIME implementations.
> 
> Depends on what you mean by "readable". It may not be processed as MIME,
> but the text will be there as mostly-readable text.

If it's not processed as MIME, it's not readable.

If the contents are text, and the text is mostly restricted to US-ASCII,
and the user both has the presence of mind and goes through the trouble
of saving the thing to a file and bringing it up in a text viewer, then
the user can pick the text bits out of the surrounding cybercrud and
(probable) quoted-printable encoding.

Sending an application/mime to a public forum is going to be as much of
a disaster as sending a signedData.  In fact, I suspect it will be even
more of a disaster.  "It says this thing is a MIME, but I can't read it
with my MIME program.  That must mean MIME broken."

Date: Tue, 29 Jul 1997 09:29:35 -0700
To: Ned Freed <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Cc: [email-masked]
Sender: [email-masked]

At 02:15 PM 7/28/97 -0700, Ned Freed wrote:
Ned,

>> In the interest of testing whether there is a simple solution to a complex
>prove to be useful in other contexts. But it does add unnecessary
complexity in
>some cases, which is bad. However, it will definitely keep converters out of

	When does it add complexity that isn't necessary?

	I'm assumin g that the text which followed the above isn't the answer.
The reason is that it pertained only to smime and was predicated on a
series of quite plausibe, but very broken, implementation actions.  It
seems to me that that isn't "unecessary complexity".  I'd guess that such
implementors are likely to get pretty much ANY mechanism wrong...

d/
--------------------
Dave Crocker
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'John Gardiner Myers'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Robert Dickinson <[email-masked]>
Subject: RE: application/mime and binary data
Date: Tue, 29 Jul 1997 00:25:18 -0700
Sender: [email-masked]

On Monday, July 28, 1997 6:22 PM, Ned Freed
[SMTP:[email-masked]] wrote:
> The MIME specification, after all, clearly implies that this is the right
> thing
> to do. And in fact it is the right thing to do -- sometimes. When you don't
> have MIME or signature support on the cc:Mail side you certainly don't want
> things tunneled. But when you do have this support the right thing to do is
> tunnel the multipart/signed through as a discrete object. I think tunneling
> should be the default, as a matter of fact. And application/mime lets us
> regain
> this default at the hands of gateways. That's all the does, really. It is a
> workaround for a major problem that is seriously jeopardizing the deployment
> of
> signature services -- the number of users on proprietary LAN email systems
is
> enormous.

Exactly right!  This has been the position from which I and Bob have
discussed this issue in the past.  There needs to be a way to send and
receive a signed entity that will look exactly like a file attachment in
a LAN email environment.  This is one of the primary reasons why
signedData exists right now.  If the same characteristics will apply to
application/mime or application/signed, then I'm all for them.  The
problem with application/mime right now is that too much needs to be
promoted to the Content-Type as a requirement of the spec.  This is a
non-starter from our point of view, because we have very little control
what the LAN mail <--> MIME gateway (both directions) will produce, and
we cannot guarantee that even the Content-Type will be set correctly.
This is precisely why the file extensions are so important to us also.

In the event that we are able to come to some consensus on
application/signed (or even application/mime) that doesn't require
parameters for the Content-Type, and that has a particular file
extension mapping that makes it unambiguously an S/MIME multipart/signed
message transmitted in an outer wrapper that can be base64 encoded to
protect the contents, then I will be much happier about giving up the
ghost of signedData support.

And as an added bonus, we won't have to worry about the destruction of
our solar system, either.

> John, this is all old news -- we've discussed these issues at enormous
length
> in the past. I strongly suggest that you review the archives of this list so
> as
> not to spend a huge amount of time recovering old ground.

I think that this is a good thing for everyone to keep in mind -- a good
portion of the old discussion took place in September of last year on
SMIME-DEV which is archived at RSA.  We have been doing pretty well in
keeping to the application/mime and application/signed discussion which
is a new perspective on this old problem and is moving us forward.

Blake

From: Steve Dusse <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: micalg semantics and use
Date: Mon, 28 Jul 1997 23:05:25 -0700
Sender: [email-masked]

OK, I can't resist the opportunity;  

How about a quick show of hands for "md5" and "sha1" (no dash).  Does
this work with existing implementations ?  Is the micalg value case
sensitive (I think I've asked this question before...) ?

-steve
>----------
>From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
>Sent: 	Monday, July 28, 1997 4:06 PM
>To: 	[email-masked]
>Subject: 	RE: micalg semantics and use
>
>At 3:20 PM -0700 7/28/97, Blake Ramsdell wrote:
>>Forget my previous proposal about pkcs7-md5 and pkcs7-sha1 -- use "md5"
>>and "sha1"!
>
>This sounds good to me.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>

Date: Mon, 28 Jul 1997 15:52:24 -0700
To: Ned Freed <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Cc: John Gardiner Myers <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:11 PM 7/28/97 -0700, Ned Freed wrote:
>I think application/mime and application/signed that allow binary encoding
>inside are a nonstarter. I for one will certainly object to such a
>specification getting registered, let alone being placed on the standards
>track, and I suspect I will not be alone. I would not mind
application/mime and
>application/signed that allow for recursive encoding of all but binary leaf
>objects, but I doubt if my personal preferences matter much here -- the
>obstacles that have to be overcome here would be huge. Frankly, I think that
>this group is doomed to destruction if it pursues this course -- asking the
>IESG to charter a group after failing to meet the stated criteria the IESG
said
>the group had to meet is one thing -- the IETF is nothing if not flexible --
>but then asking to grant that group the authority to pry open one of the most
>important application-level standards and change it in ways that will almost
>certainly reset it to proposed status boggles my mind.

	I left most of the above paragraph intact because I suspect that a number
of people have similar impressions of the application/mime specifications
and I want to lay some points to rest.

	App/Mime was written without attention to the recursive encoding problem.
Sorry 'bout that, but I missed the isue.  I believe it also escaped the
others who participated in discussions about it.  So, at the least there is
really and truly no intention to alter MIME fundamentals.  We can quibble
about the purity of Application/* but we cannot quibble about such
fundamental issues as rules for encoding.  So, to paraphrase Ned's comment,
any effort to have Application/Mime alter basic processing rules for MIME
is a non-starter.

	Observing that App/Mime is really an aggregage object in sheep's clothing
is quite useful.  The whole idea was simply to wrap a Mime object up, but
the ramifications of its being an aggregate object were not considered
nearly as carefully as (now obviously) necessary.

	The idea for app/mime comes from several different discussions and
contexts.  It isn't just trying to solve a problem for one "customer" but
several.  The need to tunnel objects is often necessary, so it's no great
shock that Mime, too, can use such a mechanism.  It would be a shame to
invent a series of specialized tunneling mechanisms, when one will do the
job.  This, of course, assumes that we can make the one do the job correctly.

	We already have rules for aggregate objects.  As I queried in the fast
note I sent before getting on a plane (the riding on which I am doing as I
type this) it seems to me that the simplest way to solve this quandary is
to apply the same rules for encoding data in app/mime as, say,
multipart/mixed.  

	To the extent that this idea is fatally flawed, I suggest that we still
need a general wrapping mechanism and need, therefore, to find a response
to the coding scheme which is sufficient to the task and, of course, which
does not in any way alter the basic Mime specification.

d/

ps.  I note that this thread is on ietf-smime, rather than ietf-types.
Being loathe to copy two lists, I nonetheless fear that -types should be
participating in this discussion.
	
--------------------
Dave Crocker
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org

Date: Mon, 28 Jul 1997 18:22:04 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime and binary data
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Paul Hoffman / IMC wrote:
> > This seems like the easiest solution to this issue. I'll add a sentence
> > that says "messages using application/mime are subject to the same encoding
> > rules as message/* and multipart/* types" to the next version of the draft.

> Adding a sentence to the spec is not sufficient--many existing
> transports and such will happily transfer-encode subtypes of application
> that they don't know anything about.

This case does not arise in practice since the contents of an
application/smime object are entirely 7bit. If there are lots of
implementations
out there that run around encoding purely 7bit data I certainly haven't
run into them.

> To apply encoding rules, the type
> has to be moved underneath the message top-level type.

Which would be fine in my opinion.

> With the encoding restrictions, the type then becomes useless for
> protecting the contents against transport encoding restrictions.

This was never the intent of the type. We get all the protection against
gratuitous change of encoding by restricting the encodings used inside of
multipart/signed to begin with.

The intent of the type was to protect against gratuitous alteration of the
overall message structure at the hands of gateways. This was the issue that
started the discussions that led to the development of application/mime. Most
MIME to cc:Mail gateways, for example, will cheerfully walk inside of any
subtype of multipart, extract the individual parts, and put them all inside of
a cc:Mail message. And the signature is ruined by this treatment. (My gateways
don't do this, of course, but I'm the exception. Most gateway vendors don't pay
the same sort of attention to RFCs that I do.) 

The MIME specification, after all, clearly implies that this is the right thing
to do. And in fact it is the right thing to do -- sometimes. When you don't
have MIME or signature support on the cc:Mail side you certainly don't want
things tunneled. But when you do have this support the right thing to do is
tunnel the multipart/signed through as a discrete object. I think tunneling
should be the default, as a matter of fact. And application/mime lets us regain
this default at the hands of gateways. That's all the does, really. It is a
workaround for a major problem that is seriously jeopardizing the deployment of
signature services -- the number of users on proprietary LAN email systems is
enormous.

> I'm left wondering what value it really has.

See above.

> Stuff encapsulated in this
> type won't be readable by existing MIME implementations.

Depends on what you mean by "readable". It may not be processed as MIME,
but the text will be there as mostly-readable text.

> If the
> generator is willing to take the unreadability hit, why wouldn't they
> use something which can really protect it against the transport, such as
> signedData?

Because with signedData the content is TOTALLY unreadable without an
S/MIME engine.

John, this is all old news -- we've discussed these issues at enormous length
in the past. I strongly suggest that you review the archives of this list so as
not to spend a huge amount of time recovering old ground.

				Ned

From: Blake Ramsdell <[email-masked]>
To: "'Laurence Lundblade'" <[email-masked]>
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Date: Mon, 28 Jul 1997 18:18:49 -0700
Sender: [email-masked]

On Monday, July 28, 1997 1:25 PM, Laurence Lundblade
[SMTP:[email-masked]] wrote:
> I don't see that as a huge problem.  We already deal with C-T-E: x-uue,
> uuencode, x-uuencode etc... I don't expect new hash algorithms to come
> along very often so the code base won't change ofen and we'll have lots of
> warning. The mapping table can be stored so it's easy to update to deal
> with varying implementations (e.g. in a resource or the registry).

I think that Steve and Ned turned a light on in my attic about this, and
that we're going to help out by setting an example and using "md5" and
"sha1" so that we can keep the mapping table size as small as possible.
I hope that the PGP/MIME boys take this into account also, if a revision
to RFC2015 is in the works.

Certainly, if there are arguments against moving in the "generic" micalg
direction they can be voiced, but from what Ned says, it's the way to
go.

Blake

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Mon, 28 Jul 1997 17:28:34 -0700
Organization: Netscape Communications Corporation
Lines: 17
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> This seems like the easiest solution to this issue. I'll add a sentence
> that says "messages using application/mime are subject to the same encoding
> rules as message/* and multipart/* types" to the next version of the draft.

Adding a sentence to the spec is not sufficient--many existing
transports and such will happily transfer-encode subtypes of application
that they don't know anything about.  To apply encoding rules, the type
has to be moved underneath the message top-level type.

With the encoding restrictions, the type then becomes useless for
protecting the contents against transport encoding restrictions.  I'm
left wondering what value it really has.  Stuff encapsulated in this
type won't be readable by existing MIME implementations.  If the
generator is willing to take the unreadability hit, why wouldn't they
use something which can really protect it against the transport, such as
signedData?

Date: Mon, 28 Jul 1997 11:59:54 -0400
From: The IESG <[email-masked]>
Subject: Protocol Action: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field to Proposed Standard
To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Sender: [email-masked]

  The IESG has approved the Internet-Draft "Communicating Presentation
  Information in Internet Messages: The Content-Disposition Header
  Field" <draft-moore-mime-cdisp-01.txt> as a Proposed Standard. The
  IESG contact person is Harald Alvestrand.

Technical Summary

 This document updates the experimental Content-disposition: field
 first described in RFC 1806 (Experimental), and places it on the
 standards track. Several of the extensions are used in the MIXER
 specifications.

Working Group Summary

 There were no objections to the suggested updates.

Protocol Quality

 The document was reviewed for the IESG by Harald Alvestrand

Date: Mon, 28 Jul 1997 16:06:58 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: micalg semantics and use
Sender: [email-masked]

At 3:20 PM -0700 7/28/97, Blake Ramsdell wrote:
>Forget my previous proposal about pkcs7-md5 and pkcs7-sha1 -- use "md5"
>and "sha1"!

This sounds good to me.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Mon, 28 Jul 1997 16:00:37 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

At 2:15 PM -0700 7/28/97, Ned Freed wrote:
>> In the interest of testing whether there is a simple solution to a complex
>> problem, let me ask whether making app/mime subject to the same encoding
>> rules as message/* and multipart/* types will fix any/all the concerns
>> aboutencoding?
>
>It certainly fixes them for me, and leaves the most desireable characteristic
>of application/[s]mime intact: That most extant products will treat it as
>opaque.

This seems like the easiest solution to this issue. I'll add a sentence
that says "messages using application/mime are subject to the same encoding
rules as message/* and multipart/* types" to the next version of the draft.

>But if vendors take the opportunity to fix multipart/signed
>handling when they add support for application/[s]mime, we win big.

I believe that this was the hope all around in the S/MIME implementor's
community. Vendors who still actively ignore multipart/signed will become
as popular as those who have crappy gateways to the Internet.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Mon, 28 Jul 1997 15:48:35 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime and binary data
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Wait! No one other than John Myers was suggesting sending binary data under
> application/mime! Neither the S/MIME spec nor the application/mime spec
> says that you can use binary under application/mime.

> The S/MIME spec directly says the opposite.

The S/MIME specification says the opposite for multipart/signed (at least
currently, but note that if application/mime were adopted as-is this
restriction could be removed from multipart/signed), but the application/mime
specification doesn't. Not only does it not forbid the use of binary
internally, it talks specifically about using base64 or quoted-printable at the
outer level, which opens the door to the use of binary inside. And since this
type is clearly composite in nature this is in clear violation of the MIME
specification.

				Ned

Date: Mon, 28 Jul 1997 15:42:30 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime and binary data
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Now, I would argue that neither of application/signed nor signedData are
> "purely composite", at least no more so than MIME under encryption.
> They're both MIME under opaque digital signatures.

On the contrary, the entire purpose of using a construct like multipart/signed
is for the object to be selectively opaque at most, so that people without
signature processors can still process the content. And the minute you start
talking about objects being selectively opaque you're talking about purely
composite objects. There is no slope here -- one step in the direction of
having regular MIME processors handle the content as MIME and it is over.

If, on the other hand, the intent is for application/signed to be 100% opaque,
then we're not talking about a composite object in the MIME sense. And then
none of the MIME rules about composites apply. But the minute you do this the
whole point of having application/signed and/or multipart/signed vanishes,
since the only reason to use such a complex structure is so that extant
processors can see the content for what it is. Once this is no longer an
issue you might as well use signedData and be done with it.

> The only technical
> difference between application/signed and signedData is whether the
> container parses like MIME or parses like PKCS7, and how difficult it is
> for a gateway to convert a multipart/signed into one or other.

True enough, but in practice this is all the difference in the world.

					Ned

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'Steve Dusse'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: micalg semantics and use
Date: Mon, 28 Jul 1997 15:20:13 -0700
Sender: [email-masked]

On Monday, July 28, 1997 2:55 PM, Ned Freed
[SMTP:[email-masked]] wrote:
> > So I gather from your approach, you'd be OK with simple micalg
> > parameters like SHA-1 and MD5.
> 
> Sure would. Frankly, I think we botched it when we assigned pgp-md5. While
> it is true that PGP adds stuff to the signature calculation besides the
> signed data, I think a better course of action would have been to simply
> note that this is in fact the case, that the signature state should
> be passed to the signature verifier without being finalized, and we should
> have stuck with md5 (or sha-1 or whatever digests PGP is now using).

Man, this is exactly the answer that I've been fishing for *forever*
about micalg!  I would absolutely *love* to get this right!  It is
completely arbitrary to the sender, but if the receiver can get more
useful information about how to process the message based on the value
of micalg, then we should fix it!  If the trend is that people are
implementing some kind of table-based mapping between "micalgs that are
different just for the sake of being different" and the actual digest
algorithm that is being used, then we should try and keep down the
number of entries if there's no good reason to differentiate.

Forget my previous proposal about pkcs7-md5 and pkcs7-sha1 -- use "md5"
and "sha1"!

Thanks, guys!

(I'm easy to make happy.)

Blake

Date: Mon, 28 Jul 1997 14:54:58 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: RE: micalg semantics and use
To: Steve Dusse <[email-masked]>
Cc: "'Ned Freed'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> So I gather from your approach, you'd be OK with simple micalg
> parameters like SHA-1 and MD5.

Sure would. Frankly, I think we botched it when we assigned pgp-md5. While
it is true that PGP adds stuff to the signature calculation besides the
signed data, I think a better course of action would have been to simply
note that this is in fact the case, that the signature state should
be passed to the signature verifier without being finalized, and we should
have stuck with md5 (or sha-1 or whatever digests PGP is now using).

				Ned

Date: Mon, 28 Jul 1997 14:33:58 -0700
To: Blake Ramsdell <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: RE: application/mime and binary data
Cc: "'Ned Freed'" <[email-masked]>, "'John Gardiner Myers'" 	 <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

I disagree with Lewis' comment. Application/mime pulls the MIME type and
parameters up from the encapsulated MIME entity so the software processing
it knows what is encapsulated. That is pretty fundamental to the
application/mime being of any use (I agree with Lewis on that). Thus the
MIME type of an S/MIME message might be:

C-T: application/mime; content-type="multipart/signed";
   protocol="application/pcks7-signature"; micalg=zodnots

The advantage that application/signed has over this is that many MUAs and
MTAs may not be able to dispatch on MIME parameters while they can do so on
MIME types. OTOH, the advantage of application/mime is that it is very
generic and may be implemented in many MUAs and thus become more widespread
than application/signed.  I expect application/mime may become very useful
for multipart/related, which is also going to be destroyed by gateways and
for which I anticipate there being stand-alone viewers.

So maybe the analogy I'd choose is a benevolent cloud, rather than
splattering chainsaw, but maybe I've been around too many marketing folks
lately...

A further way type information about the encapsulated object can be carried
across gateways (in either direction) is with the filename parameter to
Content-Disposition.  It does require a file extension just for the
particular encapsulated MIME type though. For example:
   .aps -> multipart/signed; protocol="application/pkcs7-signature"
   .mht -> multipart/related; type="text/html"

Most MUAs are pretty good about dispatching viewers based on the file
extension. For Windows this particular capability comes with the OS.

LL

At 11:20 PM -0700 7/25/97, Blake Ramsdell wrote:
> .....
>
>In the barrage of messages that formed the Great multipart/signed vs.
>signedData War of '96, a very small exchange took place with the subject
>"application/smime".  For this discussion, the most pertinent paragraph
>from that exchange was:
>
>From: "Lewis Geer (Exchange)" <[email-masked]>
>Date: Sun, 22 Sep 1996 12:34:33 -0700
>> The mime in application/mime is probably too generic.  It's possible
>> that people would start using it to tunnel other standards that might
>> not make it intact thru gateways, like mime encapsulated html (mhtml).
>> The problem with this is there is no easy way for the receiving agent
>> to tell if the application/mime content is s/mime, mhtml, or any other
>> standard (mhtml in particular is difficult as it is just a subclass of
>> multipart/related). Because of this, it's possible that the receiving
>> agent may send mhtml to an s/mime helper app.  The fix is to call
>> application/mime something like application/smime.
>
>The prospect of making Lewis' idea more generic to accommodate *any*
>multipart/signed entity (the application/signed type that is being
>discussed) is probably a good idea, and it isn't as much of a chainsaw
>as application/mime, so innocent bystanders will be safe.
>
>The idea is that any multipart/signed thing can be tunneled using
>application/signed, presumably using appropriate CTE on the
>application/signed part, the opacity is not as objectionable as
>signedData, and it is not overly general to allow potential misuse.
>Special language can also be drafted that explains why this might be a
>good thing and what situations you might use it in, and the work does
>not have to be redone for any other multipart/signed tunneling effort.
>
>Blake

Date: Mon, 28 Jul 1997 14:15:23 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime and binary data
To: Dave Crocker / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> In the interest of testing whether there is a simple solution to a complex
> problem, let me ask whether making app/mime subject to the same encoding
> rules as message/* and multipart/* types will fix any/all the concerns
> aboutencoding?

It certainly fixes them for me, and leaves the most desireable characteristic
of application/[s]mime intact: That most extant products will treat it as
opaque.

I continue to be ambivalent about whether or not this characteristic is worth
the effort. On the good side, it is a mostly harmless addition, and may in fact
prove to be useful in other contexts. But it does add unnecessary complexity in
some cases, which is bad. However, it will definitely keep converters out of
multipart/signed in the short to intermediate term, which is good. But if
vendors simply add application/smime to their tables as a synomym for
message/rfc822 (which is wrong in several ways, incidentally) and fail to also
add proper support for multipart/signed, we've actually regressed rather than
progressed. But if vendors take the opportunity to fix multipart/signed
handling when they add support for application/[s]mime, we win big.

      Fortunately he missed the pitchfork.
      Unfortunately he missed the haystack.

				Ned

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Mon, 28 Jul 1997 14:10:57 -0700
Organization: Netscape Communications Corporation
Lines: 47
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Ned Freed wrote:
> I think application/mime and application/signed that allow binary encoding
> inside are a nonstarter. I for one will certainly object to such a
> specification getting registered, let alone being placed on the standards
> track, and I suspect I will not be alone. [...] Frankly, I think that
> this group is doomed to destruction if it pursues this course -- asking the
> IESG to charter a group after failing to meet the stated criteria the IESG said
> the group had to meet is one thing -- the IETF is nothing if not flexible --
> but then asking to grant that group the authority to pry open one of the most
> important application-level standards and change it in ways that will almost
> certainly reset it to proposed status boggles my mind.

Application/mime did not come from this group.  Application/mime is an
individual submission which went through a 4-week Last Call quite some
time ago and is now in IESG limbo.  At the time I sent a formal comment
to the IESG that I believed the document did not adequetely call out the
rather subtle implications of the type and had not been reviewed as
being the modification to the base MIME spec that it was.

The S/MIME specification currently references the application/mime
specification as an external document.  I'm pointing out that
referencing this document is technically problematic (not just
politically problematic) and suggesting alternatives.

> [...] binary
> MIME under encryption (an entirely separate issue, since an encrypted object
> isn't purely composite) [...]

Many message security systems have two types of signed objects.  There
are transparent signed objects which have the property that the signed
data can be read without knowledge of the particular message security
system, but which are subject to transport mangling and encoding
restrictions.  There are also opaque signed objects which are armored
against the transport, but which are unreadable by software not
implementing the particular message security system.  multipart/signed
takes care of the "transparent signed" problem only.

The suggested alternatives for the "opaque signed" problem are
applicaiton/mime, application/signed, and signedData inside the pkcs7
object.

Now, I would argue that neither of application/signed nor signedData are
"purely composite", at least no more so than MIME under encryption. 
They're both MIME under opaque digital signatures.  The only technical
difference between application/signed and signedData is whether the
container parses like MIME or parses like PKCS7, and how difficult it is
for a gateway to convert a multipart/signed into one or other.

From: Steve Dusse <[email-masked]>
To: "'Ned Freed'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: micalg semantics and use
Date: Mon, 28 Jul 1997 13:44:51 -0700
Sender: [email-masked]

So I gather from your approach, you'd be OK with simple micalg
parameters like SHA-1 and MD5.

-steve

>----------
>From: 	Ned Freed[SMTP:[email-masked]]
>Sent: 	Sunday, July 27, 1997 11:10 PM
>To: 	Blake Ramsdell
>Cc: 	'Ned Freed'; 'Lisa Repka'; [email-masked]'
>Subject: 	Re: micalg semantics and use
>
>> > And mine as well. Note that I don't implement S/MIME myself, what I do
>> > implement is hooks that allow callouts after I've done the calculation to
>> > actually verify the signature. And I depend on micalg to do all this in a
>> > single pass.
>
>> In your case, Ned, do you hash the first part of multipart/signed using
>> the algorithm implied by micalg (something as follows):
>
>> pgp-md5, rsa-md5, pkcs7-md5 == Hash with MD5
>> rsa-sha1, rsa-sha, rsa-sha-1, pgp-sha1, pkcs7-sha1 == Hash with SHA-1
>
>I have a table for this.
>
>> and then present the result of that hash to the callout that can do the
>> actual signature validation?
>
>No. What I present is a general hash structure my generic hash routines use
>(routines that support MD2, MD4, MD5, SHA-1, RIPEMD128, RIPEMD160, and HAVAL)
>with the intermediate result of proccessing the first past, leaving the
>finalization for the signature-specific routine(s).
>
>> It seems that there may be a case (such as PGP/MIME) where other
>> information needs to be presented to the hash function along with the
>> content so that the correct hash can be recreated.  I think PGP 2.6x
>> does something like MD5(first part of multipart/signed + signature
>> classification + signature time stamp) (from RFC1991 section 6.2), but I
>> may have this wrong.
>
>Yes, but it seems that when this is done protocol designers have always
>placed
>this information after the signed data. As such, while it isn't possible to
>finish up the hash calculation completely, it is still possible to write
>generic multipart/signed support code that operates in a single pass. But
>micalg is an essential part of this.
>
>> I guess the point is -- is it always possible to complete a hash of the
>> first part of multipart/signed and have a satisfactory answer for the
>> signature validator?
>
>This depends on whether or not we keep on designing signature schemes
>taking one pass processing into account.
>
>				Ned
>

Date: Mon, 28 Jul 1997 13:24:47 -0700
To: Blake Ramsdell <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" 	 <[email-masked]>
Sender: [email-masked]

At 4:12 PM -0700 7/25/97, Blake Ramsdell wrote:
>
>But the problem is that you will not know which digest algorithm a
>particular message part will need in order to complete its signature.
>"rsa-md5", "pgp-md5" and "pkcs7-md5" are all legal values to identify
>the MD5 algorithm (even though, as you will probably find out at some
>point, the data that is presented to these hashing algorithms is not
>completely derived from the content, but may also be found in the
>signature part as well).  At some point someone will come up with
>"zoondap" which happens to be MD5.  The only option you're going to have
>in your case is to compute all of the hashes that you know how to do,
>and then provide those to any plugin that might need them so that they
>can make the determination if any of the hashes is suitable for their
>needs.

I don't see that as a huge problem.  We already deal with C-T-E: x-uue,
uuencode, x-uuencode etc... I don't expect new hash algorithms to come
along very often so the code base won't change ofen and we'll have lots of
warning. The mapping table can be stored so it's easy to update to deal
with varying implementations (e.g. in a resource or the registry).

Also agree that applications should be prepared in case the micalg
parameter doesn't exist.

LL

Date: Mon, 28 Jul 1997 13:31:09 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

Wait! No one other than John Myers was suggesting sending binary data under
application/mime! Neither the S/MIME spec nor the application/mime spec
says that you can use binary under application/mime. The S/MIME spec
directly says the opposite.

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Mon, 28 Jul 1997 13:24:57 -0700
To: [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

In the interest of testing whether there is a simple solution to a complex
problem, let me ask whether making app/mime subject to the same encoding
rules as message/* and multipart/* types will fix any/all the concerns
aboutencoding?

d/
--------------------
Dave Crocker
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org

Date: Mon, 28 Jul 1997 12:11:52 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime and binary data
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > So what you're proposing is a way to "cheat" MIME.

> The alternative, application/mime, also "cheats" MIME.  The
> application/signed proposal attempts to limit the scope of the
> "cheating" to where it is absolutely needed, in opaque digital
> signatures.

The correct term isn't "cheat", I'm afraid, it is "violate". The current
application/mime proposal is in clear violation of the MIME specification. The
MIME specification EXPRESSLY FORBIDS the use of encodings other than 7bit,
8bit, or binary on composite types. Since application/mime is clearly
composite, this is in violation of one of the more strongly worded clauses in
all of MIME.

I have a major problem with this, as you might expect. My problem stems from
the fact that when we designed MIME we were basically providing a sort of
guarantee as to what sorts of objects implementors would be presented with. And
one of the things we clearly intended to guarantee was that binary MIME would
not be hidden inside of other MIME objects, so implementors who elected to use
a line-oriented strategy to parse MIME would be safe.

This is in fact a logical extension of the care we went to not to break
implementations written in good faith to conform to RFC 821 and RFC 822 that
could only handle 7bit. We decided then that we could not make such a
non-backwards-compatible change to the infrastructure, and we based this
decision on the fact that previous attempts to develop multimedia mail
solutions hadn't made comparable guarantees and had failed as a result.

This current proposal basically does the same thing we decided against six
years ago, this time to extant MIME parsers. We have already heard from one
major vendor, Netscape, that their implementation won't handle this. And while
they may in fact be forced to change their implementation to support binary
MIME under encryption (an entirely separate issue, since an encrypted object
isn't purely composite), they should not be forced to change because we're
retroactively changing what MIME says is legal at this late date.

Finally, as a practical matter, this working group to-be doesn't have the
authority to change MIME in this way in its charter (in fact a co-director of
the applications area  has said that it is unlikely to be chartered at all) and
I doubt if a charter opening up MIME in this way would be approved in any case.

> The history of this is rather unfortunate: when both MIME and PEM were
> both under development, their respective WG meetings were scheduled at
> the same time.  Thus the MIME specification, complete with its "no
> recursive encodings" rule, was designed without the input or feedback
> from the security community.  When it later came time to do digital
> signatures in MIME, this rule seriously got in the way.

Frankly, I doubt that the PEM WG would have been able to change this even if
they had tried. While it is true that I have always thought that the recursive
encoding prohibition in MIME was excessive and that it would have been better
to simply prohibit the use of binary encodings at the leaf level on any
transport that doesn't support binary, I was a lone voice in favor of this
approach. The overwhelming majority of WG participants were in favor of banning
recursive encodings entirely.

> In any case, application/mime, application/signed, and
> application/pkcs7-mime all have the issue that they are capable of
> transporting binary MIME objects over traditional e-mail transports.  If
> this is desirable, it needs to be explicitly called out in all the
> specs.  If it is not desirable, it needs to be prohibited.  We currently
> have non-interoperation of application/pkcs7-mime due to this very
> issue.

I think application/mime and application/signed that allow binary encoding
inside are a nonstarter. I for one will certainly object to such a
specification getting registered, let alone being placed on the standards
track, and I suspect I will not be alone. I would not mind application/mime and
application/signed that allow for recursive encoding of all but binary leaf
objects, but I doubt if my personal preferences matter much here -- the
obstacles that have to be overcome here would be huge. Frankly, I think that
this group is doomed to destruction if it pursues this course -- asking the
IESG to charter a group after failing to meet the stated criteria the IESG said
the group had to meet is one thing -- the IETF is nothing if not flexible --
but then asking to grant that group the authority to pry open one of the most
important application-level standards and change it in ways that will almost
certainly reset it to proposed status boggles my mind.

				Ned

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Mon, 28 Jul 1997 12:02:15 -0700
Organization: Netscape Communications Corporation
Lines: 15
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> I believe that the debate here is about outside parts, and whether the use
> of application/mime allows an outside part to be binary. It sounds like I
> should add a sentence to 3.4.2.4 saying that application/mime messages
> should already be in 7bit format, but if it isn't, it needs a c-t-e of
> base64 or quoted-printable.

This proposed requirement appears to be vacuous.  "If it's not 7bit, it
needs to be transfer encoded in order to be transported over a 7bit
channel."  It doesn't address whether or not the content is permitted to
be arbitrary binary data.

If the content of an application/mime conforms to the requirements of
7bit data, then why is it wrapped up inside an application/mime in the
first place?

Date: Mon, 28 Jul 1997 10:31:14 -0700
From: John Gardiner Myers <[email-masked]>
To: [email-masked]
Subject: Re: application/mime and binary data
Sender: [email-masked]

> So what you're proposing is a way to "cheat" MIME.

The alternative, application/mime, also "cheats" MIME.  The
application/signed proposal attempts to limit the scope of the
"cheating" to where it is absolutely needed, in opaque digital
signatures.

The history of this is rather unfortunate: when both MIME and PEM were
both under development, their respective WG meetings were scheduled at
the same time.  Thus the MIME specification, complete with its "no
recursive encodings" rule, was designed without the input or feedback
from the security community.  When it later came time to do digital
signatures in MIME, this rule seriously got in the way.

In any case, application/mime, application/signed, and
application/pkcs7-mime all have the issue that they are capable of
transporting binary MIME objects over traditional e-mail transports.  If
this is desirable, it needs to be explicitly called out in all the
specs.  If it is not desirable, it needs to be prohibited.  We currently
have non-interoperation of application/pkcs7-mime due to this very
issue.

Date: Mon, 28 Jul 1997 12:02:36 -0400
To: John Gardiner Myers <[email-masked]>
From: "James M. Galvin" <[email-masked]>
Subject: Re: application/mime and binary data
Cc: [email-masked]
Sender: [email-masked]

At 2:21 PM -0400 7/25/97, John Gardiner Myers wrote:
>I definitely understand that some modificaiton or exception to the "no
>recursive encodings" rule of MIME is necessary to support digital
>signatures.  I currently would prefer a more limited appliation/signed
>type (application/signed being identical to multipart/signed except for
>the lack of transfer encoding restrictions and default handling) but
>could be convinced of the need for the more general type.

So what you're proposing is a way to "cheat" MIME.

You're proposing the creation of a content type under "application" that
has all the advantages and features of a "multipart" but without the one
disadvantage that digital signatures have surfaced: "no recursive
encodings".

Perhaps I'm too much of a purist but this just doesn't seem right to me,
although if the MIME community "buys" it I won't filibuster (or perhaps I
should have said "IMAP community").

Jim

----------------------------------------------------------------------------
James M. Galvin                                          [email-masked]
CommerceNet                                                  +1 410.203.2707
3209A Corporate Court                                    FAX +1 410.203.2709
Ellicott City, MD 21042                             http://www.commerce.net/

Date: Mon, 28 Jul 1997 11:59:32 -0400
To: John Gardiner Myers <[email-masked]>
From: "James M. Galvin" <[email-masked]>
Subject: Re: application/mime and binary data
Cc: [email-masked]
Sender: [email-masked]

At 2:21 PM -0400 7/25/97, John Gardiner Myers wrote:
>I definitely understand that some modificaiton or exception to the "no
>recursive encodings" rule of MIME is necessary to support digital
>signatures.  I currently would prefer a more limited appliation/signed
>type (application/signed being identical to multipart/signed except for
>the lack of transfer encoding restrictions and default handling) but
>could be convinced of the need for the more general type.

So what you're proposing is a way to "cheat" MIME.

You're proposing the creation of a content type under "application" that
has all the advantages and features of a "multipart" but without the one
disadvantage that digital signatures have surfaced: "no recursive
encodings".

Perhaps I'm too much of a purist but this just doesn't seem right to me,
although if the MIME community "buys" it I won't filibuster (or perhaps I
should have said "IMAP community").

Jim

----------------------------------------------------------------------------
James M. Galvin                                          [email-masked]
CommerceNet                                                  +1 410.203.2707
3209A Corporate Court                                    FAX +1 410.203.2709
Ellicott City, MD 21042                             http://www.commerce.net/

Date: Sun, 27 Jul 1997 23:10:22 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: micalg semantics and use
To: Blake Ramsdell <[email-masked]>
Cc: "'Ned Freed'" <[email-masked]>, "'Lisa Repka'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

> > And mine as well. Note that I don't implement S/MIME myself, what I do
> > implement is hooks that allow callouts after I've done the calculation to
> > actually verify the signature. And I depend on micalg to do all this in a
> > single pass.

> In your case, Ned, do you hash the first part of multipart/signed using
> the algorithm implied by micalg (something as follows):

> pgp-md5, rsa-md5, pkcs7-md5 == Hash with MD5
> rsa-sha1, rsa-sha, rsa-sha-1, pgp-sha1, pkcs7-sha1 == Hash with SHA-1

I have a table for this.

> and then present the result of that hash to the callout that can do the
> actual signature validation?

No. What I present is a general hash structure my generic hash routines use
(routines that support MD2, MD4, MD5, SHA-1, RIPEMD128, RIPEMD160, and HAVAL)
with the intermediate result of proccessing the first past, leaving the
finalization for the signature-specific routine(s).

> It seems that there may be a case (such as PGP/MIME) where other
> information needs to be presented to the hash function along with the
> content so that the correct hash can be recreated.  I think PGP 2.6x
> does something like MD5(first part of multipart/signed + signature
> classification + signature time stamp) (from RFC1991 section 6.2), but I
> may have this wrong.

Yes, but it seems that when this is done protocol designers have always placed
this information after the signed data. As such, while it isn't possible to
finish up the hash calculation completely, it is still possible to write
generic multipart/signed support code that operates in a single pass. But
micalg is an essential part of this.

> I guess the point is -- is it always possible to complete a hash of the
> first part of multipart/signed and have a satisfactory answer for the
> signature validator?

This depends on whether or not we keep on designing signature schemes
taking one pass processing into account.

				Ned

From: Steve Dusse <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'John Gardiner Myers'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: application/mime and binary data
Date: Sat, 26 Jul 1997 23:00:58 -0700
Sender: [email-masked]

I think you're on a roll here.  Now if we can find a way to collapse the
multipart/signed and application/s/mime into a single entity, we may be
able to move forward with a single format that meets everyone's needs.

something like:
   application/mime-multipart-pkcs7-signature (??!)
which always contains exactly one multipart/signed and is optionally
CTE'd depending on how much you trust the path to the recipient...

If we could migrate to a single such signature format, it would also
resolve the last ambiguity with application/pkcs7-mime (because that
would always indicate encryption).

-steve

>----------
>From: 	Blake Ramsdell[SMTP:[email-masked]]
>Sent: 	Friday, July 25, 1997 11:20 PM
>To: 	'Ned Freed'; 'John Gardiner Myers'
>Cc: 	[email-masked]'
>Subject: 	RE: application/mime and binary data
>
>On Friday, July 25, 1997 6:19 PM, Ned Freed
>[SMTP:[email-masked]] wrote:
>> Hmm. An interesting idea. It would certainly eliminate one level of MIME
>> structure and would limit the utility of this type. And perhaps gateways
>> would
>> learn to leave this alone, since its function is clearly associated with
>> signatures. I think I like it... Note, however, that the implications of
>2.2.1
>> 
>> would also apply to application/signed.
>
>In the barrage of messages that formed the Great multipart/signed vs.
>signedData War of '96, a very small exchange took place with the subject
>"application/smime".  For this discussion, the most pertinent paragraph
>from that exchange was:
>
>From: "Lewis Geer (Exchange)" <[email-masked]>
>Date: Sun, 22 Sep 1996 12:34:33 -0700
>> The mime in application/mime is probably too generic.  It's possible 
>> that people would start using it to tunnel other standards that might 
>> not make it intact thru gateways, like mime encapsulated html (mhtml).  
>> The problem with this is there is no easy way for the receiving agent 
>> to tell if the application/mime content is s/mime, mhtml, or any other 
>> standard (mhtml in particular is difficult as it is just a subclass of 
>> multipart/related). Because of this, it's possible that the receiving 
>> agent may send mhtml to an s/mime helper app.  The fix is to call 
>> application/mime something like application/smime.
>
>The prospect of making Lewis' idea more generic to accommodate *any*
>multipart/signed entity (the application/signed type that is being
>discussed) is probably a good idea, and it isn't as much of a chainsaw
>as application/mime, so innocent bystanders will be safe.
>
>The idea is that any multipart/signed thing can be tunneled using
>application/signed, presumably using appropriate CTE on the
>application/signed part, the opacity is not as objectionable as
>signedData, and it is not overly general to allow potential misuse.
>Special language can also be drafted that explains why this might be a
>good thing and what situations you might use it in, and the work does
>not have to be redone for any other multipart/signed tunneling effort.
>
>Blake
>

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'John Gardiner Myers'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: application/mime and binary data
Date: Fri, 25 Jul 1997 23:20:52 -0700
Sender: [email-masked]

On Friday, July 25, 1997 6:19 PM, Ned Freed
[SMTP:[email-masked]] wrote:
> Hmm. An interesting idea. It would certainly eliminate one level of MIME
> structure and would limit the utility of this type. And perhaps gateways
> would
> learn to leave this alone, since its function is clearly associated with
> signatures. I think I like it... Note, however, that the implications of
2.2.1
> 
> would also apply to application/signed.

In the barrage of messages that formed the Great multipart/signed vs.
signedData War of '96, a very small exchange took place with the subject
"application/smime".  For this discussion, the most pertinent paragraph
from that exchange was:

From: "Lewis Geer (Exchange)" <[email-masked]>
Date: Sun, 22 Sep 1996 12:34:33 -0700
> The mime in application/mime is probably too generic.  It's possible 
> that people would start using it to tunnel other standards that might 
> not make it intact thru gateways, like mime encapsulated html (mhtml).  
> The problem with this is there is no easy way for the receiving agent 
> to tell if the application/mime content is s/mime, mhtml, or any other 
> standard (mhtml in particular is difficult as it is just a subclass of 
> multipart/related). Because of this, it's possible that the receiving 
> agent may send mhtml to an s/mime helper app.  The fix is to call 
> application/mime something like application/smime.

The prospect of making Lewis' idea more generic to accommodate *any*
multipart/signed entity (the application/signed type that is being
discussed) is probably a good idea, and it isn't as much of a chainsaw
as application/mime, so innocent bystanders will be safe.

The idea is that any multipart/signed thing can be tunneled using
application/signed, presumably using appropriate CTE on the
application/signed part, the opacity is not as objectionable as
signedData, and it is not overly general to allow potential misuse.
Special language can also be drafted that explains why this might be a
good thing and what situations you might use it in, and the work does
not have to be redone for any other multipart/signed tunneling effort.

Blake

From: Blake Ramsdell <[email-masked]>
To: "'Ned Freed'" <[email-masked]>, "'Lisa Repka'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: micalg semantics and use
Date: Fri, 25 Jul 1997 20:23:41 -0700
Sender: [email-masked]

On Friday, July 25, 1997 6:45 PM, Ned Freed
[SMTP:[email-masked]] wrote:
> > > > micalg is required by rfc 1847. I think it should be required by
S/MIME
> > > > and
> > > > can't think of any reason not to include it.  The excellent reason for
> > > > requiring it is that it allows implementors to count on it and thus
> > > > simplifies their work.
> > >
> > > A show of hands -- who is using it for one-pass processing in S/MIME?
> 
> > Count our hand raised!
> 
> And mine as well. Note that I don't implement S/MIME myself, what I do
> implement is hooks that allow callouts after I've done the calculation to
> actually verify the signature. And I depend on micalg to do all this in a
> single pass.

In your case, Ned, do you hash the first part of multipart/signed using
the algorithm implied by micalg (something as follows):

pgp-md5, rsa-md5, pkcs7-md5 == Hash with MD5
rsa-sha1, rsa-sha, rsa-sha-1, pgp-sha1, pkcs7-sha1 == Hash with SHA-1

and then present the result of that hash to the callout that can do the
actual signature validation?

It seems that there may be a case (such as PGP/MIME) where other
information needs to be presented to the hash function along with the
content so that the correct hash can be recreated.  I think PGP 2.6x
does something like MD5(first part of multipart/signed + signature
classification + signature time stamp) (from RFC1991 section 6.2), but I
may have this wrong.

I guess the point is -- is it always possible to complete a hash of the
first part of multipart/signed and have a satisfactory answer for the
signature validator?  Is this enforced by micalg?  My reading of it is
that it is not enforced.  I think that Laurence is trying to do a
similar thing to what you are doing (precompute the hash and then hook
out to signature verification).

I'm not trying to be a wiseass -- I am just making sure I understand
micalg correctly.

Blake

Date: Fri, 25 Jul 1997 18:45:26 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Attempt to clear off the open issues
To: Lisa Repka <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > micalg is required by rfc 1847. I think it should be required by S/MIME and
> > > can't think of any reason not to include it.  The excellent reason for
> > > requiring it is that it allows implementors to count on it and thus
> > > simplifies their work.
> >
> > A show of hands -- who is using it for one-pass processing in S/MIME?

> Count our hand raised!

And mine as well. Note that I don't implement S/MIME myself, what I do
implement is hooks that allow callouts after I've done the calculation to
actually verify the signature. And I depend on micalg to do all this in a
single pass.

				Ned

Date: Fri, 25 Jul 1997 18:19:03 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime and binary data
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> >         Aapp/mime got a number of public reviews, most especially on the non-ietf
> > s/mime list (egad, a summer ago)?  Out of all that it looked like folks
> > were generally comfortable with it.

> I'm not sure it has been well reviewed by the MIME community.  The type
> does appear to violate section 2.2.1 of RFC 2048, so its movement onto
> the standards track is an amendment of the base MIME spec.  It may well
> be necessary to amend MIME in this way, but the change and its
> implications should be called out.

Actually, I don't think it violates 2.2.1 at all. 2.2.1 says:

   Media types must function as an actual media format: Registration of
   things that are better thought of as a transfer encoding, as a
   character set, or as a collection of separate entities of another
   type, is not allowed.  For example, although applications exist to
   decode the base64 transfer encoding [RFC 2045], base64 cannot be
   registered as a media type.

   This requirement applies regardless of the registration tree
   involved.

Now, obviously the part in question is whether or not application/mime is an
media type which is "better thought of as  as a collection of separate entities
of another type". But the entire point of application/mime is to have an
composite object where the entities inside should NOT be thought of as 
separate.

So the real question is, is the case for having such a media type sufficiently
strong? If it is then the registration process allows it, if it doesn't then
the registration process effectively bans the registration of this type.

Note that I'm not taking a position here. I'm fairly ambivalent about
application/mime -- while I think it may solve an immediate problem, the
long-term result will be that gateways will learn to treat application/mime as
a composite object (mine already do) and hence we'll be back to square one. The
only long term solution is to get gateways to Do The Right Thing when presented
with multipart/signed. However, the cost of application/mime, modulo the
encoding issue, which can be gotten rid of, is small. But so are the long term
benefits.

> I definitely understand that some modificaiton or exception to the "no
> recursive encodings" rule of MIME is necessary to support digital
> signatures.  I currently would prefer a more limited appliation/signed
> type (application/signed being identical to multipart/signed except for
> the lack of transfer encoding restrictions and default handling) but
> could be convinced of the need for the more general type.

Hmm. An interesting idea. It would certainly eliminate one level of MIME
structure and would limit the utility of this type. And perhaps gateways would
learn to leave this alone, since its function is clearly associated with
signatures. I think I like it... Note, however, that the implications of 2.2.1
would also apply to application/signed.

				Ned

P.S. I had the registration of things like application/mime in mind when I
wrote 2.2.1, BTW.

Date: Fri, 25 Jul 1997 18:17:10 -0700
From: Lisa Repka <[email-masked]>
Organization: Netscape Communications Corporation
To: [email-masked]
Subject: Re: Attempt to clear off the open issues
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> On Thursday, July 24, 1997 8:27 AM, Laurence Lundblade
> [SMTP:[email-masked]] wrote:
> > micalg is required by rfc 1847. I think it should be required by S/MIME and
> > can't think of any reason not to include it.  The excellent reason for
> > requiring it is that it allows implementors to count on it and thus
> > simplifies their work.
> 
> A show of hands -- who is using it for one-pass processing in S/MIME?

Count our hand raised!

> The problem that I have with it being MUST is that I believe that the
> conversion between signedData and multipart/signed is a useful if not
> necessary transformation, as evidenced by the fierce debate that has
> raged about it.  If the micalg is mandated, then it could potentially
> become impossible to convert a signedData entity to multipart/signed,
> since the converter may not understand how to convert the
> AlgorithmIdentifiers specified in digestAlgorithms to their micalg
> string representation.  Granted, the AlgorithmIdentifiers and their
> micalg string mapping are defined for the two "in vogue" algorithms --
> MD5 and SHA-1, so this should not be an issue for at least a little
> while.

Okay, I think what we're talking about is the possible introduction
of a new hash algorithm, which your translator cannot convert to a
new micalg string because one hasn't been defined yet.  I understand
the problem of that, but I'm not sure how important it is.  This new
algorithm is obviously *not* one of the ones already listed in the
S/MIME spec (meaning, it isn't MD2, MD5, or SHA-1).  So how many
S/MIME agents out there would be able to receive and verify such a
message anyway?  Ours can't -- those are the only 3 hash algorithms
we currently recognize.  We would certainly incorporate and support
any new algorithm that became trusted and used, but wouldn't/shouldn't
a new micalg be defined by the same time that new versions of S/MIME
agents started supporting it anyway?

What I'm saying is that I understand your issue but I think that it is,
in practice, not likely to be any real stumbling block -- and as such
I'd like to stick with the proposal of making the micalg parameter be
required because I think agents should be able to *count* on doing
one-pass processing.

lisa

Date: Fri, 25 Jul 1997 18:14:02 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The "name" parameter
To: Jamie Zawinski <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Why?  This has been a constant thorn in my side.  Does anyone actually
> object to content-disposition, or is the problem just that nobody has
> yet gotten off their butt and pushed it through?

Keith Moore and I "got off our butts" some time ago to fix the problems (by
extending the parameter value notation in MIME) and also to push the
content-disposition spec through the process. The biggest problem, however, has
been an almost complete lack of feedback from the community. Additional
feedback would have expedited the process with the IESG considerably. Enough
said.

				Ned

Date: Fri, 25 Jul 1997 17:44:22 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The "name" parameter
To: John Gardiner Myers <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Jamie Zawinski wrote:

> > Why?  This has been a constant thorn in my side.  Does anyone actually
> > object to content-disposition, or is the problem just that nobody has
> > yet gotten off their butt and pushed it through?

> (To be precise, content-disposition is currently an Experimental RFC)

> Last I heard (about a year ago), the problem was internationalization.

Well, sort of. The specific issue that was raised was what to do with
the non-ASCII filenames some operating systems support. We found out
early on in the MIME development process that this is a can of worms.

Now, the size of this can of worms depends on how you measure can size ;-) If
you measure it in terms of the potential complexity of the entire problem
space, you'll find that it is pretty darn big. For example, filesystems
sometimes present different and inconsistent views of the namespace depending
on context. Trying to capture the precise semantics of this in order to
generate canonical filename parameter values s very, very messy.

But if you measure the size by how big a problem this is in practice, the can
actually turns out to be pretty small. For one thing, file name usefulness
correlates well with the degree of homogeneity of the environment. And people
adapt to this by making their name choices increasing generic the heterogeneous
the environment they're dealing with. So you found that while the problem
overall is intractable, solving enough of it to be very useful is well within
reach.

So what we ended up doing is essentially punting on the canonicalization
issue entirely. We now provide the tools for representing filenames that
contain 8bit characters, either with or without associated charset and
language indicators. If you want to do canonicalization, fine, and if not,
that's fine too.

Finally, given that this information is never anything more than advisory, I
don't forsee any substantive interoperability problems with this approach.

				Ned

Date: Fri, 25 Jul 1997 17:16:27 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: The "name" parameter
To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> I disagree. To quote RFC 2046:

> >   An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
> >   has since been removed.  RFC 1341 also defined the use of a "NAME"
> >   parameter which gave a suggested file name to be used if the data
> >   were to be written to a file.  This has been deprecated in
> >   anticipation of a separate Content-Disposition header field, to be
> >   defined in a subsequent RFC.

> The Content-Disposition work has not moved to RFC status yet. Thus, the
> "anticipation" is a bit premature.  Note that "deprecated" and "obsolete"
> mean different things.

FWIW, the content-disposition specification was originally kept off the
standards track because of unresolved issues surrounding how to specify
character set and language information for parameter values. This issue is
resolved now that draft-freed-pvcsc-03.txt has been approved as a proposed
standard. The new content-disposition draft,  draft-moore-mime-cdisp-01.txt,
which references draft-freed-pvcsc-03.txt, is now finishing up last call, and I
have every expectation that the IESG will move it to proposed standard the next
time they meet.

As such, I think the expectation should now be that content-disposition will be
ready for use, especially given the time it will probably take to get
S/MIME out the door.

				Ned

Date: Fri, 25 Jul 1997 17:09:37 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: application/mime and binary data
Sender: [email-masked]

At 3:32 PM -0700 7/25/97, Jamie Zawinski wrote:
>For what it's worth, Netscape is one of those MUAs that can't cope with
>"Content-Transfer-Encoding: binary".  Our MIME parser is line-oriented,
>and treats unencoded CR, LF, and CRLF synonymously.  It would be a lot
>of work to make it able to handle binary MIME parts.
>
>This applies to both MIME and S/MIME objects; if an encrypted or
>opaque-signed S/MIME message has unencoded binary data inside it,
>that message won't be decoded properly.

Well, then your implementation isn't conformant anyhow. From the first
paragraph of Section 3.1.2, which is talking about inside parts:

"When generating any of the secured MIME entities below, except the
signing using the multipart/signed format, no transfer encoding at all
is required.  S/MIME implementations MUST be able to deal with binary
MIME objects. If no Content-Transfer-Encoding header is present, the
transfer encoding should be considered binary."

I believe that the debate here is about outside parts, and whether the use
of application/mime allows an outside part to be binary. It sounds like I
should add a sentence to 3.4.2.4 saying that application/mime messages
should already be in 7bit format, but if it isn't, it needs a c-t-e of
base64 or quoted-printable.

--Paul E. Hoffman, Director
--Internet Mail Consortium

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The "name" parameter
Date: Fri, 25 Jul 1997 16:54:03 -0700
Organization: Netscape Communications Corporation
Lines: 8
NNTP-Posting-Host: h-205-217-229-208.mcom.com
Sender: [email-masked]

Jamie Zawinski wrote: 
> Why?  This has been a constant thorn in my side.  Does anyone actually
> object to content-disposition, or is the problem just that nobody has
> yet gotten off their butt and pushed it through?

(To be precise, content-disposition is currently an Experimental RFC)

Last I heard (about a year ago), the problem was internationalization.

From: Blake Ramsdell <[email-masked]>
To: "'Laurence Lundblade'" <[email-masked]>
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Date: Fri, 25 Jul 1997 16:12:40 -0700
Sender: [email-masked]

On Friday, July 25, 1997 10:04 AM, Laurence Lundblade
[SMTP:[email-masked]] wrote:
> Well, I'll raise my hand a little. One thing are planning is to assume your
> local message store is secure and compute the hash values as we insert them
> into the local message store (e.g. as they come done via POP). This gains
> substantial efficiency at read time for big messages you're verifying while
> just looking at the text.

But the problem is that you will not know which digest algorithm a
particular message part will need in order to complete its signature.
"rsa-md5", "pgp-md5" and "pkcs7-md5" are all legal values to identify
the MD5 algorithm (even though, as you will probably find out at some
point, the data that is presented to these hashing algorithms is not
completely derived from the content, but may also be found in the
signature part as well).  At some point someone will come up with
"zoondap" which happens to be MD5.  The only option you're going to have
in your case is to compute all of the hashes that you know how to do,
and then provide those to any plugin that might need them so that they
can make the determination if any of the hashes is suitable for their
needs.

> >The problem that I have with it being MUST is that I believe that the
> >conversion between signedData and multipart/signed is a useful if not
> >necessary transformation, as evidenced by the fierce debate that has
> >raged about it.  If the micalg is mandated, then it could potentially
> >become impossible to convert a signedData entity to multipart/signed,
> >since the converter may not understand how to convert the
> >AlgorithmIdentifiers specified in digestAlgorithms to their micalg
> >string representation.  Granted, the AlgorithmIdentifiers and their
> >micalg string mapping are defined for the two "in vogue" algorithms --
> >MD5 and SHA-1, so this should not be an issue for at least a little
> >while.
> 
> Well, that's a good point.  We definitely ought to get the mapping straight
> no matter what. I guess my off-the-cuff answer would be that we should get
> rid of signedData completely and use application/mime wrapping of
> multipart/signed instead so there's no conversion issue and thus removing
> this argument about making micalg optional :-).

Careful -- these are separate, treacherous waters to navigate.  This
discussion is already starting up again in a separate thread, raising
some issues about application/mime and various politics that I was not
aware of.  The point is taken, however.

> This seems like a subjective trade-off so I don't have a strong opinion.
> I'll say that we should still make it required because I think we want to
> make the signature verification process faster and easier than the
> conversion process because signature verification is going to be done much
> more widely, more frequently, and on smaller platforms (like the Newton or
> Pilot).

I have talked with Paul offline, and I agree that we should make micalg
a MUST.  I will also suggest that if micalg isn't present that the
implementation SHOULD NOT throw its hands up in the air and walk away,
but should instead try to make an effort (however inefficient) to
resolve this problem.  This is, most likely, hashing the data using all
of the algorithms understood by the application, and then using the one
required to verify the signature (which will be determined when the
signature part is parsed).  The overhead is the resource overhead of
redundantly hashing the data (time and memory requirements).

Blake

To: [email-masked]
Path: news
From: Jamie Zawinski <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: application/mime and binary data
Date: Fri, 25 Jul 1997 15:32:43 -0700
Organization: Netscape Communications Corporation, Mozilla Division
Lines: 15
NNTP-Posting-Host: 205.217.227.11
Sender: [email-masked]

For what it's worth, Netscape is one of those MUAs that can't cope with
"Content-Transfer-Encoding: binary".  Our MIME parser is line-oriented,
and treats unencoded CR, LF, and CRLF synonymously.  It would be a lot
of work to make it able to handle binary MIME parts.

This applies to both MIME and S/MIME objects; if an encrypted or
opaque-signed S/MIME message has unencoded binary data inside it, 
that message won't be decoded properly.

So, I'd lean toward prohibiting cte-binary inside of S/MIME objects,
because it's less work for us (and I suspect for lots of other people 
as well.)

-- 
Jamie Zawinski         http://people.netscape.com/jwz/      about:jwz

To: [email-masked]
Path: news
From: Jamie Zawinski <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: The "name" parameter
Date: Fri, 25 Jul 1997 15:26:58 -0700
Organization: Netscape Communications Corporation, Mozilla Division
Lines: 11
NNTP-Posting-Host: 205.217.227.11
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> The Content-Disposition work has not moved to RFC status yet. Thus,
> the "anticipation" is a bit premature.

Why?  This has been a constant thorn in my side.  Does anyone actually
object to content-disposition, or is the problem just that nobody has
yet gotten off their butt and pushed it through?

-- 
Jamie Zawinski         http://people.netscape.com/jwz/      about:jwz

Date: Fri, 25 Jul 1997 13:39:28 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: The "name" parameter
Sender: [email-masked]

At 12:05 PM -0700 7/25/97, John Gardiner Myers wrote:
>Section 3.2.1 mentions the ``optional "name" parameter to the
>Content-Type field''.  Per the MIME spec, the "name" parameter is not
>applicable across all content types, it only applied to particular media
>types.

Right: application/pkcs7-mime is a media type that it could apply to.

>The parameter is obsolete, besides.

I disagree. To quote RFC 2046:

>   An additional parameter, "CONVERSIONS", was defined in RFC 1341 but
>   has since been removed.  RFC 1341 also defined the use of a "NAME"
>   parameter which gave a suggested file name to be used if the data
>   were to be written to a file.  This has been deprecated in
>   anticipation of a separate Content-Disposition header field, to be
>   defined in a subsequent RFC.

The Content-Disposition work has not moved to RFC status yet. Thus, the
"anticipation" is a bit premature.  Note that "deprecated" and "obsolete"
mean different things.

If Content-Disposition was complete, sure, we could make this change, but
given that it is still in flux, I think that leaving name= in the
Content-type here is fine.

>In "A proper S/MIME implementation MUST use the MIME types and should
>not rely on the file extensions." the word "should" should be written as
>"must".

Agree completely.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: "Nicolls, J. Weston" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: The "name" parameter
Date: Fri, 25 Jul 97 15:50:00 EDT
Sender: [email-masked]

How about using a Content-Description: field instead to carry the file name 
information?

 ----------
>>From: John Gardiner Myers
>>To: [email-masked]
>>Subject: The "name" parameter
>>Date: Friday, July 25, 1997 3:05PM
>>
>>
>>Section 3.2.1 mentions the ``optional "name" parameter to the
>>Content-Type field''.  Per the MIME spec, the "name" parameter is not
>>applicable across all content types, it only applied to particular media
>>types.  The parameter is obsolete, besides.
>>
>>The SHOULD directive refering to the "name" parameter should be simply
>>removed from the document.
>>
>>In "A proper S/MIME implementation MUST use the MIME types and should
>>not rely on the file extensions." the word "should" should be written as
>>"must".
>>
>>

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: The "name" parameter
Date: Fri, 25 Jul 1997 12:05:03 -0700
Organization: Netscape Communications Corporation
Lines: 11
NNTP-Posting-Host: h-205-217-229-208.mcom.com
Sender: [email-masked]

Section 3.2.1 mentions the ``optional "name" parameter to the
Content-Type field''.  Per the MIME spec, the "name" parameter is not
applicable across all content types, it only applied to particular media
types.  The parameter is obsolete, besides.

The SHOULD directive refering to the "name" parameter should be simply
removed from the document.

In "A proper S/MIME implementation MUST use the MIME types and should
not rely on the file extensions." the word "should" should be written as
"must".

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Attempt to clear off the open issues
Date: Fri, 25 Jul 1997 11:54:18 -0700
Organization: Netscape Communications Corporation
Lines: 14
NNTP-Posting-Host: h-205-217-229-208.mcom.com
Sender: [email-masked]

Laurence Lundblade wrote:
> Also consider that protocols
> like IMAP can't handle binary MIME (unless something changed recently).

I don't see how this is relevant.  These protocols don't dissect PKCS
objects either.

> That of course means we must change the default CTE to 7-bit (section
> 3.1.2), which of course means if there is no CTE header, the 7-bit should
> be assumed.

Aigh, I hadn't seen that sentence.  Please don't create a gratuitous
variant of MIME.  If the data doesn't conform to the 7-bit or 8-bit data
requirements, put a "c-t-e: binary" header on it.

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: binary data inside application/pkcs7-mime
Date: Fri, 25 Jul 1997 11:32:11 -0700
Organization: Netscape Communications Corporation
Lines: 25
NNTP-Posting-Host: h-205-217-229-208.mcom.com
Sender: [email-masked]

Blake Ramsdell wrote:
> One possibility is that we could add another SMIMECapability that is
> something like "preferBinaryInside" or something like that.  I'm
> somewhat hesitant to suggest this, because I'm not sure if this is an
> overloading of the SMIMECapabilities to be MIMECapabilities also.  My
> gut feeling is that it might help, but I don't know if there are going
> to be any concerns about the user having multiple mail agents,
> intermediate gateway processing, etc.

There are definitely such concerns.  I also have a concern that we
should Keep It Simple if possible.  The more things that have to be
negotiated, the worse it gets.

> The bottom line is that non-interoperability is not cool.  Do we get
> tough with the language (the inside MUST be 7-bit clean), do we come up
> with a protocol patch (preferBinaryInside), or is there some other
> answer.

There are two other options: require the inside to be 8-bit clean (using
the MIME definition of "8-bit data", and require all readers to handle
imbedded binary MIME.

Given the disaster the "no recursive encodings" rule of MIME has been,
I'd lean towards requiring readers do the little extra work that saves
composers and intermediaries so much headaches.

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: application/mime and binary data
Date: Fri, 25 Jul 1997 11:21:30 -0700
Organization: Netscape Communications Corporation
Lines: 74
NNTP-Posting-Host: h-205-217-229-208.mcom.com
Sender: [email-masked]

>         Aapp/mime got a number of public reviews, most especially on the non-ietf
> s/mime list (egad, a summer ago)?  Out of all that it looked like folks
> were generally comfortable with it.

I'm not sure it has been well reviewed by the MIME community.  The type
does appear to violate section 2.2.1 of RFC 2048, so its movement onto
the standards track is an amendment of the base MIME spec.  It may well
be necessary to amend MIME in this way, but the change and its
implications should be called out.

I definitely understand that some modificaiton or exception to the "no
recursive encodings" rule of MIME is necessary to support digital
signatures.  I currently would prefer a more limited appliation/signed
type (application/signed being identical to multipart/signed except for
the lack of transfer encoding restrictions and default handling) but
could be convinced of the need for the more general type.

> >An application/mime can transport a binary MIME object.  It is the first
> 
>         It can??  I thought c-t-e binary wasn't currently part of the standard, at
> this point?  In any event, please elaborate.  How can it do that?

c-t-e binary is currently part of the spec.  It's just that, in the
e-mail domain, there aren't a whole lot of existing transports that are
capable of transporting it.  Those transports that are capable of
transporting it are in different domains and/or enclaves (e.g. voice
mail, http)

Application/mime creates a way to transport these things within the
e-mail domain.  One can create a binary MIME object, place it within an
application/mime, apply a transfer-encoding (base64) to the body of the
application/mime, and transport the result over a 7-bit or 8-bit
channel.

> >It needs to be understood that
> >implementing application/mime will require rewriting these MIME
> 
>         There just might be some other outcomes, I suspect, if we seek them.  In
> any event I had the impression that c-t-e binary is not in widespread use.
> Why will app/mime change that?  Why will objects encoded in c-t-e binary be
> put into app/mime with any more frequency than they are now?

c-t-e binary is not in widespread use because the vast majority of
transport systems and mailbox formats are incapable of handling messages
with arbitrary binary data.  Most problematic are CR or LF octets which
are not part of a CRLF pair.  Many mailbox formats or runtime libraries
represent CRLF pairs as a single LF octet--such systems are incapable of
representing the existence of a lone LF octet in the original message. 
Many MIME readers are written to only read MIME messages which have had
their CRLF pairs encoded as single LF octets, and thus are incapable of
handling arbitrary binary MIME messages.

application/mime changes this because it permits the tunneling of a
binary MIME object through these non-binary-clean transports and mailbox
formats.  A MIME reader which is extended to interpret application/mime
recursively now has a channel by which binary MIME objects can get to
it.
 
> >The application/mime document is also entirely missing an explanation of
> >the canonical encoding implications of the type.  The contents of an
> >application/mime are in canonical (CRLF-separated) form, and this must
> >be made clear.  Many MIME parsers deal with MIME entities which have
> >had  CRLF sequences encoded into a local form of line break.  Such MIME
> 
>         Well, there's certainly nothing wrong with reminding the spec reader that
> objects being exchanged over the Internet are required to be in network
> standard form.  On the other hand it would be interesting to see an
> implementor try to send off a locally-encoded object -- inside app/mime or
> any other standardized form -- and claim that recipients should be able to
> handle it.

Experience seems to show we have to keep belaboring this point.  Make
sure to mention it MUST be in canonical, CRLF-separated form, and give a
reference to section 4 of RFC 2049.

Date: Fri, 25 Jul 1997 10:45:27 -0700
To: Dave Crocker / IMC <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Attempt to clear off the open issues
Cc: John Gardiner Myers <[email-masked]>, [email-masked]
Sender: [email-masked]

At 8:35 PM -0700 7/24/97, Dave Crocker / IMC wrote:
>John,
>
>At 04:12 PM 7/24/97 -0700, John Gardiner Myers wrote:
>
>>An application/mime can transport a binary MIME object.  It is the first
>
>	It can??  I thought c-t-e binary wasn't currently part of the
>standard, at
>this point?  In any event, please elaborate.  How can it do that?

'cause we didn't say it couldn't be binary.  I suggest we say it can't be
binary, and that we say the default CTE is 7-bit.

>>The application/mime document is also entirely missing an explanation of
>>the canonical encoding implications of the type.  The contents of an
>>application/mime are in canonical (CRLF-separated) form, and this must
>>be made clear.  Many MIME parsers deal with MIME entities which have
>>had  CRLF sequences encoded into a local form of line break.  Such MIME
>
>	Well, there's certainly nothing wrong with reminding the spec
>reader that
>objects being exchanged over the Internet are required to be in network
>standard form.  On the other hand it would be interesting to see an
>implementor try to send off a locally-encoded object -- inside app/mime or
>any other standardized form -- and claim that recipients should be able to
>handle it.

It would probably work UNIX sendmail to UNIX sendmail lulling implementors
into unconscious confusion. I agree we need some text about this issue.
It's not big deal for DOS/Windows but it's subtle for UNIX.

BTW, I didn't notice the double wrap thing before. Aside from sounding like
toothpaste ("extra protection against decay"), it seems like we're
admitting that people are going to break the unwrapping rules. I would
rather see the unwrapping rules be very clear and that we don't give anyone
an out when we use the standard to wack them over the head for breaking the
unwrapping rules. The double wrap is kind of admission that the rules won't
always work.  It also makes the implementation much more complicated. I'd
like to take it out.

LL

>
>d/
>--------------------
>Dave Crocker
>Internet Mail Consortium                               +1 408 246 8253
>675 Spruce Dr.                                    fax: +1 408 249 6205
>Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org
>
>Member, interim Policy Oversight Committee     http://www.gtld-mou.org

Date: Fri, 25 Jul 1997 10:33:58 -0700
To: Blake Ramsdell <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Cc: "'John Gardiner Myers'" <[email-masked]>, "[email-masked]'" 	 <[email-masked]>
Sender: [email-masked]

At 8:14 PM -0700 7/24/97, Blake Ramsdell wrote:
>On Thursday, July 24, 1997 4:13 PM, John Gardiner Myers
>> This "binary MIME object" problem is also an issue for the
>> application/pkcs7-mime type.  I've already heard reports of
>> noninteroperability between different S/MIME implementations, because
>> some senders imbed binary MIME objects inside an application/pkcs7-mime
>> objects and some readers cannot handle binary MIME objects contained
>> inside application/pkcs7-mime objects.
>
>...
>
>I'd like to suggest that we get tough with the language which keeps the
>interoperability, but loses the ability to slim down the message.  If
>that's too harsh, then my next choice would be preferBinaryInside.
>
>Blake

I agree with Blake, et al. Let's make it 7-bit only and disallow all the
binary stuff. The reasons I'd give are difficulty of implementation and
interoperability with the installed base.  Also consider that protocols
like IMAP can't handle binary MIME (unless something changed recently).
Let's change the document for the next draft and let those that don't like
it make their arguments.

That of course means we must change the default CTE to 7-bit (section
3.1.2), which of course means if there is no CTE header, the 7-bit should
be assumed. I believe this change is important even if we allow binary CTE
because that is the default in the 822/821 context, and we want to be able
to remove the security layers and drop messages into the environment
without changing the mime object/message.

LL

Date: Fri, 25 Jul 1997 10:04:10 -0700
To: Blake Ramsdell <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Cc: "'Paul Hoffman / IMC'" 	 <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 3:04 PM -0700 7/24/97, Blake Ramsdell wrote:
>On Thursday, July 24, 1997 8:27 AM, Laurence Lundblade
>[SMTP:[email-masked]] wrote:
>> micalg is required by rfc 1847. I think it should be required by S/MIME and
>> can't think of any reason not to include it.  The excellent reason for
>> requiring it is that it allows implementors to count on it and thus
>> simplifies their work.
>
>A show of hands -- who is using it for one-pass processing in S/MIME?
>The only other simplification of translator work would probably be the
>trivial rejection of a candidate message based on the presence of an
>unknown micalg (if you don't recognize the micalg, then don't process
>the message).  In both of these cases, the absence of the micalg is not
>fatal -- only annoying.

Well, I'll raise my hand a little. One thing are planning is to assume your
local message store is secure and compute the hash values as we insert them
into the local message store (e.g. as they come done via POP). This gains
substantial efficiency at read time for big messages you're verifying while
just looking at the text.

>This is not to assume that no one in the future will be using it for
>one-pass processing, but to point out that "SHOULD if at all possible"
>might be more appropriate language due to the lack of implementations
>that use it, and to support the point that I am about to make.
>
>The problem that I have with it being MUST is that I believe that the
>conversion between signedData and multipart/signed is a useful if not
>necessary transformation, as evidenced by the fierce debate that has
>raged about it.  If the micalg is mandated, then it could potentially
>become impossible to convert a signedData entity to multipart/signed,
>since the converter may not understand how to convert the
>AlgorithmIdentifiers specified in digestAlgorithms to their micalg
>string representation.  Granted, the AlgorithmIdentifiers and their
>micalg string mapping are defined for the two "in vogue" algorithms --
>MD5 and SHA-1, so this should not be an issue for at least a little
>while.

Well, that's a good point.  We definitely ought to get the mapping straight
no matter what. I guess my off-the-cuff answer would be that we should get
rid of signedData completely and use application/mime wrapping of
multipart/signed instead so there's no conversion issue and thus removing
this argument about making micalg optional :-).

This seems like a subjective trade-off so I don't have a strong opinion.
I'll say that we should still make it required because I think we want to
make the signature verification process faster and easier than the
conversion process because signature verification is going to be done much
more widely, more frequently, and on smaller platforms (like the Newton or
Pilot).

>Maybe this is a bigger point -- is it better to have strict language in
>the spec and have implementations that bend or break the rules, or
>better to have softer but still effective language in the spec which
>allows implementations to always be conformant with no loss of
>interoperability?

Good point too...

>
>Blake

Date: Fri, 25 Jul 1997 12:16:07 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: "James M. Galvin" <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Cc: [email-masked]
Sender: [email-masked]

At 11:41 PM -0400 7/24/97, Paul Hoffman / IMC wrote:
>Receiving agents must expect unknown values for the micalg value and handle
>them gracefully, hopefully by falling back to their two-pass checker that
>relies on the inside algorithm identifier.

Not quite.  RFC1847 requires that when the micalg parameter does not match
an interior identifier it MUST be treated as an error.

>I think we should go to MUST, particularly since it is mandated by 1847.

Yes.

Jim

----------------------------------------------------------------------------
James M. Galvin                                          [email-masked]
CommerceNet                                                  +1 410.203.2707
3209A Corporate Court                                    FAX +1 410.203.2709
Ellicott City, MD 21042                             http://www.commerce.net/

Date: Thu, 24 Jul 1997 22:44:59 -0700
To: [email-masked], [email-masked]
From: Dave Crocker / IMC <[email-masked]>
Subject: application/mime - draft-crocker-wrap-02.txt
Sender: [email-masked]

Folks,

	I have finally posted a revised version of the application/mime
specification for inclusion in the internet-drafts directory.  I completely
forgot about it, until reminded today.  All the changes are quite minor
(but necessary).  Some format changes.  Better ABNF.  Etc.

	On the matter of binary content-transfer-encoding, I've made no changes to
the specification until I understand the concern and the solution better.

	For those of an impatient nature, the document is accessible now from
<http://www.brandenburg.com/Wrap02.txt> and
<http://www.brandenburg.com/Wrap02.doc>, with the latter having the usual,
better format.

	Fire away.

d/
--------------------
Dave Crocker
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org

Date: Thu, 24 Jul 1997 20:35:12 -0700
To: John Gardiner Myers <[email-masked]>
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: Attempt to clear off the open issues
Cc: [email-masked]
Sender: [email-masked]

John,

At 04:12 PM 7/24/97 -0700, John Gardiner Myers wrote:
>The msg document makes use of the application/mime media type, which the
>IESG has not approved.  I have serious concerns with application/mime. 

	Good timing.  So good, in fact, I'm wondering who wrote the Twilight Zone
episode...

	It has been a very long time since I've even thought about the spec.  As
coincidences would have it, I just found out today that the draft has been
forgotten about by other folk, too, including the relevant area directors.
Can't blame them though.  Shakespeare was right.  The fault is in myself
not my star (or something like that.)  The IESG had a revised copy but
insisted that it be posted as an I-D before they would consider.  I then
promptly forgot about it.  I'm posting a new and slightly improved version
tonight.

	Aapp/mime got a number of public reviews, most especially on the non-ietf
s/mime list (egad, a summer ago)?  Out of all that it looked like folks
were generally comfortable with it.

>It has a far-reaching impact on MIME implementations which is both
>non-obvious and subtle, and this impact is not mentioned at all in
>draft-crocker-wrap-01.txt.  

	Indeed they are not.  This is the first I've heard of such impact.  But
sometimes things just work out...Glad we can explore it in so timely a
fashion.

>An application/mime can transport a binary MIME object.  It is the first

	It can??  I thought c-t-e binary wasn't currently part of the standard, at
this point?  In any event, please elaborate.  How can it do that?

>It needs to be understood that
>implementing application/mime will require rewriting these MIME

	There just might be some other outcomes, I suspect, if we seek them.  In
any event I had the impression that c-t-e binary is not in widespread use.
Why will app/mime change that?  Why will objects encoded in c-t-e binary be
put into app/mime with any more frequency than they are now?

>The application/mime document is also entirely missing an explanation of 
>the canonical encoding implications of the type.  The contents of an
>application/mime are in canonical (CRLF-separated) form, and this must
>be made clear.  Many MIME parsers deal with MIME entities which have
>had  CRLF sequences encoded into a local form of line break.  Such MIME

	Well, there's certainly nothing wrong with reminding the spec reader that
objects being exchanged over the Internet are required to be in network
standard form.  On the other hand it would be interesting to see an
implementor try to send off a locally-encoded object -- inside app/mime or
any other standardized form -- and claim that recipients should be able to
handle it.

d/
--------------------
Dave Crocker
Internet Mail Consortium                               +1 408 246 8253
675 Spruce Dr.                                    fax: +1 408 249 6205
Sunnyvale, CA 94086 USA              [email-masked] , http://www.imc.org

Member, interim Policy Oversight Committee     http://www.gtld-mou.org

Date: Thu, 24 Jul 1997 20:41:36 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Sender: [email-masked]

At 3:04 PM -0700 7/24/97, Blake Ramsdell wrote:
>If the micalg is mandated, then it could potentially
>become impossible to convert a signedData entity to multipart/signed,
>since the converter may not understand how to convert the
>AlgorithmIdentifiers specified in digestAlgorithms to their micalg
>string representation.  Granted, the AlgorithmIdentifiers and their
>micalg string mapping are defined for the two "in vogue" algorithms --
>MD5 and SHA-1, so this should not be an issue for at least a little
>while.

Receiving agents must expect unknown values for the micalg value and handle
them gracefully, hopefully by falling back to their two-pass checker that
relies on the inside algorithm identifier.

I think we should go to MUST, particularly since it is mandated by 1847.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Blake Ramsdell <[email-masked]>
To: "'John Gardiner Myers'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Date: Thu, 24 Jul 1997 20:14:53 -0700
Sender: [email-masked]

On Thursday, July 24, 1997 4:13 PM, John Gardiner Myers
[SMTP:[email-masked]] wrote:
> The msg document makes use of the application/mime media type, which the
> IESG has not approved.  I have serious concerns with application/mime. 
> It has a far-reaching impact on MIME implementations which is both
> non-obvious and subtle, and this impact is not mentioned at all in
> draft-crocker-wrap-01.txt.  

Yup -- I mentioned this to Paul just today.  Apparently it just fell
through the cracks, and application/mime will rise from the ashes of
expiration in short order.  I can't speak about the concerns you have
about application/mime itself -- Laurence is the man for that.

> This "binary MIME object" problem is also an issue for the
> application/pkcs7-mime type.  I've already heard reports of
> noninteroperability between different S/MIME implementations, because
> some senders imbed binary MIME objects inside an application/pkcs7-mime
> objects and some readers cannot handle binary MIME objects contained
> inside application/pkcs7-mime objects.

I can see how this could happen, and I don't know what the answer is.
On one side, you have the need to minimize the message size (if the
interior is base64 and the exterior is base64, then you can remove one
of the base64 steps to reduce your size).  On the other hand, it blows
some people's minds if you send them binary data inside of an
application/pkcs7-mime object, including my case of converting
signedData to multipart/signed and then trying to stick it back on the
(7-bit) wire.  How do you balance this?

One possibility is that we could add another SMIMECapability that is
something like "preferBinaryInside" or something like that.  I'm
somewhat hesitant to suggest this, because I'm not sure if this is an
overloading of the SMIMECapabilities to be MIMECapabilities also.  My
gut feeling is that it might help, but I don't know if there are going
to be any concerns about the user having multiple mail agents,
intermediate gateway processing, etc.

The bottom line is that non-interoperability is not cool.  Do we get
tough with the language (the inside MUST be 7-bit clean), do we come up
with a protocol patch (preferBinaryInside), or is there some other
answer.

I'd like to suggest that we get tough with the language which keeps the
interoperability, but loses the ability to slim down the message.  If
that's too harsh, then my next choice would be preferBinaryInside.

Blake

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Attempt to clear off the open issues
Date: Thu, 24 Jul 1997 16:12:35 -0700
Organization: Netscape Communications Corporation
Lines: 37
NNTP-Posting-Host: h-205-217-229-208.mcom.com
Sender: [email-masked]

I've been holding off raising new technical issues until the WG status
and charter got worked out.  Paul mentions an effort to finish up, and I
don't know what it is that is trying to be accomplished.  Repeating my
question of Jul 2, where are we?

As far as open issues goes, I don't think the issue about the
DN-to-email mapping requirements of section 3.1 of the cert document has
been resolved.

The msg document makes use of the application/mime media type, which the
IESG has not approved.  I have serious concerns with application/mime. 
It has a far-reaching impact on MIME implementations which is both
non-obvious and subtle, and this impact is not mentioned at all in
draft-crocker-wrap-01.txt.  

An application/mime can transport a binary MIME object.  It is the first
method by which this can be done in the context of internet mail.  A
large number of deployed MIME readers in the email domain are incapable
of handling binary MIME objects.  It needs to be understood that
implementing application/mime will require rewriting these MIME
implementations, and the document needs to make this requirement more
explicit.

The application/mime document is also entirely missing an explanation of 
the canonical encoding implications of the type.  The contents of an
application/mime are in canonical (CRLF-separated) form, and this must
be made clear.  Many MIME parsers deal with MIME entities which have
had  CRLF sequences encoded into a local form of line break.  Such MIME
parsers cannot be directly handed an application/mime object, especially
if that object is binary.

This "binary MIME object" problem is also an issue for the
application/pkcs7-mime type.  I've already heard reports of
noninteroperability between different S/MIME implementations, because
some senders imbed binary MIME objects inside an application/pkcs7-mime
objects and some readers cannot handle binary MIME objects contained
inside application/pkcs7-mime objects.

From: Blake Ramsdell <[email-masked]>
To: "'Laurence Lundblade'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Date: Thu, 24 Jul 1997 15:04:25 -0700
Sender: [email-masked]

On Thursday, July 24, 1997 8:27 AM, Laurence Lundblade
[SMTP:[email-masked]] wrote:
> micalg is required by rfc 1847. I think it should be required by S/MIME and
> can't think of any reason not to include it.  The excellent reason for
> requiring it is that it allows implementors to count on it and thus
> simplifies their work.

A show of hands -- who is using it for one-pass processing in S/MIME?
The only other simplification of translator work would probably be the
trivial rejection of a candidate message based on the presence of an
unknown micalg (if you don't recognize the micalg, then don't process
the message).  In both of these cases, the absence of the micalg is not
fatal -- only annoying.

This is not to assume that no one in the future will be using it for
one-pass processing, but to point out that "SHOULD if at all possible"
might be more appropriate language due to the lack of implementations
that use it, and to support the point that I am about to make.

The problem that I have with it being MUST is that I believe that the
conversion between signedData and multipart/signed is a useful if not
necessary transformation, as evidenced by the fierce debate that has
raged about it.  If the micalg is mandated, then it could potentially
become impossible to convert a signedData entity to multipart/signed,
since the converter may not understand how to convert the
AlgorithmIdentifiers specified in digestAlgorithms to their micalg
string representation.  Granted, the AlgorithmIdentifiers and their
micalg string mapping are defined for the two "in vogue" algorithms --
MD5 and SHA-1, so this should not be an issue for at least a little
while.

Maybe this is a bigger point -- is it better to have strict language in
the spec and have implementations that bend or break the rules, or
better to have softer but still effective language in the spec which
allows implementations to always be conformant with no loss of
interoperability?

Blake

From: Steve Dusse <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "'Laurence Lundblade'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Attempt to clear off the open issues
Date: Thu, 24 Jul 1997 08:51:58 -0700
Sender: [email-masked]

Aha !!  Sounds like a compelling argument to me.

-s

>----------
>From: 	Laurence Lundblade[SMTP:[email-masked]]
>Sent: 	Thursday, July 24, 1997 8:27 AM
>To: 	Paul Hoffman / IMC
>Cc: 	[email-masked]
>Subject: 	Re: Attempt to clear off the open issues
>
>At 7:15 PM -0700 7/23/97, Paul Hoffman / IMC wrote:
>>
>>- Make the micalg parameter required, not optional.
>>
>>[Comment: this is probably a bit controversial, so it is still an
>>unresolved issue. Please speak up about this if you are an implementor and
>>you have a good reason to make micalgs required.]
>
>micalg is required by rfc 1847. I think it should be required by S/MIME and
>can't think of any reason not to include it.  The excellent reason for
>requiring it is that it allows implementors to count on it and thus
>simplifies their work.
>
>LL
>
>
>

Date: Thu, 24 Jul 1997 08:27:12 -0700
To: Paul Hoffman / IMC <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: Attempt to clear off the open issues
Cc: [email-masked]
Sender: [email-masked]

At 7:15 PM -0700 7/23/97, Paul Hoffman / IMC wrote:
>
>- Make the micalg parameter required, not optional.
>
>[Comment: this is probably a bit controversial, so it is still an
>unresolved issue. Please speak up about this if you are an implementor and
>you have a good reason to make micalgs required.]

micalg is required by rfc 1847. I think it should be required by S/MIME and
can't think of any reason not to include it.  The excellent reason for
requiring it is that it allows implementors to count on it and thus
simplifies their work.

LL

Date: Wed, 23 Jul 1997 19:15:15 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Attempt to clear off the open issues
Sender: [email-masked]

Greetings again. Well, it appears we're making progress, and even though we
didn't become an IETF Working Group, we have also had some downward bogging.

In an effort to finish up, I'd like to close the following issues from the
open issue list. These issues have been in the document for at least two
cycles with little or no disucssion. This is a "speak now or forever hold
you peace" alert that they won't be on the open issues list for the next
round. Again, comment is welcome, but relative silence will be taken as
"none of us care".

- Make the micalg parameter required, not optional.

[Comment: this is probably a bit controversial, so it is still an
unresolved issue. Please speak up about this if you are an implementor and
you have a good reason to make micalgs required.]

- Need reference to allowed values for the micalg parameter in 3.4.2.2.
Need to list text values for the micalg parameter of multipart/signed.
RFC 1848 lists only "RSA-MD2" and "RSA-MD5", not "SHA-1".

[Comment: I'm going to name these 'pkcs7-sha1' and 'pkcs7-md5' to reflect
the fact that they are related to the format of the PKCS#7 data.]

- What to do if sending to multiple people with different known
capabilities? What if sending to a group, some of whom have
known capabilities, others with unknown?

[Comment: we're going to punt on this. It's up to the implementation, and
isn't a protocol issue. And it's really, really hard.]

- Do we need better heuristics for determining the encryption
capabilities of a recipient? What about guessing based on
key length?

[Comment: the SMIMECapabilities has covered this with much more precision
than a "heuristic", so we'll keep the spec as it is, with no heuristics.]

Add signedData SMIMEcapability and note about following it.

[Comment: Well, we need to do this if we're going to make SMIMECapabilities
useful. This will be added in the next round.]

- In section 3.4.2.4, we need to look at whether the SHOULDs should
be MUSTs.

[Comment: the author's group is split and waffling on this, so we'll leave
them as SHOULDs.]

Use of the S/MIME trademark.

[Comment: RSA is happy to let us use the S/MIME trademark on the current
document.]

Look at the use of PKCS-7 "data" format.

[Comment: This slipped in here without good cause. It is being fixed in
PKCS #7 version 2, which is of no concern to this spec.]

--Paul E. Hoffman, Director
--Internet Mail Consortium

Date: Wed, 09 Jul 1997 17:03:16 -0700
To: "Anthony E. Greene" <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

Sure, I'm willing to comment, but I am not sure this thread is pertinant to
this list. This mailing list isn't for discussions about X.509 or PGP,
except as they relate to S/MIME. If the subtext here is "should S/MIME
support PGP?" I understand why it is here, and think that the answer should
be yes. 

You are indeed correct that PGP 2.x doesn't have all the function that one
might possibly desire. If it did, then I'd probably have a different job now. 

We are actively enhancing the PGP infrastructure, and we are releasing
source code, freeware, and documents describing what we're doing. The first
enhancements we made shipped with V5.0. These include a new format for key
material and signatures, deprecating any algorithm in it that isn't an open
standard (for examples, both RSA and IDEA, which were the only algorithms
available in 2.x), and so on.

Within the next year or so (insert the usual disclaimer that this isn't an
announcement or commitment), you'll see us add in a number of other
features such as:

- support for strict hierarchies within the web of trust (which handle the
same sorts of issues as cross-certification, differences of meaning  when
crossing national (or more importantly, corporate) boundaries) 

- folding X.509 certs into PGP so that they look a lot like a user id with
a signature

- notations within a signature that serve the same purposes as extensions
do in an X.509 cert

- signature expiration and on-line validity checking, so as to avoid those
nasty CRLs

- message encoding that's compliant with PKCS 7 V2.0

And so on. 

In designing our futures, one of our precepts is that we're not religious
about data formats; we save our religious fervor for semantics, trust
models, not doing weak crypto, and so on. I have no particular love for
ASN.1, but I could completely recode PGP into it. Similarly, I could
completely code PGP using SPKI syntax. If you have good reasons for either
of these, I'd love to hear them.

Our goals for the next few versions of PGP are to (1) provide solutions for
our customers so that they get a strong, no-compromises security
infrastructure that interoperates with whatever they have and (2) to create
an open framework for PGP so that other people can make interoperable
applications. 

	Jon

-----
Jon Callas                                         [email-masked]
Senior Security Architect                          555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065

Organization: 5th Signal Command
Date: Wed, 09 Jul 1997 20:56:11 +0200
To: [email-masked]
From: "Anthony E. Greene" <[email-masked]>
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

At 14:37 09-07-1997 -0400, David P. Kemp wrote:
>The questions I wanted answers to were:
>
>  "given a set of operational requirements that X.509 was designed to
>   address, can that *entire* set of requirements be supported by
>   PGP-format certs?",
>
>and conversely, "can the *entire* set of PGP operational requirements
>be encoded into X.509-format certs?".  I believe the answer to the
>first question is "no", and the second is "yes", but would certainly
>welcome evidence to the contrary as an opportunity to improve the PKIX
>profile.
>

Assuming, for the sake of argument that you are correct, X.509 certs are the 
way to go. PGP is widely deployed, and the source is available, but the 
X.509 specs are available too. The ability to support expiration and other 
features is becoming more important as encryption and authentication become 
more common. 

PGP's certificate format does not support these advanced features. It can 
probably be upgraded to support X.509 and still keep backwards 
compatibility. Any PGP programmer types care to comment?

The goal for this group is to come up with the best standard possible. I 
believe that X.509 cert standards are a key to reaching that goal.

============================================================
Anthony E. Greene <[email-masked]>
Use PGP -- Envelopes and Signatures for Email
My PGP Key: <http://www.pobox.com/~agreene/pgp/agreene.key>
Freeware Win95 PGP: <http://web.mit.edu/network/pgp.html>
PGP FAQ: <http://www.pgp.net/pgpnet/pgp-faq/>
============================================================

Date: Wed, 9 Jul 1997 14:37:38 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

> From: Charles Breed <[email-masked]>
> 
> [...]
> 
> OTOH, I'll take my VeriSign class 1 X.509 cert, Serial Number 159e8f93015f3d8b608d1e6f5bfaaf1f, Validity Start: 01/29/1997 and extract the public key material and relevant data onto a PGP key ring. I provide you with the 'key'/ certificate after import. (This is all experimental, no commitment to this feature is being made here)
> 

Thanks for the information - I'll definitely have a look at the web site.
But the proposed exercise does not address the question I raised.

You answered the question:
 "given an X.509 cert, is it possible to extract the subset of
  information used by PGP and import it into a PGP cert."

I agree that this is possible, probably even trivial.

The questions I wanted answers to were:

  "given a set of operational requirements that X.509 was designed to
   address, can that *entire* set of requirements be supported by
   PGP-format certs?",

and conversely, "can the *entire* set of PGP operational requirements
be encoded into X.509-format certs?".  I believe the answer to the
first question is "no", and the second is "yes", but would certainly
welcome evidence to the contrary as an opportunity to improve the PKIX
profile.

In other words, S/MIME may be used to support a wide range of users and
policies.  X.509 certs can easily support web-of-trust models by
appropriate choice of DNs (just use a single RDN to hold the subject's
name or email address) and by ignoring naming constraints.

But can PGP certificates support mechanically enforced heirarchical trust
with the equivalent of X.509's nameConstraints extension (which specifies
a subset of the namespace which an issuer is trusted to certify).

More esoterically, can PGP certificates support user examination of
issuer policies with equivalents to X.509's certificatePolicies,
policyConstraints, and authorityInfoAccess extensions?  These extensions
are not currently widely used, but they were defined in response to a
very real need for users to know how much to trust a given certificate.
As the market matures (i.e. after the first PKIX RFC is issued :-) use
of these extensions will become more commonplace.

Even more esoterically, can PGP certificates support mappings between
different issuers' policies?  This might only be of interest to national
governments, but I suspect that it would also be useful for the
auto industry, for example, to be able to map it's notions of
information categories and assurance policies to that of the banking
industry.  Or to be able to automatically determine that a Verisign
Class 3 cert is roughly equivalent in strength to a GTE "class xyzzy"
cert.

Under the assumption that the S/MIME protocol should support the needs
of the entire community of email users, but that the security overhead
of S/MIME software should be minimized by standardizing on a single
certificate format, what should that format be?

Date: Tue, 08 Jul 1997 16:31:28 -0700
To: [email-masked] (David P. Kemp)
From: Charles Breed <[email-masked]>
Subject: Re: Comparing email header fields with certificate contents...?
Cc: [email-masked]
Sender: [email-masked]

David,

I accept your challenge !

Please obtain the PGP key (RSA) for Dave Del Torto at any of the well-known available worldwide public key servers (PKI), such as 
   http://www.pgp.com/keyserver/pks-lookup.cgi, 
   http://www-swiss.ai.mit.edu/~bal/pks-toplev.html,...

His key ID is 0x4AAF00E5, fingerprint 30D8 1F34 84E6 A83F  6EC8 D7F0 CAB3 D265 
it was created 1/21/93.

(You can also get a FREE copy of PGP 5.0 at these sites if you need to.)

OTOH, I'll take my VeriSign class 1 X.509 cert, Serial Number 159e8f93015f3d8b608d1e6f5bfaaf1f, Validity Start: 01/29/1997 and extract the public key material and relevant data onto a PGP key ring. I provide you with the 'key'/ certificate after import. (This is all experimental, no commitment to this feature is being made here)

I'll give Paul Hoffman at IMC, the list of differences between PGP 2.x and 5.x format for posting at IMC, so that the advantages within the new format are better known. This source code has been published. 

Game-On,
Charles

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Comparing email header fields with certificate contents...?
Date: Tue, 08 Jul 1997 12:02:47 -0700
Organization: Netscape Communications Corporation
Lines: 104
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Michel Ranger wrote:
> If you are a CA issuing identities to employees, and e-mail UAs force
> you to provide e-mail addresses, ISAKMP/IPsec forces you to include
> your IP address, your fax number, your department number,
> and all sorts of other application info, your certificate
> half-life could be weeks instead of months or years. ( ie similar to
> getting a new badge everytime a new application rolls out, or a piece
> of information changes ).

Email is not just another application.  In an enterprise, email is
increasingly mission critical and central to business processes.

Enterprises are in an extremely good position to make their e-mail
identity namespace have the exact permanency and uniqueness properties
they require.

David P. Kemp wrote: 
> 1) User agents MUST be able to map certified identities (DNs) to
>    email addresses, under control of the user.

So, you're proposing pushing the task of managing identity mappings onto
the end user?  This is going to end up giving them an extremely
unpleasant user experience.  In this situation, what is the value of
having a CA involved in the process at all?  The user could just as
"easily" map email addresses to public keys as to DN's.

> From: John Gardiner Myers <[email-masked]>
> > Historically my published email address has been more stable than any of
> > my employer, residence address, or ISP.
> 
> Huh?  For how long have you been [email-masked]?  As of Dec '96
> (sasl draft -07) you were [email-masked].

Since the time since I was first [email-masked], my published e-mail
address has changed once.  During the same time, my employer has changed
twice and my residence address has changed twice (soon to be three
times.)

> How, except for intuition, am I expected to know
> that the person with a Netscape address is the same person that wrote
> SASL?

How, except for intuition, are you expected to know that the "John
Myers" at my previous address is the same person as at my current
address?  How are you expected to know that "c=US, o=Carnegie Mellon
University, cn=John G. Myers" and "c=US, o=Netscape Communications,
cn=John Myers" are the same person?  

> What you should care about is that I wish to be known as "David P.
> Kemp" in some unambiguous naming domain of my choice, regardless of
> whether I send/get email from/to [email-masked] or [email-masked]
> or 138954,[email-masked] or [email-masked].

> Even "Elizabeth Taylor" is really "C=US, O=SAG, CN=Elizabeth Taylor" [...]

For professional e-mail purposes, you seem to have chosen
"missi.ncsc.mil" as the unambiguous naming domain fo your choice, and
that naming domain has assigned you the name "dpkemp".

If the DN is the form of identity that people care about, then that is
the form that UA's should present.  In that case, there is no reason for
the UA's to map the identity "people should care about" into the form
"people should not care about".

> If you want to use the DNS part of an RFC822 address as the naming
> authority for your permanent identity, that is fine.  You can choose
> to get certs with an RFC822 address as your name.  But that is a
> totally separate function from the business of routing messages to a
> location where your UA can find them.  Forcing the two to be linked
> together in a certificate is a gross layering violation.

I never said that one's canonical, published e-mail address is the same
as the address of the location one's UA picks up messages.  It is common
practice, especially in enterprises, for them to be different.

> If S/MIME
> forces the UA to use the email address in a cert, how could I send
> an S/MIME message to my wife from the IETF terminal room?

The same way you send the message from anywhere.  You sign with the
private key of a cert conatining your preferred published e-mail
address.  You're already going to want the client configured to attach
your preferred e-mail address to the headers.

> There is no security benefit to requiring delivery addresses in
> certificates, since if the message gets misdelivered it can't be read
> anyway.  The worst that can happen if the user misconfigures the UA
> is that the message won't get to it's intended recipient.  Requiring
> the CA to certify message routing information will just gum up the
> works when the routing is not static.

The CA is not certifying message routing information, it is certifying
an identity which has RFC 822 syntax.  It is up to the issuer of the RFC
822 identity to manage the routing, but that routing can be changed
without affecting any certifications of the identity.

> * But requiring CAs to certify email delivery addresses for *all*
>   S/MIME users is unworkable if *any* users change addresses,
>   and certification provides *no* identity-linking benefit if the
>   email delivery infrastructure does not enforce name uniqueness.

All of this is true for DN's as well, and I've mentioned before that
DN's permanency and uniqueness properties are no better than those for
email identities.

From: Michel Ranger <[email-masked]>
Cc: S/MIME Test <[email-masked]>
Subject: Cross-post : How to test S/MIME interop, how to test with PKCS#7, PKCS #10, SSL client and server certs
Date: Tue, 8 Jul 1997 00:08:02 -0400
Sender: [email-masked]

The first attempt for this message was bounced on some lists, here it is
on the lists that bounced...second and last try.

--------------------------

>Greetings,
>
>This message has been posted to a number of lists, sorry if you got
>multiple
>copies.
>
>We have put together the next phase of a set of test tools, products
>and
>auto-responders to assist developers with various security
>technologies.
>
>Some of you know and use the following, but we have moved, thus the
>service
>was interrupted for a while.  
>
>We have restored and re-organized to expand the services.
>
>
>S/MIME - PKCS#7 Messages : mailto:[email-masked]
>------------------------
>You can send an e-mail message to [email-masked]
>This will allow developers and users to send and receive all kinds of
>S/MIME-PKCS#7 messages to and from this auto-responder.
>
>This will help in testing dual key to single key, and vice
>versa interop.  For a discussion of dual key systems, please see
>http://www.entrust.com/library.htm#key_pairs
>
>Many vendors in the RSA S/MIME interop tests(
>http://www.rsa.com/rsa/S-MIME/smime_test.htm) , the EMA Security
>Challenge
>and the EDI over internet have demonstrated interop between single and
>dual key systems.
>
>This will be useful to those that want to interop with dual key based,
>public CAs and their clients.
>
>SSL Client Certs : Instant Gratification
>----------------------------------------
>http://www.entrust.com/webmenu.htm
>
>This web site will allow you to get x509v1 certs, quickly.
>If you want x509v3, see below.
>
>PKCS#10, CAPI, SSL Web Server Certs : Instant Gratification
>--------------------------------------------
>http://www.entrust.com/webmenu.htm
>This web site will allow you to get x509v1 certs, quickly.
>If you want x509V3 and/or support for Microsoft IE that is not yet on
>the
>instant demo yet, you can download Entrust/WebCA from
>http://www.entrust.com/webca_readme.htm 
>
>Misc Certificate Request Tool : Entrust/WebCA
>----------------------------------------------
>If you want x509V3 and/or support for Microsoft IE that is not yet on
>the
>instant demo or for those that want to set up their own CA for testing
>and interop to issue certs to web servers, browsers and S/MIME e-mail
>packages, you can download Entrust/WebCA for free from
>http://www.entrust.com/webca_readme.htm
>
>Note : We have done testing with a few S/MIME user agents and it worked
>for
>them in our tests, but any feedback for others is appreciated.
>
>Future Services
>---------------
>Entrust, Entrust customers and our partners will be rolling out a
>number of
>new auto-responder CAs in order to prototype a collection of next
>generation
>public service CAs and enterprise CAs coming on line in the coming
>months.
>Watch our web site for additional information.
>
>Best effort, legal disclaimer, Community Self-Support, etc
>----------------------------------------------------------
>Alas, we have spent a lot of time and money getting this to this stage.
>
>These on-line CAs are for demonstration and development purposes.
>
>No background checks are done before issuing the instant certs.
>
>WebCA users, can do their own background checks if they choose, before
>issuing certs.  See http://www.entrust.com/why.htm and
>http://www.entrust.com/insource.htm for additional technical
>information
>in this regard.
>
>Final Note
>----------
>Many of our developers spent their nights and weekends getting this
>going,
>and now it's time for them to move to other projects.  We'll do our
>best
>to keep things up to date, but this developer service is described  by
>the 
>legalese words "best-effort".
>
>
>Hope this helps move a few yardsticks forward,
>Michel 
>

>
>----------------------------------------------
>Michel Ranger                
>Entrust Technologies
>mailto:[email-masked]
>tel: 613-247-2577 
>http://www.entrust.com
>
>
>Entrust Validation String : KQCZ-E5W7-RUPM
>

Date: Mon, 07 Jul 1997 10:50:35 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Comparing email header fields with certificate contents...?
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
> >
> > > (If email address is the most stable thing in your life,
> > > more stable than your employer, your residence address, or your ISP,
> > > then you as an individual could choose to make it your Certified
> > > primary identity for personal communications.
> >
> > Historically my published email address has been more stable than any of
> > my employer, residence address, or ISP.

> Huh?  For how long have you been [email-masked]?  As of Dec '96
> (sasl draft -07) you were [email-masked].  And if you still get mail sent
> to the old address, is it based on the kindness of cmu maintaining an
> account for you with a .forward file, or on a commercial email
> forwarding service?  How, except for intuition, am I expected to know
> that the person with a Netscape address is the same person that wrote
> SASL?  Even if you had certificates for both the old and new email
> addresses, how would they be linked together for identity purposes?

John didn't say that his address hadn't changed recently, only that
historically his email address has been more stable than any other detail. I
find much the same thing to be true in my life as well, BTW -- in the past 8
years or so my physical address information has changed seven times and phone
information has changed three times, whereas my email address has only changed
once.

As a matter of fact in practice I sometimes find that email addresses are _too_
stable for assigning some sorts of identity and associated credentials. For
example, my job in a company can change, necessitating a change of credentials,
without my email address changing. (I have seen this lead to unnecessary email
address changes in practice.) Or consider the case of role-based mailbox names
like postmaster. Or take John's case -- it is far from obvious that an S/MIME
certificate assigned by CMU should transfer to John in his new job at Netscape.

Another thing nobody has bothered to point out is that the multiplicity of
email addresses many people have is frequently a non-issue insofar as identity
is concerned. Many if not most large companies implement some form of canonical
email addressing, where all of a given user's addresses are collapsed
automatically into some canonical form, and mail sent to the canonical address
is routed automatically to the user's preferred mailbox.

The bottom line is that the mapping of identity to and from email addresses is
something that has to be possible for implementations to do. However, it is
also something you cannot possibly standardize the specifics of to a large
degree without making things unusable. The most you can do is require that
email-address-based identity be an available option and leave out most of the
specifics of how this form of identity has to be set up.

This is far from a new discussion, BTW. The IETF has been grappling with the
question of identity for well over a decade now. And the one thing I've learned
from all the details simply cannot be nailed down without effectively making
the protocol unusable for many potential users. Walking the line between
enough specifics to make things implementable and interoperable while not
having so many as to make things unusable is a very, very difficult job.

				Ned

Date: Mon, 7 Jul 1997 12:34:35 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

From: John Gardiner Myers <[email-masked]>
> 
> > (If email address is the most stable thing in your life,
> > more stable than your employer, your residence address, or your ISP,
> > then you as an individual could choose to make it your Certified
> > primary identity for personal communications.
> 
> Historically my published email address has been more stable than any of
> my employer, residence address, or ISP.

Huh?  For how long have you been [email-masked]?  As of Dec '96
(sasl draft -07) you were [email-masked].  And if you still get mail sent
to the old address, is it based on the kindness of cmu maintaining an
account for you with a .forward file, or on a commercial email
forwarding service?  How, except for intuition, am I expected to know
that the person with a Netscape address is the same person that wrote
SASL?  Even if you had certificates for both the old and new email
addresses, how would they be linked together for identity purposes?

> > If the CA is only certifying a (one-time) association
> > between a key and an email address, that is a pretty weak assertion.
> > Certainly not something I'd pay money for :-).
> 
> I'd certainly be unwilling to pay for any messaging cert that doesn't at
> least give me this assertion.  I could care less about wheter you're
> "David P. Kemp" at a certain residence or "David P. Kemp, Jr." at the
> same or other residence, I care whether or not a message is from or to
> the same thing as was the last time I interacted with whatever
> "[email-masked]" is.

What you should care about is that I wish to be known as "David P.
Kemp" in some unambiguous naming domain of my choice, regardless of
whether I send/get email from/to [email-masked] or [email-masked]
or 138954,[email-masked] or [email-masked].

Even "Elizabeth Taylor" is really "C=US, O=SAG, CN=Elizabeth Taylor" since
it is the business of the SAG to establish name permanency and prevent
name reuse regardless of marriage, employer, address, etc.  If a middle
name is required as a disambiguator, they require it.  If a full common
name has already been taken, the poor actor who comes along second has
to pick a different one.  Other naming authorities/domains may have
different rules :-).

If you want to use the DNS part of an RFC822 address as the naming
authority for your permanent identity, that is fine.  You can choose
to get certs with an RFC822 address as your name.  But that is a
totally separate function from the business of routing messages to a
location where your UA can find them.  Forcing the two to be linked
together in a certificate is a gross layering violation.  If S/MIME
forces the UA to use the email address in a cert, how could I send
an S/MIME message to my wife from the IETF terminal room?

There is no security benefit to requiring delivery addresses in
certificates, since if the message gets misdelivered it can't be read
anyway.  The worst that can happen if the user misconfigures the UA
is that the message won't get to it's intended recipient.  Requiring
the CA to certify message routing information will just gum up the
works when the routing is not static.

Summary:

* You can already use an rfc822Name as your certificate identity 
  (subjectAltName) if you wish to do so.

* But requiring CAs to certify email delivery addresses for *all*
  S/MIME users is unworkable if *any* users change addresses,
  and certification provides *no* identity-linking benefit if the
  email delivery infrastructure does not enforce name uniqueness.

Date: Mon, 07 Jul 97 07:51:33 
From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Subject: Re: Comparing email header fields with certificate conten
Sender: [email-masked]

I agree with Dave.  I think that #1 and #3 are more likely in the near 
term, but I would like to see #2 deployed in the future.

Russ

>Summary:
>
>1) User agents MUST be able to map certified identities (DNs) to
>   email addresses, under control of the user.
>
>2) User agents MAY support certified mapping of identity to email
>   address, using attribute certificates.
>
>3) User agents MAY use the email address from the subjectAltName extension
>   (of a normal certificate) but MUST NOT require it to be present.

Date: Mon, 7 Jul 1997 10:09:02 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

From: Charles Breed <[email-masked]>
> 
> These limitations are ALL related to the X.509 certificate structure.
> If S/MIME (PKCS #7) could handle additional cert types, like PGP or
> SDSI, life would be better :)
> 
> A pgp 'certificate' is comprised of 1) Key Packet w/preferred
> algorithm, 2) User ID Packet, may contain DN, CN, email,... 3)
> Signature Packets making the binding or assertion of Packet 1 and 2.
> Since X509 has only one sig wrapped around the whole thing, it will
> always be very limiting.

The X.509 certificate format itself is not inherently "very limiting".
It is trivial to encode the semantics of PGP or SPKI/SDSI into X.509
certificates, if that is the desired usage model.

For example, the User ID can be a DN (which includes CN as a subset),
an rfc822 or DNS name, EDI name, URI, IP address, and/or two forms of
privately-defined names (an OID itself, and a blob tagged by an OID).
Multiple names are allowed in a single certificate.

The Key Packet definition of the public key algorithm and parameters
is of course included in the X.509 subjectPublicKeyInfo field, and if
one wants to encode symmetric algorithms into certificates (I don't),
that can be done with extensions.

If you want different authorities (or the same authority) to bind
separate attributes together using separate signatures, that is the
precise purpose of the X.509 attribute certificate.  An ID cert and a
collection of attribute certs taken together offer whatever Packet
(or Payload) structure you care to define.  (I gag at the thought of
putting W3C/Java Manifests into an X.509 certificate extension, but in
theory that too could be done.)

If you want SDSI naming semantics (names local to the issuer -
"Billy-Bob's Dave"), you can of course put that kind of name into an
X.509 DN - as a naked CN.  If you want SPKI names (no name, just the
hash of the public key), that can go in a DN too ("SN=92847cf8"),
although including the PK hash explicitly in a cert containing the
subject's public key would just be wasting space.

In other words, the ASN.1 certificate definition from X.509 does not
place restrictions on the contents or semantics or trust model that can
be embodied in those certificates.  Traditionally, X.509 certs have
been used to encode heirarchical trust and global names, and the
defined set of extensions are geared toward enabling those models to
provide security for the X.500 Directory. But since local names are a
subset of global names, and the mechanisms for enforcing web-of-trust
are a subset of those required for heirarchical trust, the existing
X.509 certificate structure can be used in traditionally-non-X.509
environments simply by not using some of it's capability and by defining
other environment-specific extensions.

Arguments over certificate encoding are just red herrings.  I don't
care how Simple SPKI turns out to be, an application that supports
X.509 and SPKI and PGP will be more complex than one that supports
X.509 only.  X.509 can encompass all the functionality (trust model,
naming model, and authorization model) of SPKI and PGP, whereas the
converse is not true.  X.509 is a framework, a vessel into which
diverse capabilities can be poured, the PKI equivalent of Base64.

A friendly challenge: I'll encode the most complex PGP-cert you can
come up with in X.509 format if you'll encode a traditional X.509-model
v3 cert in PGP format :-).

If everyone who needed to use Public Key Certificates would agree to
use a single low-level encoding, life would be better :-).

Date: Sat, 5 Jul 1997 11:19:53 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: New version of the S/MIME draft
Sender: [email-masked]

And the other shoe drops. I've updated the S/MIME draft and submitted it to
the Internet Drafts editor. The draft is available at
<http://www.imc.org/draft-dusse-smime-msg>. The changes are:

========

Changed the "FOO" from the previous draft back to RC2 and gave a
reference to the Internet Draft describing it. Added back the
OIDs for RC2 in Appendix A.

All of section 3 was completely replaced.

Updated the reference section to point to Internet Drafts for PKCS
docs.

Removed the reference to PKCS #9 in 2.5.1 by stating the syntax.

Removed signedAndEnveloped from the draft.

========

There are still many open issues. Further, no one has been paying much
attention to the -cert document, although certificates have proven to be
problematic for S/MIME developers. Comments on that draft are still
certainly appropriate.

--Paul E. Hoffman, Director
--Internet Mail Consortium

From: Michel Ranger <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'John Gardiner Myers'" <[email-masked]>
Subject: RE: Comparing email header fields with certificate contents...?
Date: Fri, 4 Jul 1997 09:00:11 -0400
Sender: [email-masked]

>----------
>From: 	John Gardiner Myers[SMTP:[email-masked]]
>Sent: 	Wednesday, July 02, 1997 9:04 PM
>To: 	[email-masked]
>Subject: 	Re: Comparing email header fields with certificate contents...?
>
>Ron Craswell wrote:
>>"At a minimum, either the Distinguished Name used to identify an
>>Internet mail entity MUST include an Internet mail address, or some
>>other mechanism MUST be implemented in the user agent to provide for
>>mapping Distinguished Names to Internet mail address."
>>
>>It seems apparent that this will generate a set of CAs that are creating
>>certs without an internet-style EA attribute (under the assumption that
>>the user agent will handle the mapping) and a set of user agents that
>>will assume they don't have to handle the mapping (under the reverse
>>assumption.)
>>
>>Shouldn't either one or the other case be mandated?
>
>I'll agree with that.
>
>> I'll vote for the UA mapping.
>
>We don't vote in the IETF, we present arguments to support our
>positions.
>
>S/MIME is primarily a security system for internet messages.  Internet
>messaging identities are in the form of RFC 822 addresses.  It is thus
>entirely reasonable and preferable to require that systems which provide
>identity certification for the internet to deal with internet (rfc822)
>identities.
>
>Also, using a mapping system raises concerns about security and trust
>weaknesses in the mapping system.
>
>Michel Ranger wrote:
>> I vote for UA mapping as well.  Some CAs or companies may want to issue
>> certs that are not e-mail specific, where an e-mail address would not be
>> appropriate to enforce as mandatory.
>
>There is at least an order of magnitude more UAs than CAs.  The cost of
>saving the CAs the work causes an inordinate amount of extra work to be
>borne by the UAs.  This is backwards.
>
>CAs are by definition in the business of asserting things about
>identity.  If a CA wants to issue certs that are useful for e-mail, it
>is not unreasonable to expect them to assert something about the e-mail
>identity.
I guess instead of voting again, I'll elaborate my arguments.

As everything else, it depends on your perspective. 
The consumer internet space is quite different from the corporate space.
A CA that wants to issue as many certs per user, per year, per
application,
will have a much different perspective, than someone running a CA within
a company that does not want a management nightmare in dealing with a
short certificate half-life.

If you are a CA issuing identities to employees, and e-mail UAs force
you to
provide e-mail addresses, ISAKMP/IPsec forces you to include 
your IP address, your fax number, your department number, 
 and all sorts of other application info, your certificate
half-life could be weeks instead of months or years. ( ie similar to
getting a new 
badge everytime a new application rolls out, or a piece
of information changes ).

This is over and above the cost argument.  Then think about the possible
list of certificate every user has, and god knows for which application,
the
growth of CRLs, the number of passwords. The number of passwords are
what
certificate based systems are  supposed to reduce, not increase.

Our products will allow you to specify the e-mail address, as an option,
but it is 
optional. As a matter of CA CPS, many of our customers , won't include
the e-mail address
in the certificate, as a matter of policy.  Others will include it, for
convenience or assertion
purposes as you mention.  In summary, it is a policy and environment
specific decision.

Hope this helps,

Michel

>
>

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Comparing email header fields with certificate contents...?
Date: Thu, 03 Jul 1997 13:55:24 -0700
Organization: Netscape Communications Corporation
Lines: 73
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

David P. Kemp wrote:

> The identity associated with an email address is derived primarily by
> the content that has historically been associated (in the mind of the
> reader) with that address.  If the email address were unique and
> permanent, it might be suitable for use as a primary identity.  But
> email addresses typically change more often than Common Names, so
> *requiring* the email address to be the primary identity is not
> appropriate.

But Common Names are far from being unique, so utterly fail to be
suitable for use as a primary identity.

In your argument, you compare the permanency qualities of email
addresses with Common Names, then assert that DNs are therefore are more
suitable than email addresses.  This arugment is bogus becuase DNs are
not the same as Common Names.  DNs contain Common Names, but since
Common Names do not fit the uniqueness requirement, DNs contain other
information.  This other information changes about as often as (if not
more frequently than) the email address, so DNs taken as a whole have no
better permanency properties than email addresses.

> (If email address is the most stable thing in your life,
> more stable than your employer, your residence address, or your ISP,
> then you as an individual could choose to make it your Certified
> primary identity for personal communications.

Historically my published email address has been more stable than any of
my employer, residence address, or ISP.

In US culture, none of employer, residence, or ISP are even close to
being stable over a person's life.  Even Common Name isn't completely
stable for almost half the population.  Then there are other cultures to
consider.

> In that case, the
> mapping from identity to email address is trivial.  But it is still a
> mapping.)

And the mapping from the combination of Common Name and any of the above
to an identity is similarly a mapping.  Sometimes the mapping is not
unique.

The identity that UAs care about *is* the email address.  It is
reasonable to require this information be provided by the CA.

> When attribute certificates come into common use, it would be appropriate
> to use them to provide a Certified mapping from identity to email address.
> But if the only choice is between 1) using email as the primary identity
> and mapping other attributes (public key, DN, etc) to it, and 2) requiring
> the user and the UA to maintain a mapping from identity to email address,
> I'll choose 2.

Again, there are far fewer CAs than UAs in the world, and CAs are better
equipped to deal with issues of identity.

> In addition, CAs issuing certificates online typically call those
> certificates "zero assurance", because the only thing they prove is
> that on a particular date a keyholder can get a copy of email sent to
> that address.  If the CA is only certifying a (one-time) association
> between a key and an email address, that is a pretty weak assertion.
> Certainly not something I'd pay money for :-).

I'd certainly be unwilling to pay for any messaging cert that doesn't at
least give me this assertion.  I could care less about wheter you're
"David P. Kemp" at a certain residence or "David P. Kemp, Jr." at the
same or other residence, I care whether or not a message is from or to
the same thing as was the last time I interacted with whatever
"[email-masked]" is.

Now, if "missi.ncsc.mil" gave better information to the CA doing the
certification, or if "missi.ncsc.mil" was the CA itself, then the
assurance the CA could provide would be stronger.

Date: Thu, 03 Jul 1997 12:47:26 -0700
To: [email-masked] (John Myers), "[email-masked]'" <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

These limitations are ALL related to the X.509 certificate structure. If S/MIME (PKCS #7) could handle additional cert types, like PGP or SDSI, life would be better :)

A pgp 'certificate' is comprised of 1) Key Packet w/preferred algorithm, 2) User ID Packet, may contain DN, CN, email,... 3) Signature Packets making the binding or assertion of Packet 1 and 2. Since X509 has only one sig wrapped around the whole thing, it will always be very limiting.

cb

At 11:28 AM 7/3/97 -0700, John Myers wrote:
>Ron Craswell wrote:
>> Imagine that there is no UA mapping mechanism and certificates are bound
>> to people directly by the E-Mail Attribute.  Now imagine that you just
>> paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
>> you to undergo DNA testing and a polygraph scan.  Now imagine your
>> e-mail address gets changed.
>
>Imagine you marry or divorce and your name gets changed.  Imagine you
>move to another state and your drivers license and address gets
>changed.  Imagine your employer is acquired or divests and your
>organizational affiliation gets changed.  Imagine you emigrate to
>another country and your national ID number changes.
>
>>  Oh well... (or, heaven forbid, that you
>> have two e-mail addresses.  Nevermind, nobody has more than one e-mail
>> address.)
>
>So you put two e-mail addresses in the cert, or you have two certs for
>the same key pair.
>
>> All sarcasm aside, the important thing is to map your understanding of a
>> person's identity with the contents of the data they're sending you.  If
>> your understanding is based on their e-mail address then that's an
>> appropriate binding.  If, OTOH, it's based on a VISA number, or Driver's
>> License, or SSN, etc. then that's what's appropriate to be in the cert.
>
>If your understanding of an identity is based on something other than
>their e-mail address, then there's no need for the UA to map their
>identity to an e-mail address.  The appropriate thing then is for the UA
>to present the identity in the form that it is based.
>
>

Date: Thu, 03 Jul 1997 11:28:59 -0700
From: [email-masked] (John Myers)
To: "[email-masked]'" <[email-masked]>
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

Ron Craswell wrote:
> Imagine that there is no UA mapping mechanism and certificates are bound
> to people directly by the E-Mail Attribute.  Now imagine that you just
> paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
> you to undergo DNA testing and a polygraph scan.  Now imagine your
> e-mail address gets changed.

Imagine you marry or divorce and your name gets changed.  Imagine you
move to another state and your drivers license and address gets
changed.  Imagine your employer is acquired or divests and your
organizational affiliation gets changed.  Imagine you emigrate to
another country and your national ID number changes.

>  Oh well... (or, heaven forbid, that you
> have two e-mail addresses.  Nevermind, nobody has more than one e-mail
> address.)

So you put two e-mail addresses in the cert, or you have two certs for
the same key pair.

> All sarcasm aside, the important thing is to map your understanding of a
> person's identity with the contents of the data they're sending you.  If
> your understanding is based on their e-mail address then that's an
> appropriate binding.  If, OTOH, it's based on a VISA number, or Driver's
> License, or SSN, etc. then that's what's appropriate to be in the cert.

If your understanding of an identity is based on something other than
their e-mail address, then there's no need for the UA to map their
identity to an e-mail address.  The appropriate thing then is for the UA
to present the identity in the form that it is based.

Date: Thu, 3 Jul 1997 09:55:32 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comparing email header fields with certificate contents...?
Sender: [email-masked]

> From: John Gardiner Myers <[email-masked]>
> 
> Ron Craswell wrote:
> >
> >Shouldn't either one or the other case be mandated?
> 
> I'll agree with that.
> 
> > I'll vote for the UA mapping.
> 
> We don't vote in the IETF, we present arguments to support our
> positions.

The identity associated with an email address is derived primarily by
the content that has historically been associated (in the mind of the
reader) with that address.  If the email address were unique and
permanent, it might be suitable for use as a primary identity.  But
email addresses typically change more often than Common Names, so
*requiring* the email address to be the primary identity is not
appropriate.  (If email address is the most stable thing in your life,
more stable than your employer, your residence address, or your ISP,
then you as an individual could choose to make it your Certified
primary identity for personal communications.  In that case, the
mapping from identity to email address is trivial.  But it is still a
mapping.)

When attribute certificates come into common use, it would be appropriate
to use them to provide a Certified mapping from identity to email address.
But if the only choice is between 1) using email as the primary identity
and mapping other attributes (public key, DN, etc) to it, and 2) requiring
the user and the UA to maintain a mapping from identity to email address,
I'll choose 2.

In addition, CAs issuing certificates online typically call those
certificates "zero assurance", because the only thing they prove is
that on a particular date a keyholder can get a copy of email sent to
that address.  If the CA is only certifying a (one-time) association
between a key and an email address, that is a pretty weak assertion.
Certainly not something I'd pay money for :-).

Summary:

1) User agents MUST be able to map certified identities (DNs) to
   email addresses, under control of the user.

2) User agents MAY support certified mapping of identity to email
   address, using attribute certificates.

3) User agents MAY use the email address from the subjectAltName extension
   (of a normal certificate) but MUST NOT require it to be present.

From: Ron Craswell <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'John Gardiner Myers'" <[email-masked]>
Subject: RE: Comparing email header fields with certificate contents...?
Date: Wed, 2 Jul 1997 21:02:03 -0700
Sender: [email-masked]

On Wednesday, July 02, 1997 6:05 PM, John Gardiner Myers
[SMTP:[email-masked]] wrote:
> 
> S/MIME is primarily a security system for internet messages.  Internet
> messaging identities are in the form of RFC 822 addresses.  It is thus
> entirely reasonable and preferable to require that systems which provide
> identity certification for the internet to deal with internet (rfc822)
> identities.

Imagine that there is no UA mapping mechanism and certificates are bound
to people directly by the E-Mail Attribute.  Now imagine that you just
paid 1000 digi-bucks for a VeriSign Class 20 certificate which required
you to undergo DNA testing and a polygraph scan.  Now imagine your
e-mail address gets changed.  Oh well... (or, heaven forbid, that you
have two e-mail addresses.  Nevermind, nobody has more than one e-mail
address.)

All sarcasm aside, the important thing is to map your understanding of a
person's identity with the contents of the data they're sending you.  If
your understanding is based on their e-mail address then that's an
appropriate binding.  If, OTOH, it's based on a VISA number, or Driver's
License, or SSN, etc. then that's what's appropriate to be in the cert.
--
Ron Craswell
Deming Internet Security
<http://www.deming.com>

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Re: Comparing email header fields with certificate contents...?
Date: Wed, 02 Jul 1997 18:04:51 -0700
Organization: Netscape Communications Corporation
Lines: 43
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

Ron Craswell wrote:
>"At a minimum, either the Distinguished Name used to identify an
>Internet mail entity MUST include an Internet mail address, or some
>other mechanism MUST be implemented in the user agent to provide for
>mapping Distinguished Names to Internet mail address."
>
>It seems apparent that this will generate a set of CAs that are creating
>certs without an internet-style EA attribute (under the assumption that
>the user agent will handle the mapping) and a set of user agents that
>will assume they don't have to handle the mapping (under the reverse
>assumption.)
>
>Shouldn't either one or the other case be mandated?

I'll agree with that.

> I'll vote for the UA mapping.

We don't vote in the IETF, we present arguments to support our
positions.

S/MIME is primarily a security system for internet messages.  Internet
messaging identities are in the form of RFC 822 addresses.  It is thus
entirely reasonable and preferable to require that systems which provide
identity certification for the internet to deal with internet (rfc822)
identities.

Also, using a mapping system raises concerns about security and trust
weaknesses in the mapping system.

Michel Ranger wrote:
> I vote for UA mapping as well.  Some CAs or companies may want to issue
> certs that are not e-mail specific, where an e-mail address would not be
> appropriate to enforce as mandatory.

There is at least an order of magnitude more UAs than CAs.  The cost of
saving the CAs the work causes an inordinate amount of extra work to be
borne by the UAs.  This is backwards.

CAs are by definition in the business of asserting things about
identity.  If a CA wants to issue certs that are useful for e-mail, it
is not unreasonable to expect them to assert something about the e-mail
identity.

To: [email-masked]
Path: news
From: John Gardiner Myers <[email-masked]>
Newsgroups: mcom.list.ietf-smime
Subject: Status of charter
Date: Wed, 02 Jul 1997 17:28:15 -0700
Organization: Netscape Communications Corporation
Lines: 10
NNTP-Posting-Host: 205.217.229.208
Sender: [email-masked]

So, where are we?

Jeff Schiller had imposed a deadline of July first to deal with the IP
issues around S/MIME.  It appears that RSA has dealt with the RC2 IP
issue.  The other issue I see as having been raised has to do with the
trademark on the name "S/MIME".  What is the status of that and how does
that affect the chartering process?

The milestones in the proposed charter appear to be off, since they
specify deliverables this month.

Date: Wed, 2 Jul 1997 12:15:56 -0700
From: [email-masked] (Matt Bishop)
To: [email-masked]
Subject: CFP: 1998 SNDSS (updated; last reminder!)
Sender: [email-masked]

CALL FOR PAPERS

The Internet Society Symposium on Network and Distributed System Security

Where: Catamaran Resort, San Diego, California
When: March 11-13, 1998

GOAL: The symposium will foster information exchange between hardware and
software developers of network and distributed system security services.
The intended audience is those who are interested in the practical aspects
of network and distributed system security, focusing on actual system
design and implementation, rather than theory.  Encouraging and enabling
the Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium.  Symposium proceedings
will be published by the Internet Society.  Topics for the symposium
include, but are not limited to, the following:

* Architectures for large-scale, heterogeneous distributed systems
* Security in malleable systems: mobile code, mobile agents, dynamic policy
  updates, etc.
* Special problems: e.g. interplay between security goals and other goals --
  efficiency, reliability, interoperability, resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies -- very
  large systems like the Internet, high-speed systems like the gigabit 
  testbeds, wireless systems, and personal communication systems.
* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, Archie, and WAIS.
* Electronic commerce:  payment services, fee-for-access, EDI, notary;
  endorsement, licensing, bonding, and other forms of assurance; intellectual 
  property protections

GENERAL CHAIR:
	David Balenson, Trusted Information Systems
PROGRAM CHAIRS:
	Matt Bishop, University of California at Davis
	Steve Kent, BBN
PROGRAM COMMITTEE:
	Steve Bellovin, AT&T Labs -- Research
	Doug Engert, Argonne National Laboratories
	Warwick Ford, VeriSign
	Li Gong, JavaSoft
	Rich Graveman, Bellcore
	Ari Juels, RSA Laboratories
	Tom Longstaff, CERT/CC
	Doug Maughan, National Security Agency
	Dan Nessett, 3Com Corporation
	Rich Parker, NATO
	Michael Roe, Cambridge University
	Rob Rosenthal, DARPA
	Wolfgang Schneider, GMD Darmstadt
	Christoph Schuba, Purdue University
	Win Treese, Open Market, Inc.
	Jonathan Trostle, Novell
	Gene Tsudik, USC/Information Sciences Institute
	Steve Welke, Institute for Defense Analyses
LOCAL ARRANGEMENTS CHAIR:
	Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
	Steve Welke, Institute for Defense Analyses
LOGISTICS CHAIR:
	Torryn Brazell, Internet Society

SUBMISSIONS: The committee invites technical papers and panel
proposals, for topics of technical and general interest.  Technical
papers should be 10-20 pages in length.  Panel proposals should be two
pages and should describe the topic, identify the panel chair, explain
the format of the panel, and list three to four potential panelists.
Technical papers will appear in the proceedings.  A description of each
panel will appear in the proceedings, and may at the discretion of the
panel chair, include written position statements from each panelist.

Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author.  The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.

Submissions must be received by 1 August 1997, and should be made via
electronic mail in either PostScript or ASCII format.  If the committee
is unable to print a PostScript submission, it will be returned and
hardcopy requested.  Therefore, PostScript submissions should arrive
well before 1 August.  If electronic submission is difficult,
submissions should be sent via postal mail.

All submissions and program related correspondence (only) should be
directed to the program chair:  Matt Bishop, Department of Computer
Science, University of California at Davis, Davis CA  95616-8562,
Email: [email-masked]. Phone: +1 (916) 752-8060,
FAX: +1 (916) 752-4767,

Dates, final call for papers, advance program, and registration
information will be available at the URL:
http://www.isoc.org/conferences/ndss98.

Each submission will be acknowledged by e-mail.  If acknowledgment is
not received within seven days, please contact the program chair as in-
dicated above.  Authors and panelists will be notified of acceptance by
1 October 1997.  Instructions for preparing camera-ready copy for the
proceedings will be sent at that time.  The camera-ready copy must be
received by 1 November 1997.