Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
From: David Sternlight <[email-masked]>
To: Gunther Schadow <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sun, 30 Nov 1997 15:54:53 -0800

Gunther Schadow wrote:
> 
> Sorry for the massive cross-post, I just didn't know which e-mail list
> David's reply came about...

It was posted to all the groups your original post went to. I simply did a
"reply" in my mailer. ;-)

> First I'll summarize your points:

(more like labelling, but let's assume readers are following this thread.)

> 
> 1. The "userbase"
> 
> 2. Trust "algorithms"
> 
> 3. Either has "unique" advantages
> 
> 4. Intellectual "property"
> 
> 5. The "gift model" no longer holds today
> 
> > Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
> > RSA-key PGP user base in free version 5.53, along with the web of
> > signatures built up over several years. Again--never mind; the Open PGP
> > working group must simply insure that that cannot happen again with Open
> > PGP.
> 
> 6. David, you are obviously from the S/MIME camp, and you keep
> fighting against PGP, even though I did not raise my voice for PGP
> vs. S/MIME. There is a misunderstanding to my open letter.

I am a user of both. I was one of the first users of PGP until I found it
infringed. I then mounted a campaign behind the scenes (I wasn't looking for
credit, and I wasn't the only one) with Bidzos to license RSA for PGP. In the
event, Phil's intransigence (see Garfinkel's book) got in the way for a very
long time, but this wasn't because of any lack of my efforts, Eric Hughes'
efforts, or the goodwill of Jim Bidzos (see Garfinkel). When MIT PGP came out
as street-legal I was one of the first users, and both Jeff Schiller and Derek
Atkins signed my key. I have also helped beta test various versions, including
two US/Canada ones and FileCrypt. I find each of PGP and
S/MIME-X509-Netscape/Explorer have their unique and non-substituable uses,
mainly revolving around distinctions between their trust models.

As for your claim that you weren't raising your voice for PGP, if you reread
your post perhaps you will see why I thought in places you were. Never
mind--it's not worth sidetracking a discussion of principles and objectives
for that.

> 
> 7. Either standards are not a reduction of choice and optionality, or
> you are against the standardization.

There are two distinct trust models and systems involved. Each has a
non-substitutable and important place. Thus two standards are appropriate and
a reductionist argument isn't. Such cases are common in standards work.
Eventually the marketplace may choose one over the other, or each may be
viable for its purpose. We're not writing the Decalogue here.

> 
> If yor S/MIME has the "user base" and is self sufficient in that, why
> are you seeking for the blessings of being called an Internet
> standard? It sounds to me as if you're arguing  It is probably an abuse > of the term "standard" not being an end in itself but a marketing tool.

Do you have a question about substance here rather than an accusation?

> 
> > > I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
> > > require ASN.1, X500 and other OSI stuff that  does not merge very well
> > > with  the rest of  the Internet infrastructure.
> >
> > Like the bumblebee, S/MIME is out there in millions (well over 25 million)
> > of installed base copies of Netscape and Explorer. Perhaps if there is a
> > problem with the "internet infrastructure" it is that which needs
> > adjustment.
> 
> What I meant by "infrastructure" is design and technology. The IETF
> has early enough opened itself up to OSI concepts and ASN.1. However,
> these keep to not really fit into the rest of the internet
> infrastructure. One good example is that X500 needed LDAP to be
> deployed within the Internet infrastructure.

Sounds like you're arguing for some combination of the status quo and the easy
way out.

> 
> > Thus far I've not heard of the Internet crashing down because
> > of the particular crypto protocols in, say, Netscape. There are far more
> 
> I am not talking about crashes -- these happened to me back in the
> times when I used "userbase" and "marketplace" software :-). I am
> talking about interoperability on an open an equal basis. I speak your
> language, you speak mine.

Esperanto has not caught on in the marketplace, and for good reason.

> most innovations have been achieved by governamntal funding and *not*
> on industry on a competitional basis.

That isn't accurate. "Some" would be more apt. But you weren't arguing for
that in any case, since government funding for the Internet is mostly over.
You were arguing for the free "gift" model rather than the intellectual
property model.

<more stuff on the big government R&D model omitted>

> 
>  There is not much to be
> theoretically developed in security today, all knowledge is there for
> more than ten years.

I leave that statement for readers to contemplate, with my jaw hanging down in amazement.

>The problem is deployment. Companies seem to be
> too involved with patent rights and marketing that they are unable to
> deploy knowledge and standards that do exist since many many
> years.

That's also one for the readers to consider. Hint--there are well over 25
million copies of complete mail/news/browser software packages deployed using
S/MIME, and more copies are downloaded by the day--at a massive rate
heretofore not seen.

> 
> 
> 2. Trust "algorithms"
> 
> PGP is already on its way towards trusted third parties. And it is
> useful. Conversely, I have heard S/MIME and SSL to be used without
> real TTPs, but with a locally base of certificates. You are right,
> both methods have its uses. But you are badly wrong in pointing out
> that both methods require mutually non-interoperable software.

I didn't say "require". I said each trust model would become corrupted if it
attempted to encompass the other.

> 
> 3. Either has "unique" advantages
> 
> see above. If they had, why not listing them and join all advantages
> into one standard? 

Perhaps I should have said "unique and mutually exclusive" to drive the point
home, though I thought I had done that with my examples. For instance it is
mutually exclusive to allow anyone to be a signer and to allow only those
meeting certain standards to be signers.

David

Date: Sun, 30 Nov 1997 23:41:54 +0100 (MET)
From: Gunther Schadow <[email-masked]>
To: [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Sorry for the massive cross-post, I just didn't know which e-mail list
David's reply came about...

> > I am  a member of a  EDI standards organization currently  preparing a
> > recommendation  for   their   members on  applying    Internet  E-Mail
> > standards.  Of course, security is a major issue here. Our observation
> > is that the  field is everything else than  clear while PGP and S/MIME
> > camps  are fighting each   other.

First I'll summarize your points:

> Actually, my perception is somewhat different. It is that S/MIME is
> simply going about its business, and has by far the most massively
> installed base on the Internet, in terms of both Netscape and
> Microsoft, as well as by far the broadest capital investment, in

1. The "userbase"

> terms of its consortium. I use both, think each has its place, and
> think the difference is in trust algorithms.  I believe each trust
> algorithm has important uses and neither should try to subsume the
> other because it will lose unique advantages for the things it is
> well suited.

2. Trust "algorithms"

3. Either has "unique" advantages

> My own observation is that most such conflicts (other than religious wars)
> stem from the unwillingness on the part of PGP fans to acknowledge that
> S/MIME involves intellectual property--a fact--which is entitled to a fair
> return. This is most odd, since PGP is also a commercial product which is
> sold in the marketplace.

4. Intellectual "property"

> There is also a deeper issue involved. The Internet was originally built
> with a significant component of the "gift" model. Software was free for the
> taking, and a rich uncle, the US taxpayer, provided for much that had to be
> paid for. This is no longer the case, and
> the Internet is well and truly a free-market commercial proposition
> although some users are subsidized to this day, mostly academics and
> students. It is exactly these users who seem most vociferous about "free".
> This is both inappropriate and maladaptive.

5. The "gift model" no longer holds today

> Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
> RSA-key PGP user base in free version 5.53, along with the web of
> signatures built up over several years. Again--never mind; the Open PGP
> working group must simply insure that that cannot happen again with Open
> PGP.

6. David, you are obviously from the S/MIME camp, and you keep
fighting against PGP, even though I did not raise my voice for PGP
vs. S/MIME. There is a misunderstanding to my open letter.

> > As  much as I am confident
> > in the IETF  to stick to its  former  policy propagating open,  freely
> > available, simple and effective standards, I am nevertheless concerned
> > that industry is  on the edge to do  a lot of harm in  that field.  It
> > seems already that the  "Internet Mail Consortium"  will have a strong
> > impact in  IETF   standardization, and  as  the   IMC is   an industry
> > consortium, is not committed to the IETF policy.
>
> One must face the reality of both existence and choice in the marketplace.

7. Either standards are not a reduction of choice and optionality, or
you are against the standardization. 

If yor S/MIME has the "user base" and is self sufficient in that, why
are you seeking for the blessings of being called an Internet
standard? It is probably an abuse of the term "standard" not being an
end in itself but a marketing tool.

> > I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
> > require ASN.1, X500 and other OSI stuff that  does not merge very well
> > with  the rest of  the Internet infrastructure.
>
> Like the bumblebee, S/MIME is out there in millions (well over 25 million)
> of installed base copies of Netscape and Explorer. Perhaps if there is a
> problem with the "internet infrastructure" it is that which needs
> adjustment.

What I meant by "infrastructure" is design and technology. The IETF
has early enough opened itself up to OSI concepts and ASN.1. However,
these keep to not really fit into the rest of the internet
infrastructure. One good example is that X500 needed LDAP to be
deployed within the Internet infrastructure. 

> Thus far I've not heard of the Internet crashing down because
> of the particular crypto protocols in, say, Netscape. There are far more

I am not talking about crashes -- these happened to me back in the
times when I used "userbase" and "marketplace" software :-). I am
talking about interoperability on an open an equal basis. I speak your
language, you speak mine. That is O.K. Any ideolect for the sake of
"intellectual property" (what a term after all!) is impeding
interoperability. You raised the points about RC2 elsewhere. And, was
it you, who used the term "fascist" for the people who claim that
internet standards be openly specified and freely useable from that
specification? (If it was not you, it was an other David -- but your
points where so similar)

> Actors are entitled to a return from their investment in intellectual
> property. In this case the ultimate beneficiary are the assignees of the
> inventors, e.g. MIT. You are appealing to a model here which has long been
> discredited as a basis for the stimulation and preservation of innovation..

Oops? I think I am hearing wrong. "A model which has long been
discredited as a basis for the stimulation and preservation of
innovation". Now tell me, who invented the Internet that Microsoft is
so proud of today (at last, once they became aware of it)? It was
developed at universities, funded by DARPA. This is why I think that
most innovations have been achieved by governamntal funding and *not*
on industry on a competitional basis. Think of the NASA for an other
example. But back to the internet. Tell me, who invented it? Industry
was in fact not really interested in it before some Physicists at CERN
(again a governmentally founded research organization) invented the
WWW. The industry discovered the WWW as a perfect marketing tool, and
helped spread the HTTP/TCP/IP as the most important informational
revolution since the Television. But did they add any technological
benefit to these protocols? Tell me? So how can you say that anything
else "discredits" itself as a basis for innovation? I have been
repeatedly frustrated by the intellectual poorness of software
industry, and I would long have quit informatics if there was not the
other side: inspiring researchers that live the freedom of speech and
intellectual sharing!

> It was RSADSI who, in effect, brought RSA and many other algorithms to the
> marketplace, including two used in PGP. Similarly, it was IDEA which also
> (as a commercial product via ASCOM AG) contributed to PGP. RSA Laboratories
> continues to be one source for much of the world's crypto research outside
> of government. That isn't an eelymosynary gift but must ultimately draw on

First of all it was not RSADSI. It was Rivest, Shamir and Adleman, who
worked at MIT founded by governmental grants (a fact that -- in your
voice -- should discredit the innovative nature of the RSA
algorithm). As much as five (5!) years later, the patent was
claimed. This patent was then sold to RSADSI. Since then, RSADSI
together with US crypto legislation and NSA is effectively fighting
against the wide spread use of security standards in the name of some
"intellectual property" (and anti-kommunist paranoia at the side of US
govt. and NSA). It is the scandal that the discovery of asymmetric
ciphers is only about 10 years olter than that of packet switched
networking. While the latter succeeded revolutionizing the
informational world, the world of security still suffers from the new
advocates of the "intellectual property" construct.

> payment for intellectual property. The notion that the Internet should use
> only free crypto is a guaranteed formula to kill such innovation except in
> the glacial corridors of academe, and force the successful commercial
> actors to "tunnel" rather than benefitting the entire net. And even those
> magisterial academic confines lead to things like RSA and RSADSI; to patent
> licensing and charging for intellectual property.

This is rubbish, and you know it. There is not much to be
theoretically developed in security today, all knowledge is there for
more than ten years. The problem is deployment. Companies seem to be
too involved with patent rights and marketing that they are unable to
deploy knowledge and standards that do exist since many many
years. This is the kind of "anti-innovative" behavior that is
discrediting the software industry as being oriented towards commerce,
profit at first, and not towards intellectual innovations, not even
towards their user's needs: as interoperability is one of the most
important user-need being sacrificed for the sake of "intellectual
property". 

> Of course if you want guaranteed old technology, don't use anything until
> the patent has expired.

Diffie-Hellman is luckily out of that margin. It is good old
technology!

> <MOSS discussion omitted>

that was in fact my main point. But you seem to love fighting against
PGP. So, here goes ...

> > Why don't they sit together, listing their
>
> I believe this would be a major blunder.

Boy, can you explain me how in the world reconciliation can ever be a
blunder? The "world of difference" is speaking here.

I would stop here, did I not start with listing your arguments in a
few points.

1. The "userbase"

The userbase that you cite comes easily by having Netscape and
Microsoft select S/MIME. But don't ask how many S/MIME installations
do exist, but how many of them are actually *used*. I'd be interested
in a good statistics that compares actual *users* not posessors of
S/MIME vs. PGP software.

2. Trust "algorithms"

PGP is already on its way towards trusted third parties. And it is
useful. Conversely, I have heard S/MIME and SSL to be used without
real TTPs, but with a locally base of certificates. You are right,
both methods have its uses. But you are badly wrong in pointing out
that both methods require mutually non-interoperable software.

The interesting point is that the only real algorithmical difference
between traditional PGP vs. RSADSI was the use of IDEA vs. RC4. MOSS
-- here I am at my point -- shows clearly how easy it is to just use
these algorithms at will in a modular and interoperable way. They are
both so similar and the differences are so ridiculously unimportant
that it is a scandal that there is no common open Internet security
standard yet.

3. Either has "unique" advantages

see above. If they had, why not listing them and join all advantages
into one standard? It is blunder? It is the only intellectual work
that is missing in the field. See how the world suffers from commerce
which is obviously unable to bring this little reconciliation while
loosing the slight "difference" which they are all so proud of.

4. Intellectual "property"

It is a term that has to be discussed. But not now. The interesting
point is to study the intellectual revolution that spread from the
invention of Gutenberg's technology to spread ideas and compare it
with the recently raised issue of "property". Ridicoulous if Einstein,
Heisenberg, Zuse, Watson, or whoever you name, had insist on their
"intellectual property".

5. The "gift model" no longer holds today

I showed you the opposit above. Again tell me, who invented the
internet and what did "the industry" do about it?

6. David, you are obviously from the S/MIME camp, and you keep
fighting against PGP, even though I did not raise my voice for PGP
vs. S/MIME. There is a misunderstanding to my open letter.

My claim was to preach reconciliation on an open basis. I am sorry for
this thread to fall into a flamewar.

regards
-Gunther

Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany
Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin.
[email-masked]               http://userpage.fu-berlin.de/~gusw
----------------------------------#include <usual/disclaimer>-----------

Date: Sun, 30 Nov 1997 12:47:12 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: Gunther Schadow <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Sender: [email-masked]

Gunther Schadow wrote:

> TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY.
>
> I am  a member of a  EDI standards organization currently  preparing a
> recommendation  for   their   members on  applying    Internet  E-Mail
> standards.  Of course, security is a major issue here. Our observation
> is that the  field is everything else than  clear while PGP and S/MIME
> camps  are fighting each   other.

Actually, my perception is somewhat different. It is that S/MIME is simply
going
about its business, and has by far the most massively installed base on the
Internet,
in terms of both Netscape and Microsoft, as well as by far the broadest
capital
investment, in terms of its consortium. I use both, think each has its
place, and think
the difference is in trust algorithms. I believe each trust algorithm has
important
uses and neither should try to subsume the other because it will lose
unique advantages for the things it is well suited.

My own observation is that most such conflicts (other than religious wars)
stem from the unwillingness on the part of PGP fans to acknowledge that
S/MIME involves intellectual property--a fact--which is entitled to a fair
return. This is most odd, since PGP is also a commercial product which is
sold in the marketplace.

There is also a deeper issue involved. The Internet was originally built
with a significant component of the "gift" model. Software was free for the
taking, and a rich uncle, the US taxpayer, provided for much that had to be
paid for. This is no longer the case, and
the Internet is well and truly a free-market commercial proposition
although some users are subsidized to this day, mostly academics and
students. It is exactly these users who seem most vociferous about "free".
This is both inappropriate and maladaptive.

As I understand it, the real Internet policy about intellectual property is
NOT "unencumbered" but rather  something like "'freely available on
non-discriminatory--or perhaps "reasonable"--terms"'. Internet policy is
supposed to be (if my understanding is correct) "intellectual property
neutral" and not hostile to intellectual property. If that is correct, much
recent pressure on RSADSI with respect to S/MIME was from a few small
actors with loud voices throwing their Internet weight around. Never
mind--we now have an S/MIME 3 working group with certain ground rules and
that's where we're proceeding from.

Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge
RSA-key PGP user base in free version 5.53, along with the web of
signatures built up over several years. Again--never mind; the Open PGP
working group must simply insure that that cannot happen again with Open
PGP.

> Unfortunately, marketing  interests
> seem to play the major role  in that fight.

I have observed this entirely as: 1. Attempts to restrict S/MIME
intellectual property and disadvantage RSADSI and 2. Attempts to tilt the
playing field to the advantage of PGP Inc.  by taking advantage of the fact
that originally PGP had little intellectual property of its own but used
the intellectual property of others and some of that intellectual property
of others has now come off patent protection. 3. Attempts to make wrong the
actions of RSADSI in protecting their intellectual property and pursuing
their legal right to insure that licensees honor their agreements. From my
perspective it has looked like a crooked dice game. When the above is
brought to attention, we often see ad hominem responses indicative of the
weaknesses of those proponents' intellectual positions.

> As  much as I am confident
> in the IETF  to stick to its  former  policy propagating open,  freely
> available, simple and effective standards, I am nevertheless concerned
> that industry is  on the edge to do  a lot of harm in  that field.  It
> seems already that the  "Internet Mail Consortium"  will have a strong
> impact in  IETF   standardization, and  as  the   IMC is   an industry
> consortium, is not committed to the IETF policy.

One must face the reality of both existence and choice in the marketplace.
The IMC represents successful actors in that marketplace. Some of the
smaller ones support PGP but the most successful support S/MIME. The
largest supporter of PGP in that group is Qualcomm and if you strip out
their non-crypto business they are relatively small. Thus complaints about
the IMC read like more pro-PGP partisanship. The facts are that Ford, GM,
and Toyota make the cars, not MIT or DeLorean, and any realistic standard
has to take account of what is out there in the marketplace. An attempt to
impose the desires of a small self-appointed elite is doomed to fail under
the current massively public Internet model.

> I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
> require ASN.1, X500 and other OSI stuff that  does not merge very well
> with  the rest of  the Internet infrastructure.

Like the bumblebee, S/MIME is out there in millions (well over 25 million)
of installed base copies of Netscape and Explorer. Perhaps if there is a
problem with the "internet infrastructure" it is that which needs
adjustment. Thus far I've not heard of the Internet crashing down because
of the particular crypto protocols in, say, Netscape. There are far more
serious threats to worry about. My fear of S/MIME creating problems for
"the rest of the internet infrastructure" is 47th on my list of fears, just
below the fear of aliens taking over my computer. I do not mean to make
light of your concerns, but given the huge installed base of S/MIME
applications out there now, some acknowledgement of the realities of the
marketplace is in order.

> Of  course the use of
> patent encumbered algorithms is  a deleterious "feature" of S/MIME  --
> this also shows whose only real interest

Here you move from a laudable discussion of principles and objectives to
the imputation of motives and make-wrong. It does not add to the
discussion.

> it is to  have S/MIME. It is
> not common sense, it is the profit  of one company: RSA Data Security,
> Inc.

Actors are entitled to a return from their investment in intellectual
property. In this case the ultimate beneficiary are the assignees of the
inventors, e.g. MIT. You are appealing to a model here which has long been
discredited as a basis for the stimulation and preservation of innovation..
It was RSADSI who, in effect, brought RSA and many other algorithms to the
marketplace, including two used in PGP. Similarly, it was IDEA which also
(as a commercial product via ASCOM AG) contributed to PGP. RSA Laboratories
continues to be one source for much of the world's crypto research outside
of government. That isn't an eelymosynary gift but must ultimately draw on
payment for intellectual property. The notion that the Internet should use
only free crypto is a guaranteed formula to kill such innovation except in
the glacial corridors of academe, and force the successful commercial
actors to "tunnel" rather than benefitting the entire net. And even those
magisterial academic confines lead to things like RSA and RSADSI; to patent
licensing and charging for intellectual property.

Of course if you want guaranteed old technology, don't use anything until
the patent has expired.

<Microsoft bogeyman analogy omitted>

> On the other hand PGP  is doing  a  definite cut  in its tradition  in
> order to move  away from  patent  encumbered algorithms. However,  PGP
> uses an ad-hoc binary format as  well. Even though  it is simpler than
> ASN.1/DER,   it is still unnecessarily  obscure,  when  applied in the
> world of MIME.

You seem to forget that although PGP would like its royalty costs to be
"free", it charges for its commercial products. One cannot make a case here
for anything other than self-interest. It is true that PGP gives away
crippled non-commercial versions that won't affect what it sees as its self
interest. RSADSI gives away RSAREF and RSAREF2 as well, so that one is a
wash.

<MOSS discussion omitted>

> Anyway, what I refuse to accept is that the two camps (PGP and S/MIME)
> do not try to collaborate.

The two working groups are, as I understand it, under instructions to
collaborate when areas of commonality are involved. What is more, MIME
provides an overarching structure that could bring both under at least a
common "envelope" structure if desired. Let us hope such cooperation is
more than grudging lip service.

> Why don't they sit together, listing their
> features in an abstract manner, independent from any format like ASN.1
> or PGP's  or any technology  like X509?  These feature-lists  could be
> merged, in order to  come up with  an abstract security  specification
> that includes both approaches.

I believe this would be a major blunder. The advantages of web of trust are
that anyone may be his own certifier, with whatever rules he wishes to make
and perhaps publish. The advantages of rigid-heirarchical are that nobody
but audited, known-standard certifiers with particular published rule-sets
are valid. The first is extremely useful among small, mutually known groups
in which members are willing to investigate each certifier's standards. The
second is essential for arms-length and commercial interaction in which
users must rely on standardized, known, supervised assurances with respect
to trust procedures and cannot personally investigate each certifier.

Trying to make either model do the job of the other will corrupt it such
that it will lose some of its own advantages. I note that most action in
this direction is with respect to PGP trying to get some of S/MIME's
"market share". I think this to be a very bad idea. In the end, unless
there are versions of PGP software which will, hard-wired, accept only
rigid-heirarchical trust, this will corrupt both trust models with respect
to PGP.

What I am saying is that although much focus has been on particular
algorithms in the past, the "openness" of Open PGP reveals that this is
really a distraction (fundamental principle-wise), and the real crux of the
matter is trust models.

> This abstract specification could then
> be mapped to concrete technologies, whether  MIME (=> MOSS), ASN.1 (=>
> PKCS) or the PGP-style.  Conversion software could be used as gateways
> between these protocols.
>
> If this where done,  the IMC or any other  involved party  could show,
> whether their work  in the IETF is  for the sake  of the community  or
> just  for their own  market share.

Again a specious dichotomy is being set up between "the sake of the
community" and "commercial viability". The two are inextricably
intertwined.

> Get back  to common sense, now! Get
> the Internet back into people's hands!

"Power to me and my friends!" uh, er, um, oops, "Power to the People!"

David

Date: Sun, 30 Nov 1997 09:11:57 -0500
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Steve Crocker <[email-masked]> (by way of Steve Crocker <[email-masked]>)
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use  MOSS?
Cc: [email-masked]
Sender: [email-masked]

[This is a resend of my previous message with corrected addresses for Jim
Galvin and the ietf-open-pgp working group.  Please discard my previous
message.]

Gunther,

Thanks for your kind words about MOSS.

Let me offer a bit of perspectrive about MOSS in relation to S/MIME.  MOSS
was designed to take full advantage of MIME.  It uses the MIME facilities
for hnadling multiple parts and for encoding binary information.  Although
MIME is enormously successful, it does have some technical wrinkles that
complicated the design of MOSS and make the resulting design less elegant
than we would have liked.  I'm referring specifically to MIME's requirement
that everything be encoded in a 7bit format and that the encoding be only
in the atomic parts of the structure.

Meanwhile, S/MIME adherents usually take the position that MOSS cannot be
implemented easily unless one has a complete MIME implementation already.
S/MIME, on the other hand, is designed to make maximum use of PKCS formats.
 It implements enough MIME to be compatible with MIME format, but doesn't
use MIME mechanisms internally.

Let me also comment on one technical detail.  You suggest that messages in
the MOSS forat could be transliterated easily into other formats.  While it
is true that the text and structure of a MOSS message could be
transliterated into other formats, signatures are specific to the precise
encoding of a message and cannot be transliterated.

At the time MOSS was designed, PGP was not compatible with MIME and there
was no clear path for bringing PGP into the standards arena.  That's since
changed.

Steve

Date: Sun, 30 Nov 1997 08:56:41 -0500
To: Gunther Schadow <[email-masked]>
From: Steve Crocker <[email-masked]>
Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Gunther,

Thanks for your kind words about MOSS.

Let me offer a bit of perspectrive about MOSS in relation to S/MIME.  MOSS
was designed to take full advantage of MIME.  It uses the MIME facilities
for hnadling multiple parts and for encoding binary information.  Although
MIME is enormously successful, it does have some technical wrinkles that
complicated the design of MOSS and make the resulting design less elegant
than we would have liked.  I'm referring specifically to MIME's requirement
that everything be encoded in a 7bit format and that the encoding be only
in the atomic parts of the structure.

Meanwhile, S/MIME adherents usually take the position that MOSS cannot be
implemented easily unless one has a complete MIME implementation already.
S/MIME, on the other hand, is designed to make maximum use of PKCS formats.
 It implements enough MIME to be compatible with MIME format, but doesn't
use MIME mechanisms internally.

Let me also comment on one technical detail.  You suggest that messages in
the MOSS forat could be transliterated easily into other formats.  While it
is true that the text and structure of a MOSS message could be
transliterated into other formats, signatures are specific to the precise
encoding of a message and cannot be transliterated.

At the time MOSS was designed, PGP was not compatible with MIME and there
was no clear path for bringing PGP into the standards arena.  That's since
changed.

Steve

----------------------------------
Steve Crocker                                   Desk:  +1 703 716 5214
CyberCash, Inc.                                 Main:  +1 703 620 4200
2100 Reston Parkway                             Fax:   +1 703 620 4215
Reston, VA 20191                                [email-masked]

Date: Sun, 30 Nov 1997 14:39:03 +0100 (MET)
From: Gunther Schadow <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY.

I am  a member of a  EDI standards organization currently  preparing a
recommendation  for   their   members on  applying    Internet  E-Mail
standards.  Of course, security is a major issue here. Our observation
is that the  field is everything else than  clear while PGP and S/MIME
camps  are fighting each   other.  Unfortunately, marketing  interests
seem to play the major role  in that fight. As  much as I am confident
in the IETF  to stick to its  former  policy propagating open,  freely
available, simple and effective standards, I am nevertheless concerned
that industry is  on the edge to do  a lot of harm in  that field.  It
seems already that the  "Internet Mail Consortium"  will have a strong
impact in  IETF   standardization, and  as  the   IMC is   an industry
consortium, is not committed to the IETF policy.

I   have a strong  personal distaste  with S/MIME,   as the PKCS specs
require ASN.1, X500 and other OSI stuff that  does not merge very well
with  the rest of  the Internet infrastructure.  Of  course the use of
patent encumbered algorithms is  a deleterious "feature" of S/MIME  --
this also shows whose only real interest  it is to  have S/MIME. It is
not common sense, it is the profit  of one company: RSA Data Security,
Inc.  The other  industry that present  itself as deciples of RSA D.S.
Inc.  is  there to serve as distributors  of patent license royalties.
This is a very similar marketing strategy as  we all know far too much
from Bill Gates. Do  you really want  such attitudes to  influence the
Internet?

On the other hand PGP  is doing  a  definite cut  in its tradition  in
order to move  away from  patent  encumbered algorithms. However,  PGP
uses an ad-hoc binary format as  well. Even though  it is simpler than
ASN.1/DER,   it is still unnecessarily  obscure,  when  applied in the
world of MIME. 

Unfortunately, the MOSS  specification   RFC1848 seems to   have  been
forgotten. MOSS beats both S/MIME  and PGP in terms  of being open and
straight forward. It fits  very well into the MIME  world and does not
require any other technology than MIME. And  most important, it is not
engaged  in any way  to a  certain set of    algorithms.  MOSS can  be
translated from and  to S/MIME as well as  traditional or Open PGP. It
transcends the specifics of any of these technology.

I really   much like to  see MOSS  having   a future in   the Internet
community. I would myself write a concise implementation of a flexible
multi-algorithm   MOSS that would be   freely available.  And I think,
others would do so as well. 

Anyway, what I refuse to accept is that the two camps (PGP and S/MIME)
do not try to collaborate.  Why don't they sit together, listing their
features in an abstract manner, independent from any format like ASN.1
or PGP's  or any technology  like X509?  These feature-lists  could be
merged, in order to  come up with  an abstract security  specification
that includes both approaches.  This abstract specification could then
be mapped to concrete technologies, whether  MIME (=> MOSS), ASN.1 (=>
PKCS) or the PGP-style.  Conversion software could be used as gateways
between these protocols.

If this where done,  the IMC or any other  involved party  could show,
whether their work  in the IETF is  for the sake  of the community  or
just  for their own  market share. Get back  to common sense, now! Get
the Internet back into people's hands!

regards
-Gunther

Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany
Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin.
[email-masked]               http://userpage.fu-berlin.de/~gusw
----------------------------------#include <usual/disclaimer>-----------

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Entrust OID registry?
Date: Wed, 26 Nov 1997 14:35:24 -0500
Sender: [email-masked]

Hi David,

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Wednesday, November 26, 1997 1:11 PM
>To: 	[email-masked]
>Subject: 	Entrust OID registry?
>
>
>The document http://www.imc.org/ietf-smime/oids.html (Note to Paul: it is
>not referenced from the ietf-smime page) contains the following
>Algorithm Identifiers:
>
>    cast3CBC OBJECT IDENTIFIER ::=
>        {1 2 840 113533 7 66 3}
>    cast5CBC OBJECT IDENTIFIER ::=
>        {1 2 840 113533 7 66 10}
>
>
>Whereas the OID registry at
>http://domen.uninett.no/~hta/ietf/oid/1.2.840.html
>contains registrations for "1.2.840.113553 - Nortel US", under which appears
>"1.2.840.113553.7.66 - Secure Networks Algorithms".

This one is incorrect:  the fourth number should be "113533".

>Neither www.nortel.com nor www.entrust.com seem to have an OID registry
>which could verify which of these entries has the typo.  So,
>
>  1) Anyone know where to get the list of organizations under 1.2.840?
>
>  2) Anyone know which is the correct OID for Nortel/Entrust?
>
>  3) Anyone know if Entrust has published the OID's under it's control
>       including the AlgorithmIdentifier parameter syntax for CAST5 ?

The details for CAST5 can be found in Section 2.6 of RFC 2144.  I'm
actually not sure off-hand which other OIDs we've published, but I can
find out if you want...

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

From: Scott Hollenbeck <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: ESS-00 ContentHints Attribute
Date: Wed, 26 Nov 1997 10:40:18 PST
Sender: [email-masked]

Russ,

I don't believe there's any advantage to having unauthenticated
ContentHints.  My original receipt processing proposal said this:

"The contentHints attribute must only be used as an authenticated
message attribute."

That being the case, I suggest we change ESS-00 to reflect that
contentHints must be authenticated.  However, I also like your
idea of renaming the arc -- there are other attributes that need
to be added, and they don't all allegedly need to be authenticated.

Scott

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Wednesday, November 26, 1997 10:58 AM
To:	Scott Hollenbeck
Cc:	[email-masked]
Subject:	Re: ESS-00 ContentHints Attribute

What advantage is there to putting ContentHints in the unauthenticated
attributes?

If it us an issue, I can change the name of the OID Arc so that it is
attributes (authenticated and unauthenticated) without changing the numbers.

Russ

At 05:10 AM 11/26/97 PST, Scott Hollenbeck wrote:
>Section 1.3.4 of the 18 November ESS-00 documents says that
>a contentHints attribute has a "MUST BE authenticated" value
>of "no".  However, the OID registry found at
>
>http://www.imc.org/ietf-smime/oids.html
>
>Lists the id-aa-contentHint attribute under the authenticated
>attributes arc.  In my mind, this implies that the attribute
>must be authenticated if present.  Should the attribute
>always be authenticated (thus requiring a change to ESS-00),
>or should we add an arc for attributes that can be either
>authenticated or not?

Date: Wed, 26 Nov 1997 10:31:44 -0800
To: [email-masked] (David P. Kemp), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Entrust OID registry?
Sender: [email-masked]

At 01:11 PM 11/26/97 -0500, David P. Kemp wrote:
>
>The document http://www.imc.org/ietf-smime/oids.html (Note to Paul: it is
>not referenced from the ietf-smime page)

Noted, and soon to be fixed, thanks!

>contains the following
>Algorithm Identifiers:
>
>    cast3CBC OBJECT IDENTIFIER ::=
>        {1 2 840 113533 7 66 3}
>    cast5CBC OBJECT IDENTIFIER ::=
>        {1 2 840 113533 7 66 10}

Which were put there at the request of an Entrust employee. I, too, would
like to know if this person was right...

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 26 Nov 1997 13:11:55 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Entrust OID registry?
Sender: [email-masked]

The document http://www.imc.org/ietf-smime/oids.html (Note to Paul: it is
not referenced from the ietf-smime page) contains the following
Algorithm Identifiers:

    cast3CBC OBJECT IDENTIFIER ::=
        {1 2 840 113533 7 66 3}
    cast5CBC OBJECT IDENTIFIER ::=
        {1 2 840 113533 7 66 10}

Whereas the OID registry at http://domen.uninett.no/~hta/ietf/oid/1.2.840.html
contains registrations for "1.2.840.113553 - Nortel US", under which appears
"1.2.840.113553.7.66 - Secure Networks Algorithms".

Neither www.nortel.com nor www.entrust.com seem to have an OID registry
which could verify which of these entries has the typo.  So,

  1) Anyone know where to get the list of organizations under 1.2.840?

  2) Anyone know which is the correct OID for Nortel/Entrust?

  3) Anyone know if Entrust has published the OID's under it's control
       including the AlgorithmIdentifier parameter syntax for CAST5 ?

Date: Wed, 26 Nov 1997 12:44:05 -0500 (EST)
From: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
Subject: Re: PGP evolving, improving
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>Peterson is quite mistaken in his post below.
(who  8*)

>Free PGP had used RSAREF (for RSA), a software package made available free 
by RSADSI for anyone's non-commercial use. No patent issues, fees, or 
litigation are involved. This is TOTALLY clear, not "not exactly clear" 
as Peterson claims.  There is no "may be exempt" about those versions of 
free PGP. Thay are, in fact, fully licensed for non-commercial use of RSA.  
He should read the RSAREF license.

May have changed but when it first came out I looked into the RSAREF and 
was rather astounded by the wording of the "free" license agreement - looked
like something Microsoft might have written. Wasn't even something the I,
as a hobbyist, would sign since the restrictions seemed to outlive the 
patent.

Not going into the fact that you missed my point entirely since it is more
properly directed at PGP Inc. - Is there something in the license you have
with RSA for the commercial product that limits what you can put into a 
"free" version without paying RSA a fee ? If that is "no" then I too will
ask why the free version should not contain the older mechanisms for 
compatability. (I use the commercial version so do not know if it does or
does not).
					Warmly,
						Padgett

Date: Wed, 26 Nov 1997 08:57:59 -0800
From: David Sternlight <[email-masked]>
Reply-To: [email-masked]
Organization: DSI/USCRPAC/IER
To: "A. Padgett Peterson P.E. Information Security" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: PGP evolving, improving
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------msF9FDBF5E9A87FDB35AAF7313
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit

(This message is being copied to the S/MIME list only for the matter in the last
paragraph of my response. Readers of the S/MIME list are requested to ignore the
matter that is PGP-specific).

Peterson is quite mistaken in his post below.

Free PGP had used RSAREF (for RSA), a software package made available free by
RSADSI for anyone's non-commercial use. No patent issues, fees, or litigation are
involved. This is TOTALLY clear, not "not exactly clear" as Peterson claims.  There
is no "may be exempt" about those versions of free PGP. Thay are, in fact, fully
licensed for non-commercial use of RSA.  He should read the RSAREF license.

The usage has nothing to do with Viacrypt, mergers, or anything else of the sort.
It was that package, used in MIT PGP 2.x, (as well as the use of RSA overseas) that
produced the huge RSA key base that made PGP's reputation and which they wave in
front of the IETF to legitimiize themselves,. That PGP Inc. dropped RSA key
generation in Free PGP 5.0 (while continuing to use RSAREF--so it was a completely
gratuitous act), and then in Free 5.52 completely disabled any RSA compatibility
with that huge user base, is, I assert, unconscionable. SInce they have done that,
leaving aside the 'biting the hand that feeds one' aspect, the IETF should not
credit any PGP Inc. user base claims involving number of holders of RSA PGP keys.
This leaves PGP as a minuscule segment of the market compared with, for example,
the installed base of S/MIME applications (well over 25 million) from Netscape and
Microsoft. Any IETF standards activities must take account of that physical reality
in the marketplace.

Of more technical importance, this group should insure that this cannot happen
again. "Open" anything should not be designed so that an entire user base of keys
and certificates resulting from the standard will later become obsolete just
because a post-release algorithm is later added to the standard or an existing
algorithm in the release is "improved".

PGP Inc., having proven (in my view) their untrustworthiness on this point, should
not be allowed any configuration influence at all with an Open PGP standard, and
the IETF should insure that no control or influence of any kind over intellectual
property can be exercised on Open PGP by PGP Inc. I make this point not as a
general principle (since "non-discriminatory access on equitable terms" is the IETF
policy mantra despite the attempts of some to go beyond that in the case of
S/MIME), but rather because of PGP  Inc's specific behavior in obsoleting this
entire user base of PGP RSA keyholders in their latest versions of Free PGP..

Finally, a related point. If the pace of the Open PGP standards group is anything
like the past history of voluntary PGP efforts (or maybe voluntary anything
efforts), by the time the standard is done the RSA patent will have expired (or
close enought not to make much difference to reasonable market penetration rates).
It seems to me a realistic view of that eventuality and of realistic project
scheduling might be useful in avoiding much of the to and fro fussing on this topic
as well as totally avoiding all the noise about PGP Inc. vs. RSADSI. So to do would
have the advantage that one resultant IETF standard (Open PGP) could be designed to
be equally available to commercial users while using as "musts" two widely-trusted
algorithms, RSA and TDES.

If that thinking were accepted, the focus, as between the Open PGP standard and the
S/MIME 3 standard, can become what at least this writer thinks it ought to be--one
standard for web of trust and another for rigid heirarchical certification. This
would insure the (security) purity of each model, its use for the things it is most
suited for, and avoid any attempt to corrupt either (to try to emulate the other
and get some of its market share). To do otherwise would lose some of either the
free-form character of web of trust, or the exclusionary assurance character of
rigid heirarchical. (By "exclusionary" I mean that every certifier must fall within
the overall tree structure and to do so must meet specified, audited standards for
certification operations assured from the top down, as an "if and only if"
condition.)

David

A. Padgett Peterson P.E. Information Security wrote:

> Note: this is really politics and not RFC business - my apologies but something
>       of a sore point.
>
> David rote:
>
> >And free PGP users didn't deserve an eased upgrade path, but rather to forcibly
> >obsolete all their keys, signatures and web of trust in the new version?
> >Especially since the RSA-key Free PGP user base is where PGP Inc. made their
> >reputation and the size of that base is constantly cited to the IETF and in
> >press releases as PGP's "customer base". Don't be ridiculous. And watch who you
> >throw stones at--can you say "glass house"?
>
> Am surprised at this posting as it seems to forget one major problem: RSA is
> patented. I have been told repeatedly by PGP that one of the reasons they do
> not offer a site license (nor a real personal license for that matter in the
> sense of being authorized to operate on all solely-used computers) is a
> requirement by RSA for a "per CPU" fee.
>
> True, the "free" version may be exempt under the terms of the patent but
> this has never been exactly clear. Do suspect that when PGP and Viacrypt
> did their inverse triangular multibuyout which resulted in a common point
> for both free and commercial versions that some of the clauses of the RSA
> license began covering PGP Inc and thus the "free" version as well (do you
> realize that there are fifty thousand lawyers in Florida alone ?  Twice as
> many Southern Bell yellow pages of attorneys as doctors and churches
> combined ?)
>
> Would be nice if RSA put the mechanism into the public domain but since they
> reniged on the S/MIME components, I have doubts that this will happen.
>
> Sounds like an opportunity for some programmer to create a "front end" to
> determine which is being used and to invoke the correct version but this is
> the reason that RSA (or any proprietary mechanism) should *never* be a MUST.
>
>                                                 Warmly,
>                                                         Padgett

--------------msF9FDBF5E9A87FDB35AAF7313
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------msF9FDBF5E9A87FDB35AAF7313--

Date: Wed, 26 Nov 1997 10:58:20 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: ESS-00 ContentHints Attribute
Cc: [email-masked]
Sender: [email-masked]

What advantage is there to putting ContentHints in the unauthenticated
attributes?

If it us an issue, I can change the name of the OID Arc so that it is
attributes (authenticated and unauthenticated) without changing the numbers.

Russ

At 05:10 AM 11/26/97 PST, Scott Hollenbeck wrote:
>Section 1.3.4 of the 18 November ESS-00 documents says that
>a contentHints attribute has a "MUST BE authenticated" value
>of "no".  However, the OID registry found at
>
>http://www.imc.org/ietf-smime/oids.html
>
>Lists the id-aa-contentHint attribute under the authenticated
>attributes arc.  In my mind, this implies that the attribute
>must be authenticated if present.  Should the attribute
>always be authenticated (thus requiring a change to ESS-00),
>or should we add an arc for attributes that can be either
>authenticated or not?
>
>----->
>Scott Hollenbeck (mailto: [email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>
>

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-00 ContentHints Attribute
Date: Wed, 26 Nov 1997 05:10:51 PST
Sender: [email-masked]

Section 1.3.4 of the 18 November ESS-00 documents says that
a contentHints attribute has a "MUST BE authenticated" value
of "no".  However, the OID registry found at

http://www.imc.org/ietf-smime/oids.html

Lists the id-aa-contentHint attribute under the authenticated
attributes arc.  In my mind, this implies that the attribute
must be authenticated if present.  Should the attribute
always be authenticated (thus requiring a change to ESS-00),
or should we add an arc for attributes that can be either
authenticated or not?

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

Date: Mon, 24 Nov 1997 21:45:49 -0500 (EST)
From: Tony Mione <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
cc: Tony Mione <[email-masked]>
Subject: PGP Implementor's survey
Sender: [email-masked]

PGP Implementor's survey

	The IETF OpenPGP Working Group is currently formalizing message
certificate formats used by PGP. As part of this effort, we are trying to
find out what implementations exist of various pgp-based products and
tools.

	This survey is designed to gather that information. We ask that you
take time to fill out and return this survey if you fall into one of the
following catagories:

	- You have written a pgp-based tool or an implementation of pgp
	- You are in the process of writing one of the above
	- You are planning to write one of the above

	If you are only in the planning stages (or very early in the
development stage), answer the questions as though in the future tense
"What platforms do you plan to support?", "Will it be compatible with
2.6.x?", etc.

	Please answer the following questions as completely as possible.
When completed, email back to [email-masked] or print the form,
fill it out and FAX it to Antonino Mione at +1 (732)-445-2968.

	Thanks for your help.

						Antonino N. Mione

						[email-masked]

----- BEGIN PGP SURVEY FORM -----

			PGP Implementation Survey

Identification of the Package and Legal Issues
----------------------------------------------

 1) Name of Package: ______________________________________________________

 2) Contact Name:__________________________________________________________

            Phone #:_______________________________________________________

	    Email Address:_________________________________________________

 3) Is the software a commercial product, shareware, freeware, other?

        ___________________________________________________________________

 4) How can one obtain it (URL, anonymous ftp, prepaid ftp retrieval, etc)?

        ___________________________________________________________________

        ___________________________________________________________________

        ___________________________________________________________________

General Characteristics of the Package
--------------------------------------

5) On which platform(s) does it run?
	__ Windows 3.1.x
	__ Windows 95
	__ Windows NT
	__ MS-DOS
	__ Mac/OS (7.5, 8.0, etc)
	__ Unix (list flavors) : __________________________________________

			___________________________________________________
	__ Amiga
	__ MVS
	__ OpenVMS
	__ Handheld/embeded devices : _____________________________________
	__ Other(s) : _____________________________________________________

 6) Is source distributed or available? ___________________________________

 7) What type of product is this (check all that apply)?

	__ Full PGP application?
	__ Email plug-in (i.e. Eudora)?
	__ Browser plug-in (i.e. Netscape)?
	__ Programming API
		__ C, C++
		__ Perl
		__ Other

 8) Does it support PGP 2.6.x compatibility? ______________________________

	Exceptions? : _____________________________________________________

 9) Does it support PGP 5.x compatibility? ________________________________

	Exceptions? : _____________________________________________________

10) With what other PGP-Based implementations or products (that you know of)
	does it interoperate? 

        ___________________________________________________________________

        ___________________________________________________________________

        ___________________________________________________________________

Technical Characteristics of the Package
----------------------------------------

11) Which Symmetric Encryption algorithms does it support?
	__ DES
	__ 3-DES
	__ CAST
	__ IDEA
	__ Blowfish
	__ SAFER
	__ Others : _______________________________________________________

12) Which Public Key Encryption algorithms does it support?
	__ RSA
	__ ElGammal
	__ D/H
	__ Elliptic Curve
	__ Others : _______________________________________________________

13) Which Message Digest algorithms does it support?
	__ MD4
	__ MD5
	__ SHA-1
	__ Tiger
	__ RIPEMD-160
	__ Others : ______________________________________________________

14) Which Signature algorithms does it support?
	__ RSA
	__ DSS
	__ Others : ______________________________________________________

15) Which email armoring algorithms does it support?
	__ RADIX-64 ASCII Armor
	__ Mime
	__ UUENCODE/UUDECODE
	__ Others : _______________________________________________________

16) Besides standard PGP message formats, does it support any additional
	certificate formats? If so, which ones?
	__ X.509
	__ PKIX
	__ Others :  ______________________________________________________

Thanks again!

----- END PGP SURVEY FORM -----

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B  0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report   ***** Important: John 17:3 *****

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-msg-00.txt
Date: Sat, 22 Nov 1997 12:51:06 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Message Specification
	Author(s)	: 
	Filename	: draft-ietf-smime-msg-00.txt
	Pages		: 24
	Date		: 21-Nov-97
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
 
S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.
 
Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-msg-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-msg-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-msg-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-msg-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-msg-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cert-00.txt
Date: Sat, 22 Nov 1997 12:50:40 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-00.txt
	Pages		: 13
	Date		: 21-Nov-97
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an
S/MIME agent needs to certify that the key is valid. This draft
describes the mechanisms S/MIME uses to create and validate keys using
certificates.
 
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG].
 
In order to handle S/MIME certificates, an agent has to follow
specifications in this draft, as well as some of the specifications
listed in the following documents:
 - ''PKCS #1: RSA Encryption'', [PKCS-1].
 - ''Cryptographic Message Syntax'', [CMS].
 - ''PKCS #10: Certification Request Syntax'', [PKCS-10].

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cert-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cert-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cert-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cert-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cert-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 21 Nov 1997 11:44:36 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Comments to 11/18/97 ESS
Sender: [email-masked]

All,

IMHO, Paul has done a miraculous job of sifting through the millions of
e-mail messages regarding the last version of ESS to produce the 11/18/97
ESS.  I have a few comments:

1) Sec 1.3.4, table:  The implication of the table of attributes is that
"authentication is optional" for the counterSignature attribute.  PKCS #9
states that the counterSignature attribute MUST NOT BE authenticated.
Please add the following text immediately after the table: "If a
counterSignature attribute is present, then it MUST BE included in the
unauthenticated attributes.  It MUST NOT BE included in the authenticated
attributes."

2) Sec 2, intro, 1rst para: Please change: "Returning a signed receipt
provides proof of delivery to the originator of
a message and allows the originator to demonstrate to a third party that the
recipient received the message." to "Returning a signed receipt provides
proof of delivery to the originator of a message and allows the originator
to demonstrate to a third party that the recipient was able to verify the
signature of the original message."

3) Sec 2.2, intro para: Please add: "A ReceiptRequest attribute MUST NOT be
included in the attributes of a SignerInfo in a SignedData object that
encapsulates a Receipt content.  In other words, the user agent MUST NOT
request a signed receipt for a signed receipt."

4) Sec 2.2, intro para: Please add: "A MLExpansionHistory attribute MUST NOT
be included in the attributes of a SignerInfo in a SignedData object that
encapsulates a Receipt content.  This is true because when a
SignedData/Receipt is sent to an MLA for distribution, then the MLA must
always encapsulate the received SignedData/Receipt in an outer SignedData in
which the MLA will include the MLExpansionHistory attribute.  The MLA MUST
NOT change the authenticatedAttributes of the received signedData/Receipt
object, so it can't add the MLExpansionHistory to the SignedData/Receipt." 

5) Sec 2.3, 2nd para, last sent: Please replace "In this case, the receiving
agent may choose whether or not to send a receipt." With "In this case, the
receiving agent SHOULD send a signed receipt for the message that requests a
signed receipt."

6) Sec 2.4, Receipt Creation:  I believe that Section 2.4 should be changed
so that it includes hashing the authenticatedAttributes included in the
SignerInfo containing the receipt signature value included in the
SignedData/Receipt.    This allows the recipient of a signedData/Receipt to
verify the authenticity of the authenticatedAttributes such as signingTime,
etc.  If people agree with this recommendation then I will draft a new
section 2.4 that is similar to the CMS text for hashing either the content
or content with authenticatedAttributes.

7) Sec 2.6:  Please replace "[More is needed here or in an appendix
detailing how to do this for each
kind of signature.]" with "Separate documents describe the
algorithm-specific details of the signature verification process for each
signature algorithm that is used in conjunction with the CMS protocol."

8) Sec 2.7, bullet 2: Please move "as described in the "Receipt Creation"
section." to the end of Sec 2.7, bullet 3.

9) Sec 4.2.2, bullet 3.3.1: Please replace: "The MLA encapsulates the
received signedData object in an SignedData object," with "The MLA
encapsulates the received signedData object in an outer SignedData object,".
Added the word "outer" to reinforce the fact that an outer SignedData
created by the MLA encapsulates an inner SignedData (created by the
originating user) that was received by the MLA.

10) Sec 4.2.2, flow chart: Please replace bullet 3.3 in the flow chart with:
"3.3. Encapsulate in a SignedData layer and add a mlExpansionHistory
attribute."  The rest of the text is not needed because the only way to
reach this point in the flow chart is if the signed data was neither
SignedData nor EnvelopedData.
 
11) Appendix C, Open Issues:  Agree that an ASN.1 module should be added
that collects all the ASN.1 from the whole document.

12) Appendix C, Open Issues:  Recommend that the ASN.1 definitions included
in the text should not be changed.  In other words, I believe that ESS
implementors can correctly interpret the inclusion of the two ASN.1:1994
types (BMPString and UniversalString) in the draft.

13) Appendix C, Open Issues:  I am not sure what this means: "5: The
security considerations section needs to be fleshed out, including
discussions of what happens if receiving clients don't check things very
well."  Does this imply that more error checking guidance needs to be added??

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: More ESS-00 Attribute Comments
Date: Fri, 21 Nov 1997 07:35:00 PST
Sender: [email-masked]

Section 1.3.4 mentions the existence of a contentIdentifier
and encapsulatedContentType attribute outside of the
receiptRequest attribute.  OIDs for these attributes are
missing from the OID registry web page.

In section 2.8 "signedContentIdentifier  OCTET STRING,"
was changed to "signedContentIdentifier  ContentIdentifier,"
but the definition of ContentIdentifier is missing from
the rest of the ASN.1 (though it is mentioned in section
1.3.4).  I suggest addition of

ContentIdentifier ::= OCTET STRING

just before or after the definition of ub-receiptsTo to make
things a bit clearer.

Also, the definition of signedContentIdentifier in the
Receipt structure (section 2.9) should be changed from
OCTET STRING to ContentIdentifier to be consistent with
the receipt request syntax in section 2.8.

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

Date: Fri, 21 Nov 1997 08:07:13 -0500
To: Scott Hollenbeck <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-00 Receipt Requests
Sender: [email-masked]

All,

I agree with Scott's proposed change.  If Scott's change is accepted, then
the following changes should be made in addition to those specified in
Scott's msg:

1) Sec 2.3, bullet 2.1 should be deleted.  Bullet 2.1 states: "2.1. If the
value of allOrNone is noReceipt, then a signed receipt MUST NOT be created."

2) Sec 2.3: Flow chart would need to be changed to delete the noReceipt choice.

3) Throughout the text, "allOrNone" would need to be changed to
"allOrFirstTier". 

4) Sec 2.8: The text describing the receiptsFrom field would need to be
changed to delete the text "- no receipts are requested".

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-00 Attributes and Values
Date: Fri, 21 Nov 1997 04:28:48 PST
Sender: [email-masked]

I noticed that the 18 November version of the ESS document
includes changes with respect to authenticated attributes
and the syntax for their values.  However, the new version
mixes the attribute names and the type used to represent the
value syntax.  For example, in section 2.8 we find
"receiptRequest" used to identify both a receiptRequest
attribute OID and the receiptRequest value SEQUENCE.  In all
cases, the value syntax type should be represented with a
different identifier.

Section 2.8: receiptRequest ::= SEQUENCE -> ReceiptRequest ::= SEQUENCE
Section 2.10: contentHints ::= SEQUENCE -> ContentHints ::= SEQUENCE
Section 3.2: securityLabel ::= SET -> SecurityLabel ::= SET

Since the OIDs for these and other attributes have been removed
from this document, the document that contains (or will contain)
the OIDs should be referenced.  Since that document doesn't yet
exist maybe there should just be a placeholder for now.

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: ESS-00 Receipt Requests
Date: Fri, 21 Nov 1997 04:17:51 PST
Sender: [email-masked]

I think we have a situation with our current receipt request
syntax that leads to a bit of extra complexity.  Here's the
issue:

Suppose a message creator does not request a signed receipt.
Using the current syntax there are two ways to indicate this
desire:

1. Do not include a receiptRequest attribute, or
2. Add a receiptRequest attribute, setting the value
of receiptsFrom->allOrNone to noReceipt.

In the MSP world we don't have the luxury of option number
1, so we used the noReceipt value to indicate that a receipt
isn't requested.  I don't think we need to support a noReceipt
value in S/MIME to indicate that a receipt isn't requested
because option #1 provides a clearer and easier to process
mechanism.

Having made that argument, I propose that we alter the ESS
syntax as follows:

ReceiptsFrom ::= CHOICE {
  allOrFirstTier  [0] AllOrFirstTier, -- formerly "allOrNone [0]AllOrNone",
  receiptList     [1] SEQUENCE OF GeneralNames }

AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
-- Remove noReceipt and move the other values up by one.
  allReceipts          (0),
  firstTierRecipients  (1) }

Thoughts?

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 21 Nov 97 12:13:29 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Fri, 21 Nov 97 12:13:29 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971121121329-7EAD]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Fri, 21 Nov 97 12:13:29 +0000
X400-Content-Identifier: Re(2): A draft A
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

Russ,

I think that you have not understood my ASN.1

> We have
> presiousley agreed that backward compatibility with PKCS#7 version 1.5 is
> highly desirable.  This aproach is different than PKCS#7 version 1.5.

My original draft module contained ASN.1 which I intended and still believe to be 100% "bits on the wire identical" to PKCS#7 version 1.5 in its definition of signatureValue.  If you believe that the original module fails to achieve this intention then please identify where you think it fails.

It was John Pawling who was arguing that the signatureValue was only required to be compatible for RSA signatures. My revised proposal retains the "100% bits on the wire identical to PKCS#7 version 1.5" objective in its definition of RSASignatureValue.

> We can argue all day about the depth we want to go to define the syntax.

If the syntax of the object on which the signature is computed is ill-defined then there is considerable scope for different implementors making different assumptions about it, resulting in interworking failures. In the current draft of CMS that syntax is not defined at all!

Jim

From: "Rich Ankney" <[email-masked]>
To: "John Pawling" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments to CMS-01
Date: Thu, 20 Nov 1997 19:42:04 -0500
Sender: [email-masked]

> >5) Sec 6, Intro, Step 3:  Do you think that it is worthwhile to mention
in
> >the CMS spec that a sending agent should include a copy of the
> >content-encryption key that is protected using the originator's key
material
> >so that the originator can always decrypt the message?
> 
> Good idea.  How about:
> 	3.  For the originator and each recipient, the encrypted 
> 	content-encryption key and other recipient-specific 
> 	information are collected into a RecipientInfo value, defined 
> 	in Section 6.2.
> 

I'd prefer that this be optional.

Regards,
Rich

To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
Cc: "John Pawling" <[email-masked]>, [email-masked]
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
From: EKR <[email-masked]>
Date: 20 Nov 1997 16:55:11 -0800
Lines: 24
Sender: [email-masked]

"Jim Craigie" TEL +44-1635-202124 <[email-masked]> writes:
> John,
[..snip..]
> > [JSP: Because then the CMS definition would need to define SignatureValue as
> > ANY to provide sufficient flexibility to support a variety of signature
> > algorithms.  I believe that defining SignatureValue as an OCTET STRING is
> > the better choice.]
> 
> I disagree. Embedding an ASN.1 encoding within the value of an OCTET
> STRING or a BIT STRING requires two passes of ASN.1 parsing, unless
> you write special case code.
While this is true, I consider this a feature rather than a bug, in
most cases.  In terms of software design, it's reasonably common (at
the CMS level) to treat signatures as opaque values, with the ASN.1
parsing of the signature (if necessary) being done in the module that
does the signature verification rather than in the module that does
the message processing. Popular cryptographic interfaces (e.g. BSAFE)
encourage this behavior. 

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Thu, 20 Nov 1997 19:37:02 -0500 (EST)
From: Bancroft Scott <[email-masked]>
To: Jim Craigie TEL +44-1635-202124 <[email-masked]>
Cc: [email-masked]
Subject: Re: Re(2): Comments on the Cryptographic Message Syntax
Sender: [email-masked]

On Thu, 20 Nov 1997, Jim Craigie TEL +44-1635-202124 wrote:

> > Phil is correct in all of the above.  However, given that the 
> > OSS ASN.1 Tools already supports BER, DER and PER, it will be 
> > very easy for us to support CER.  You can be certain that if 
> > CER is required by this or any other standard OSS will provide 
> > immediate support for it - before any implementor has a need.
> 
> Sounds fine. But it has been suggested that supporting CER might
> be expensive. How much extra would CER support cost?

CER support would be made a base component of the OSS ASN.1 Tools and
would not affect its cost in any way.  This is no different from our
support for DER, PER, ASN.1:1994, etc., which we provide at no extra cost
to new or existing customers (i.e., customers who already have the OSS
ASN.1 Tools pay nothing for new features, and new features don't raise
the cost of the product).  As always, it is royalty-free.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Thu, 20 Nov 1997 19:27:14 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments to CMS-01
Cc: [email-masked]
Sender: [email-masked]

All,

I agree with all of Russ' responses to my comments.

Russ wrote: Does the above wording satisfy this concern too?

Yes.

- John Pawling

Date: Thu, 20 Nov 1997 19:11:56 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim:

I am responding to one part of your message (see below).

We can argue all day about the depth we want to go to define the syntax.
But, I strongly encouage the group to avoid this rat hole.  We have
presiousley agreed that backward compatibility with PKCS#7 version 1.5 is
highly desirable.  This aproach is different than PKCS#7 version 1.5.  In
my opinion, this fact should be the end of discussion.

In my opinion, the difference in not very significant in a real
implementation.  In either situation, the output of the ASN.1 decode will
be passed to the crypto routines.  If the format carried in the protocol is
different in any way from the arguments neded by the crypto routines, then
glue code must be written to deal with it.

Russ

>I disagree. Embedding an ASN.1 encoding within the value of an OCTET 
>STRING or a BIT STRING requires two passes of ASN.1 parsing, unless 
>you write special case code. It is much better to define the syntax 
>properly to enable it to be parsed in one pass. An Information Object 
>Set replaces the now deprecated use of ANY, to give a syntax like:
>
>SignerInfo ::= SEQUENCE {
>        version Version,
>        issuerAndSerialNumber IssuerAndSerialNumber,
>        digestAlgorithm DigestAlgorithmIdentifier,
>        authenticatedAttributes [0] Attributes OPTIONAL,
>        signatureAlgorithm SignatureAlgorithmIdentifier,
>        signature SIGNATURE-VALUE.&Type 
>          ([email-masked]}),
>        unauthenticatedAttributes [1] Attributes OPTIONAL }
>
>SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
>
>SIGNATURE-VALUE ::= CLASS {
>        &id  ALGORITHM.&id,
>        &Type }
>        WITH SYNTAX {&Type IDENTIFIED BY &id }
>
>SignatureValueTable SIGNATURE-VALUE ::= { rsa-signature-value, 
>dss-signature-value, x509-signature-value, another-signature-value, 
>... }
>
>rsa-signature-value SIGNATURE-VALUE ::= { RSASignatureValue 
>  IDENTIFIED BY id-rsa-signature }
>
>RSASignatureValue ::= ENCRYPTED { DigestInfo }
>
>DigestInfo ::= SEQUENCE {
>        digestAlgorithm DigestAlgorithmIdentifier,
>        digest Digest }
>
>Digest ::= HASHED { CHOICE {
>        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
>        authenticated-attributes [0] EXPLICIT Attributes } }
>
>dss-signature-value SIGNATURE-VALUE ::= { DSSSignatureValue 
>  IDENTIFIED BY id-dss-signature }
>
>DSSSignatureValue ::= SEQUENCE {
>        r INTEGER,
>        s INTEGER }
>
>x509-signature-value SIGNATURE-VALUE ::= { BIT STRING 
>  IDENTIFIED BY id-x509-signature }
>
>another-signature-value SIGNATURE-VALUE ::= { OCTET STRING 
>  IDENTIFIED BY id-another-signature }
>

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 20 Nov 97 23:40:05 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu, 20 Nov 97 23:40:05 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971120234005-64FC]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Thu, 20 Nov 97 23:40:05 +0000
X400-Content-Identifier: Re: A draft ASN.
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "John Pawling" <[email-masked]>
Cc: [email-masked]
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

John,
> 
> >As CER is a subset of BER I cannot see how the cost of adding support for CER
> >can be so significant. 
> 
> [JSP:  It is significant to a small company.  For example, we are adding DER
> capabilities to a BER-capable ToolKit.  It takes a significant amount of
> time to add the many blocks of code required to enforce the additional
> constraints imposed by DER and then to test these new capabilities.  I am
> assuming that adding yet another type of encoding (i.e. CER) would require a
> similar amount of effort to develop and test the capabilities.]

Most of the constraints are common between CER and DER, so it actually
requires a very small amount of effort to add CER if you already support DER.

> 
> 
> >If the PKCS#7 syntax is to be used in some cases then it is essential to
> retain its ASN.1 definition, but this could be in an Information Object Set
> which varies according to the algorithm identifier. 
> 
> [JSP: I agree.  The PKCS #7-like syntax could be included in an Appendix to
> the CMS describing how the RSA signature algorithm is used in conjunction
> with the CMS spec.]
> 
> 
> >What syntax is required for elliptic curves?
> >
> >If I understand the description of the DSS algorithm its output is two
> integers, which are encoded into an ASN.1 sequence. If this is used in the
> X.509 SIGNATURE parameterised type then the DER encoding of this sequence is
> placed within the BIT STRING which is the ENCRYPTED parameterised type.
> 
> [JSP: When DSS is used to sign a cert, then the signatureValue BIT STRING
> includes the ASN.1 encoded SEQUENCE of the R and S INTEGERs.]
> 
> 
> > Above you say that the SignatureValue should be an OCTET STRING. Were you
> proposing that this contained the encoding of the BIT STRING or the SEQUENCE?
> 
> 
> [JSP: In DSS-signed SignerInfos, the SignatureValue OCTET STRING will
> contain the ASN.1 encoded SEQUENCE of the R and S INTEGERs.]
> 
> 
> >Why not just make the SignatureValue be the sequence of the two integers in
> the DSS case?
> 
> [JSP: Because then the CMS definition would need to define SignatureValue as
> ANY to provide sufficient flexibility to support a variety of signature
> algorithms.  I believe that defining SignatureValue as an OCTET STRING is
> the better choice.]

I disagree. Embedding an ASN.1 encoding within the value of an OCTET STRING or a BIT STRING requires two passes of ASN.1 parsing, unless you write special case code. It is much better to define the syntax properly to enable it to be parsed in one pass. An Information Object Set replaces the now deprecated use of ANY, to give a syntax like:

SignerInfo ::= SEQUENCE {
        version Version,
        issuerAndSerialNumber IssuerAndSerialNumber,
        digestAlgorithm DigestAlgorithmIdentifier,
        authenticatedAttributes [0] Attributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SIGNATURE-VALUE.&Type ([email-masked]}),
        unauthenticatedAttributes [1] Attributes OPTIONAL }

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

SIGNATURE-VALUE ::= CLASS {
        &id  ALGORITHM.&id,
        &Type }
        WITH SYNTAX {&Type IDENTIFIED BY &id }

SignatureValueTable SIGNATURE-VALUE ::= { rsa-signature-value, dss-signature-value, x509-signature-value, another-signature-value, ... }

rsa-signature-value SIGNATURE-VALUE ::= { RSASignatureValue IDENTIFIED BY id-rsa-signature }

RSASignatureValue ::= ENCRYPTED { DigestInfo }

DigestInfo ::= SEQUENCE {
        digestAlgorithm DigestAlgorithmIdentifier,
        digest Digest }

Digest ::= HASHED { CHOICE {
        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
        authenticated-attributes [0] EXPLICIT Attributes } }

dss-signature-value SIGNATURE-VALUE ::= { DSSSignatureValue IDENTIFIED BY id-dss-signature }

DSSSignatureValue ::= SEQUENCE {
        r INTEGER,
        s INTEGER }

x509-signature-value SIGNATURE-VALUE ::= { BIT STRING IDENTIFIED BY id-x509-signature }

another-signature-value SIGNATURE-VALUE ::= { OCTET STRING IDENTIFIED BY id-another-signature }

> 
> 
> >RecipientKeyIdentifier
> 
> [JSP: I don't believe that RecipientKeyIdentifier needs to be changed from
> the existing CMS-01 syntax, because the RecipientIdentifier provides the
> CHOICE of issuerAndSerialNumber and RecipientKeyIdentifier.  I believe that
> the current CMS-01 syntax provides sufficient flexibility to uniquely
> identify any X.509 Certificate.]
> 
I disagree, for reasons stated in previous messages.

Jim

From: Larry Layten <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: RE: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Date: Thu, 20 Nov 1997 15:44:54 -0600
Sender: [email-masked]

Sorry about my last empty comment:

I agree with John Pawling -- Lets keep it simple -- at least
for this version.

Larry

[JP]:
> But the cost of specifying and supporting two encoding options within
> S/MIME (assigning parallel OIDs for each, etc) is quite significant,
> and the result is ugly.

Date: Thu, 20 Nov 1997 16:43:32 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: Comments to CMS-01
Cc: [email-masked]
Sender: [email-masked]

John:

>1) Sec 3, last para: This paragraph discusses "external signatures".  This
>concept adds significant complexity to the CMS security services.  Is it
>really needed?

Yes.  S/MIME needs it.

>2) Sec 3, last para:  If it is decided that the CMS spec still needs to
>support "external signatures", then the following issue needs to be
>clarified.   Is it true that the signatureValue in a SignedData object in
>which the content is absent is calculated exactly as with a SignedData in
>which the content is present?  If so, then please add a sentence to the last
>para of Sec 3 stating that fact. 

Okay.  I will add the following:
	If the ContentInfo value is absent, the signatureValue is 
	calculated as though the ContentInfo value were present.
	The presumed ContentInfo must have the content type set to 
	id-data and the content omitted.

>3) Sec 3, last para: If it is decided that the CMS spec still needs to
>support "external signatures", then please add the following sentence:  "In
>this case, the content type within the ContentInfo must be id-data and the
>content field of the ContentInfo must be omitted (i.e. absent)."

Does the above wording satisfy this concern too?

>4) Sec 5.2: This references PKCS #9.  The WG still needs to duplicate the
>PKCS #9 contents in an IETF-controlled document.  The CMS should then be
>changed to reference the IETF-controlled document.

Agree.  This is an open issue.  I think that a future CMS draft will
include a section "Useful Attributes" that duplicates the relevant parts of
PKCS#9.

>5) Sec 6, Intro, Step 3:  Do you think that it is worthwhile to mention in
>the CMS spec that a sending agent should include a copy of the
>content-encryption key that is protected using the originator's key material
>so that the originator can always decrypt the message?

Good idea.  How about:
	3.  For the originator and each recipient, the encrypted 
	content-encryption key and other recipient-specific 
	information are collected into a RecipientInfo value, defined 
	in Section 6.2.

>6) Sec 7.1: This section states: "The definition of
>CertificateRevocationList is imported from X.509.
>      CertificateRevocationLists ::= SET OF CertificateRevocationList".
>
>However, the 97 X.509 Recommendation includes the following definition of
>CertificateRevocationList:
>
>"certificateRevocationList	ATTRIBUTE	::=	{
>				WITH SYNTAX	CertificateList
>				EQUALITY MATCHING RULE certificateListExactMatch
>				ID				id-at-certificateRevocationList }
>
>CertificateList	::= SIGNED { SEQUENCE {
>  version	Version OPTIONAL,
>        	-- if present, version must be v2
>  signature	AlgorithmIdentifier,
>  issuer	Name,
>  thisUpdate	Time,
>  nextUpdate	Time OPTIONAL,
>  revokedCertificates	SEQUENCE OF SEQUENCE {
>				userCertificate		CertificateSerialNumber,
>				revocationDate		Time,
>				crlEntryExtensions	Extensions OPTIONAL } OPTIONAL,
>  crlExtensions	[0]  Extensions OPTIONAL }}"
>
>I believe that the intent was for the CMS SignedData and OriginatorInfo
>syntaxes to include a SET OF CertificateList rather than SET OF
>CertificateRevocationList (which would be a SET of attributes containing
>CertificateLists).

Agree.  I changed it to CertificateList.

Russ

To: Russ Housley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
From: EKR <[email-masked]>
Date: 20 Nov 1997 11:12:58 -0800
Lines: 32
Sender: [email-masked]

Russ Housley <[email-masked]> writes:
> >As CER is a subset of BER I cannot see how the cost of adding support 
> >for CER can be so significant. 
> 
> I must ask a different question.  DER was defined in 1988 and many folks
> have implementations, and the specification must continue to support DER
> for backward compatibility.  Given these facts, what is the value of CER
> over DER that makes it worth the additional development and testing?  I
> understand the desire for single pass processing, but I am not convinced
> that the improvement in single pass processing is worth the hastles to
> support two encoding formats.

It's important to remember here that we already have one pass
processing for the common case: Data. [1] What Section 5.3 
actually means (for the Data case) is 'digest the input data'.

Moreover, signing a CER encoding is problematic because
it breaks the (IMHO important) layering between the data
to which the cryptographic services are being applied
(I.e. the message) and the message wrapper. This is particularly
important for Data, where the data being transferred may
well not be (and in the case of S/MIME, isn't) BER encoded
at all. This strikes me as a very bad idea.

-Ekr

[1] In fact, as I understand the S/MIME spec, section 2.4.1 requires
that this is the only case when you're doing S/MIME.

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

From: Larry Layten <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Jim Craigie TEL +44-1635-202124'" <[email-masked]>
Subject: RE: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Date: Thu, 20 Nov 1997 12:34:00 -0600
Sender: [email-masked]

----------
From: 	Jim Craigie TEL +44-1635-202124[SMTP:[email-masked]]
Sent: 	Thursday, November 20, 1997 11:38 AM
To: 	[email-masked]
Subject: 	Re(2): A draft ASN.1 module for Cryptographic Message Syntax

> But the cost of specifying and supporting two encoding options within
> S/MIME (assigning parallel OIDs for each, etc) is quite significant,
> and the result is ugly.

I'm not advocating that for all signature algorithms there should be
two object identifiers, one for the signature applied to CER encoding
and one for the signature applied to DER encoding. What I am advocating
is that CMS allows the choice between CER and DER when a signature
algorithm is specified.

For example, CMS might define one object identifier for RSA with SHA-1
on the DER encoding (for backward compatability), and another object
identifier for DSS with SHA-1 on the CER encoding (where presumably
we don't have a backward compatability issue).

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 20 Nov 97 17:38:51 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu, 20 Nov 97 17:38:51 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971120173851-66FE]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Thu, 20 Nov 97 17:38:51 +0000
X400-Content-Identifier: Re(2): Comments 
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "Bancroft Scott" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): Comments on the Cryptographic Message Syntax
Sender: [email-masked]

Bancroft,

> Phil is correct in all of the above.  However, given that the 
> OSS ASN.1 Tools already supports BER, DER and PER, it will be 
> very easy for us to support CER.  You can be certain that if 
> CER is required by this or any other standard OSS will provide 
> immediate support for it - before any implementor has a need.

Sounds fine. But it has been suggested that supporting CER might
be expensive. How much extra would CER support cost?

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 20 Nov 97 17:38:52 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu, 20 Nov 97 17:38:52 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971120173852-6414]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Thu, 20 Nov 97 17:38:52 +0000
X400-Content-Identifier: Re(2): Comments 
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): Comments on the Cryptographic Message Syntax
Sender: [email-masked]

> CER would require the addition
> of a flag or the assignment for additonal OIDs to distinguish CER from DER.

The OID for a signature algorithm specifies whether the algorithm
is applied to the CER encoding or to the DER encoding. For older
definitions where this is not specified, assume DER.

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 20 Nov 97 17:38:53 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu, 20 Nov 97 17:38:52 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971120173852-171D]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [email-masked]
Date: Thu, 20 Nov 97 17:38:52 +0000
X400-Content-Identifier: Re(2): A draft A
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked]
Subject: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

> But the cost of specifying and supporting two encoding options within
> S/MIME (assigning parallel OIDs for each, etc) is quite significant,
> and the result is ugly.

I'm not advocating that for all signature algorithms there should be
two object identifiers, one for the signature applied to CER encoding
and one for the signature applied to DER encoding. What I am advocating
is that CMS allows the choice between CER and DER when a signature
algorithm is specified.

For example, CMS might define one object identifier for RSA with SHA-1
on the DER encoding (for backward compatability), and another object
identifier for DSS with SHA-1 on the CER encoding (where presumably
we don't have a backward compatability issue).

Jim

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-00.txt
Date: Thu, 20 Nov 1997 10:31:59 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-00.txt
	Pages		: 21
	Date		: 19-Nov-97
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP], but are useful in many other environments,
particularly business and finance. The services are:
 - signed receipts
 - security labels
 - secure mailing lists
 
The services described here are extensions to S/MIME version 2 [SMIME2] and
S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME
version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number
of the services require mechanisms described in Cryptographic Message
Syntax [CMS].
 
This draft is being discussed on the ''ietf-smime'' mailing list. To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-ess-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-ess-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ess-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ess-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: A draft ASN.1 module for Cryptographic Message Syntax
Date: Wed, 19 Nov 1997 13:37:41 -0800
Sender: [email-masked]

On Wednesday, November 19, 1997 10:38 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> I agree with Jim and Russ :-).

Oh, yeah?  Well I agree with you.

> I'm definitely opposed to having a choice of two valid encodings.
> If we can't get agreement on always using CER for parts of CMS that
> both a) require a distinguished encoding and b) have unbounded size,
> then we should punt and always use DER despite the performance
> implications.

I really think that we should go with either DER or CER and then leave
it at that.  I don't think that a hybrid where both are used could be
anything other than confusing.  If we get to the point of using CER,
then we have to punt on S/MIME v2 compatibility and we might as well as
go with PKCS #7 v2 as a base document also.

I really, really wish that CER had come along a bit earlier.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 19 Nov 1997 13:37:43 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

> 
> Jim,
> 
> >As CER is a subset of BER I cannot see how the cost of adding support 
> >for CER can be so significant. 
> 
> I must ask a different question.  DER was defined in 1988 and many folks
> have implementations, and the specification must continue to support DER
> for backward compatibility.  Given these facts, what is the value of CER
> over DER that makes it worth the additional development and testing?  I
> understand the desire for single pass processing, but I am not convinced
> that the improvement in single pass processing is worth the hastles to
> support two encoding formats.
> 
> Russ

I agree with Jim and Russ :-).

The cost of developing and adding CER capability to a DER-capable
encoder should be small enough as to be negligible.  The actual coding
layer is a tiny proportion of the software required to process just
X.509 certificates, and an even tinier proportion of a full CMS package.

But the cost of specifying and supporting two encoding options within
S/MIME (assigning parallel OIDs for each, etc) is quite significant,
and the result is ugly.  I wouldn't have a problem with picking CER
as the only valid encoding for the outer layers, and actually think this
would be desirable if S/MIME is expected to handle multi-megabyte
attachments.  (I've emailed myself 50 MB tarfiles on occasion, and
MISSI has applications for signing very large files).
It's not impossible to do two passes over the content - a once-over
scan to establish the lengths and a second pass to do the encoding.  But
it is a dog when the mail-handling process is I/O-bound rather than
CPU-bound.

I'm definitely opposed to having a choice of two valid encodings.
If we can't get agreement on always using CER for parts of CMS that
both a) require a distinguished encoding and b) have unbounded size,
then we should punt and always use DER despite the performance
implications.

Date: Wed, 19 Nov 1997 12:21:12 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim,

>As CER is a subset of BER I cannot see how the cost of adding support 
>for CER can be so significant. 

I must ask a different question.  DER was defined in 1988 and many folks
have implementations, and the specification must continue to support DER
for backward compatibility.  Given these facts, what is the value of CER
over DER that makes it worth the additional development and testing?  I
understand the desire for single pass processing, but I am not convinced
that the improvement in single pass processing is worth the hastles to
support two encoding formats.

Russ

Date: Wed, 19 Nov 1997 10:55:28 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: SIGNED {} - Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

> From: "Phillip H. Griffin" <[email-masked]>
> 
> The text "expands to a SEQUENCE of the data being signed, an algorithm 
> identifier, and a bit string" means that after parameterized type text
> substitution on the nested parameterized types that make up the X.509
> SIGNED {} type, you get the equivalent ASN.1 definition:
> 
>    SIGNED { ToBeSigned } ::= SEQUENCE {
>       toBeSigned  ToBeSigned,
>       algorithm   AlgorithmIdentifier,
>       signature   BIT STRING
>    }
> 
> This definition is signature scheme neutral. The four parameterized
> type definitions used in X.509 are not. They imply that a digital
> signature scheme perform an encrypted hash to sign an object. The
> HASHED {}, ENCRYPTED {}, SIGNATURE {}, and SIGNED {} that follow 
> should be replaced with a simpler version of SIGNED {}.

I agree.

Perhaps the definitions in the as-yet-unratified 1997 version
of X.509, which have been changed from the 1993 version and now refer to
ENCRYPTED-HASH {}, can be changed again to simply refer to SIGNED {}.

Date: Wed, 19 Nov 1997 09:55:29 -0500
To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Re(2): Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim,

>As CER is a subset of BER I cannot see how the cost of adding support for CER
>can be so significant. 

[JSP:  It is significant to a small company.  For example, we are adding DER
capabilities to a BER-capable ToolKit.  It takes a significant amount of
time to add the many blocks of code required to enforce the additional
constraints imposed by DER and then to test these new capabilities.  I am
assuming that adding yet another type of encoding (i.e. CER) would require a
similar amount of effort to develop and test the capabilities.]

>However, I didn't think that I was requiring support
>for CER. Any such requirement would be contained in a requirement for
>mandatory support of a signature algorithm defined to use CER. I am simply
>stating an existing fact in a way that allows efficient implementation for
>signature algorithms which use CER. That is not a requirement, but a help
>for implementors who encounter signature algorithms defined to apply the
>signature to the CER encoding.

[JSP: The current CMS spec states that all data to be hashed must be DER
encoded.  This implies that a CMS implementation only needs to support DER
and BER.  Your draft CMS ASN.1 module included:  "-- In Cryptographic
Message Syntax the HASHED parameterised type applies the hash function to
the contents octets component of a CER or DER encoding of a value of the
parameter."  This implies that a CMS implementation must support DER and BER
and should support CER to accommodate signature algorithms that require it.
This adds expense and somplexity.]

>Are you proposing the syntax defined in PKCS#7 for RSA algorithms? 

[JSP: No.  I am proposing that SignatureValue should simply be defined as an
OCTET STRING and that the SignerInfo signatureAlgorithm will indicate
exactly what data is to be encrypted (signed) to form the SignatureValue.]

>If the PKCS#7 syntax is to be used in some cases then it is essential to
retain its ASN.1 definition, but this could be in an Information Object Set
which varies according to the algorithm identifier. 

[JSP: I agree.  The PKCS #7-like syntax could be included in an Appendix to
the CMS describing how the RSA signature algorithm is used in conjunction
with the CMS spec.]

>What syntax is required for elliptic curves?
>
>If I understand the description of the DSS algorithm its output is two
integers, which are encoded into an ASN.1 sequence. If this is used in the
X.509 SIGNATURE parameterised type then the DER encoding of this sequence is
placed within the BIT STRING which is the ENCRYPTED parameterised type.

[JSP: When DSS is used to sign a cert, then the signatureValue BIT STRING
includes the ASN.1 encoded SEQUENCE of the R and S INTEGERs.]

> Above you say that the SignatureValue should be an OCTET STRING. Were you
proposing that this contained the encoding of the BIT STRING or the SEQUENCE? 

[JSP: In DSS-signed SignerInfos, the SignatureValue OCTET STRING will
contain the ASN.1 encoded SEQUENCE of the R and S INTEGERs.]

>Why not just make the SignatureValue be the sequence of the two integers in
the DSS case?

[JSP: Because then the CMS definition would need to define SignatureValue as
ANY to provide sufficient flexibility to support a variety of signature
algorithms.  I believe that defining SignatureValue as an OCTET STRING is
the better choice.]

>RecipientKeyIdentifier

[JSP: I don't believe that RecipientKeyIdentifier needs to be changed from
the existing CMS-01 syntax, because the RecipientIdentifier provides the
CHOICE of issuerAndSerialNumber and RecipientKeyIdentifier.  I believe that
the current CMS-01 syntax provides sufficient flexibility to uniquely
identify any X.509 Certificate.]

>
>Jim
>

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 19 Nov 97  4:18:26 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed, 19 Nov 97  4:18:26 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971119041826-4336]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Wed, 19 Nov 97  4:18:26 +0000
X400-Content-Identifier: Re(2): Re(2): A 
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "John Pawling" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

John,

> >Note that CER encoding can always be used (though not necessarily efficiently) even
> >if DER alone is specified, as a digestAlgorithm can be defined to decode the DER and
> >re-encode in CER before applying the hash function. It is more efficient to have the
> >digestAlgorithmIdentifier specify which of CER or DER is to be applied, however.
> 
> [JSP: Please note that many ASN.1 Tool kits do not support CER, so addition
> of CER as a requirement will significantly increase the cost of complying
> with the CMS spec.]

As CER is a subset of BER I cannot see how the cost of adding support for CER
can be so significant. However, I didn't think that I was requiring support
for CER. Any such requirement would be contained in a requirement for
mandatory support of a signature algorithm defined to use CER. I am simply
stating an existing fact in a way that allows efficient implementation for
signature algorithms which use CER. That is not a requirement, but a help
for implementors who encounter signature algorithms defined to apply the
signature to the CER encoding.

> 
> 
> >> 2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
> >> of digestAlgorithm and digest.  CMS, Section 5.4 does not mandate the
> >> inclusion of the digestAlgorithm in the message signature generation
> >> process.  In fact, only the digest itself is input to the DSS algorithm. I
> >> recommend replacing your current SignatureValue, DigestInfo and Digest
> >> definitions with the definition of SignatureValue as an OCTET STRING.  The
> >> SignerInfo signatureAlgorithm will indicate exactly what data is to be
> >> encrypted to form the SignatureValue.  There should be appendices to CMS for
> >> DSS, RSA, Elliptical curve (future), etc.
> >
> >This depends on the extent to which CMS is to be compatable with PKCS#7, which
> >does mandate that the digestAlgorithm is included within the signature value.
> >While it would be possible to have the signatureAlgorithm define the structure
> >of the data that is signed, what is the benefit? 
> 
> [JSP: The benefit is for the CMS to allow the DSS (aka DSA) signature
> applied to a CMS SignedData object to be compliant with the 21 June 1996
> ANSI X9.57, "Public Key Cryptography For The Financial Services Industry:
> Certificate Management" specification

Are you proposing the syntax defined in PKCS#7 for RSA algorithms? If the PKCS#7 syntax is to be used in some cases then it is essential to retain its ASN.1 definition, but this could be in an Information Object Set which varies according to the algorithm identifier. What syntax is required for elliptic curves?

If I understand the description of the DSS algorithm its output is two integers, which are encoded into an ASN.1 sequence. If this is used in the X.509 SIGNATURE parameterised type then the DER encoding of this sequence is placed within the BIT STRING which is the ENCRYPTED parameterised type. Above you say that the SignatureValue should be an OCTET STRING. Were you proposing that this contained the encoding of the BIT STRING or the SEQUENCE? Why not just make the SignatureValue be the sequence of the two integers in the DSS case?

> Notes:
> 
> 2) The SIGNED type does not include the signature algorithm identifier in
> the signature computation.  In order to deter attacks based upon modifying
> the hash or signature algorithm identifiers conveyed in the message,
> applications using the SIGNED type should include the algorithm identifier
> in the actual data being signed. 
> 

That should be formalised in the ASN.1

> 
> >> 
> >> 4) I don't believe that the WG has approved of your definition of
> >> RecipientKeyIdentifier (including Name and CertificateAssertion) which is
> >> significantly more complicated than the current CMS defnition.
> >
> >Again, I would welcome some discussion of this.
> 
> [JSP: How about if we defined RecipientKeyIdentifier as a
> CertificateAssertion (rather than a sequence of subjectName and
> CertificateAssertion) (except that I would like to see text in the CMS spec
> prohibiting the use of the CertificateAssertion "pathToName" choice)??]

I agree that the subjectName is not always necessary (e.g. if the
CertificateAssertion contains issuer and serialNumber) but I disagree
that it is never necessary here. For example, if the CertificateAssertion
contains just subjectKeyIdentifier then a subjectName may be essential
for economic processing by each recipient if a CA's allocation of values
for subjectKeyIdentifier give the same value to many users (e.g. if the
value is a sequence number for each user, or the date of issue).

I agree with prohibiting pathToName. So my revised proposal is:

RecipientKeyIdentifier ::= SEQUENCE {
        certificateSubjectName  [0] Name OPTIONAL,
        recipientCertificateSelector  CertificateAssertion(WITH COMPONENTS{..., pathToName ABSENT}) }

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 19 Nov 97  4:18:24 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed, 19 Nov 97  4:18:24 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:24260-971119041824-69FF]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Wed, 19 Nov 97  4:18:24 +0000
X400-Content-Identifier: Re(2): Re(2): Co
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "John Pawling" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): Re(2): Comments on the Cryptographic Message Syntax
Sender: [email-masked]

John,

> After reading the R-H requirements, I now agree with Jim that
> "originatorCertificateSelector CertificateAssertion OPTIONAL" should be
> added to the RecipientInfo SEQUENCE.
> 
> However, I have another concern as follows: CertificateAssertion includes
> "pathToName" as an option.  X.509 describes "pathToName" as follows:
> "pathToName matches unless the certificate has a name constraints extension
> which inhibits the construction of a certification path to the presented
> name value."  Do we really need the pathToName option in the
> originatorCertificateSelector CertificateAssertion in the  RecipientInfo
> SEQUENCE??  It adds significant complexity to the process of matching the
> originator's key material with the recipientInfo.  Could we adopt Jim's
> recommended solution with a caveat stating that "pathToName" is prohibited?

Agreed. There is no issue here, since the name constraints extension can only
apply to CA Certificates, and we are selecting from user certificates, so it
is not appropriate to use the pathToName option within CertificateAssertion.
This restriction could be formalised into the ASN.1 as follows:

originatorCertificateSelector CertificateAssertion(WITH COMPONENTS{..., pathToName ABSENT}) OPTIONAL

Of course, any name constraints in CA certificates must be applied when
verifying the certification path (but we're not discussing that here).

Jim

Date: Tue, 18 Nov 1997 17:06:10 -0500
To: Russ Housley <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comments on the Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

All,

I agree with all of Russ' points.  I would prefer not to add the complexity
and expense of supporting CER, but I am not violently opposed to CER.  I
agree that RecipientInfo originator-cert-selector could simply be a choice
of IssuerAndSerialNumber and subjectKeyId.

- John Pawling 

Date: Tue, 18 Nov 1997 16:11:22 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: SIGNED {} - Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Cc: Jim Craigie TEL +44-1635-202124 <[email-masked]>, [email-masked]
Sender: [email-masked]

Jim,

The majority of your message provided comments to the ANSI X9.57 Spec, so I
am not going to debate those comments because this is not the proper forum.
Please address those comments to Rich Ankney, [email-masked].

You stated "S/MIME should not require RSA signatures."  This was exactly my
original point.

Jim Craigie included the following syntaxes in his draft CMS module:
>SignatureValue ::= ENCRYPTED { DigestInfo }
>
>DigestInfo ::= SEQUENCE {
>        digestAlgorithm DigestAlgorithmIdentifier,
>        digest Digest }
>
>Digest ::= HASHED { CHOICE {
>        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
>        authenticated-attributes [0] EXPLICIT Attributes } }

This set of syntaxes mandates the RSA-style of generating a digital
signature.  My point was to replace this set of syntaxes with:
SignatureValue ::= OCTET STRING

The SignerInfo signatureAlgorithm will indicate exactly what data is to be
encrypted (signed) to form the SignatureValue.  There should be appendices
to CMS for DSS, RSA, Elliptical curve (future), etc.

- John Pawling

From: "Rich Ankney" <[email-masked]>
To: "Scott Hollenbeck" <[email-masked]>, "'John Pawling'" <[email-masked]>
Cc: "'IETF S/MIME'" <[email-masked]>
Subject: Re: CMS-01 SignerInfo and Attribute Certificates
Date: Tue, 18 Nov 1997 15:28:37 -0500
Sender: [email-masked]

So how about making it a CHOICE { Name, [0] GeneralName }??

/ Rich

----------
> From: Scott Hollenbeck <[email-masked]>
> To: 'John Pawling' <[email-masked]>
> Cc: 'IETF S/MIME' <[email-masked]>
> Subject: RE: CMS-01 SignerInfo and Attribute Certificates
> Date: Tuesday, November 18, 1997 11:59 AM
> 
> -----Original Message-----
> From:	John Pawling [SMTP:[email-masked]]
> Sent:	Tuesday, November 18, 1997 10:52 AM
> To:	Scott Hollenbeck; 'IETF S/MIME'
> Subject:	Re: CMS-01 SignerInfo and Attribute Certificates
> 
> Scott,
> 
> The simple substitution of GeneralNames for Name in IsuerAndSerialNumber
> will break backwards compatibility with PKCS #7 v1.5.  
> 
> [SAH]  Yes, it will, but I don't think the current spec is workable
> as written.  How do you map a non-Name GeneralNames choice to a Name?

Date: Tue, 18 Nov 1997 15:00:28 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

Russ Housley wrote:
> 
> Jim:
> 
> I guess that you kave real problems with PKIX Part 1.  The x.509 version 3
> is defined using 1988 ASN.1 in that document.  Take a look.  By the way,
> PKIX Part 1 is in last call.
> 
> Russ
> 

Let's hope that any ASN.1 errors PKIX contains can be corrected 
before it passes. As noted in my original post, 

   The S/MIME work is not alone in this problem. I've just finished
creating 
   ASN.1:1994 definitions for PKCS #12. It too attempts to use BMPString
in 
   code that uses the superceded ANY DEFINED BY, which is described in
Annex 
   I (not an intgral part of the ASN.1 standards). The current PKIX work
also
   attempts to merge the standards.

Phil

> At 06:00 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
> >> Jim:
> >>
> >> Thanks.  Can you provide 1988 syntax?
> >>
> >> Russ
> >
> >Not if you want to use version 3 certificates. Using 1988 ASN.1 would
> limit you to using only version 1 certificates, as there is no conceivable
> way to write constraints on version 2 or version 3 certificates (which are
> defined in 1994 ASN.1) to use only 1988 compatable ASN.1.
> >
> >As noted by Phil Griffin a week ago, you cannot (for obvious reasons)
> import into 1988 ASN.1 types which use features which were not defined in
> 1988 ASN.1.
> >
> >> There are a few syntax errors in the ASN.1, a draft and WIP, but my
> >> real concern is the mixing of ASN.1:1988/90 and the current standard,
> >> ASN.1:1994. By my reading, the current standard states that the two
> >> can not be mixed in X.680, section A.2, "Mixing ASN.1-88/90 and
> >> current ASN.1 notation":
> >>
> >>  "Both the ASN.1-88/90 and the current ASN.1 notation specify a
> >>  top-level syntactic construct which is an ASN.1 module. A user of
> >>  ASN.1 writes a collection of ASN.1 modules, and may import
> >>  definitions from other ASN.1 modules."
> >>
> >> [snip PHG]
> >>
> >>  "Where a module conforms to the ASN.1-88/90 notation, type and value
> >>  references may be imported from a module that was defined using the
> >>  current notation. Such types and values must be associated with types
> >>  that can be defined using only the ASN.1-88/90 notation. For example,
> >>  a module written using the ASN.1-88/90 notation cannot import a value
> >>  of type UniversalString, since this type is defined in the current
> >>  notation but not in ASN.1-88/90;  it can, however, import values whose
> >>  types are, for example, INTEGER, IA5String, etc."
> >>
> >> Both BMPString and UniversalString are types defined only in the
> >> current standard, ASN.1:1994. The S/MIME work is not alone in this
> >> problem. I've just finished creating ASN.1:1994 definitions for PKCS
> >> #12. It too attempts to use BMPString in code that uses the
> >> superceded ANY DEFINED BY, which is described in Annex I (not an
> >> intgral part of the ASN.1 standards). The current PKIX work also
> >> attempts to merge the standards.
> >>
> >> Such ASN.1 usage will certainly break tools that correctly implement
> >> the ASN.1 standards. I'm not sure why there's so much reluctance to
> >> migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
> >> specifications than X.208-X.209.
> >>
> >> An alternative would be to drop national language support and keep
> >> using ASN.1:1988/90.
> >>
> >> Phil
> >> --
> >> Phillip H. Griffin
> >
> >
> >Jim
> >

Date: Tue, 18 Nov 1997 13:23:19 -0500
To: Scott Hollenbeck <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: CMS-01 SignerInfo and Attribute Certificates
Cc: "'IETF S/MIME'" <[email-masked]>
Sender: [email-masked]

Scott,

IMHO, the SignerInfo IssuerAndSerialNumber does not need to identify the
signer's Attribute Cert (AC), but it must uniquely identify the signer's
X.509 Cert with which the AC is associated.  The PKIX X.509 Cert and CRL
Profile allows X.509 Certs to include an empty sequence as the Issuer Name
and a critical IssuerAltName extension which might contain a Name form.  The
current CMS IssuerAndSerialNumber does not include sufficient flexibility to
uniquely identify X.509 certs that use non-Name IssuerAltName forms instead
of the Issuer Name.  If the S/MIME v3 Certificate Handling spec allows empty
Issuer Names and non-Name IssuerAltName forms, then I believe that
IssuerAndSerialNumber should be changed as follows:

IssuerAndSerialNumber ::= SEQUENCE {
  issuer        Name,
  serialNumber  SerialNumber
  issuerAltName [0] IMPLICIT GeneralNames OPTIONAL}

This would be backwards compatible with PKCS #7, v1.5.  The accompanying
text in CMS should state that the SignerInfo version shall be 1 if the
issuer Name is used and issuerAltName is absent.  If the issuerAltName is
present, then the version shall be 2.  If a v2 SignerInfo is mistakenly sent
to a legacy application that only understands v1 SignerInfo, then,
hopefully, the legacy software will gracefully report an error when it
detects that the version is not 1. 

- John Pawling  

Date: Mon, 17 Nov 1997 10:01:41 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>> 2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
>> of digestAlgorithm and digest.  CMS, Section 5.4 does not mandate the
>> inclusion of the digestAlgorithm in the message signature generation
>> process.  In fact, only the digest itself is input to the DSS algorithm.  I
>> recommend replacing your current SignatureValue, DigestInfo and Digest
>> definitions with the definition of SignatureValue as an OCTET STRING.  The
>> SignerInfo signatureAlgorithm will indicate exactly what data is to be
>> encrypted to form the SignatureValue.  There should be appendices to CMS
for
>> DSS, RSA, Elliptical curve (future), etc.
>
>This depends on the extent to which CMS is to be compatable with PKCS#7,
which
>does mandate that the digestAlgorithm is included within the signature value.
>While it would be possible to have the signatureAlgorithm define the
structure
>of the data that is signed, what is the benefit? Is there any reason not to
>retain compatability with PKCS#7 here?

Yes.  When the RSA signature algorithm is used, there will be
compatability.  The signature algorithm identifier tells the implementor
what xact process to use in the caluclation and verification of the signature.

Russ

Date: Mon, 17 Nov 1997 09:56:36 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim:

I guess that you kave real problems with PKIX Part 1.  The x.509 version 3
is defined using 1988 ASN.1 in that document.  Take a look.  By the way,
PKIX Part 1 is in last call.

Russ

At 06:00 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
>> Jim:
>> 
>> Thanks.  Can you provide 1988 syntax?
>> 
>> Russ
>
>Not if you want to use version 3 certificates. Using 1988 ASN.1 would
limit you to using only version 1 certificates, as there is no conceivable
way to write constraints on version 2 or version 3 certificates (which are
defined in 1994 ASN.1) to use only 1988 compatable ASN.1.
>
>As noted by Phil Griffin a week ago, you cannot (for obvious reasons)
import into 1988 ASN.1 types which use features which were not defined in
1988 ASN.1.
>
>> There are a few syntax errors in the ASN.1, a draft and WIP, but my
>> real concern is the mixing of ASN.1:1988/90 and the current standard,
>> ASN.1:1994. By my reading, the current standard states that the two 
>> can not be mixed in X.680, section A.2, "Mixing ASN.1-88/90 and 
>> current ASN.1 notation":
>> 
>>  "Both the ASN.1-88/90 and the current ASN.1 notation specify a
>>  top-level syntactic construct which is an ASN.1 module. A user of 
>>  ASN.1 writes a collection of ASN.1 modules, and may import 
>>  definitions from other ASN.1 modules."
>> 
>> [snip PHG]
>> 
>>  "Where a module conforms to the ASN.1-88/90 notation, type and value 
>>  references may be imported from a module that was defined using the
>>  current notation. Such types and values must be associated with types 
>>  that can be defined using only the ASN.1-88/90 notation. For example, 
>>  a module written using the ASN.1-88/90 notation cannot import a value 
>>  of type UniversalString, since this type is defined in the current 
>>  notation but not in ASN.1-88/90;  it can, however, import values whose 
>>  types are, for example, INTEGER, IA5String, etc."
>> 
>> Both BMPString and UniversalString are types defined only in the 
>> current standard, ASN.1:1994. The S/MIME work is not alone in this
>> problem. I've just finished creating ASN.1:1994 definitions for PKCS
>> #12. It too attempts to use BMPString in code that uses the 
>> superceded ANY DEFINED BY, which is described in Annex I (not an 
>> intgral part of the ASN.1 standards). The current PKIX work also
>> attempts to merge the standards.
>> 
>> Such ASN.1 usage will certainly break tools that correctly implement 
>> the ASN.1 standards. I'm not sure why there's so much reluctance to
>> migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
>> specifications than X.208-X.209. 
>> 
>> An alternative would be to drop national language support and keep
>> using ASN.1:1988/90. 
>> 
>> Phil
>> -- 
>> Phillip H. Griffin         
>
>
>Jim
>

Date: Mon, 17 Nov 1997 09:46:07 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Comments on the Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim:

>> >1. ASN.1 Canonical Encoding Rules should be allowed

You say that CER requires indefinite length for constructed encodings, and
prohibits definite length for constructed encodings. Thus, CER, like DER,
provides gives a unique encoding of any structure.

I have never looked up CER, so I assume that you are correct.  How do other
people feel about adding support for CER?  This would require the addition
of a flag or the assignment for additonal OIDs to distinguish CER from DER.
 Is the increased possibility of non-interoperability wother the CER
improved handling for one-pass processing.

>> >2. There is an ambiguity about which octets are input to hash and
>> encryption algorithms
>
>Perhaps I'll try a concrete example to illustrate. Consider the data
>string "Hello" whose characters are represented by the octets
>48656C6C6F. This is encoded into an ASN.1 Octet String as
>040548656C6C6F. If this is a Data Content Type, it is encoded in the
>content field of a ContentInfo as A007040548656C6C6F.
>
>The first paragraph says "the input [to the hash function] is the 
>content octets of the DER encoding of the content field of the 
>ContentInfo" - that means strip of the identifier and length octets from
>the encoding of the content field to give 040548656C6C6F as the input to
>the hash function. However, the second paragraph extracted above
>suggests that the input to the hash function is just 48656C6C6F.

I will try and make it clear that the hash is calculated over "Hello"

>> >3. User Keying Materials
>
>You are adding additional overhead when there is only one recipient 
>using that form of key management (as the algorithm-identifier is 
>carried twice in your encoding) and some processing complexity in all
>cases (the receiver needs a local table to indicate for which algorithms
>to search for UKM) in order to achieve a small saving in message size 
>when multiple recipients use the same form of key management.
>
>You are also assuming that all algorithms that may use UKM will require 
>the same UKM data for all recipients. This seems an unsafe assumption.

In my experience, most recipients will all use the same form of key
management.  The CMS allows every reipient to use a different key
management algorithm, but I expect this to be the exception, not the rule.

Two key management algorithms allow the same UKM to be used for each
recipient: X9.42 Diffie-Hellman and KEA.  There are certainly other
algorithms that require a different UKM-like value for each recipient.  In
these cases, the UKM is the wrong place to carry the value;; a parameter to
the algorithm identifier is better.

The whole point of the UKM field is to carry the relatively large value
once instead of once per recipient.  In my opinion, the reduced overhead is
worth the slightly more complex implementation.

>> >4. RecipientKeyIdentifier
>
>Why do you consider more than one recipient with the same subject key 
>identifier to be an unlikely event? The subject key identifier might 
>simply be an incremental counter of the certificates issued by a CA to 
>each user, or the date on which the certificate was issued - in these 
>cases several recipients having the same value would seem quite likely.
>Why not allow the recipient's name to be present?

My experience with KEA in the MISSI PKI shows this to be the case.  The
whole point is to offer an alternative that is small.  If your PKI has many
subject public key identifier collisions, then you should use the isser and
serial number alternative.  This must be unique, but it is bigger than the
subject public key identifier.

>> >5. Originator Certificate selection
>> >
>> >Some key agreement algorithms use different originator keys for 
>> >different recipients. It is therefore necessary to add an 
>> >originator-cert-selector to RecipientInfo:
>> >
>> >     RecipientInfo ::= SEQUENCE {
>> >          version Version,
>> >          rid RecipientIdentifier,
>> >          keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>> >          encryptedKey EncryptedKey,
>> >          originator-cert-selector CertificateAssertion OPTIONAL }
>> 
>> Okay, but I think that the location within the structure might be
>> incorrect.  It needs to come sooner to accompdate single-pass
>> processing.
>
I did not add this yet.  But I will add some form of selection in the next
version.  The CertificateAssertion syntax is far more complex that I
expected.  Unless others on the list think that this is the correct way to
preceed, I will make as simpler subset.  In fact, the two methods used to
identofy recipient certificates should be enough: subject public key
identifier and issuer plus serial number.

The  ASN.1 for CertificateAssertion follows so that readers can make up
their own minds....

Russ

>CertificateAssertion ::= SEQUENCE {
>        serialNumber            [0] CertificateSerialNumber     OPTIONAL,
>        issuer                  [1] Name                        OPTIONAL,
>        subjectKeyIdentifier    [2] SubjectKeyIdentifier        OPTIONAL,
>        authorityKeyIdentifier  [3] AuthorityKeyIdentifier      OPTIONAL,
>        certificateValid        [4] UTCTime                     OPTIONAL,
>        privateKeyValid         [5] GeneralizedTime             OPTIONAL,
>        subjectPublicKeyAlgID   [6] OBJECT IDENTIFIER           OPTIONAL,
>        keyUsage                [7] KeyUsage                    OPTIONAL,
>        subjectAltName          [8] AltNameType                 OPTIONAL,
>        policy                  [9] CertPolicySet               OPTIONAL,
>        pathToName              [10] Name                       OPTIONAL }
>
>AltNameType ::= CHOICE { 
>        builtinNameForm ENUMERATED {
>                                rfc822Name                      (1),
>                                dNSName                         (2),
>                                x400Address                     (3),
>                                directoryName                   (4),
>                                ediPartyName                    (5),
>                                uniformResourceIdentifier       (6),
>                                iPAddress                       (7),
>                                registeredId                    (8) },
>        otherNameForm   OBJECT IDENTIFIER }
>

Date: Tue, 18 Nov 1997 13:03:37 -0500 (EST)
From: Bancroft Scott <[email-masked]>
Reply-To: Bancroft Scott <[email-masked]>
To: [email-masked]
Subject: Re: Comments on the Cryptographic Message Syntax
Sender: [email-masked]

"Phillip H. Griffin" <[email-masked]> wrote:

> > Some comments on the Cryptographic Message Syntax spec:
> >
> > 1. ASN.1 Canonical Encoding Rules should be allowed
>
> Yes, but DER rules. CER would seem the more logical choice, and
> I looked at this issue some time back earlier this year, but I
> could find not one single ASN.1 specification that had adopted
> CER. And I know of no free or commercial products that support
> CER at this time.

Phil is correct in all of the above.  However, given that the 
OSS ASN.1 Tools already supports BER, DER and PER, it will be 
very easy for us to support CER.  You can be certain that if 
CER is required by this or any other standard OSS will provide 
immediate support for it - before any implementor has a need.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Date: Tue, 18 Nov 1997 12:07:03 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: John Pawling <[email-masked]>
CC: Jim Craigie TEL +44-1635-202124 <[email-masked]>, [email-masked]
Subject: SIGNED {} - Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

In "Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax"

John Pawling wrote:
> 
> All,
> 
snip
> 
> >To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
> >From: [email-masked] (John Pawling)
> >Subject: Re: Re(2): A draft ASN.1 module for Cryptographic Message
> >   Syntax
> >Cc: [email-masked]
> >
> >Jim,
> >
> >Thank you for your responses.  My responses are in-line:
> >
> >[JSP] is:
> >================================
> >John Pawling
> >[email-masked]
> >J.G. Van Dyke & Associates, Inc.
> >================================
> >
snip

> >>>
> >>> 2) Your module mandates that a SignatureValue must be an ENCRYPTED 
> >>> SEQUENCE of digestAlgorithm and digest.  CMS, Section 5.4 does not 
> >>> mandate the inclusion of the digestAlgorithm in the message 
> >>> signature generation process.  In fact, only the digest itself is 
> >>> input to the DSS algorithm.  I recommend replacing your current 
> >>> SignatureValue, DigestInfo and Digest definitions with the
> >>> definition of SignatureValue as an OCTET STRING.  The
> >>> SignerInfo signatureAlgorithm will indicate exactly what data is to 
> >>> be encrypted to form the SignatureValue.  There should be 
> >>> appendices to CMS for DSS, RSA, Elliptical curve (future), etc.
> >>
> >>This depends on the extent to which CMS is to be compatable with 
> >>PKCS#7, which does mandate that the digestAlgorithm is included 
> >>within the signature value. While it would be possible to have the 
> >>signatureAlgorithm define the structure of the data that is signed,
> >>what is the benefit?
> >
> >[JSP: The benefit is for the CMS to allow the DSS (aka DSA) signature
> >applied to a CMS SignedData object to be compliant with the 21 June 
> >1996 ANSI X9.57, "Public Key Cryptography For The Financial Services 
> >Industry: Certificate Management" specification which states:
> >
> >"5.3.  Signatures
> >
> >5.3.1. Single Signatures
> >
> >Signatures are defined by the use of the SIGNED parameterized type, 
> >which expands to a SEQUENCE of the data being signed, an algorithm 
> >identifier, and a bit string which is the actual signature.  The 
> >SIGNED type, in turn, uses the ENCRYPTED and HASHED types.  A public 
> >key encryption (or signature) algorithm is applied to the hash of the
> >data to be signed.

The text "expands to a SEQUENCE of the data being signed, an algorithm 
identifier, and a bit string" means that after parameterized type text
substitution on the nested parameterized types that make up the X.509
SIGNED {} type, you get the equivalent ASN.1 definition:

   SIGNED { ToBeSigned } ::= SEQUENCE {
      toBeSigned  ToBeSigned,
      algorithm   AlgorithmIdentifier,
      signature   BIT STRING
   }

This definition is signature scheme neutral. The four parameterized
type definitions used in X.509 are not. They imply that a digital
signature scheme perform an encrypted hash to sign an object. The
HASHED {}, ENCRYPTED {}, SIGNATURE {}, and SIGNED {} that follow 
should be replaced with a simpler version of SIGNED {}.

The text "encryption (or signature) algorithm is applied" refers
to the problem for elliptic curve DSA and many other signature
schemes posed by the X.509 definitions. RSA uses an encryption
based signature scheme, and is called for in X.509. But with
DSA, there's no need to encrypt the hash. The hash is merely
"signed". A simplified SIGNED {} type that says nothing about
which signature scheme is applied should be used. S/MIME should
not require RSA signatures.

> >
> >HASHED {ToBeHashed} ::= OCTET STRING (CONSTRAINED BY {
> >    -- must be the result of applying a hashing procedure to
> >    -- the DER-encoded octets of a value of
> >    ToBeHashed })
> >
> >ENCRYPTED {ToBeEnciphered} ::= BIT STRING (CONSTRAINED BY {
> >    -- must be the result of applying an encipherment
> >    -- procedure to the DER-encoded octets of a value of
> >    ToBeEnciphered })
> >
> >SIGNED {ToBeSigned}::=SEQUENCE {
> >    data          ToBeSigned,
> >    COMPONENTS OF  SIGNATURE {ToBeSigned} }
> >
> >SIGNATURE {OfSignature} ::= SEQUENCE {
> >    algorithm        AlgorithmIdentifier,
> >    encryptedDigest   ENCRYPTED { HASHED {OfSignature} } }
> >    -- For the DSA, the contents octets of the signature BIT STRING 
> >    -- shall be interpreted as being the DER encoding of the type:
> >    --  SEQUENCE {
> >    -- r       INTEGER,
> >    -- s       INTEGER }
> >
> >The data to be signed is encoded using the ASN.1 distinguished 
> >encoding rules (DER) as described in ANSI TG-9-199x, Abstract Syntax 
> >Notation and Encoding Rules for Financial Industry Standards and 
> >X.509.  The complete encoding is hashed using the hash algorithm 
> >implied by the signature algorithm ID.  The complete encoding is 
> >hashed using the hash algorithm implied by the signature algorithm ID. 

Hard to tell the following is true from looking at ENCRYPTED {}.

> > The DSA is then used to sign the hash, resulting in the signature.

snip

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: Scott Hollenbeck <[email-masked]>
To: "'John Pawling'" <[email-masked]>
Cc: "'IETF S/MIME'" <[email-masked]>
Subject: RE: CMS-01 SignerInfo and Attribute Certificates
Date: Tue, 18 Nov 1997 08:59:36 PST
Sender: [email-masked]

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Tuesday, November 18, 1997 10:52 AM
To:	Scott Hollenbeck; 'IETF S/MIME'
Subject:	Re: CMS-01 SignerInfo and Attribute Certificates

Scott,

The simple substitution of GeneralNames for Name in IsuerAndSerialNumber
will break backwards compatibility with PKCS #7 v1.5.  

[SAH]  Yes, it will, but I don't think the current spec is workable
as written.  How do you map a non-Name GeneralNames choice to a Name?

Date: Tue, 18 Nov 1997 10:52:08 -0500
To: Scott Hollenbeck <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: CMS-01 SignerInfo and Attribute Certificates
Sender: [email-masked]

Scott,

The simple substitution of GeneralNames for Name in IsuerAndSerialNumber
will break backwards compatibility with PKCS #7 v1.5.  

- John Pawling 

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: CMS-01 SignerInfo and Attribute Certificates
Date: Tue, 18 Nov 1997 06:13:56 PST
Sender: [email-masked]

When creating an S/MIME v3 signed message, a SignerInfo structure is
created.  This structure contains an IssuerAndSerialNumber structure.
IssuerAndSerialNumber looks like this:

IssuerAndSerialNumber ::= SEQUENCE {
  issuer        Name,
  serialNumber  SerialNumber }

If the message signer is represented with an X.509 or PKCS #6
extended certificate, determining the issuer's Name and the
signer's serial number is straightforward.  If, however, the
signer is represented with an attribute certificate it might
not be possible to get a map to a Name value because the
attribute certificate issuer field is GeneralNames, not Name.
What happens when the issuer's GeneralNames is represented by
something other than a Name?

Maybe IssuerAndSerialNumber should be changed to use type
GeneralNames for the issuer field instead of Name...

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

Date: Tue, 18 Nov 1997 07:48:29 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: More Comments to CMS-01
Sender: [email-masked]

All,

I believe that I can answer my first question.  "external signatures" are
needed to support the application/pkcs7-signature MIME Type.  Please ignore
my first comment.  All of my other comments/questions still apply.

- John Pawling

>Return-Path: <[email-masked]>
>Date: Mon, 17 Nov 1997 19:12:05 -0500
>X-Sender: jsp@ajsn101
>To: [email-masked]
>From: [email-masked] (John Pawling)
>Subject: Comments to CMS-01
>Sender: [email-masked]
>Precedence: bulk
>
>Russ (and friends),
>
>Thank you for incorporating my previous comments into the November 97
>Cryptographic Message Syntax (CMS-01).  I have a few comments to CMS-01:
>
>1) Sec 3, last para: This paragraph discusses "external signatures".  This
>concept adds significant complexity to the CMS security services.  Is it
>really needed?
>
>2) Sec 3, last para:  If it is decided that the CMS spec still needs to
>support "external signatures", then the following issue needs to be
>clarified.   Is it true that the signatureValue in a SignedData object in
>which the content is absent is calculated exactly as with a SignedData in
>which the content is present?  If so, then please add a sentence to the last
>para of Sec 3 stating that fact. 
>
>3) Sec 3, last para: If it is decided that the CMS spec still needs to
>support "external signatures", then please add the following sentence:  "In
>this case, the content type within the ContentInfo must be id-data and the
>content field of the ContentInfo must be omitted (i.e. absent)."
>
>4) Sec 5.2: This references PKCS #9.  The WG still needs to duplicate the
>PKCS #9 contents in an IETF-controlled document.  The CMS should then be
>changed to reference the IETF-controlled document.
>
>5) Sec 6, Intro, Step 3:  Do you think that it is worthwhile to mention in
>the CMS spec that a sending agent should include a copy of the
>content-encryption key that is protected using the originator's key material
>so that the originator can always decrypt the message?
>
>6) Sec 7.1: This section states: "The definition of
>CertificateRevocationList is imported from X.509.
>      CertificateRevocationLists ::= SET OF CertificateRevocationList".
>
>However, the 97 X.509 Recommendation includes the following definition of
>CertificateRevocationList:
>
>"certificateRevocationList	ATTRIBUTE	::=	{
>				WITH SYNTAX	CertificateList
>				EQUALITY MATCHING RULE certificateListExactMatch
>				ID				id-at-certificateRevocationList }
>
>CertificateList	::= SIGNED { SEQUENCE {
>  version	Version OPTIONAL,
>        	-- if present, version must be v2
>  signature	AlgorithmIdentifier,
>  issuer	Name,
>  thisUpdate	Time,
>  nextUpdate	Time OPTIONAL,
>  revokedCertificates	SEQUENCE OF SEQUENCE {
>				userCertificate		CertificateSerialNumber,
>				revocationDate		Time,
>				crlEntryExtensions	Extensions OPTIONAL } OPTIONAL,
>  crlExtensions	[0]  Extensions OPTIONAL }}"
>
>I believe that the intent was for the CMS SignedData and OriginatorInfo
>syntaxes to include a SET OF CertificateList rather than SET OF
>CertificateRevocationList (which would be a SET of attributes containing
>CertificateLists).
>
>In summary, please change sec 7.1 to state: "The definition of
>CertificateList is imported from X.509.
>      CertificateRevocationLists ::= SET OF CertificateList".
>
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>

Date: Mon, 17 Nov 1997 19:12:05 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Comments to CMS-01
Sender: [email-masked]

Russ (and friends),

Thank you for incorporating my previous comments into the November 97
Cryptographic Message Syntax (CMS-01).  I have a few comments to CMS-01:

1) Sec 3, last para: This paragraph discusses "external signatures".  This
concept adds significant complexity to the CMS security services.  Is it
really needed?

2) Sec 3, last para:  If it is decided that the CMS spec still needs to
support "external signatures", then the following issue needs to be
clarified.   Is it true that the signatureValue in a SignedData object in
which the content is absent is calculated exactly as with a SignedData in
which the content is present?  If so, then please add a sentence to the last
para of Sec 3 stating that fact. 

3) Sec 3, last para: If it is decided that the CMS spec still needs to
support "external signatures", then please add the following sentence:  "In
this case, the content type within the ContentInfo must be id-data and the
content field of the ContentInfo must be omitted (i.e. absent)."

4) Sec 5.2: This references PKCS #9.  The WG still needs to duplicate the
PKCS #9 contents in an IETF-controlled document.  The CMS should then be
changed to reference the IETF-controlled document.

5) Sec 6, Intro, Step 3:  Do you think that it is worthwhile to mention in
the CMS spec that a sending agent should include a copy of the
content-encryption key that is protected using the originator's key material
so that the originator can always decrypt the message?

6) Sec 7.1: This section states: "The definition of
CertificateRevocationList is imported from X.509.
      CertificateRevocationLists ::= SET OF CertificateRevocationList".

However, the 97 X.509 Recommendation includes the following definition of
CertificateRevocationList:

"certificateRevocationList	ATTRIBUTE	::=	{
				WITH SYNTAX	CertificateList
				EQUALITY MATCHING RULE certificateListExactMatch
				ID				id-at-certificateRevocationList }

CertificateList	::= SIGNED { SEQUENCE {
  version	Version OPTIONAL,
        	-- if present, version must be v2
  signature	AlgorithmIdentifier,
  issuer	Name,
  thisUpdate	Time,
  nextUpdate	Time OPTIONAL,
  revokedCertificates	SEQUENCE OF SEQUENCE {
				userCertificate		CertificateSerialNumber,
				revocationDate		Time,
				crlEntryExtensions	Extensions OPTIONAL } OPTIONAL,
  crlExtensions	[0]  Extensions OPTIONAL }}"

I believe that the intent was for the CMS SignedData and OriginatorInfo
syntaxes to include a SET OF CertificateList rather than SET OF
CertificateRevocationList (which would be a SET of attributes containing
CertificateLists).

In summary, please change sec 7.1 to state: "The definition of
CertificateList is imported from X.509.
      CertificateRevocationLists ::= SET OF CertificateList".

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: ESS Signed Receipt AuthAttributes Comment
Date: Mon, 17 Nov 1997 19:06:58 -0500
Sender: [email-masked]

I agree; option 2 is most flexible...

Regards,
Rich

----------
> From: John Pawling <[email-masked]>
> To: [email-masked]
> Subject: ESS Signed Receipt AuthAttributes Comment
> Date: Monday, November 17, 1997 4:33 PM
> 
> All,
> 
> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00),
Section
> 2.4, Receipt Creation, includes a description of how to calculate the
> signature value of a SignedData object encapsulating a Receipt content
(i.e.
> SignedData/Receipt).  This process does not include hashing the
> authenticatedAttributes taht might be included in the SignerInfo
containing
> the receipt signature value included in the SignedData/Receipt.  The last
> sentence of Section 2.4 states that the signingTime attribute should be
> included in the SignedData/Receipt.  However, ESS, Section 1.3.4.
Placement
> of Attributes, states that the signingTime attribute must be
authenticated.
> Therefore, the Section 2.4 SignedDataReceipt hashing process does not
> include authenticatedAttributes included in the SignedData/Receipt, yet
it
> recommends that the signingTime attribute should be included in the
> authenticatedAttributes of the SignedData/Receipt.  IMHO, this
contadiction
> needs to be corrected.
> 
> Recommend that ESS be changed in one of the following ways:
> 
> 1) Change last sentence of Section 2.4 to explictly state that the
> signingTime attribute should be included in the unauthenticatedAttributes
of
> the SignedData/Receipt (even though Section 1.3.4 states that signingTime
> must be authenticated).
> 
> - OR - 
> 
> 2) Change Section 2.4 so that it includes hashing the
> authenticatedAttributes included in the SignerInfo containing the receipt
> signature value included in the SignedData/Receipt.  (Note: The ESS
should
> also state that a SignedData/Receipt is not allowed to include
> receiptRequest or MLExpansionHistory attributes.)
> 
> I recommend option 2.
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 

Date: Mon, 17 Nov 1997 19:00:42 -0500
To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

All,

In the enclosed message, I stated:

"[JSP: How about if we defined RecipientKeyIdentifier as a
CertificateAssertion (rather than a sequence of subjectName and
CertificateAssertion) (except that I would like to see text in the CMS spec
prohibiting the use of the CertificateAssertion "pathToName" choice)??]"

I need to change this to:

[JSP: I don't believe that RecipientKeyIdentifier needs to be changed from
the existing CMS-01 syntax, because the RecipientIdentifier provides the
CHOICE of issuerAndSerialNumber and RecipientKeyIdentifier.  I believe that
the current CMS-01 syntax provides sufficient flexibility to uniquely
identify any X.509 Certificate.]

- John Pawling

>To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
>From: [email-masked] (John Pawling)
>Subject: Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
>Cc: [email-masked]
>
>Jim,
>
>Thank you for your responses.  My responses are in-line:
>
>[JSP] is: 
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>At 07:04 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
>>John,
>>
>>I accidently resent a message sent last week - I would apologise for this,
except
>>that resending it has generated some discussion! I don't think that you can
>>interpret the lack of discussion as a consensus against my proposals any more
>>than I could interpet it as a consensus in favour!
>
>[JSP: Agreed.]
>
>
>>> 1) Your module mentions the hashing of CER-encoded data.  I don't believe
>>> that the WG has approved of that option, so I recommend deleting any mention
>>> of CER.
>>
>>I recommend that the option is discussed before it is decided whether to
delete it!
>
>[JSP: Agree that this option needs to be further discussed.]
>
>
>>Note that CER encoding can always be used (though not necessarily
efficiently) even
>>if DER alone is specified, as a digestAlgorithm can be defined to decode
the DER and
>>re-encode in CER before applying the hash function. It is more efficient
to have the
>>digestAlgorithmIdentifier specify which of CER or DER is to be applied,
however.
>
>[JSP: Please note that many ASN.1 Tool kits do not support CER, so addition
of CER as a requirement will significantly increase the cost of complying
with the CMS spec.]
>
>
>>
>>> 
>>> 2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
>>> of digestAlgorithm and digest.  CMS, Section 5.4 does not mandate the
>>> inclusion of the digestAlgorithm in the message signature generation
>>> process.  In fact, only the digest itself is input to the DSS algorithm.  I
>>> recommend replacing your current SignatureValue, DigestInfo and Digest
>>> definitions with the definition of SignatureValue as an OCTET STRING.  The
>>> SignerInfo signatureAlgorithm will indicate exactly what data is to be
>>> encrypted to form the SignatureValue.  There should be appendices to CMS for
>>> DSS, RSA, Elliptical curve (future), etc.
>>
>>This depends on the extent to which CMS is to be compatable with PKCS#7, which
>>does mandate that the digestAlgorithm is included within the signature value.
>>While it would be possible to have the signatureAlgorithm define the structure
>>of the data that is signed, what is the benefit? 
>
>[JSP: The benefit is for the CMS to allow the DSS (aka DSA) signature
applied to a CMS SignedData object to be compliant with the 21 June 1996
ANSI X9.57, "Public Key Cryptography For The Financial Services Industry:
Certificate Management" specification which states:
>
>"5.3.	Signatures
>
>5.3.1.	Single Signatures
>
>Signatures are defined by the use of the SIGNED parameterized type, which
expands to a SEQUENCE of the data being signed, an algorithm identifier, and
a bit string which is the actual signature.  The SIGNED type, in turn, uses
the ENCRYPTED and HASHED types.  A public key encryption (or signature)
algorithm is applied to the hash of the data to be signed.
>
>HASHED {ToBeHashed} ::= OCTET STRING (CONSTRAINED BY {
>    -- must be the result of applying a hashing procedure to 
>    -- the DER-encoded octets of a value of
>    ToBeHashed })
>
>ENCRYPTED {ToBeEnciphered} ::= BIT STRING (CONSTRAINED BY {
>    -- must be the result of applying an encipherment
>    -- procedure to the DER-encoded octets of a value of
>    ToBeEnciphered })
>
>SIGNED {ToBeSigned}::=SEQUENCE {
>    data	   ToBeSigned, 
>    COMPONENTS OF  SIGNATURE {ToBeSigned} }
>
>SIGNATURE {OfSignature} ::= SEQUENCE {
>    algorithm	      AlgorithmIdentifier,
>    encryptedDigest   ENCRYPTED { HASHED {OfSignature} } }
>    -- For the DSA, the contents octets of the signature BIT STRING shall be 
>    -- interpreted as being the DER encoding of the type: 
>    --  SEQUENCE {
>    --	r	INTEGER,
>    --	s	INTEGER }
>
>The data to be signed is encoded using the ASN.1 distinguished encoding
rules (DER) as described in ANSI TG-9-199x, Abstract Syntax Notation and
Encoding Rules for Financial Industry Standards and X.509.  The complete
encoding is hashed using the hash algorithm implied by the signature
algorithm ID.  The complete encoding is hashed using the hash algorithm
implied by the signature algorithm ID.  The DSA is then used to sign the
hash, resulting in the signature.
>
>Notes:
>
>1) According to the definition above, the DSA is applied to the DER
encoding of the hash, which has a length of 22 bytes (tag, length, and
contents).  Since the input to the DSA signature process is only 160 bits,
the tag and length bytes of the DER encoding are not included in the
computation of the signature; only the actual contents of the encoding (the
hash) is signed.
>
>2) The SIGNED type does not include the signature algorithm identifier in
the signature computation.  In order to deter attacks based upon modifying
the hash or signature algorithm identifiers conveyed in the message,
applications using the SIGNED type should include the algorithm identifier
in the actual data being signed. 
>
>For the DSA, the contents octets of the signature BIT STRING shall be
interpreted as being the DER encoding of the type:
>
>SEQUENCE {
>r	INTEGER,
>s	INTEGER }
>
>That is, the encoding of the sequence is wrapped inside a BIT STRING."
>
>
>>Is there any reason not to
>>retain compatability with PKCS#7 here?
>
>[JSP: Yes for the aforementioned reason.]
>
>
>>> 
>>> 3) Your module includes "originatorCertificateSelector CertificateAssertion
>>> OPTIONAL" in RecipientInfo.  I don't believe that the WG has formed a
>>> consensus that originatorCertificateSelector must be a part of
>>> RecipientInfo.  I believe that omitting the originator cert and including
>>> originatorCertificateSelector in RecipientInfo adds significant complexity
>>> to an already complex protocol.
>>
>>I have not proposed omitting the originator certificate. I propose use of the
>>CertificateAssertion syntax since this is exactly the syntax used to select
>>certificates from a directory,
>
>[JSP: Agree with your proposal except that I would like to see text in the
CMS spec prohibiting the use of the CertificateAssertion "pathToName" choice.]
>
>
>>> 
>>> 4) I don't believe that the WG has approved of your definition of
>>> RecipientKeyIdentifier (including Name and CertificateAssertion) which is
>>> significantly more complicated than the current CMS defnition.
>>
>>Again, I would welcome some discussion of this.
>
>[JSP: How about if we defined RecipientKeyIdentifier as a
CertificateAssertion (rather than a sequence of subjectName and
CertificateAssertion) (except that I would like to see text in the CMS spec
prohibiting the use of the CertificateAssertion "pathToName" choice)??]
>
>
>>
>>Jim
>>
>

Date: Mon, 17 Nov 1997 16:33:42 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS Signed Receipt AuthAttributes Comment
Sender: [email-masked]

All,

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00), Section
2.4, Receipt Creation, includes a description of how to calculate the
signature value of a SignedData object encapsulating a Receipt content (i.e.
SignedData/Receipt).  This process does not include hashing the
authenticatedAttributes taht might be included in the SignerInfo containing
the receipt signature value included in the SignedData/Receipt.  The last
sentence of Section 2.4 states that the signingTime attribute should be
included in the SignedData/Receipt.  However, ESS, Section 1.3.4. Placement
of Attributes, states that the signingTime attribute must be authenticated.
Therefore, the Section 2.4 SignedDataReceipt hashing process does not
include authenticatedAttributes included in the SignedData/Receipt, yet it
recommends that the signingTime attribute should be included in the
authenticatedAttributes of the SignedData/Receipt.  IMHO, this contadiction
needs to be corrected.

Recommend that ESS be changed in one of the following ways:

1) Change last sentence of Section 2.4 to explictly state that the
signingTime attribute should be included in the unauthenticatedAttributes of
the SignedData/Receipt (even though Section 1.3.4 states that signingTime
must be authenticated).

- OR - 

2) Change Section 2.4 so that it includes hashing the
authenticatedAttributes included in the SignerInfo containing the receipt
signature value included in the SignedData/Receipt.  (Note: The ESS should
also state that a SignedData/Receipt is not allowed to include
receiptRequest or MLExpansionHistory attributes.)

I recommend option 2.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Mon, 17 Nov 1997 15:51:54 -0500
To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim,

Thank you for your responses.  My responses are in-line:

[JSP] is: 
================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 07:04 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
>John,
>
>I accidently resent a message sent last week - I would apologise for this,
except
>that resending it has generated some discussion! I don't think that you can
>interpret the lack of discussion as a consensus against my proposals any more
>than I could interpet it as a consensus in favour!

[JSP: Agreed.]

>> 1) Your module mentions the hashing of CER-encoded data.  I don't believe
>> that the WG has approved of that option, so I recommend deleting any mention
>> of CER.
>
>I recommend that the option is discussed before it is decided whether to
delete it!

[JSP: Agree that this option needs to be further discussed.]

>Note that CER encoding can always be used (though not necessarily
efficiently) even
>if DER alone is specified, as a digestAlgorithm can be defined to decode
the DER and
>re-encode in CER before applying the hash function. It is more efficient to
have the
>digestAlgorithmIdentifier specify which of CER or DER is to be applied,
however.

[JSP: Please note that many ASN.1 Tool kits do not support CER, so addition
of CER as a requirement will significantly increase the cost of complying
with the CMS spec.]

>
>> 
>> 2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
>> of digestAlgorithm and digest.  CMS, Section 5.4 does not mandate the
>> inclusion of the digestAlgorithm in the message signature generation
>> process.  In fact, only the digest itself is input to the DSS algorithm.  I
>> recommend replacing your current SignatureValue, DigestInfo and Digest
>> definitions with the definition of SignatureValue as an OCTET STRING.  The
>> SignerInfo signatureAlgorithm will indicate exactly what data is to be
>> encrypted to form the SignatureValue.  There should be appendices to CMS for
>> DSS, RSA, Elliptical curve (future), etc.
>
>This depends on the extent to which CMS is to be compatable with PKCS#7, which
>does mandate that the digestAlgorithm is included within the signature value.
>While it would be possible to have the signatureAlgorithm define the structure
>of the data that is signed, what is the benefit? 

[JSP: The benefit is for the CMS to allow the DSS (aka DSA) signature
applied to a CMS SignedData object to be compliant with the 21 June 1996
ANSI X9.57, "Public Key Cryptography For The Financial Services Industry:
Certificate Management" specification which states:

"5.3.	Signatures

5.3.1.	Single Signatures

Signatures are defined by the use of the SIGNED parameterized type, which
expands to a SEQUENCE of the data being signed, an algorithm identifier, and
a bit string which is the actual signature.  The SIGNED type, in turn, uses
the ENCRYPTED and HASHED types.  A public key encryption (or signature)
algorithm is applied to the hash of the data to be signed.

HASHED {ToBeHashed} ::= OCTET STRING (CONSTRAINED BY {
    -- must be the result of applying a hashing procedure to 
    -- the DER-encoded octets of a value of
    ToBeHashed })

ENCRYPTED {ToBeEnciphered} ::= BIT STRING (CONSTRAINED BY {
    -- must be the result of applying an encipherment
    -- procedure to the DER-encoded octets of a value of
    ToBeEnciphered })

SIGNED {ToBeSigned}::=SEQUENCE {
    data	   ToBeSigned, 
    COMPONENTS OF  SIGNATURE {ToBeSigned} }

SIGNATURE {OfSignature} ::= SEQUENCE {
    algorithm	      AlgorithmIdentifier,
    encryptedDigest   ENCRYPTED { HASHED {OfSignature} } }
    -- For the DSA, the contents octets of the signature BIT STRING shall be 
    -- interpreted as being the DER encoding of the type: 
    --  SEQUENCE {
    --	r	INTEGER,
    --	s	INTEGER }

The data to be signed is encoded using the ASN.1 distinguished encoding
rules (DER) as described in ANSI TG-9-199x, Abstract Syntax Notation and
Encoding Rules for Financial Industry Standards and X.509.  The complete
encoding is hashed using the hash algorithm implied by the signature
algorithm ID.  The complete encoding is hashed using the hash algorithm
implied by the signature algorithm ID.  The DSA is then used to sign the
hash, resulting in the signature.

Notes:

1) According to the definition above, the DSA is applied to the DER encoding
of the hash, which has a length of 22 bytes (tag, length, and contents).
Since the input to the DSA signature process is only 160 bits, the tag and
length bytes of the DER encoding are not included in the computation of the
signature; only the actual contents of the encoding (the hash) is signed.

2) The SIGNED type does not include the signature algorithm identifier in
the signature computation.  In order to deter attacks based upon modifying
the hash or signature algorithm identifiers conveyed in the message,
applications using the SIGNED type should include the algorithm identifier
in the actual data being signed. 

For the DSA, the contents octets of the signature BIT STRING shall be
interpreted as being the DER encoding of the type:

SEQUENCE {
r	INTEGER,
s	INTEGER }

That is, the encoding of the sequence is wrapped inside a BIT STRING."

>Is there any reason not to
>retain compatability with PKCS#7 here?

[JSP: Yes for the aforementioned reason.]

>> 
>> 3) Your module includes "originatorCertificateSelector CertificateAssertion
>> OPTIONAL" in RecipientInfo.  I don't believe that the WG has formed a
>> consensus that originatorCertificateSelector must be a part of
>> RecipientInfo.  I believe that omitting the originator cert and including
>> originatorCertificateSelector in RecipientInfo adds significant complexity
>> to an already complex protocol.
>
>I have not proposed omitting the originator certificate. I propose use of the
>CertificateAssertion syntax since this is exactly the syntax used to select
>certificates from a directory,

[JSP: Agree with your proposal except that I would like to see text in the
CMS spec prohibiting the use of the CertificateAssertion "pathToName" choice.]

>> 
>> 4) I don't believe that the WG has approved of your definition of
>> RecipientKeyIdentifier (including Name and CertificateAssertion) which is
>> significantly more complicated than the current CMS defnition.
>
>Again, I would welcome some discussion of this.

[JSP: How about if we defined RecipientKeyIdentifier as a
CertificateAssertion (rather than a sequence of subjectName and
CertificateAssertion) (except that I would like to see text in the CMS spec
prohibiting the use of the CertificateAssertion "pathToName" choice)??]

>
>Jim
>

Date: Mon, 17 Nov 1997 14:46:59 -0500
To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Re(2): Comments on the Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim and friends,

After reading the R-H requirements, I now agree with Jim that
"originatorCertificateSelector CertificateAssertion OPTIONAL" should be
added to the RecipientInfo SEQUENCE.

However, I have another concern as follows: CertificateAssertion includes
"pathToName" as an option.  X.509 describes "pathToName" as follows:
"pathToName matches unless the certificate has a name constraints extension
which inhibits the construction of a certification path to the presented
name value."  Do we really need the pathToName option in the
originatorCertificateSelector CertificateAssertion in the  RecipientInfo
SEQUENCE??  It adds significant complexity to the process of matching the
originator's key material with the recipientInfo.  Could we adopt Jim's
recommended solution with a caveat stating that "pathToName" is prohibited?

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 04:58 AM 11/14/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
>John,
>
>> I respectfully disagree with proposal #5 in the enclosed message trail that
>> "originator-certificate-selector" needs to be added to the RecipientInfo
>> SEQUENCE.  IMHO, there should only be a single originating entity that
>> protects keys for inclusion in the EnvelopedData ReceipientInfos.  That
>> single originating entity can include multiple key management certs in the
>> OriginatorInfo component of EnvelopedData.  For example, if the originator
>> has included both DH-protected and KEA-protected
>> copies of the content-encryption key in recipientInfos, then separate
>> certificates including the originator's KEA and DH public key material would
>> be present in originatorInfo.  The recieving agent can identify the correct
>> originator's cert from which to extract the public key to use to form the
>> pairwise key to decrypt a RecipientInfo encryptedKey by comparing the
>> keyEncryptionIdentifier with the subjectPublicKeyInfo algorithm identifier
>> in each of the originator's certs.
>
>What you say may be true for these algorithms. However, for Royal Holloway
algorithms the originator uses a send key which is different for each
recipient's CA - that is, the same originator send key can only be used for
multiple recipients who share a common CA. So in general the originator will
include several certificates for different public send keys for the same
algorithm - hence the need for the originator-certificate-selector.
>
>> 
>> IMHO, the addition of "originator-certificate-selector" to the
>> ReceipientInfo SEQUENCE adds needless complexity.  Furthermore, it allows
>> the syntax to support different originating entities protecting keys using
>> the same algorithm.  I don't believe that is a valid requirement.  
>
>
The requirement for originator-certificate-selector is not for the case of
different originating entities, although if the solution happens to support
this isn't that a bonus.
>
>Jim
>

Date: Mon, 17 Nov 1997 09:56:56 -0800
From: Karen Rosenthal <[email-masked]>
Organization: Premenos
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Receipt mechanism(s)
Sender: [email-masked]

Chuck,

Has there ever been any thought/discussion of pulling the signed receipt
section out of the MIME-based Secure EDI draft, and into a working
group/draft of its own?

The MDN based signed receipts address some of the issues coming up in
the S/MIME receipt discussions, are really not EDI specific.  Both the
S/MIME and PGP groups are looking for receipt mechanisms  (the former
obviously more actively), and there has been talk before of trying to
combine efforts between the two groups, where appropriate.

Sure, we can all support Message Disposition Notifications, S/MIME
receipts, some day PGP receipts, AUTACKs, etc, but is there not benefit
in a well developed, centralized and higher-level receipt mechanism?

Regards,
--
Karen Rosenthal               Email: [email-masked]
Premenos                      Tel#:  1-510-688-2928
1000 Burnett Ave              Fax#:  1-510-602-2133
Concord, CA  94520            Visit: http://www.premenos.com

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-01.txt
Date: Mon, 17 Nov 1997 10:27:24 -0500
Sender: [email-masked]

--NextPart

A Revised Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-01.txt
	Pages		: 18
	Date		: 14-Nov-97
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign or encrypt arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5.
   Wherever possible, backward compatibility is preserved; however,
   changes were necessary to accomodate attribute certificate transfer
   and key agreement techniques for key management.
 
   This drfat obosletes the previously released <draft-housley-smime-
   cms-00.txt>.
 
   This draft is being discussed on the ''ietf-smime'' mailing list. To
   subscribe, send a message to:
        [email-masked]
   with the single ''subscribe'' word in the body of the message. Also,
   there is a Web site for the mailing list at:
        <http://www.imc.org/ietf-smime/>.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-cms-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-01.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sat, 15 Nov 1997 10:11:21 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New version of the CMS draft is available
Sender: [email-masked]

The -01 version of the CMS draft is now available from
<http://www.imc.org/draft-ietf-smime-cms>. Note that the file name has
changed from "draft-housely-smime-cms" to "draft-ietf-smime-cms" due to the
fact that we're now a Working Group. Blake and I will submit new versions
of the other drafts this week, and the name change will take effect there too.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 14 Nov 1997 09:48:10 +0100
From: Wolfgang Schneider <[email-masked]>
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: S/MIME WG meeting at December IETF
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> My understanding from ftp://ftp.ietf.org/ietf/0mtg-agenda.txt is that
> December 10 from 1530-1730 is the S/MIME WG meeting.  The slot seems
> excellent from the point of view that there aren't any other
> security-related things meeting at the same time.

I read from Steve Kent's mail that the PKIX group meets at
exactly the same time.

Wolfgang Schneider

Stephen Kent wrote:
> 
> Folks,
> 
>         There has been a schedule change for our Wednesday, to minimize
> overlaps with other WG meetings that are of interest to PKIX WG members.
> 
>         We will still meet on Monday from 9:30-11:30, as before.  Our
> second slot, still on Wednesday, is now at 1530-1730 opposite ip1394, rtfm,
> bmwg, mpls.
> 
> Steve

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 14 Nov 97  7:04:54 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Fri, 14 Nov 97  7:04:54 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971114070454-639A]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Fri, 14 Nov 97  7:04:54 +0000
X400-Content-Identifier: Re(2): A draft A
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "John Pawling" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

John,

I accidently resent a message sent last week - I would apologise for this, except
that resending it has generated some discussion! I don't think that you can
interpret the lack of discussion as a consensus against my proposals any more
than I could interpet it as a consensus in favour!

> 1) Your module mentions the hashing of CER-encoded data.  I don't believe
> that the WG has approved of that option, so I recommend deleting any mention
> of CER.

I recommend that the option is discussed before it is decided whether to delete it!

Note that CER encoding can always be used (though not necessarily efficiently) even
if DER alone is specified, as a digestAlgorithm can be defined to decode the DER and
re-encode in CER before applying the hash function. It is more efficient to have the
digestAlgorithmIdentifier specify which of CER or DER is to be applied, however.

> 
> 2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
> of digestAlgorithm and digest.  CMS, Section 5.4 does not mandate the
> inclusion of the digestAlgorithm in the message signature generation
> process.  In fact, only the digest itself is input to the DSS algorithm.  I
> recommend replacing your current SignatureValue, DigestInfo and Digest
> definitions with the definition of SignatureValue as an OCTET STRING.  The
> SignerInfo signatureAlgorithm will indicate exactly what data is to be
> encrypted to form the SignatureValue.  There should be appendices to CMS for
> DSS, RSA, Elliptical curve (future), etc.

This depends on the extent to which CMS is to be compatable with PKCS#7, which
does mandate that the digestAlgorithm is included within the signature value.
While it would be possible to have the signatureAlgorithm define the structure
of the data that is signed, what is the benefit? Is there any reason not to
retain compatability with PKCS#7 here?

> 
> 3) Your module includes "originatorCertificateSelector CertificateAssertion
> OPTIONAL" in RecipientInfo.  I don't believe that the WG has formed a
> consensus that originatorCertificateSelector must be a part of
> RecipientInfo.  I believe that omitting the originator cert and including
> originatorCertificateSelector in RecipientInfo adds significant complexity
> to an already complex protocol.

I have not proposed omitting the originator certificate. I propose use of the
CertificateAssertion syntax since this is exactly the syntax used to select
certificates from a directory,

> 
> 4) I don't believe that the WG has approved of your definition of
> RecipientKeyIdentifier (including Name and CertificateAssertion) which is
> significantly more complicated than the current CMS defnition.

Again, I would welcome some discussion of this.

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 14 Nov 97  6:00:03 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Fri, 14 Nov 97  6:00:03 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971114060003-6199]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Fri, 14 Nov 97  6:00:03 +0000
X400-Content-Identifier: Re(2): A draft A
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

> Jim:
> 
> Thanks.  Can you provide 1988 syntax?
> 
> Russ

Not if you want to use version 3 certificates. Using 1988 ASN.1 would limit you to using only version 1 certificates, as there is no conceivable way to write constraints on version 2 or version 3 certificates (which are defined in 1994 ASN.1) to use only 1988 compatable ASN.1.

As noted by Phil Griffin a week ago, you cannot (for obvious reasons) import into 1988 ASN.1 types which use features which were not defined in 1988 ASN.1.

> There are a few syntax errors in the ASN.1, a draft and WIP, but my
> real concern is the mixing of ASN.1:1988/90 and the current standard,
> ASN.1:1994. By my reading, the current standard states that the two 
> can not be mixed in X.680, section A.2, "Mixing ASN.1-88/90 and 
> current ASN.1 notation":
> 
>  "Both the ASN.1-88/90 and the current ASN.1 notation specify a
>  top-level syntactic construct which is an ASN.1 module. A user of 
>  ASN.1 writes a collection of ASN.1 modules, and may import 
>  definitions from other ASN.1 modules."
> 
> [snip PHG]
> 
>  "Where a module conforms to the ASN.1-88/90 notation, type and value 
>  references may be imported from a module that was defined using the
>  current notation. Such types and values must be associated with types 
>  that can be defined using only the ASN.1-88/90 notation. For example, 
>  a module written using the ASN.1-88/90 notation cannot import a value 
>  of type UniversalString, since this type is defined in the current 
>  notation but not in ASN.1-88/90;  it can, however, import values whose 
>  types are, for example, INTEGER, IA5String, etc."
> 
> Both BMPString and UniversalString are types defined only in the 
> current standard, ASN.1:1994. The S/MIME work is not alone in this
> problem. I've just finished creating ASN.1:1994 definitions for PKCS
> #12. It too attempts to use BMPString in code that uses the 
> superceded ANY DEFINED BY, which is described in Annex I (not an 
> intgral part of the ASN.1 standards). The current PKIX work also
> attempts to merge the standards.
> 
> Such ASN.1 usage will certainly break tools that correctly implement 
> the ASN.1 standards. I'm not sure why there's so much reluctance to
> migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
> specifications than X.208-X.209. 
> 
> An alternative would be to drop national language support and keep
> using ASN.1:1988/90. 
> 
> Phil
> -- 
> Phillip H. Griffin         

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 14 Nov 97  4:58:22 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Fri, 14 Nov 97  4:58:21 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971114045821-530A]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Fri, 14 Nov 97  4:58:21 +0000
X400-Content-Identifier: Re(2): Comments 
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "John Pawling" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, [email-masked]
Subject: Re(2): Comments on the Cryptographic Message Syntax
Sender: [email-masked]

John,

> I respectfully disagree with proposal #5 in the enclosed message trail that
> "originator-certificate-selector" needs to be added to the RecipientInfo
> SEQUENCE.  IMHO, there should only be a single originating entity that
> protects keys for inclusion in the EnvelopedData ReceipientInfos.  That
> single originating entity can include multiple key management certs in the
> OriginatorInfo component of EnvelopedData.  For example, if the originator
> has included both DH-protected and KEA-protected
> copies of the content-encryption key in recipientInfos, then separate
> certificates including the originator's KEA and DH public key material would
> be present in originatorInfo.  The recieving agent can identify the correct
> originator's cert from which to extract the public key to use to form the
> pairwise key to decrypt a RecipientInfo encryptedKey by comparing the
> keyEncryptionIdentifier with the subjectPublicKeyInfo algorithm identifier
> in each of the originator's certs.

What you say may be true for these algorithms. However, for Royal Holloway algorithms the originator uses a send key which is different for each recipient's CA - that is, the same originator send key can only be used for multiple recipients who share a common CA. So in general the originator will include several certificates for different public send keys for the same algorithm - hence the need for the originator-certificate-selector.

> 
> IMHO, the addition of "originator-certificate-selector" to the
> ReceipientInfo SEQUENCE adds needless complexity.  Furthermore, it allows
> the syntax to support different originating entities protecting keys using
> the same algorithm.  I don't believe that is a valid requirement.  

The requirement for originator-certificate-selector is not for the case of different originating entities, although if the solution happens to support this isn't that a bonus.

Jim

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Fri, 14 Nov 97  4:19:13 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Fri, 14 Nov 97  4:19:13 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971114041913-2C8B]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Fri, 14 Nov 97  4:19:13 +0000
X400-Content-Identifier: Re(2): Comments 
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: "Russ Housley" <[email-masked]>
Cc: [email-masked]
Subject: Re(2): Comments on the Cryptographic Message Syntax
Sender: [email-masked]

Russ

> 
> >Some comments on the Cryptographic Message Syntax spec:
> >
> >1. ASN.1 Canonical Encoding Rules should be allowed
> >
> >>                                                            Single-
> >>    pass operation has one significant drawback; it is difficult to
> >>    perform encode operations using the Distinguished Encoding Rules
> >>    (DER) encoding in a single pass since the lengths of the various
> >>    components may not be known in advance. Since DER encoding is
> >>    required by the signed-data content type, an extra pass may be
> >>    necessary when a content type other than data is encapsulated.
> >
> >Why does the signed-data content type require DER? Why doesn't it allow
> >the choice of CER or DER, with the digest algorithm-identifier indicating
> >which? For example, SHA-1 on the CER encoding would have a different 
> >algorithm-identifier to SHA-1 on the DER encoding. [For anyone unfamiliar
> >with CER, it is defined in the 1994 version of ASN.1, and is identical to
> >DER except that CER uses indefinite length encoding (which permits 
> >single-pass encoding) and constructed encoding of strings.]
> 
> Does CER prohibit definite length encoding?  If not, there would be more
> than one way to enocde the same structure.

Yes. CER requires indefinite length for constructed encodings, and prohibits definite length for constructed encodings. Like DER, CER gives a unique encoding of any structure.

> 
> >2. There is an ambiguity about which octets are input to hash and
> encryption algorithms
> >
> >>    The message digest calculation process computes a message digest on
> >>    either the content being signed or the content together with the
> >>    signer's authenticated attributes. In either case, the initial input
> >>    to the message digest calculation process is the "value" of the
> >>    content being signed. Specifically, the initial input is the content
> >>    octets of the DER encoding of the content field of the ContentInfo
> >>    value to which the signing process is applied. Only the contents
> >>    octets of the DER encoding of that field are input to the message
> >>    digest algoritm, not the identifier octets or the length octets.
> >> 
> >>    When the content being signed has content type data and the
> >>    authenticatedAttributes field is absent, then just the value of the
> >>    data (e.g., the contents of a file) is input to the message digest
> >>    calculation. This has the advantage that the length of the content
> >>    being signed need not be known in advance of the encryption process.
> >> 
> >>    Although the identifier octets and the length octets are not included
> >>    in the message digest calculation, they are still protected by other
> >>    means. The length octets are protected by the nature of the message
> >>    digest algorithm since it is computationally infeasible to find any
> >>    two distinct messages of any length that have the same message
> >>    digest.
> >> 
> >
> >The first of the three paragraphs above says something different about 
> >which octets are input into the hash function than the implication of 
> >the second and third paragraphs. Consider the encoding of the content 
> >field of the ContentInfo in the following examples:
> >
> >For the data content type:
> >
> >Identifier      Length  Contents
> >[0]             nnn     
> >                        Identifier      Length  Contents
> >                        OctetString     nnn     xxxxxxxxx
> >
> >
> >For the signed-data content type:
> >
> >Identifier      Length  Contents
> >[0]             nnn     
> >                        Identifier      Length  Contents
> >                        Sequence        nnn     
> >                                                Identifier      Length  Contents
> >                                                Integer         1       1
> >
> >
> >The first paragraph above says that it is the contents octets of the 
> >content field which is input to the hash function - i.e. octets starting
> >with the identifier for OctetString in the case of the data content type
> >- but the second paragraph implies that it is just the contents octets 
> >of this OctetString. Should the first paragraph be changed to replace 
> >"content octets of the DER encoding of the content field" by "DER 
> >encoding of the content octets of the type within the content field"? 
> >That is, does the input to the hash start with the identifier for 
> >Integer in the case of signed-data?
> 
> I read the first paragrph three times.  I do not see the issue.  Maybe you
> can try explaining it again....

Perhaps I'll try a concrete example to illustrate. Consider the data string "Hello" whose characters are represented by the octets 48656C6C6F. This is encoded into an ASN.1 Octet String as 040548656C6C6F. If this is a Data Content Type, it is encoded in the content field of a ContentInfo as A007040548656C6C6F.

The first paragraph says "the input [to the hash function] is the content octets of the DER encoding of the content field of the ContentInfo" - that means strip of the identifier and length octets from the encoding of the content field to give 040548656C6C6F as the input to the hash function. However, the second paragraph extracted above suggests that the input to the hash function is just 48656C6C6F.

> 
> >3. User Keying Materials
> >
> >Surely these should be included within the parameters component of the
> >algorithm-identifier for algorithms which require such material.
> 
> No.  The following structure is present for each recipient:
> 
>   RecipientInfo ::= SEQUENCE {
>     version Version,
>     rid RecipientIdentifier,
>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>     encryptedKey EncryptedKey }
> 
> If the UKM is carried in the KeyEncryptionAlgorithmIdentifier, then it is
> carried several times, once for each recipient.  UKMs can be large (128
> bytes), so we want to carry it once for all of the recipients that use that
> form of key management.

You are adding additional overhead when there is only one recipient using that form of key management (as the algorithm-identifier is carried twice in your encoding) and some processing complexity in all cases (the receiver needs a local table to indicate for which algorithms to search for UKM) in order to achieve a small saving in message size when multiple recipients use the same form of key management.

You are also assuming that all algorithms that may use UKM will require the same UKM data for all recipients. This seems an unsafe assumption.

> 
> >4. RecipientKeyIdentifier
> >
> >RecipientKeyIdentifier is not an adequate identification of a recipient, 
> >since subjectKeyIdentifier is only unique within the scope of an 
> >individual recipient, and it is not accompanied by any other 
> >identification of the recipient. I suggest that the more general 
> >CertificateAssertion syntax from X.509 should be used instead of the 
> >restrictive subjectKeyIdentifier:
> >
> >     RecipientKeyIdentifier ::= SEQUENCE {
> >          recipient-name                  Name,
> >          recipient-certificate-selector  CertificateAssertion}
> 
> Within the set of recipients, the subject key identifier should narrow the
> "hits" significantly.  In the unlikely event that there is more than one
> recipinet with the same subject key identifier, then the recipient can try
> each "hit."

Why do you consider more than one recipient with the same subject key identifier to be an unlikely event? The subject key identifier might simply be an incremental counter of the certificates issued by a CA to each user, or the date on which the certificate was issued - in these cases several recipients having the same value would seem quite likely. Why not allow the recipient's name to be present?

> 
> >5. Originator Certificate selection
> >
> >Some key agreement algorithms use different originator keys for different
> >recipients. It is therefore necessary to add an originator-certificate-
> >selector to RecipientInfo:
> >
> >     RecipientInfo ::= SEQUENCE {
> >          version Version,
> >          rid RecipientIdentifier,
> >          keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
> >          encryptedKey EncryptedKey,
> >          originator-certificate-selector CertificateAssertion OPTIONAL }
> 
> Okay, but I think that the location within the structure might be
> incorrect.  It needs to come sooner to accompdate single-pass processing.

OK

> 
> Please send me the ASN.1 for CertificateAssertion.

Attached

> 
> Russ

Jim

CertificateAssertion ::= SEQUENCE {
        serialNumber            [0] CertificateSerialNumber     OPTIONAL,
        issuer                  [1] Name                        OPTIONAL,
        subjectKeyIdentifier    [2] SubjectKeyIdentifier        OPTIONAL,
        authorityKeyIdentifier  [3] AuthorityKeyIdentifier      OPTIONAL,
        certificateValid        [4] UTCTime                     OPTIONAL,
        privateKeyValid         [5] GeneralizedTime             OPTIONAL,
        subjectPublicKeyAlgID   [6] OBJECT IDENTIFIER           OPTIONAL,
        keyUsage                [7] KeyUsage                    OPTIONAL,
        subjectAltName          [8] AltNameType                 OPTIONAL,
        policy                  [9] CertPolicySet               OPTIONAL,
        pathToName              [10] Name                       OPTIONAL }

AltNameType ::= CHOICE { 
        builtinNameForm ENUMERATED {
                                rfc822Name                      (1),
                                dNSName                         (2),
                                x400Address                     (3),
                                directoryName                   (4),
                                ediPartyName                    (5),
                                uniformResourceIdentifier       (6),
                                iPAddress                       (7),
                                registeredId                    (8) },
        otherNameForm   OBJECT IDENTIFIER }

Date: Thu, 13 Nov 1997 23:15:42 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

Russ Housley wrote:
> 
> Phil:
> 
> I hate SET OF too.  However, I wonder if this example will really be that
> complex.  I suspect that the number of elements in the SET will be quite
> small.  In practice, the SecurityCategories OID will define a structure
> that represents several security categories.  Given this situation, is it
> worth the effort to add the CHOICE.
>

It's not worth the effort. I favor John Pawling's 
arguments and agree it should not be changed.

Phil

> What do others on the list think?
> 
> Russ
> 
> At 04:20 PM 11/5/97 -0500, Phillip H. Griffin wrote:
> >John Pawling wrote:
> >>
> >> Phil,
> >>
> >> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> >> international standard representation of security label and it is used by
> >> many existing programs.  The X.411 SecurityLabel syntax includes
> >> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> >> with X.411, it should not be changed.
> >>
> >> ================================
> >> John Pawling
> >> [email-masked]
> >> J.G. Van Dyke & Associates, Inc.
> >> ================================
> >>
> >
> >I agree that no change should be made that breaks backwards
> >compatibility, but it would be possible, if accompanied with
> >a change in version, to alter the definition to
> >
> >  SecurityCategories ::= CHOICE {
> >    setOf  SET SIZE (1..ub-security-categories) OF
> >                               SecurityCategory,
> >    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
> >                               SecurityCategory
> >  }
> >
> >  ub-security-categories INTEGER ::= 64
> >
> >so that no additional tagging were needed to distinguish
> >between the two types. If typically the SET OF size is
> >small and the data easy to sort, it probably wouldn't
> >be worth the effort.
> >
> >> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >> >The type defined as
> >> >
> >> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >> >                             SecurityCategory
> >> >
> >> >requires sorting under DER that would not be required if the
> >> >type were defined as a SEQUENCE OF.
> >> >
> >> >X.690, which defines DER restrictions in section 11, "Restrictions
> >> >on BER employed by both CER and DER", states that for components of
> >> >type SET OF, "The encodings of the component values of a set-of
> >> >value shall appear in ascending order, the encodings being compared
> >> >as octet strings."
> >> >
> >> >Under DER, with SEQUENCE OF, the sender can control the order
> >> >of components, but with SET OF, the final sort requirement rules,
> >> >and sometimes may add unanticipated overhead to message processing.
> >> >It was primarily for this reason, the the SET specification is
> >> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >> >types like
> >> >
> >> >  Certificates ::= SEQUENCE OF Certificate
> >> >
> >> >and avoid sorting what (hopefully) might be efficiently
> >> >organized certificate chains in SignedData. Same for the CRLs
> >> >and Attributes definitions.
> >> >
> >> >Phil
> >
> >Phil
> >--
> >Phillip H. Griffin
> >ASN.1-SET-Java-Security    Griffin Consulting
> >[email-masked]        1625 Glenwood Avenue
> >919.828.7114               Raleigh, North Carolina 27608 USA
> >------------------------------------------------------------
> >          Visit  http://www.fivepointsfestival.com
> >------------------------------------------------------------
> >

-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Thu, 13 Nov 1997 19:10:05 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Even newer versions of the drafts
Sender: [email-masked]

Well, it's nice to know that the most important work we have left to do on
v2 is dealing with capitalization. :-)

Does everyone agree with Jim's thourough study of the matter? If so, I'm
feeling like turning the drafts in this weekend as final for the
informational RFC. Of course, the RFC editor or the IESG may kick them back
for any of a number of reasons, but I think capitalization isn't one of them.

SpEaK uP nOw If YoU hAvE oBjEcTiOnS.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Even newer versions of the drafts
Date: Thu, 13 Nov 1997 18:45:06 -0800
Sender: [email-masked]

OK here is my concept of where things are and how to fix the
SMIMECaptabliites naming problem:

1.  The OID should be refered to by the smimeCapibilities name. (Like
Blake I want to spite the standard, but I don't want to live with the
result.)
	This changes appendix  A.5 to
	smimeCapabilities OBJECT IDENTIFIER ::= ....
	
2.  The ASN structures is referenced by the name SMIMECapabilities
	This changes appendix A to
	SMIMECapabilities := SEQUENCE OF SMIMECapability

3.  The Attribute (which is the combination of the capabilities and the
OID) is referenced by the name S/MIME Capabilities Attribute. 

The attribute name references is consistant with what is done in section
2.5.1 with the Signing-Time Attrbute (neither the OID or the ASN is
specified here).  It also seperates the pair of items from the indivual
items.

Thus 2.5.2 becomes (note that I have done more changes than just
changing sMIMECapabilies to S/MIME Capabilies, I have also adjusted some
wording as well).

2.5.2 S/MIME Capabilities Attribute

The S/MIME capabilities attribute includes signature algorithms (such as
"md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"), and
key
encipherment algorithms (such as "rsaEncryption"). It also includes a
non-algorithm capability which is the preference for signedData.
SMIMECapabilities was
designed to be flexible and extensible so that, in
the future, a means of identifying other capabilities and preferences
such
as certificates can be added in a way that will not cause current
clients
to break.

The semantics of the S/MIME capabilites attribute specify a partial list
as
to what the client announcing the SMIMECapabilites can support. A client
does not have to list every capability it supports, and probably should
not
list all its capabilities so that the capabilities list doesn't get too
long. In an SMIMECapabilities encoding, the OIDs are listed in order of
their preference, but SHOULD be logically separated along the lines of
their categories (signature algorithms, symmetric algorithms, key
encipherment algorithms, etc.)

The structure of  SMIMECapabilities was designed to facilitate simple
table lookups and binary comparisons in order to determine matches. For
instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST
be
identically encoded regardless of the implementation.

In the case of symmetric algorithms, the associated parameters for the
OID
MUST specify all of the parameters necessary to differentiate between
two
instances of the same algorithm. For instance, the number of rounds and
block size for RC5 must be specified in addition to the key length.

There is a list of OIDs (the registered SMIMECapability list) that is
centrally maintained and is separate from this draft. The list of OIDs
is
maintained by the Internet Mail Consortium at
<http://www.imc.org/ietf-smime/oids.html>.

The OIDs that correspond to algorithms SHOULD use the same OID as the
actual algorithm, except in the case where the algorithm usage is
ambiguous
from the OID. For instance, in an earlier draft, rsaEncryption was
ambiguous because it could refer to either a signature algorithm or a
key
encipherment algorithm. In the event that an OID is ambiguous, it needs
to
be arbitrated by the maintainer of the registered S/MIME capabilities
list as
to which type of algorithm will use the OID, and a new OID MUST be
allocated under the smimeCapabilities OID to satisfy the other use of
the
OID.

The registered S/MIME capabilities list specifies the parameters for
OIDs
that need them, most notably key lengths in the case of variable-length
symmetric ciphers. In the event that there are no differentiating
parameters for a particular OID, the parameters MUST be omitted, and
MUST
NOT be encoded as NULL.

Additional values for SMIMECapability may be defined in the
future. Receiving agents MUST handle a SMIMECapabilities object that has
values that it does not recognize in a graceful manner.

From: "Blake Ramsdell" <[email-masked]>
To: "'Carlisle Adams'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Thu, 13 Nov 1997 15:41:03 -0800
Sender: [email-masked]

On Thursday, November 13, 1997 2:52 PM, Carlisle Adams
[SMTP:[email-masked]] wrote:
> I've seen no response to my suggestion that TimeStampToken could be an
> additional way to specify signing time for a document (which makes me
> wonder if that message actually made it to the list).

In my case I saw this, but I believe that it is solving a different
problem.  We can certainly discuss this more within the context of "how
are we going to solve the problem of trusted time stamps from a
third-party time stamp authority", but I think the concern at hand was
fixing the SigningTime attribute which is the sender's unverified
opinion as to when he sent a message.

As an aside, I think we should talk about this some more because I like
the idea.

> I'm not necessarily proposing that this get added to the S/MIME
> specification yet (since the time stamp work is still in its early
> stages), but this does argue in favor of the CHOICE construct, since
> additional choices can then be added in the future without much trouble.

But I think that the TimeStampToken goes into a different attribute, not
the SigningTime attribute.  Is that not the case?  The decision for the
CHOICE for signingTime probably shouldn't affect TimeStampToken.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 13 Nov 1997 15:39:07 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME WG meeting at December IETF
Sender: [email-masked]

>According to Steve Kent the second PXIX I session is scheduled for 10 Nov
>between 1530-1730.  Murphy strikes again.

The current schedule that Blake points to has the second PKIX session on
Wednesday from 1300-1500, with S/MIME on Wednesday from 1530-1730. The
first PKIX session in Monday from 930-1130. Russ explicitly asked for
S/MIME to *not* conflict with PKIX, so I'd be surprized if this has changed.

For those of you new to the IETF, WG meetings shuffle madly up to about a
week before the meeting, so don't buy a one-day plane ticket yet. Things
can and will shift. Check <ftp://ftp.ietf.org/ietf/0mtg-agenda.txt> often.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Thu, 13 Nov 1997 17:51:51 -0500
Sender: [email-masked]

All,

I've seen no response to my suggestion that TimeStampToken could be an
additional way to specify signing time for a document (which makes me
wonder if that message actually made it to the list).

I'm not necessarily proposing that this get added to the S/MIME
specification yet (since the time stamp work is still in its early
stages), but this does argue in favor of the CHOICE construct, since
additional choices can then be added in the future without much trouble.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Thursday, November 13, 1997 2:11 PM
>To: 	[email-masked]; [email-masked]
>Subject: 	RE: SigningTime
>
>All,
>
>I now agree with Dave and Blake's original argument that the SigningTime
>should be defined as a CHOICE of UTCTime or GeneralizedTime.  I agree with
>Dave's point that it is straightforward for the decoding software to examine
>the Tag field of the SigningTime to determine if the time is encoded as a
>UTCTime or GeneralizedTime.  
>
>In summary, all of the PKCS #9 attribute syntaxes and OIDs need to be copied
>to an IETF-controlled S/MIME-related spec.  When that happens, the
>SigningTime needs to be changed to the following syntax:
>
>CHOICE {
>  utcTime           UTCTime,
>  generalizedTime   GeneralizedTime }
>
>I assume that we want to adopt text similar to PKIX I such as:
>
>When encoding the SigningTime attribute, sending agents MUST encode dates
>through the year 2049 as UTCTime and MUST encode dates in 2050 or later as
>GeneralizedTime.
>
>- John Pawling  
>

Date: Thu, 13 Nov 1997 17:55:29 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: S/MIME WG meeting at December IETF
Sender: [email-masked]

All,

According to Steve Kent the second PXIX I session is scheduled for 10 Nov
between 1530-1730.  Murphy strikes again.

- John Pawling

At 02:33 PM 11/13/97 -0800, Blake Ramsdell wrote:
>My understanding from ftp://ftp.ietf.org/ietf/0mtg-agenda.txt is that
>December 10 from 1530-1730 is the S/MIME WG meeting.  The slot seems
>excellent from the point of view that there aren't any other
>security-related things meeting at the same time.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Thu, 13 Nov 1997 14:50:52 -0800
Sender: [email-masked]

On Thursday, November 13, 1997 2:32 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> I believe that the intention of the WG is to use the existing PKCS #9
> SigningTime OID for the new syntax so that legacy S/MIME v2 apps will
> recognize the SigningTime attribute.  The 2049 rule would give all vendors
> 52 years to upgrade their legacy products to recognize the GenTime choice.

This is my understanding also, in light of the recent discussion.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME WG meeting at December IETF
Date: Thu, 13 Nov 1997 14:33:49 -0800
Sender: [email-masked]

My understanding from ftp://ftp.ietf.org/ietf/0mtg-agenda.txt is that
December 10 from 1530-1730 is the S/MIME WG meeting.  The slot seems
excellent from the point of view that there aren't any other
security-related things meeting at the same time.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 13 Nov 1997 17:32:22 -0500
To: [email-masked], [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: SigningTime
Sender: [email-masked]

Phil,

I believe that the intention of the WG is to use the existing PKCS #9
SigningTime OID for the new syntax so that legacy S/MIME v2 apps will
recognize the SigningTime attribute.  The 2049 rule would give all vendors
52 years to upgrade their legacy products to recognize the GenTime choice.
 
- John Pawling

At 04:38 PM 11/13/97 -0500, [email-masked] wrote:
>Since the proposed choice type SigningTime will be a different
>type that that defined by RSA in PKCS #9, will there be a new
>S/MIME OID assigned to this type?
>
>John Pawling wrote:
>> 
>> All,
>> 
>> I now agree with Dave and Blake's original argument that the SigningTime
>> should be defined as a CHOICE of UTCTime or GeneralizedTime.  I agree with
>> Dave's point that it is straightforward for the decoding software to examine
>> the Tag field of the SigningTime to determine if the time is encoded as a
>> UTCTime or GeneralizedTime.
>> 
>> In summary, all of the PKCS #9 attribute syntaxes and OIDs need to be copied
>> to an IETF-controlled S/MIME-related spec.  When that happens, the
>> SigningTime needs to be changed to the following syntax:
>> 
>> CHOICE {
>>   utcTime           UTCTime,
>>   generalizedTime   GeneralizedTime }
>> 
>> I assume that we want to adopt text similar to PKIX I such as:
>> 
>> When encoding the SigningTime attribute, sending agents MUST encode dates
>> through the year 2049 as UTCTime and MUST encode dates in 2050 or later as
>> GeneralizedTime.
>> 
>> - John Pawling
>> 
>> At 12:51 PM 11/13/97 -0500, David P. Kemp wrote:
>> >> From: "Blake Ramsdell" <[email-masked]>
>> >>
>> >> > Constructing the ChoiceOfTime is the easy part.  My point is that it
adds
>> >> > complexity to the SignedData decoding software that must determine which
>> >> > choice was chosen.  For example, in 2051, our code will need to be
able to
>> >> > decode stored SignedData objects some of which include SigningTime with
>> >> > UTCTime choice and others that include SigningTime with GeneralizedTime
>> >> > choice.  Sure, there are ways of determining which choice was
chosen, but
>> >> > the OID check for the signingTime or NewSigningTime attributes would be
>> >> > quicker and easier.
>> >>
>> >> I understand.  Point taken.
>> >>
>> >> > In the signingTime or NewSigningTime attributes environment, you
could use
>> >> > an equivalent strategy to ensure backwards compatibility by
including the
>> >> > signingTime (UTCTime) attribute in SignedData objects generated thru the
>> >> > year 2049 and including newSigningTime (GeneralizedTime) in SignedData
>> >> > objects generated on 2050 or after.  Using this strategy, in 2051,  the
>> >> > software can easily determine which flavor of signing time was included
>> in a
>> >> > SignedData object simply by examining the attribute OID.
>> >>
>> >> Yup -- I agree with this.  This does sound better.
>> >
>> >
>> >I agree with the goal of reducing complexity, but I believe having two
>> >different OIDs is more complex than having only a single OID.
>> >
>> >There are (at least) three ways of determining the encoding of the
>> >SigningTime field:  examining the attribute OID (SigningTime or
>> >NewSigningTime), examining the BER tag code (UTCTime or GeneralizedTime),
>> >or examining the time string itself.  For the 2051 example where either
>> >choice may be present, it's easiest to examine the one byte tag type,
>> >rather than to match against two different attribute OIDs or parse
>> >the time string.
>> >
>> >If Blake & John are now agreed that two attributes are better than one,
>> >I'm not against it.  But IMHO adding a NewSigningTime attribute both:
>> >
>> > * makes the spec uglier (having two different attributes to accomplish
>> >    the identical functionality, just using different syntax), and
>> > * makes the resulting software more complex.
>> >
>
>Phil
>-- 
>Phillip H. Griffin         Griffin Consulting
>[email-masked]        ASN.1-SET-Java-Security
>919.828.7114               1625 Glenwood Avenue
>919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>
>

Date: Thu, 13 Nov 1997 17:29:05 -0500
To: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

Jim,

Thank you very much for sending your proposed CMS module.  I have a few
comments:

1) Your module mentions the hashing of CER-encoded data.  I don't believe
that the WG has approved of that option, so I recommend deleting any mention
of CER.

2) Your module mandates that a SignatureValue must be an ENCRYPTED SEQUENCE
of digestAlgorithm and digest.  CMS, Section 5.4 does not mandate the
inclusion of the digestAlgorithm in the message signature generation
process.  In fact, only the digest itself is input to the DSS algorithm.  I
recommend replacing your current SignatureValue, DigestInfo and Digest
definitions with the definition of SignatureValue as an OCTET STRING.  The
SignerInfo signatureAlgorithm will indicate exactly what data is to be
encrypted to form the SignatureValue.  There should be appendices to CMS for
DSS, RSA, Elliptical curve (future), etc.

3) Your module includes "originatorCertificateSelector CertificateAssertion
OPTIONAL" in RecipientInfo.  I don't believe that the WG has formed a
consensus that originatorCertificateSelector must be a part of
RecipientInfo.  I believe that omitting the originator cert and including
originatorCertificateSelector in RecipientInfo adds significant complexity
to an already complex protocol.  It doesn't take many
originatorCertificateSelector fields to exceed the size of the originator's
cert.  For those unfamiliar with CertificateAssertion, here is the definition:

CertificateAssertion ::= SEQUENCE {
	serialNumber		[0] CertificateSerialNumber	OPTIONAL,
	issuer			[1] Name 			OPTIONAL,
	subjectKeyIdentifier	[2] SubjectKeyIdentifier	OPTIONAL,
	authorityKeyIdentifier	[3] AuthorityKeyIdentifier 	OPTIONAL,
	certificateValid	[4] Time			OPTIONAL,
	privateKeyValid		[5] GeneralizedTime		OPTIONAL,
	subjectPublicKeyAlgID	[6] OBJECT IDENTIFIER		OPTIONAL,
	keyUsage		[7] KeyUsage			OPTIONAL,
	subjectAltName		[8] AltNameType		        OPTIONAL,
	policy			[9] CertPolicySet		OPTIONAL,
	pathToName		[10] Name			OPTIONAL }

AltNameType ::= CHOICE { 
	builtinNameForm	ENUMERATED {
		rfc822Name		  (1),
		dNSName		          (2),
		x400Address		  (3),
		directoryName	          (4),
		ediPartyName		  (5),
		uniformResourceIdentifier (6),
		iPAddress		  (7),
		registeredId	  	  (8) },

4) I don't believe that the WG has approved of your definition of
RecipientKeyIdentifier (including Name and CertificateAssertion) which is
significantly more complicated than the current CMS defnition.

- John Pawling

At 08:26 PM 11/13/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
>CryptographicMessageSyntax { iso member-body usa(840) rsadsi(113549)
>                pkcs(1) 7 module(0) version(3) }
>-- Should the module OID be from the RSA branch, or from elsewhere?
>DEFINITIONS IMPLICIT TAGS ::=
>BEGIN
>
>IMPORTS
>
>-- Directory Information Framework
>
>        Attribute, Name
>        ----
>        FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 
>                informationFramework(1) 3 }
>
>-- Directory Authentication Framework
>
>        AlgorithmIdentifier, AttributeCertificate, Certificate, 
>        CertificateList, CertificateSerialNumber, HASHED { }, SIGNED { }
>        ----
>        FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) 
>                authenticationFramework(7) 3 }
>
>-- In Cryptographic Message Syntax the HASHED parameterised type applies
the hash function to the 
>-- contents octets component of a CER or DER encoding of a value of the
parameter.
>
>-- Directory Certificate Extensions
>
>        CertificateAssertion
>        ----
>        FROM CertificateExtensions { joint-iso-itu-t ds(5) module(1) 
>                certificateExtensions(26) 0 };
>
>
>
>-- The ENCRYPTED parameterised type is redefined here because Cryptographic
Message Syntax encrypted values are 
>-- defined as OCTET STRING, instead of BIT STRING as in the Directory
Authentication Framework
>
>ENCRYPTED { ToBeEnciphered } ::= OCTET STRING ( CONSTRAINED BY {
>-- must be the result of applying an encipherment procedure to the contents
octets component --
>-- of a definite-length BER-encoding of a value of -- ToBeEnciphered } )
>
>
>
>ContentInfo ::= SEQUENCE {
>        content-type  CMS-CONTENT-TYPE.&id ({CMSContentTable}),
>        cms-content [0] CMS-CONTENT-TYPE.&Type ({CMSContentTable}
>                                     {@content-type}) OPTIONAL }
>
>CMS-CONTENT-TYPE ::= TYPE-IDENTIFIER
>
>CMSContentTable CMS-CONTENT-TYPE ::= { data, signed-data, enveloped-data, ... }
>
>-- Data
>
>data CMS-CONTENT-TYPE ::= { Data IDENTIFIED BY id-data }
>
>Data ::= OCTET STRING
>
>-- Signed Data
>
>signed-data CMS-CONTENT-TYPE ::= { SignedData IDENTIFIED BY id-signed-data }
>
>SignedData ::= SEQUENCE {
>        version Version, 
>        digestAlgorithms DigestAlgorithmIdentifiers,
>        contentInfo ContentInfo,
>        certificates [0] CertificateSet OPTIONAL,
>        crls [1] CertificateRevocationLists OPTIONAL,
>        signerInfos SignerInfos }
>
>Version ::= INTEGER
>
>DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
>
>DigestAlgorithmIdentifier ::= AlgorithmIdentifier
>
>CertificateSet ::= SET OF CertificateChoice
>
>CertificateChoice ::= CHOICE {
>        certificate Certificate,
>        extendedCertificate [0] ExtendedCertificate,
>        attributeCertificate [1] AttributeCertificate }
>
>CertificateRevocationLists ::= SET OF CertificateList
>
>SignerInfos ::= SET OF SignerInfo
>
>SignerInfo ::= SEQUENCE {
>        version Version,
>        issuerAndSerialNumber IssuerAndSerialNumber,
>        digestAlgorithm DigestAlgorithmIdentifier,
>        authenticatedAttributes [0] Attributes OPTIONAL,
>        signatureAlgorithm SignatureAlgorithmIdentifier,
>        signature SignatureValue,
>        unauthenticatedAttributes [1] Attributes OPTIONAL }
>
>IssuerAndSerialNumber ::= SEQUENCE {
>        issuer Name,
>        serialNumber CertificateSerialNumber }
>
>SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
>
>SignatureValue ::= ENCRYPTED { DigestInfo }
>
>DigestInfo ::= SEQUENCE {
>        digestAlgorithm DigestAlgorithmIdentifier,
>        digest Digest }
>
>Digest ::= HASHED { CHOICE {
>        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
>        authenticated-attributes [0] EXPLICIT Attributes } }
>
>-- Enveloped Data
>
>enveloped-data CMS-CONTENT-TYPE ::= { EnvelopedData
>        IDENTIFIED BY id-enveloped-data }
>
>EnvelopedData ::= SEQUENCE {
>        version Version,
>        originatorInfo [0] OriginatorInfo OPTIONAL,
>        recipientInfos RecipientInfos,
>        encryptedContentInfo EncryptedContentInfo }
>
>OriginatorInfo ::= SEQUENCE {
>        certificates [0] CertificateSet OPTIONAL,
>        crls [1] CertificateRevocationLists OPTIONAL }
>
>RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
>
>RecipientInfo ::= SEQUENCE {
>        version Version,
>        recipientIdentifier RecipientIdentifier,
>        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>        encryptedKey EncryptedKey,
>        originatorCertificateSelector CertificateAssertion OPTIONAL }
>
>RecipientIdentifier ::= CHOICE {
>        issuerAndSerialNumber IssuerAndSerialNumber,
>        recipientKeyIdentifier [0] RecipientKeyIdentifier,
>        mailListKeyIdentifier [1] MailListKeyIdentifier }
>
>RecipientKeyIdentifier ::= SEQUENCE {
>        recipientName Name,
>        recipientCertificateSelector  CertificateAssertion }
>
>MailListKeyIdentifier ::= SEQUENCE {
>        kekIdentifier OCTET STRING,
>        date GeneralizedTime OPTIONAL,
>        otherKeyAttribute Attribute OPTIONAL }
>
>KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
>
>EncryptedKey ::= OCTET STRING
>
>EncryptedContentInfo ::= SEQUENCE {
>        contentType CMS-CONTENT-TYPE.&id ({CMSContentTable}),
>        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
>        encryptedContent [0] ENCRYPTED {CMS-CONTENT-TYPE.&Type 
>                        ({CMSContentTable} {@contentType}) } OPTIONAL }
>
>ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
>
>-- Object Identifiers
>
>id-pkcs-7 OBJECT IDENTIFIER ::=
>        { iso member-body usa(840) rsadsi(113549) pkcs(1) 7 }
>
>id-data OBJECT IDENTIFIER ::= { id-pkcs-7 1 }
>
>id-signed-data OBJECT IDENTIFIER ::= { id-pkcs-7 2 }
>
>id-enveloped-data OBJECT IDENTIFIER ::= { id-pkcs-7 3 }
>
>-- Definitions from PKCS#6
>
>ExtendedCertificate ::= SIGNED { ExtendedCertificateInfo }
>
>ExtendedCertificateInfo ::= SEQUENCE {
>        version Version,
>        certificate Certificate,
>        attributes Attributes }
>
>Attributes ::= SET OF Attribute
>
>END -- of CryptographicMessageSyntax
>
>
>
>
>

Date: Thu, 13 Nov 1997 16:38:06 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: SigningTime
Sender: [email-masked]

Since the proposed choice type SigningTime will be a different
type that that defined by RSA in PKCS #9, will there be a new
S/MIME OID assigned to this type?

John Pawling wrote:
> 
> All,
> 
> I now agree with Dave and Blake's original argument that the SigningTime
> should be defined as a CHOICE of UTCTime or GeneralizedTime.  I agree with
> Dave's point that it is straightforward for the decoding software to examine
> the Tag field of the SigningTime to determine if the time is encoded as a
> UTCTime or GeneralizedTime.
> 
> In summary, all of the PKCS #9 attribute syntaxes and OIDs need to be copied
> to an IETF-controlled S/MIME-related spec.  When that happens, the
> SigningTime needs to be changed to the following syntax:
> 
> CHOICE {
>   utcTime           UTCTime,
>   generalizedTime   GeneralizedTime }
> 
> I assume that we want to adopt text similar to PKIX I such as:
> 
> When encoding the SigningTime attribute, sending agents MUST encode dates
> through the year 2049 as UTCTime and MUST encode dates in 2050 or later as
> GeneralizedTime.
> 
> - John Pawling
> 
> At 12:51 PM 11/13/97 -0500, David P. Kemp wrote:
> >> From: "Blake Ramsdell" <[email-masked]>
> >>
> >> > Constructing the ChoiceOfTime is the easy part.  My point is that it adds
> >> > complexity to the SignedData decoding software that must determine which
> >> > choice was chosen.  For example, in 2051, our code will need to be able to
> >> > decode stored SignedData objects some of which include SigningTime with
> >> > UTCTime choice and others that include SigningTime with GeneralizedTime
> >> > choice.  Sure, there are ways of determining which choice was chosen, but
> >> > the OID check for the signingTime or NewSigningTime attributes would be
> >> > quicker and easier.
> >>
> >> I understand.  Point taken.
> >>
> >> > In the signingTime or NewSigningTime attributes environment, you could use
> >> > an equivalent strategy to ensure backwards compatibility by including the
> >> > signingTime (UTCTime) attribute in SignedData objects generated thru the
> >> > year 2049 and including newSigningTime (GeneralizedTime) in SignedData
> >> > objects generated on 2050 or after.  Using this strategy, in 2051,  the
> >> > software can easily determine which flavor of signing time was included
> in a
> >> > SignedData object simply by examining the attribute OID.
> >>
> >> Yup -- I agree with this.  This does sound better.
> >
> >
> >I agree with the goal of reducing complexity, but I believe having two
> >different OIDs is more complex than having only a single OID.
> >
> >There are (at least) three ways of determining the encoding of the
> >SigningTime field:  examining the attribute OID (SigningTime or
> >NewSigningTime), examining the BER tag code (UTCTime or GeneralizedTime),
> >or examining the time string itself.  For the 2051 example where either
> >choice may be present, it's easiest to examine the one byte tag type,
> >rather than to match against two different attribute OIDs or parse
> >the time string.
> >
> >If Blake & John are now agreed that two attributes are better than one,
> >I'm not against it.  But IMHO adding a NewSigningTime attribute both:
> >
> > * makes the spec uglier (having two different attributes to accomplish
> >    the identical functionality, just using different syntax), and
> > * makes the resulting software more complex.
> >

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu, 13 Nov 97 20:26:49 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu, 13 Nov 97 20:26:49 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971113202649-0E50]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [email-masked]
Date: Thu, 13 Nov 97 20:26:49 +0000
X400-Content-Identifier: A draft ASN.1 mo
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked]
Subject: A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

CryptographicMessageSyntax { iso member-body usa(840) rsadsi(113549)
                pkcs(1) 7 module(0) version(3) }
-- Should the module OID be from the RSA branch, or from elsewhere?
DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

-- Directory Information Framework

        Attribute, Name
        ----
        FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 
                informationFramework(1) 3 }

-- Directory Authentication Framework

        AlgorithmIdentifier, AttributeCertificate, Certificate, 
        CertificateList, CertificateSerialNumber, HASHED { }, SIGNED { }
        ----
        FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) 
                authenticationFramework(7) 3 }

-- In Cryptographic Message Syntax the HASHED parameterised type applies the hash function to the 
-- contents octets component of a CER or DER encoding of a value of the parameter.

-- Directory Certificate Extensions

        CertificateAssertion
        ----
        FROM CertificateExtensions { joint-iso-itu-t ds(5) module(1) 
                certificateExtensions(26) 0 };

-- The ENCRYPTED parameterised type is redefined here because Cryptographic Message Syntax encrypted values are 
-- defined as OCTET STRING, instead of BIT STRING as in the Directory Authentication Framework

ENCRYPTED { ToBeEnciphered } ::= OCTET STRING ( CONSTRAINED BY {
-- must be the result of applying an encipherment procedure to the contents octets component --
-- of a definite-length BER-encoding of a value of -- ToBeEnciphered } )

ContentInfo ::= SEQUENCE {
        content-type  CMS-CONTENT-TYPE.&id ({CMSContentTable}),
        cms-content [0] CMS-CONTENT-TYPE.&Type ({CMSContentTable}
                                     {@content-type}) OPTIONAL }

CMS-CONTENT-TYPE ::= TYPE-IDENTIFIER

CMSContentTable CMS-CONTENT-TYPE ::= { data, signed-data, enveloped-data, ... }

-- Data

data CMS-CONTENT-TYPE ::= { Data IDENTIFIED BY id-data }

Data ::= OCTET STRING

-- Signed Data

signed-data CMS-CONTENT-TYPE ::= { SignedData IDENTIFIED BY id-signed-data }

SignedData ::= SEQUENCE {
        version Version, 
        digestAlgorithms DigestAlgorithmIdentifiers,
        contentInfo ContentInfo,
        certificates [0] CertificateSet OPTIONAL,
        crls [1] CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

Version ::= INTEGER

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

CertificateSet ::= SET OF CertificateChoice

CertificateChoice ::= CHOICE {
        certificate Certificate,
        extendedCertificate [0] ExtendedCertificate,
        attributeCertificate [1] AttributeCertificate }

CertificateRevocationLists ::= SET OF CertificateList

SignerInfos ::= SET OF SignerInfo

SignerInfo ::= SEQUENCE {
        version Version,
        issuerAndSerialNumber IssuerAndSerialNumber,
        digestAlgorithm DigestAlgorithmIdentifier,
        authenticatedAttributes [0] Attributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unauthenticatedAttributes [1] Attributes OPTIONAL }

IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber CertificateSerialNumber }

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureValue ::= ENCRYPTED { DigestInfo }

DigestInfo ::= SEQUENCE {
        digestAlgorithm DigestAlgorithmIdentifier,
        digest Digest }

Digest ::= HASHED { CHOICE {
        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
        authenticated-attributes [0] EXPLICIT Attributes } }

-- Enveloped Data

enveloped-data CMS-CONTENT-TYPE ::= { EnvelopedData
        IDENTIFIED BY id-enveloped-data }

EnvelopedData ::= SEQUENCE {
        version Version,
        originatorInfo [0] OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo }

OriginatorInfo ::= SEQUENCE {
        certificates [0] CertificateSet OPTIONAL,
        crls [1] CertificateRevocationLists OPTIONAL }

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= SEQUENCE {
        version Version,
        recipientIdentifier RecipientIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey,
        originatorCertificateSelector CertificateAssertion OPTIONAL }

RecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        recipientKeyIdentifier [0] RecipientKeyIdentifier,
        mailListKeyIdentifier [1] MailListKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
        recipientName Name,
        recipientCertificateSelector  CertificateAssertion }

MailListKeyIdentifier ::= SEQUENCE {
        kekIdentifier OCTET STRING,
        date GeneralizedTime OPTIONAL,
        otherKeyAttribute Attribute OPTIONAL }

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

EncryptedKey ::= OCTET STRING

EncryptedContentInfo ::= SEQUENCE {
        contentType CMS-CONTENT-TYPE.&id ({CMSContentTable}),
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] ENCRYPTED { CMS-CONTENT-TYPE.&Type 
                        ({CMSContentTable} {@contentType}) } OPTIONAL }

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

-- Object Identifiers

id-pkcs-7 OBJECT IDENTIFIER ::=
        { iso member-body usa(840) rsadsi(113549) pkcs(1) 7 }

id-data OBJECT IDENTIFIER ::= { id-pkcs-7 1 }

id-signed-data OBJECT IDENTIFIER ::= { id-pkcs-7 2 }

id-enveloped-data OBJECT IDENTIFIER ::= { id-pkcs-7 3 }

-- Definitions from PKCS#6

ExtendedCertificate ::= SIGNED { ExtendedCertificateInfo }

ExtendedCertificateInfo ::= SEQUENCE {
        version Version,
        certificate Certificate,
        attributes Attributes }

Attributes ::= SET OF Attribute

END -- of CryptographicMessageSyntax

Date: Thu, 13 Nov 1997 14:11:08 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: SigningTime
Sender: [email-masked]

All,

I now agree with Dave and Blake's original argument that the SigningTime
should be defined as a CHOICE of UTCTime or GeneralizedTime.  I agree with
Dave's point that it is straightforward for the decoding software to examine
the Tag field of the SigningTime to determine if the time is encoded as a
UTCTime or GeneralizedTime.  

In summary, all of the PKCS #9 attribute syntaxes and OIDs need to be copied
to an IETF-controlled S/MIME-related spec.  When that happens, the
SigningTime needs to be changed to the following syntax:

CHOICE {
  utcTime           UTCTime,
  generalizedTime   GeneralizedTime }

I assume that we want to adopt text similar to PKIX I such as:

When encoding the SigningTime attribute, sending agents MUST encode dates
through the year 2049 as UTCTime and MUST encode dates in 2050 or later as
GeneralizedTime.

- John Pawling  

At 12:51 PM 11/13/97 -0500, David P. Kemp wrote:
>> From: "Blake Ramsdell" <[email-masked]>
>>
>> > Constructing the ChoiceOfTime is the easy part.  My point is that it adds
>> > complexity to the SignedData decoding software that must determine which
>> > choice was chosen.  For example, in 2051, our code will need to be able to
>> > decode stored SignedData objects some of which include SigningTime with
>> > UTCTime choice and others that include SigningTime with GeneralizedTime
>> > choice.  Sure, there are ways of determining which choice was chosen, but
>> > the OID check for the signingTime or NewSigningTime attributes would be
>> > quicker and easier.
>> 
>> I understand.  Point taken.
>> 
>> > In the signingTime or NewSigningTime attributes environment, you could use
>> > an equivalent strategy to ensure backwards compatibility by including the
>> > signingTime (UTCTime) attribute in SignedData objects generated thru the
>> > year 2049 and including newSigningTime (GeneralizedTime) in SignedData
>> > objects generated on 2050 or after.  Using this strategy, in 2051,  the
>> > software can easily determine which flavor of signing time was included
in a
>> > SignedData object simply by examining the attribute OID.
>> 
>> Yup -- I agree with this.  This does sound better.
>
>
>I agree with the goal of reducing complexity, but I believe having two
>different OIDs is more complex than having only a single OID.
>
>There are (at least) three ways of determining the encoding of the
>SigningTime field:  examining the attribute OID (SigningTime or
>NewSigningTime), examining the BER tag code (UTCTime or GeneralizedTime),
>or examining the time string itself.  For the 2051 example where either
>choice may be present, it's easiest to examine the one byte tag type,
>rather than to match against two different attribute OIDs or parse
>the time string.
>
>If Blake & John are now agreed that two attributes are better than one,
>I'm not against it.  But IMHO adding a NewSigningTime attribute both:
>
> * makes the spec uglier (having two different attributes to accomplish
>    the identical functionality, just using different syntax), and
> * makes the resulting software more complex.
>

Date: Thu, 13 Nov 1997 12:51:28 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: SigningTime
Sender: [email-masked]

> From: "Blake Ramsdell" <[email-masked]>
>
> > Constructing the ChoiceOfTime is the easy part.  My point is that it adds
> > complexity to the SignedData decoding software that must determine which
> > choice was chosen.  For example, in 2051, our code will need to be able to
> > decode stored SignedData objects some of which include SigningTime with
> > UTCTime choice and others that include SigningTime with GeneralizedTime
> > choice.  Sure, there are ways of determining which choice was chosen, but
> > the OID check for the signingTime or NewSigningTime attributes would be
> > quicker and easier.
> 
> I understand.  Point taken.
> 
> > In the signingTime or NewSigningTime attributes environment, you could use
> > an equivalent strategy to ensure backwards compatibility by including the
> > signingTime (UTCTime) attribute in SignedData objects generated thru the
> > year 2049 and including newSigningTime (GeneralizedTime) in SignedData
> > objects generated on 2050 or after.  Using this strategy, in 2051,  the
> > software can easily determine which flavor of signing time was included in a
> > SignedData object simply by examining the attribute OID.
> 
> Yup -- I agree with this.  This does sound better.

I agree with the goal of reducing complexity, but I believe having two
different OIDs is more complex than having only a single OID.

There are (at least) three ways of determining the encoding of the
SigningTime field:  examining the attribute OID (SigningTime or
NewSigningTime), examining the BER tag code (UTCTime or GeneralizedTime),
or examining the time string itself.  For the 2051 example where either
choice may be present, it's easiest to examine the one byte tag type,
rather than to match against two different attribute OIDs or parse
the time string.

If Blake & John are now agreed that two attributes are better than one,
I'm not against it.  But IMHO adding a NewSigningTime attribute both:

 * makes the spec uglier (having two different attributes to accomplish
    the identical functionality, just using different syntax), and
 * makes the resulting software more complex.

Date: Thu, 13 Nov 1997 07:52:49 -0500
To: "Rich Ankney" <[email-masked]>, "Trevor Freeman" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Receipts vs. SignedData
Sender: [email-masked]

Rich,

That sounds good to me.

- John Pawling

At 06:41 PM 11/12/97 -0500, Rich Ankney wrote:
>Ah...  We are in sync on this. But your message leads to another question:
>
>Should we document that a recipient can reject received messages (i.e.
>SignedData) based on the encapsulated content type?  This is not obvious
>from any of the documents, and perhaps should be mentioned in CMS.
>
>Regards,
>Rich
>
>----------
>> From: John Pawling <[email-masked]>
>> To: Rich Ankney <[email-masked]>; Trevor Freeman
><[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry Layten'
><[email-masked]>; [email-masked]'
>> Subject: Re: Receipts vs. SignedData
>> Date: Wednesday, November 12, 1997 5:13 PM
>> 
>> Rich,
>> 
>> The following example depicts the detailed nesting for a CMS SignedData
>object: 
>> 
>> Outermost Layer: 
>>   MIME Heading encapsulating:
>>     ASN.1 encoded ContentInfo including:
>>       ContentType set to SignedData OID
>>       Content ANY including: 
>>         ASN.1 encoded SignedData including (among other things):
>>           ContentInfo including: 
>>             ContentType set to Data OID
>>             Content ANY including:
>>               ASN.1 encoded Data OCTET STRING including:
>>                 MIME Heading encapsulating:
>>      	          original content
>> 
>> 
>> The following example depicts the detailed nesting for a CMS/ESS
>> SignedData/Receipt: 
>> 
>> Outermost Layer: 
>>   MIME Heading encapsulating:
>>     ASN.1 encoded ContentInfo including:
>>       ContentType set to SignedData OID
>>       Content ANY including: 
>>         ASN.1 encoded SignedData including (among other things):
>>           ContentInfo including: 
>>             ContentType set to Receipt OID
>>             Content ANY including:
>>               ASN.1 encoded Receipt
>> 
>> When a user agent receives any CMS object it must first decode the outer
>> ContentInfo to determine the type of CMS object encapsulated within the
>> ContentInfo.  In the vast majority of cases, the receiving agent must
>decode
>> the actual CMS object to obtain the originator certificates, algorithms
>> applied to the object, etc.  In the case of decoding a
>SignedData/Receipt,
>> as part of the generic decoding process, the receiving agent discovers
>that
>> the SignedData encapsulates a Receipt content.  At this point the
>receiving
>> agent knows that the received CMS object is a SignedData/Receipt and can
>> take the appropriate actions.
>> 
>> Therefore, I do not believe that the ESS strategy for SignedData/Receipt
>> adds much work at all to the initial steps of processing a received CMS
>> object.  After all of the other steps, having to examine the inner
>> contentInfo contentType is trivial.
>> 
>> As far as having to read both the CMS and ESS specs to figure all of this
>> out, I don't believe that is a big deal when you consider the sum total
>of
>> all specs that one must read to implement ASN.1, V3 X.509 Certs, etc,
>etc.
>> The ESS is an optional part of the S/MIME v3 Message Spec environment. 
>If a
>> vendor does not wish to support signed receipts, then it can simply
>ignore
>> them as unrecognized objects.
>> 
>> - John Pawling
>> 
>> 
>> 
>> At 04:31 PM 11/12/97 -0500, Rich Ankney wrote:
>> >I think there's still a disconnect here.
>> >
>> >Is the following correct?
>> >
>> >A normal message (of type 'data') is signed, giving a SignedData
>> >whose inner content is type 'data'.
>> >
>> >A receipt is signed, giving another SignedData whose inner conten
>> >is type 'receipt'.
>> >
>> >The thing I was objecting to is having to peel open the inner
>contentInfo
>> >and determine it's type, in order to know what kind of digesting to do.
>> >This means the digesting part of CMS applies to all contents being
>> >signed except for receipts; the processing for receipts is described in
>> >ESS.  So handling of SignedData is now spread across two documents,
>> >which isn't exactly optimal from a developer's point of view.    
>> >
>> >Regards,
>> >Rich
>> >----------
>> >> From: John Pawling <[email-masked]>
>> >> To: Rich Ankney <[email-masked]>; Trevor Freeman
>> ><[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry
>Layten'
>> ><[email-masked]>; [email-masked]'
>> >> Subject: Re: Receipts vs. SignedData
>> >> Date: Wednesday, November 12, 1997 3:56 PM
>> >> 
>> >> Rich,
>> >> 
>> >> I agree with you that the ESS Receipt strategy should remain as is and
>> >that
>> >> the CMS spec should be clarified to state that the message-digesting
>> >process
>> >> that it describes only applies to the SignedData content type.
>> >> 
>> >> - John Pawling
>> > 
>> >
>> 
>

From: Trevor Freeman <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: ESS-00 Multiple Signed Receipts Issue
Date: Thu, 13 Nov 1997 04:43:03 -0800
Sender: [email-masked]

John,
It is clear we have a difference of opinion here, so let me try a different
tack.

I think I am correct in summarising your position by saying that in your
opinion the cryptographic service can only tie two messages together, the
request and a single response with a fixed meaning from a recipient, all
other receipt types are in fact application messages, which have to be
correlated by non-cryptographic means. 
My position on the other hand it that there are instances where there is a
requirement to have more than a single response from a recipient, that
response can be used to convey other meaning than simply the recipient was
able to verify the originators signature. All of these other responses need
to be bound to the original request and the receipt responses correlated for
the originator so they have some idea what is going on. If the cryptographic
service has a means of binding and correlating these messages together, why
invent another mechanism? The existing technique used to bind the receipt
request to a receipt, can equally be used to bind other messages. Why cannot
the intrinsic ability of the cryptographic service to bind messages together
be used for a wider set of messages that the ones currently defined in the
draft?
I see no benefit to continue this on the list, and I suggest we continue the
discussion off-line.
Trevor

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, November 12, 1997 1:49 PM
> To:	Trevor Freeman
> Cc:	[email-masked]
> Subject:	RE: ESS-00 Multiple Signed Receipts Issue
> 
> Trevor,
> 
> Thank you very much for your additional feedback.  I respectfully disagree
> with your points as follows:
> 
> You stated: 
> >> >The signed receipt process as outlined only considers a single type of
> >> >receipt. If fact there are more that one type of receipt. Examples of
> >> >these types would be
> >> >	A message has been delved to a mail box (but not opened).
> 
> The delivery of a message to a mail box does not involve any cryptographic
> services, so a signed receipt is inappropriate.  This requirement should
> be
> met by an element of the commnication protocol, not the security protocol.
> For example, in the X.400 environment, the X.400 receipt (not a signed
> receipt) provides this service.  The real solution is to enhance SMTP to
> include a SMTP receipt (not a CMS/ESS signed receipt).
> 
> 
> >> >A message has been opened
> 
> Depending on your definition of "opened", the "opening" of a message does
> not necessarily mean that the message signature was verified, so a signed
> receipt is inappropriate.  The signed receipt must only be sent if the
> recipient can verify the signature of the message.
> 
> 
> >> >The recipient acknowledges they have read (and hopefully understood)
> >> >the message
> 
> This is way beyond the scope of crytographic services, so a signed receipt
> is inappropriate.  This requirement would be met by the recipient sending
> a
> message back to the originator stating "I read you message and understood
> it".
> 
> 
> >> >	The recipient has actioned the message
> 
> Again, this is way beyond the scope of crytographic services, so a signed
> receipt is inappropriate.  This requirement would be met by the recipient
> sending a message back to the originator stating "I have acted upon your
> message".
> 
> 
> >> >Some of these receipts may mandate recipient intervention, such as
> >> >acknowledgement and actioned. You may require different receipt types
> >> from
> >> >different people, therefore I would envisage the requirement for
> multiple
> >> >receipt requests to be contained within the authenticated attributes
> of a
> >> >single message, with different users being asked for different types
> of
> >> >receipt.
> 
> I disagree with your proposal that ESS should allow for multiple,
> different
> receipt requests  in a SignedData object, because I disagree with your
> basic
> philosophy to try to solve problems in the communications protocol using
> security protocol elements.
> 
> 
> >The point is that these other types of receipt also have to be
> >cryptographically bound to the receipt request, as such they form part of
> >the cryptographic security services.
> 
> I disagree with this point because I disagree with your basic philosophy
> to
> try to solve problems in the communications protocol using security
> protocol
> elements.
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> 
> At 01:48 AM 11/12/97 -0800, Trevor Freeman wrote:
> >Hi Jon,
> >The point is that these other types of receipt also have to be
> >cryptographically bound to the receipt request, as such they form part of
> >the cryptographic security services. I therefore do not agree with you
> >interpretation that these other types of receipt are outside a
> cryptographic
> >security service or the ESS. There seem two way to progress this, 
> >	either the receipt type is enhanced to include the capability to
> >define other types of receipt 
> >	or, even at this early stage of the standard, we start defining the
> >addition of an extended receipt type request which would include the
> receipt
> >type attribute along with all the other attributes included in the
> current
> >definition.
> >I know which option looks the ugliest.
> >I also see no justification for making the receipt a new data type. It
> can
> >just as easy be carried as an authenticated attribute. All it is a piece
> of
> >signed data.
> >Trevor
> >> -----Original Message-----
> >> From:	[email-masked] [SMTP:[email-masked]]
> >> Sent:	Friday, November 07, 1997 4:07 PM
> >> To:	Trevor Freeman
> >> Cc:	[email-masked]
> >> Subject:	RE: ESS-00 Multiple Signed Receipts Issue
> >> 
> >> Trevor,
> >> 
> >> Thank you very much for your feedback.  The CMS and ESS specifications
> >> specify cryptographic security services, so the CMS/ESS signed receipt
> >> should only provide cryptographic security services.  The purpose of
> the
> >> CMS/ESS signed receipt is to prove to the originator that the recipient
> >> was
> >> able to verify the signature of the original message. This is the only
> >> purpose for the ESS/CMS signed receipt that is within the scope of the
> CMS
> >> and ESS specifications.  The other types of receipts that you list are
> >> outside the scope of CMS and ESS, so they should be documented in
> separate
> >> specifications that are not security-specific specifications.    
> >> 
> >> A CMS/ESS signed receipt is constructed by encapsulating an ESS Receipt
> >> object within a CMS SignedData object.  The Receipt signature value is
> >> included in the SignerInfo included in the SignedData object which
> >> encapsulates the Receipt object.  The SignerInfo includes
> >> autheticatedAttributes and unAuthenticatedAttributes.  Therefore, a
> >> CMS/ESS
> >> signed receipt can include any of the attributes listed in ESS (and
> some
> >> from PKCS #9) or it could include privately defined attributes.  This
> >> provides a lot of flexibility for the recipient to provide information
> >> back
> >> to the originator of the original message.
> >> 
> >> In my opinion, there is an open issue regarding whether or not all
> >> receiptRequests included in a SignedData object MUST be identical.  I
> can
> >> think of some bizarre scenarios in which different signers may wish to
> >> require that signed receipts be sent to specific
> >> entities, etc.  However, stating "All SignerInfos MUST contain the same
> >> receiptRequest attribute." would simplify processing.  I could go
> either
> >> way.
> >> 
> >> In summary, I believe that we should not change the signed receipt
> >> syntaxes
> >> and text included in ESS (other than adding clarifying text regarding
> >> multiple receiptRequests included in a signedData object). 
> >> 
> >> ================================
> >> John Pawling   
> >> [email-masked]                             
> >> J.G. Van Dyke & Associates, Inc.           
> >> ================================
> >> 
> >> 
> >> 
> >> At 07:25 AM 11/7/97 -0800, Trevor Freeman wrote:
> >> >I have a couple of related issues with signed receipts. 
> >> >The signed receipt process as outlined only considers a single type of
> >> >receipt. If fact there are more that one type of receipt. Examples of
> >> these
> >> >types would be
> >> >	A message has been delved to a mail box (but not opened).
> >> >	A message has been opened
> >> >	The recipient acknowledges they have read (and hopefully understood)
> >> >the message
> >> >	The recipient has actioned the message
> >> >Some of these receipts may mandate recipient intervention, such as
> >> >acknowledgement and actioned. You may require different receipt types
> >> from
> >> >different people, therefore I would envisage the requirement for
> multiple
> >> >receipt requests to be contained within the authenticated attributes
> of a
> >> >single message, with different users being asked for different types
> of
> >> >receipt.
> >> >
> >> >Another requirement of the originator is that they may require some
> >> >additional information from the recipient to be returned as part of
> the
> >> >receipt. This additional content may be considered mandatory by the
> >> >originator. A drawback of defining the receipt as a new data type is
> that
> >> it
> >> >does not allow a place for this recipient originated information to be
> >> >returned with the receipt. I would therefore submit that the receipt
> >> should
> >> >therefore be an authenticated attribute of the signed data structure
> in
> >> the
> >> >receipt not a new content. This would allow any new content to be
> >> returned
> >> >as part of the receipt message in the content info of the signed data
> >> type
> >> >in the normal way.
> >> >
> >> >To show my thoughts on these requirements may be reflected in the
> >> message,
> >> >here is my suggestion at what the receipt request should look like.
> >> >
> >> >ReceiptRequest ::= SEQUENCE {
> >> >            reciptType ::= BIT STRING {
> >> >                       delivery                     (0),
> >> >                       read                         (1),
> >> >                       acknowledgement     (2),
> >>                        actioned                   (3), }
> >> >           recipientAdditionalInformation           BOOLEAN DEFAULT
> >> FALSE,
> >> >           encapsulatedContentType
> EncapsulatedContentType
> >> >OPTIONAL,
> >> >           signedContentIdentifier                     OCTET STRING,
> >> >           receiptsFrom
> ReceiptsFrom,
> >> >           receiptsTo                                       SEQUENCE
> >> (SIZE
> >> >(1..ub-receiptsTo))
> >> >                                       OF GeneralNames OPTIONAL }
> >> >           ub-receiptsTo INTEGER ::= 16
> >> >
> >> >Receipt := SEQUENCE {
> >> >    reciptType ::= BIT STRING {
> >> >                       delivery                     (0),
> >> >                       read                         (1),
> >> >                       acknowledgement     (2),
> >> >                       actioned                   (3), }
> >> >    encapsulatedContentType        EncapsulatedContentType OPTIONAL,
> >> >    signedContentIdentifier        OCTET STRING,
> >> >    originatorSignatureValue       OCTET STRING }
> >> >
> >> >Trevor
> >> >
> >> >> -----Original Message-----
> >> >> From:	[email-masked] [SMTP:[email-masked]]
> >> >> Sent:	Wednesday, November 05, 1997 11:48 PM
> >> >> To:	[email-masked]
> >> >> Subject:	ESS-00 Multiple Signed Receipts Issue
> >> >> 
> >> >> All,
> >> >> 
> >> >> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
> >> >> describes the process of an originator requesting signed receipts
> and a
> >> >> recipient returning signed receipts.  There can be multiple
> SignerInfos
> >> >> present within a SignedData object.  Each SignerInfo can include
> >> >> authenticatedAttributes.  Therefore, a single SignedData object may
> >> >> include
> >> >> multiple SignerInfos each of which include a receiptRequest
> attribute.
> >> I
> >> >> believe that this should be allowed and should be documented in the
> >> ESS.
> >> >> 
> >> >> 
> >> >> For example, if an originator desires to send a signed message
> >> requesting
> >> >> signed receipts to a set of users composed of RSA-only and DSA-only
> >> users.
> >> >> The originator's software can include one SignerInfo that includes
> an
> >> RSA
> >> >> signature value and a receiptRequest attribute.  The same SignedData
> >> >> object
> >> >> could include another SignerInfo that includes a DSA signature value
> >> and a
> >> >> receiptRequest attribute.  In this example, the RSA-capable
> recipients
> >> >> would
> >> >> return an RSA signed receipt to the originator and the DSA-capable
> >> >> recipients would return a DSA signed receipt to the originator.
> >> >> 
> >> >> I believe that the general processing rules in ESS should state that
> a
> >> >> receiving agent should build a signed receipt for each SignerInfo in
> >> the
> >> >> SignedData object for which it verifies the signature and which
> >> requests a
> >> >> signed receipt.  This may result in multiple signed receipts being
> >> >> constructed and returned for a single SignedData object. 
> >> >> 
> >> >> I also believe that we should add a restriction that only one
> >> >> receiptRequest
> >> >> attribute can be included in the authenticatedAttributes of a
> >> SignerInfo.
> >> >> 
> >> >> I will include specific comments to ESS-00 in a follow-up message,
> but
> >> I
> >> >> wanted to raise this issue separately because I beleive that it
> >> deserves
> >> >> special attention.
> >> >> 
> >> >> ================================
> >> >> John Pawling   
> >> >> [email-masked]                             
> >> >> J.G. Van Dyke & Associates, Inc.           
> >> >> ================================
> >> >> 
> >> >
> >

From: Scott Hollenbeck <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: Initial S/MIME 3 CMS Comments
Date: Thu, 13 Nov 1997 03:44:14 PST
Sender: [email-masked]

Russ,

To answer your questions:

CertificateSerialNumber *is* defined in the current X.509 draft.  I'm
not sure when it appeared, but it doesn't appear in the '88 version of
X.509.  So, if you plan to use '88 syntax I suppose we ought to go '88
all the way.

Yes, the definition of Name is exported from the '88 version of X.501.

Scott

-----Original Message-----
From:	Russ Housley [SMTP:[email-masked]]
Sent:	Wednesday, November 12, 1997 12:35 PM
To:	Scott Hollenbeck
Cc:	[email-masked]
Subject:	Re: Initial S/MIME 3 CMS Comments

Scott:

>1. The definition of SignedData includes
>
>crls [1] IMPLICIT CRLs OPTIONAL
>
>but no definition for CRLs is provided.  A definition for the old PKCS #7
>CertificateRevocationLists is provided in section 7.1.  Either section
>7.1 should be changed to define CRLs or the SignedData definition should be
>changed to use CertificateRevocationLists.  I suggest changing the SignedData
>definition to use the existing PKCS #7 definition.

Fixed.

>2. Section 5.2 includes
>
>signatureAlgorithm   signatureAlgorithmIdentifier
>
>"signatureAlgorithmIdentifier" should be SignatureAlgorithmIdentifier, with
>an upper case "S".

Fixed.

>3. Section 7.7 includes
>
>serialNumber  CertificateSerialNumber
>
>PKCS #7 says that CertificateSerialNumber is imported from X.509, but the
>1988 X.509 spec doesn't include a definition for CertificateSerialNumber.
>It defines "SerialNumber".  This should be changed to SerialNumber unless
>CertificateSerialNumber is defined in a later version of X.509.

Okay.  I droped "Certificate."  And I added a sentence about the imports.
Is Name in X.501?

>4. In section 7.9 a definition for Version is included.  Version is defined
>in X.509, so maybe it could be included from X.509 instead of adding a
>definition here.

I do not want to get it from there because it nails down the numbers that
are allowed.

Russ

From: "Blake Ramsdell" <[email-masked]>
To: "'Rich Ankney'" <[email-masked]>, "'Trevor Freeman'" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'John Pawling'" <[email-masked]>
Subject: RE: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 17:55:27 -0800
Sender: [email-masked]

On Wednesday, November 12, 1997 3:45 PM, Rich Ankney
[SMTP:[email-masked]] wrote:
> But there is!  (from my reading of ESS, anyway).  If the inner ContentInfo
> is a receipt, I hash the concatenation of the original message (not present
> in this content) and the receipt, rather than just the inner content (which
> is 
> just the receipt).  Or am I incredibly confused??

Nope.  I am.  My apologies.  From John's message, this description is
correct.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Wed, 12 Nov 1997 15:39:15 -0800
Sender: [email-masked]

On Wednesday, November 12, 1997 3:23 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> Constructing the ChoiceOfTime is the easy part.  My point is that it adds
> complexity to the SignedData decoding software that must determine which
> choice was chosen.  For example, in 2051, our code will need to be able to
> decode stored SignedData objects some of which include SigningTime with
> UTCTime choice and others that include SigningTime with GeneralizedTime
> choice.  Sure, there are ways of determining which choice was chosen, but
> the OID check for the signingTime or NewSigningTime attributes would be
> quicker and easier.

I understand.  Point taken.

> In the signingTime or NewSigningTime attributes environment, you could use
> an equivalent strategy to ensure backwards compatibility by including the
> signingTime (UTCTime) attribute in SignedData objects generated thru the
> year 2049 and including newSigningTime (GeneralizedTime) in SignedData
> objects generated on 2050 or after.  Using this strategy, in 2051,  the
> software can easily determine which flavor of signing time was included in a
> SignedData object simply by examining the attribute OID.

Yup -- I agree with this.  This does sound better.

> I'm apologize if I'm being a pain, but I'm just trying to ward off more
> complexity in an already complex protocol (and getting more complex each
day).

I don't think you're being a pain (hey, I should be apologizing, not
you).  It's better to be picky and get it right than it is to have
unwritten "steeped in oral tradition" rules.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Rich Ankney" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "'Trevor Freeman'" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'John Pawling'" <[email-masked]>
Subject: Re: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 18:45:23 -0500
Sender: [email-masked]

----------
> From: Blake Ramsdell <[email-masked]>
> To: 'Rich Ankney' <[email-masked]>; 'Trevor Freeman'
<[email-masked]>; 'Larry Layten' <[email-masked]>;
[email-masked]'; 'John Pawling' <[email-masked]>
> Subject: RE: Receipts vs. SignedData
> Date: Wednesday, November 12, 1997 5:11 PM
> 
> On Wednesday, November 12, 1997 1:32 PM, Rich Ankney
> [SMTP:[email-masked]] wrote:
> > Is the following correct?
> > 
> > A normal message (of type 'data') is signed, giving a SignedData
> > whose inner content is type 'data'.
> 
> This is correct -- the inner content is identified by the PKCS #7 data
> OID, and the content is MIME data.
> 
> > A receipt is signed, giving another SignedData whose inner conten
> > is type 'receipt'.
> 
> The inner content is identified by the ESS receipt OID, and the content
> is a Receipt structure.
> 
> > The thing I was objecting to is having to peel open the inner
contentInfo
> > and determine it's type, in order to know what kind of digesting to do.
> > This means the digesting part of CMS applies to all contents being
> > signed except for receipts; the processing for receipts is described in
> > ESS.  So handling of SignedData is now spread across two documents,
> > which isn't exactly optimal from a developer's point of view.    
> 
> There is no change in the digesting -- you follow the steps in CMS (hash
> the content part of the inner ContentInfo, then either use that to
> verify the signature or verify the signature on the SignerInfo's
> authenticatedAttributes, etc.)
>
But there is!  (from my reading of ESS, anyway).  If the inner ContentInfo
is a receipt, I hash the concatenation of the original message (not present
in this content) and the receipt, rather than just the inner content (which
is 
just the receipt).  Or am I incredibly confused??
 
> The resulting Receipt structure may need to be handled in a special way,
> but the signature provided by the enclosing SignedData should be
> computed identically to any other SignedData entity.
> 
> I think we're still missing, and I don't know how to explain it better,
> or if my understanding is wrong.
> 

Regards,
Rich

From: "Rich Ankney" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 18:41:39 -0500
Sender: [email-masked]

Ah...  We are in sync on this. But your message leads to another question:

Should we document that a recipient can reject received messages (i.e.
SignedData) based on the encapsulated content type?  This is not obvious
from any of the documents, and perhaps should be mentioned in CMS.

Regards,
Rich

----------
> From: John Pawling <[email-masked]>
> To: Rich Ankney <[email-masked]>; Trevor Freeman
<[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry Layten'
<[email-masked]>; [email-masked]'
> Subject: Re: Receipts vs. SignedData
> Date: Wednesday, November 12, 1997 5:13 PM
> 
> Rich,
> 
> The following example depicts the detailed nesting for a CMS SignedData
object: 
> 
> Outermost Layer: 
>   MIME Heading encapsulating:
>     ASN.1 encoded ContentInfo including:
>       ContentType set to SignedData OID
>       Content ANY including: 
>         ASN.1 encoded SignedData including (among other things):
>           ContentInfo including: 
>             ContentType set to Data OID
>             Content ANY including:
>               ASN.1 encoded Data OCTET STRING including:
>                 MIME Heading encapsulating:
>      	          original content
> 
> 
> The following example depicts the detailed nesting for a CMS/ESS
> SignedData/Receipt: 
> 
> Outermost Layer: 
>   MIME Heading encapsulating:
>     ASN.1 encoded ContentInfo including:
>       ContentType set to SignedData OID
>       Content ANY including: 
>         ASN.1 encoded SignedData including (among other things):
>           ContentInfo including: 
>             ContentType set to Receipt OID
>             Content ANY including:
>               ASN.1 encoded Receipt
> 
> When a user agent receives any CMS object it must first decode the outer
> ContentInfo to determine the type of CMS object encapsulated within the
> ContentInfo.  In the vast majority of cases, the receiving agent must
decode
> the actual CMS object to obtain the originator certificates, algorithms
> applied to the object, etc.  In the case of decoding a
SignedData/Receipt,
> as part of the generic decoding process, the receiving agent discovers
that
> the SignedData encapsulates a Receipt content.  At this point the
receiving
> agent knows that the received CMS object is a SignedData/Receipt and can
> take the appropriate actions.
> 
> Therefore, I do not believe that the ESS strategy for SignedData/Receipt
> adds much work at all to the initial steps of processing a received CMS
> object.  After all of the other steps, having to examine the inner
> contentInfo contentType is trivial.
> 
> As far as having to read both the CMS and ESS specs to figure all of this
> out, I don't believe that is a big deal when you consider the sum total
of
> all specs that one must read to implement ASN.1, V3 X.509 Certs, etc,
etc.
> The ESS is an optional part of the S/MIME v3 Message Spec environment. 
If a
> vendor does not wish to support signed receipts, then it can simply
ignore
> them as unrecognized objects.
> 
> - John Pawling
> 
> 
> 
> At 04:31 PM 11/12/97 -0500, Rich Ankney wrote:
> >I think there's still a disconnect here.
> >
> >Is the following correct?
> >
> >A normal message (of type 'data') is signed, giving a SignedData
> >whose inner content is type 'data'.
> >
> >A receipt is signed, giving another SignedData whose inner conten
> >is type 'receipt'.
> >
> >The thing I was objecting to is having to peel open the inner
contentInfo
> >and determine it's type, in order to know what kind of digesting to do.
> >This means the digesting part of CMS applies to all contents being
> >signed except for receipts; the processing for receipts is described in
> >ESS.  So handling of SignedData is now spread across two documents,
> >which isn't exactly optimal from a developer's point of view.    
> >
> >Regards,
> >Rich
> >----------
> >> From: John Pawling <[email-masked]>
> >> To: Rich Ankney <[email-masked]>; Trevor Freeman
> ><[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry
Layten'
> ><[email-masked]>; [email-masked]'
> >> Subject: Re: Receipts vs. SignedData
> >> Date: Wednesday, November 12, 1997 3:56 PM
> >> 
> >> Rich,
> >> 
> >> I agree with you that the ESS Receipt strategy should remain as is and
> >that
> >> the CMS spec should be clarified to state that the message-digesting
> >process
> >> that it describes only applies to the SignedData content type.
> >> 
> >> - John Pawling
> > 
> >
> 

Date: Wed, 12 Nov 1997 18:23:10 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: SigningTime
Sender: [email-masked]

Blake,

Constructing the ChoiceOfTime is the easy part.  My point is that it adds
complexity to the SignedData decoding software that must determine which
choice was chosen.  For example, in 2051, our code will need to be able to
decode stored SignedData objects some of which include SigningTime with
UTCTime choice and others that include SigningTime with GeneralizedTime
choice.  Sure, there are ways of determining which choice was chosen, but
the OID check for the signingTime or NewSigningTime attributes would be
quicker and easier.

In the signingTime or NewSigningTime attributes environment, you could use
an equivalent strategy to ensure backwards compatibility by including the
signingTime (UTCTime) attribute in SignedData objects generated thru the
year 2049 and including newSigningTime (GeneralizedTime) in SignedData
objects generated on 2050 or after.  Using this strategy, in 2051,  the
software can easily determine which flavor of signing time was included in a
SignedData object simply by examining the attribute OID.

IMHO, this issue is different than with the v3 X.509 certs.  In that case,
they were constrained by the basic Certificate syntax.  In this case, we
have much more flexibility because we are dealing with a set of attributes
(i.e. OID and ANY).

I'm apologize if I'm being a pain, but I'm just trying to ward off more
complexity in an already complex protocol (and getting more complex each day).

- John Pawling

At 03:03 PM 11/12/97 -0800, Blake Ramsdell wrote:
>On Wednesday, November 12, 1997 2:35 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> It seems to me that it would be much simpler to have two separate
>> attributes: one for UTCTime and the other for GeneralizedTime.  This
>> strategy  allows the receiving application to quickly identify the flavor of
>> the signing time based on the OID identifying the attribute.  IMHO, the
>> ChoiceOfTime just adds complexity because the receiving agent has to figure
>> out which choice was chosen.
>
>The concern for me (as usual) is backwards compatibility.  There is no
>implementation complexity to using ChoiceOfTime with a sliding window,
>since this gives implementors a grace period before implementing
>GeneralizedTime -- use UTCTime through the year 2049 and use
>GeneralizedTime for 2050 or after.  This seems like it is the best
>balance between compatibility and complexity.
>
>If we have a separate OID identifying the GeneralizedTime attribute,
>then the current implementations won't see it and won't be able to use
>it.  If we use the sliding window, nothing changes in applications until
>around 2040.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Wed, 12 Nov 1997 15:03:37 -0800
Sender: [email-masked]

On Wednesday, November 12, 1997 2:35 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> It seems to me that it would be much simpler to have two separate
> attributes: one for UTCTime and the other for GeneralizedTime.  This
> strategy  allows the receiving application to quickly identify the flavor of
> the signing time based on the OID identifying the attribute.  IMHO, the
> ChoiceOfTime just adds complexity because the receiving agent has to figure
> out which choice was chosen.

The concern for me (as usual) is backwards compatibility.  There is no
implementation complexity to using ChoiceOfTime with a sliding window,
since this gives implementors a grace period before implementing
GeneralizedTime -- use UTCTime through the year 2049 and use
GeneralizedTime for 2050 or after.  This seems like it is the best
balance between compatibility and complexity.

If we have a separate OID identifying the GeneralizedTime attribute,
then the current implementations won't see it and won't be able to use
it.  If we use the sliding window, nothing changes in applications until
around 2040.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 12 Nov 1997 17:44:49 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: More Comments to CMS-00
Cc: [email-masked]
Sender: [email-masked]

Russ,

IMHO, the simplest strategy would be to always include the originator's cert
in the EnvelopedData OriginatorInfo (when required for the key management
algorithm) and not add any fields to EnvelopedData RecipientInfo which
identifies the originator (optionally).

If CMS does not mandate the inclusion of the originator's cert in the
EnvelopedData OriginatorInfo (when required for the key management
algorithm), then a field must be added to the EnvelopedData RecipientInfo
which is used to identify the originator's cert (when required for the key
management algorithm) (similar to Jim Craigie's
"originator-certificate-selector" proposal).

The latter strategy would certainly work and would allow the originator's
cert to be omitted, but it adds complexity to an already complex protocol.

- John Pawling

At 10:59 AM 11/12/97 -0500, Russ Housley wrote:
>John:
>
>I agree that I need to add a paragraph about OriginatorInfo.  The words
>that you provide suggest that the certs should not be OPTIONAL.  I do not
>think that this is correct.  In some cases, the originator might know that
>his certificate is already in the recipient's cache.
>
>Russ
>
>At 06:23 PM 11/4/97 -0500, John Pawling wrote:
>>All,
>>
>>I need to enhance my previous comment #8 to be:
>>
>>8) sec 6.1: Please add the following text to the description of the fields
>>of type EnvelopedData:  "originatorInfo includes information regarding the
>>originator.  It is present in EnvelopedData only if required by the key
>>management algorithm (e.g. Diffie-Hellman (DH), Key Exchange Algorithm
>>(KEA)).  At a minimum, originatorInfo must include the certificate
>>containing the originator's key management public key material required by
>>the recipient to form the pairwise key required to decrypt the recipient's
>>copy of the content-encryption key.  originatorInfo may include multiple key
>>management certificates for the same subject (i.e. originator).  For
>>example, if the originator has included both DH-protected and KEA-protected
>>copies of the content-encryption key in recipientInfos, then separate
>>certificates including the originator's KEA and DH public key material would
>>be required in originatorInfo."  
>>
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>================================
>>
>>
>>>To: [email-masked]
>>>From: [email-masked] (John Pawling)
>>>Subject: Comments to CMS-00
>>>Cc: 
>>>Bcc: 
>>>X-Attachments: 
>>>
>>>All,
>>>
>>>IMHO Russ Housley has done a most excellent job of drafting the
>>"Cryptographic Message Syntax" spec.  I have the following minor comments:
>>>
>>>1) Abstract: Please change "deriveded" to "derived".
>>>
>>>2) Sec 3: Please change "in 3 The methods below" to "The methods below".
>>>
>>>3) Sec 5: Please change: "The signer's public key is either contained in a
>>certificate included in the signer information, or is referenced by an
>>issuer distinguished name and an issuer-specific serial number that uniquely
>>identify the certificate containing the public key." to "The signer's public
>>key is referenced by an issuer distinguished name and an issuer-specific
>>serial number that uniquely identify the certificate containing the public
>>key.  The signer's certificate may be included in the SignedData
>>certificates field."
>>>
>>>4) Sec 5, last sentence: Please change "signiture" to "signature".
>>>
>>>5) sec 5.1, version description: Please change "version shall 1" to
>>"version shall be 1"
>>>
>>>6) sec 5.1, certificates description: Please change "version shall 1" to
>>"version shall be 1"
>>>
>>>7) sec 5.4: Please change two occurrences of "algorithm deployed" to
>>"algorithm employed".
>>>
>>>8) sec 6.1: Please add the following text to the description of the fields
>>of type EnvelopedData:  "originatorInfo includes information regarding the
>>originator.  It is present in EnvelopedData only if required by the key
>>management algorithm (e.g. Diffie-Hellman)."
>>>
>>>================================
>>>John Pawling   
>>>[email-masked]                             
>>>J.G. Van Dyke & Associates, Inc.           
>>>================================
>>>  
>>>
>>>
>>>
>>>
>>>At 06:01 PM 11/1/97 -0800, Paul Hoffman / IMC wrote:
>>>>The Internet Draft for the message format to be used in S/MIME 3 is now
>>>>available; please see <http://www.imc.org/draft-housley-smime-cms>. This is
>>>>the replacement for PKCS #7 1.5, and is only slightly different. Strap on
>>>>your ASN.1 goggles and enjoy!
>>>>
>>>>Two other parts of S/MIME 3 (the message spec and the optional security
>>>>enhancements) will be appearing shortly. The certs spec will appear in a
>>>>few weeks, once we finish with the v2 certs definition.
>>>>
>>>>
>>>>--Paul Hoffman, Director
>>>>--Internet Mail Consortium
>>>>
>>>
>>
>

Date: Wed, 12 Nov 1997 17:35:24 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: SigningTime
Sender: [email-masked]

Blake,

It seems to me that it would be much simpler to have two separate
attributes: one for UTCTime and the other for GeneralizedTime.  This
strategy  allows the receiving application to quickly identify the flavor of
the signing time based on the OID identifying the attribute.  IMHO, the
ChoiceOfTime just adds complexity because the receiving agent has to figure
out which choice was chosen.

- John Pawling

At 02:12 PM 11/12/97 -0800, Blake Ramsdell wrote:
>On Wednesday, November 12, 1997 9:20 AM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> The PKCS #9 spec defines the SigningTime attribute to be UTCTime.
>> 
>> Propose that a new attribute should be defined called NewSigningTime that is
>> defined as a GeneralizedTime.  If the WG agrees, then a new OID would need
>> to be defined to identify NewSigningTime.  If the WG agrees, then the ESS
>> spec should be enhanced to include NewSigningTime and recommend its use
>> instead of SigningTime.
>
>For compatibility, should we make this ChoiceOfTime, leave the OID the
>same, and specify the same sliding window as PKIX part 1?  Didn't we do
>some work in this area already?
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Wed, 12 Nov 1997 12:35:12 -0500
To: Scott Hollenbeck <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Initial S/MIME 3 CMS Comments
Cc: [email-masked]
Sender: [email-masked]

Scott:

>1. The definition of SignedData includes
>
>crls [1] IMPLICIT CRLs OPTIONAL
>
>but no definition for CRLs is provided.  A definition for the old PKCS #7
>CertificateRevocationLists is provided in section 7.1.  Either section
>7.1 should be changed to define CRLs or the SignedData definition should be
>changed to use CertificateRevocationLists.  I suggest changing the SignedData
>definition to use the existing PKCS #7 definition.

Fixed.

>2. Section 5.2 includes
>
>signatureAlgorithm   signatureAlgorithmIdentifier
>
>"signatureAlgorithmIdentifier" should be SignatureAlgorithmIdentifier, with
>an upper case "S".

Fixed.

>3. Section 7.7 includes
>
>serialNumber  CertificateSerialNumber
>
>PKCS #7 says that CertificateSerialNumber is imported from X.509, but the
>1988 X.509 spec doesn't include a definition for CertificateSerialNumber.
>It defines "SerialNumber".  This should be changed to SerialNumber unless
>CertificateSerialNumber is defined in a later version of X.509.

Okay.  I droped "Certificate."  And I added a sentence about the imports.
Is Name in X.501?

>4. In section 7.9 a definition for Version is included.  Version is defined
>in X.509, so maybe it could be included from X.509 instead of adding a
>definition here.

I do not want to get it from there because it nails down the numbers that
are allowed.

Russ

Date: Wed, 12 Nov 1997 17:21:09 -0500
To: "Blake Ramsdell" <[email-masked]>, "'Rich Ankney'" <[email-masked]>, "'Trevor Freeman'" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Receipts vs. SignedData
Sender: [email-masked]

Blake,

With all due respect, your understanding is wrong.  Rich is correct that the
process to calculate the hash required to validate the signature of a
regular SignedData object (content and attributes) is different than the
process to calculate the hash required to validate the signature of a
SignedData/Receipt (content from original message and Receipt content).  But
that is OK, because the SignedData/Receipt provides different security
services than a normal SignedData object, so the processing rules are
different.  CMS provides the rules for validating a regular SignedData
object and ESS provide the rules for validating a SignedData/Receipt.

- John Pawling

At 02:11 PM 11/12/97 -0800, Blake Ramsdell wrote:
>On Wednesday, November 12, 1997 1:32 PM, Rich Ankney
>[SMTP:[email-masked]] wrote:
>> Is the following correct?
>> 
>> A normal message (of type 'data') is signed, giving a SignedData
>> whose inner content is type 'data'.
>
>This is correct -- the inner content is identified by the PKCS #7 data
>OID, and the content is MIME data.
>
>> A receipt is signed, giving another SignedData whose inner conten
>> is type 'receipt'.
>
>The inner content is identified by the ESS receipt OID, and the content
>is a Receipt structure.
>
>> The thing I was objecting to is having to peel open the inner contentInfo
>> and determine it's type, in order to know what kind of digesting to do.
>> This means the digesting part of CMS applies to all contents being
>> signed except for receipts; the processing for receipts is described in
>> ESS.  So handling of SignedData is now spread across two documents,
>> which isn't exactly optimal from a developer's point of view.    
>
>There is no change in the digesting -- you follow the steps in CMS (hash
>the content part of the inner ContentInfo, then either use that to
>verify the signature or verify the signature on the SignerInfo's
>authenticatedAttributes, etc.)
>
>The resulting Receipt structure may need to be handled in a special way,
>but the signature provided by the enclosing SignedData should be
>computed identically to any other SignedData entity.
>
>I think we're still missing, and I don't know how to explain it better,
>or if my understanding is wrong.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: SMIMECapabilities OID
Date: Wed, 12 Nov 1997 14:18:02 -0800
Sender: [email-masked]

On Wednesday, November 12, 1997 12:50 PM, Russ Housley
[SMTP:[email-masked]] wrote:
> You are correct; the first letter must be lower case.  My personal
> preference would be smimeCapabilities.

I have no preference.  Your suggestion is prettier, but I like the
sarcastic statement that sMIMECapabilities makes about ASN.1 naming
rules :).

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 12 Nov 1997 17:13:06 -0500
To: "Rich Ankney" <[email-masked]>, "Trevor Freeman" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Receipts vs. SignedData
Sender: [email-masked]

Rich,

The following example depicts the detailed nesting for a CMS SignedData object: 

Outermost Layer: 
  MIME Heading encapsulating:
    ASN.1 encoded ContentInfo including:
      ContentType set to SignedData OID
      Content ANY including: 
        ASN.1 encoded SignedData including (among other things):
          ContentInfo including: 
            ContentType set to Data OID
            Content ANY including:
              ASN.1 encoded Data OCTET STRING including:
                MIME Heading encapsulating:
     	          original content

The following example depicts the detailed nesting for a CMS/ESS
SignedData/Receipt: 

Outermost Layer: 
  MIME Heading encapsulating:
    ASN.1 encoded ContentInfo including:
      ContentType set to SignedData OID
      Content ANY including: 
        ASN.1 encoded SignedData including (among other things):
          ContentInfo including: 
            ContentType set to Receipt OID
            Content ANY including:
              ASN.1 encoded Receipt

When a user agent receives any CMS object it must first decode the outer
ContentInfo to determine the type of CMS object encapsulated within the
ContentInfo.  In the vast majority of cases, the receiving agent must decode
the actual CMS object to obtain the originator certificates, algorithms
applied to the object, etc.  In the case of decoding a SignedData/Receipt,
as part of the generic decoding process, the receiving agent discovers that
the SignedData encapsulates a Receipt content.  At this point the receiving
agent knows that the received CMS object is a SignedData/Receipt and can
take the appropriate actions.

Therefore, I do not believe that the ESS strategy for SignedData/Receipt
adds much work at all to the initial steps of processing a received CMS
object.  After all of the other steps, having to examine the inner
contentInfo contentType is trivial.

As far as having to read both the CMS and ESS specs to figure all of this
out, I don't believe that is a big deal when you consider the sum total of
all specs that one must read to implement ASN.1, V3 X.509 Certs, etc, etc.
The ESS is an optional part of the S/MIME v3 Message Spec environment.  If a
vendor does not wish to support signed receipts, then it can simply ignore
them as unrecognized objects.

- John Pawling

At 04:31 PM 11/12/97 -0500, Rich Ankney wrote:
>I think there's still a disconnect here.
>
>Is the following correct?
>
>A normal message (of type 'data') is signed, giving a SignedData
>whose inner content is type 'data'.
>
>A receipt is signed, giving another SignedData whose inner conten
>is type 'receipt'.
>
>The thing I was objecting to is having to peel open the inner contentInfo
>and determine it's type, in order to know what kind of digesting to do.
>This means the digesting part of CMS applies to all contents being
>signed except for receipts; the processing for receipts is described in
>ESS.  So handling of SignedData is now spread across two documents,
>which isn't exactly optimal from a developer's point of view.    
>
>Regards,
>Rich
>----------
>> From: John Pawling <[email-masked]>
>> To: Rich Ankney <[email-masked]>; Trevor Freeman
><[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry Layten'
><[email-masked]>; [email-masked]'
>> Subject: Re: Receipts vs. SignedData
>> Date: Wednesday, November 12, 1997 3:56 PM
>> 
>> Rich,
>> 
>> I agree with you that the ESS Receipt strategy should remain as is and
>that
>> the CMS spec should be clarified to state that the message-digesting
>process
>> that it describes only applies to the SignedData content type.
>> 
>> - John Pawling
> 
>

Date: Wed, 12 Nov 1997 15:50:07 -0500
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SMIMECapabilities OID
Cc: [email-masked]
Sender: [email-masked]

Blake:

You are correct; the first letter must be lower case.  My personal
preference would be smimeCapabilities.

Russ

At 09:38 PM 10/31/97 -0800, Blake Ramsdell wrote:
>This recent chatter about OIDs leads me to believe that we have violated
>the OID naming conventions with the SMIMECapabilities OID.  The initial
>'S' should probably be lower-case:
>
>sMIMECapabilities
>
>And now we're as cool as dNSName in PKIX!
>
>Russ / Peter / whoever -- is this indeed the convention?
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>

Date: Wed, 12 Nov 1997 09:22:48 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Cc: [email-masked]
Sender: [email-masked]

Phil:

I hate SET OF too.  However, I wonder if this example will really be that
complex.  I suspect that the number of elements in the SET will be quite
small.  In practice, the SecurityCategories OID will define a structure
that represents several security categories.  Given this situation, is it
worth the effort to add the CHOICE.

What do others on the list think?

Russ

At 04:20 PM 11/5/97 -0500, Phillip H. Griffin wrote:
>John Pawling wrote:
>> 
>> Phil,
>> 
>> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
>> international standard representation of security label and it is used by
>> many existing programs.  The X.411 SecurityLabel syntax includes
>> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
>> with X.411, it should not be changed.
>> 
>> ================================
>> John Pawling
>> [email-masked]
>> J.G. Van Dyke & Associates, Inc.
>> ================================
>> 
>
>I agree that no change should be made that breaks backwards 
>compatibility, but it would be possible, if accompanied with 
>a change in version, to alter the definition to
>
>  SecurityCategories ::= CHOICE {
>    setOf  SET SIZE (1..ub-security-categories) OF
>                               SecurityCategory,
>    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
>                               SecurityCategory
>  }
>
>  ub-security-categories INTEGER ::= 64
>
>so that no additional tagging were needed to distinguish 
>between the two types. If typically the SET OF size is
>small and the data easy to sort, it probably wouldn't 
>be worth the effort.
>
>> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
>> >The type defined as
>> >
>> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
>> >                             SecurityCategory
>> >
>> >requires sorting under DER that would not be required if the
>> >type were defined as a SEQUENCE OF.
>> >
>> >X.690, which defines DER restrictions in section 11, "Restrictions
>> >on BER employed by both CER and DER", states that for components of
>> >type SET OF, "The encodings of the component values of a set-of
>> >value shall appear in ascending order, the encodings being compared
>> >as octet strings."
>> >
>> >Under DER, with SEQUENCE OF, the sender can control the order
>> >of components, but with SET OF, the final sort requirement rules,
>> >and sometimes may add unanticipated overhead to message processing.
>> >It was primarily for this reason, the the SET specification is
>> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
>> >types like
>> >
>> >  Certificates ::= SEQUENCE OF Certificate
>> >
>> >and avoid sorting what (hopefully) might be efficiently
>> >organized certificate chains in SignedData. Same for the CRLs
>> >and Attributes definitions.
>> >
>> >Phil
>
>Phil
>-- 
>Phillip H. Griffin         
>ASN.1-SET-Java-Security    Griffin Consulting
>[email-masked]        1625 Glenwood Avenue
>919.828.7114               Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Wed, 12 Nov 1997 14:12:54 -0800
Sender: [email-masked]

On Wednesday, November 12, 1997 9:20 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> The PKCS #9 spec defines the SigningTime attribute to be UTCTime.
> 
> Propose that a new attribute should be defined called NewSigningTime that is
> defined as a GeneralizedTime.  If the WG agrees, then a new OID would need
> to be defined to identify NewSigningTime.  If the WG agrees, then the ESS
> spec should be enhanced to include NewSigningTime and recommend its use
> instead of SigningTime.

For compatibility, should we make this ChoiceOfTime, leave the OID the
same, and specify the same sliding window as PKIX part 1?  Didn't we do
some work in this area already?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "'Rich Ankney'" <[email-masked]>, "'Trevor Freeman'" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'John Pawling'" <[email-masked]>
Subject: RE: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 14:11:27 -0800
Sender: [email-masked]

On Wednesday, November 12, 1997 1:32 PM, Rich Ankney
[SMTP:[email-masked]] wrote:
> Is the following correct?
> 
> A normal message (of type 'data') is signed, giving a SignedData
> whose inner content is type 'data'.

This is correct -- the inner content is identified by the PKCS #7 data
OID, and the content is MIME data.

> A receipt is signed, giving another SignedData whose inner conten
> is type 'receipt'.

The inner content is identified by the ESS receipt OID, and the content
is a Receipt structure.

> The thing I was objecting to is having to peel open the inner contentInfo
> and determine it's type, in order to know what kind of digesting to do.
> This means the digesting part of CMS applies to all contents being
> signed except for receipts; the processing for receipts is described in
> ESS.  So handling of SignedData is now spread across two documents,
> which isn't exactly optimal from a developer's point of view.    

There is no change in the digesting -- you follow the steps in CMS (hash
the content part of the inner ContentInfo, then either use that to
verify the signature or verify the signature on the SignerInfo's
authenticatedAttributes, etc.)

The resulting Receipt structure may need to be handled in a special way,
but the signature provided by the enclosing SignedData should be
computed identically to any other SignedData entity.

I think we're still missing, and I don't know how to explain it better,
or if my understanding is wrong.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 12 Nov 1997 10:59:57 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: More Comments to CMS-00
Cc: [email-masked]
Sender: [email-masked]

John:

I agree that I need to add a paragraph about OriginatorInfo.  The words
that you provide suggest that the certs should not be OPTIONAL.  I do not
think that this is correct.  In some cases, the originator might know that
his certificate is already in the recipient's cache.

Russ

At 06:23 PM 11/4/97 -0500, John Pawling wrote:
>All,
>
>I need to enhance my previous comment #8 to be:
>
>8) sec 6.1: Please add the following text to the description of the fields
>of type EnvelopedData:  "originatorInfo includes information regarding the
>originator.  It is present in EnvelopedData only if required by the key
>management algorithm (e.g. Diffie-Hellman (DH), Key Exchange Algorithm
>(KEA)).  At a minimum, originatorInfo must include the certificate
>containing the originator's key management public key material required by
>the recipient to form the pairwise key required to decrypt the recipient's
>copy of the content-encryption key.  originatorInfo may include multiple key
>management certificates for the same subject (i.e. originator).  For
>example, if the originator has included both DH-protected and KEA-protected
>copies of the content-encryption key in recipientInfos, then separate
>certificates including the originator's KEA and DH public key material would
>be required in originatorInfo."  
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>>To: [email-masked]
>>From: [email-masked] (John Pawling)
>>Subject: Comments to CMS-00
>>Cc: 
>>Bcc: 
>>X-Attachments: 
>>
>>All,
>>
>>IMHO Russ Housley has done a most excellent job of drafting the
>"Cryptographic Message Syntax" spec.  I have the following minor comments:
>>
>>1) Abstract: Please change "deriveded" to "derived".
>>
>>2) Sec 3: Please change "in 3 The methods below" to "The methods below".
>>
>>3) Sec 5: Please change: "The signer's public key is either contained in a
>certificate included in the signer information, or is referenced by an
>issuer distinguished name and an issuer-specific serial number that uniquely
>identify the certificate containing the public key." to "The signer's public
>key is referenced by an issuer distinguished name and an issuer-specific
>serial number that uniquely identify the certificate containing the public
>key.  The signer's certificate may be included in the SignedData
>certificates field."
>>
>>4) Sec 5, last sentence: Please change "signiture" to "signature".
>>
>>5) sec 5.1, version description: Please change "version shall 1" to
>"version shall be 1"
>>
>>6) sec 5.1, certificates description: Please change "version shall 1" to
>"version shall be 1"
>>
>>7) sec 5.4: Please change two occurrences of "algorithm deployed" to
>"algorithm employed".
>>
>>8) sec 6.1: Please add the following text to the description of the fields
>of type EnvelopedData:  "originatorInfo includes information regarding the
>originator.  It is present in EnvelopedData only if required by the key
>management algorithm (e.g. Diffie-Hellman)."
>>
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>================================
>>  
>>
>>
>>
>>
>>At 06:01 PM 11/1/97 -0800, Paul Hoffman / IMC wrote:
>>>The Internet Draft for the message format to be used in S/MIME 3 is now
>>>available; please see <http://www.imc.org/draft-housley-smime-cms>. This is
>>>the replacement for PKCS #7 1.5, and is only slightly different. Strap on
>>>your ASN.1 goggles and enjoy!
>>>
>>>Two other parts of S/MIME 3 (the message spec and the optional security
>>>enhancements) will be appearing shortly. The certs spec will appear in a
>>>few weeks, once we finish with the v2 certs definition.
>>>
>>>
>>>--Paul Hoffman, Director
>>>--Internet Mail Consortium
>>>
>>
>

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: SigningTime
Date: Wed, 12 Nov 1997 17:00:50 -0500
Sender: [email-masked]

Hi,

As an additional option, a new attribute might be defined called
TimeStampToken (for the cases in which trusted time is required on a
message and trusted time stamp servers exist in a network).  See

     ftp://ds.internic.net/internet-drafts/draft-adams-time-stamp-00.txt

for details.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

>----------
>From: 	[email-masked][SMTP:[email-masked]]
>Sent: 	Wednesday, November 12, 1997 12:20 PM
>To: 	[email-masked]
>Subject: 	SigningTime
>
>All,
>
>The PKCS #9 spec defines the SigningTime attribute to be UTCTime.
>
>Propose that a new attribute should be defined called NewSigningTime that is
>defined as a GeneralizedTime.  If the WG agrees, then a new OID would need
>to be defined to identify NewSigningTime.  If the WG agrees, then the ESS
>spec should be enhanced to include NewSigningTime and recommend its use
>instead of SigningTime.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================ 
>
>

From: "Rich Ankney" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 16:31:57 -0500
Sender: [email-masked]

I think there's still a disconnect here.

Is the following correct?

A normal message (of type 'data') is signed, giving a SignedData
whose inner content is type 'data'.

A receipt is signed, giving another SignedData whose inner conten
is type 'receipt'.

The thing I was objecting to is having to peel open the inner contentInfo
and determine it's type, in order to know what kind of digesting to do.
This means the digesting part of CMS applies to all contents being
signed except for receipts; the processing for receipts is described in
ESS.  So handling of SignedData is now spread across two documents,
which isn't exactly optimal from a developer's point of view.    

Regards,
Rich
----------
> From: John Pawling <[email-masked]>
> To: Rich Ankney <[email-masked]>; Trevor Freeman
<[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry Layten'
<[email-masked]>; [email-masked]'
> Subject: Re: Receipts vs. SignedData
> Date: Wednesday, November 12, 1997 3:56 PM
> 
> Rich,
> 
> I agree with you that the ESS Receipt strategy should remain as is and
that
> the CMS spec should be clarified to state that the message-digesting
process
> that it describes only applies to the SignedData content type.
> 
> - John Pawling

Date: Wed, 12 Nov 1997 15:56:35 -0500
To: "Rich Ankney" <[email-masked]>, "Trevor Freeman" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Receipts vs. SignedData
Sender: [email-masked]

Rich,

I agree with you that the ESS Receipt strategy should remain as is and that
the CMS spec should be clarified to state that the message-digesting process
that it describes only applies to the SignedData content type.

- John Pawling

At 03:29 PM 11/12/97 -0500, Rich Ankney wrote:
>I do think that, if the Receipt mechanism remains as is, we need to fix
>the relevant portions of CMS to indicate that the message-digesting
>process is dependent upon the type of content being signed.  The
>current text works for all types except receipts, which the text in ESS
>handles.  This may not be such a bad thing, as we may come up with similar
>kinds of constructs that include data in the signature which is not present
>in the contentInfo.
>
>Regards,
>Rich
>
>----------
>> From: John Pawling <[email-masked]>
>> To: Trevor Freeman <[email-masked]>; 'Rich Ankney'
><[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry Layten'
><[email-masked]>; [email-masked]'
>> Subject: RE: Receipts vs. SignedData
>> Date: Wednesday, November 12, 1997 2:55 PM
>> 
>> Trevor,
>> 
>> I respectfully disagree with your proposal to change the ESS
>specification
>> to move Receipt to an authenticated attribute of the signed data type. 
>If
>> your proposal was adopted, then the content would be completely absent
>from
>> the SignedData object including the Receipt attribute.  The ContentInfo
>> field of SignedData is not optional, so your proposal implies that a new
>OID
>> would need to be defined for use in the ContentInfo ContentType
>indicating
>> that the Content ANY field is absent. In fact, your proposal is less
>> efficient than the current ESS strategy, because in the attribute case
>you
>> would have to include two OIDs (one which identifies the Receipt
>attribute
>> and another in the contentInfo indicating that the contnet is absent)
>> whereas the current ESS strategy requires only one OID (in the
>contentInfo
>> indicating that a Receipt is encpasulated in the ContentInfo).
>> 
>> To reply to the other comments in the message trail.  Yes, the
>ESS-specified
>> processing for a SignedData/Receipt is different than for a regular
>> SignedData object because different security services are provided.  The
>> SignedData ContentInfo OID will indicate that the SignedData encapsulates
>a
>> Receipt content, so it will be straightforward for an Application to
>> determine when a SignedData includes a Receipt content and to take the
>> appropriate actions.
>> 
>> In summary, I believe that the ESS Receipt strategy should not be changed
>> (except to add clarifying text stating that multiple, identical
>> ReceiptRequest attributes can be present in a SignedData object as
>discussed
>> in previous e-mail messages).
>> 
>> ================================
>> John Pawling   
>> [email-masked]                             
>> J.G. Van Dyke & Associates, Inc.           
>> ================================
>> 
>> 
>> At 07:20 AM 11/12/97 -0800, Trevor Freeman wrote:
>> >I think this is a good reason to change the ESS specification to move
>> >receipts to an authenticated attribute of the signed data type. Why do
>we
>> >need a new data type to convey this receipt information in the first 
>place?
>> >There is a signed data layer with the receipt with authenticated
>attributes
>> >so lets use it. 
>> >Trevor
>> >
>> >> -----Original Message-----
>> >> From:	Rich Ankney [SMTP:[email-masked]]
>> >> Sent:	Tuesday, November 11, 1997 11:01 PM
>> >> To:	Blake Ramsdell; 'Larry Layten'; [email-masked]'
>> >> Subject:	Re: Receipts vs. SignedData
>> >> 
>> >> ----------
>> >> > From: Blake Ramsdell <[email-masked]>
>> >> > To: 'Rich Ankney' <[email-masked]>; 'Larry Layten'
><[email-masked]>;
>> >> [email-masked]'
>> >> > Subject: RE: Receipts vs. SignedData
>> >> > Date: Tuesday, November 11, 1997 4:46 PM
>> >> > 
>> >> > On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
>> >> > [SMTP:[email-masked]] wrote:
>> >> > > Agreed; I'm just looking for a way to have common processing of
>> >> > > SignedData, regardless of the inner content.  If there's no
>secure,
>> >> > > clean way to do it, I can live with what's there now.  Perhaps the
>> >> > > OUTER content should be Receipt, instead of SignedData, where
>> >> > > a Receipt is then the combination of SignedData and (inner)
>> >> > > Receipt, processed as defined in ESS?
>> >> > 
>> >> > I may be confused here, so someone please correct me if I am wrong.
>> >> > 
>> >> > Rich, my understanding of your comments is that the signature
>> >> > verification of S/MIME messages of outer content type SignedData are
>> >> > handled inconsistently, depending on whether or not it encloses MIME
>> >> > data (identified by the PKCS #7-defined OID "data") or a Receipt
>> >> > structure (identified by the newly created "receipt" OID under the
>SMIME
>> >> > arc).  Is this the case?  My understanding is that the SignedData
>> >> > signature computation for both is exactly the same, and that the
>only
>> >> > processing difference occurs when the inner content (either the MIME
>> >> > data or the Receipt structure) is removed and processed.  That is,
>the
>> >> > MIME data is processed through the MIME engine, and the Receipt
>> >> > structure is processed through "other means" that are
>> >> > receiver-dependent.
>> >> >
>> >> Maybe it's me that's confused, but it seems to me that Section 5.3 of
>> >> the CMS spec describes how to compute the message digest: on the
>> >> DER encoding of the content being signed (the ContentInfo).  This is
>> >> then used, if necessary, as the messageDigest attribute (if
>> >> authenticatedAttributes are used), else it is signed directly.
>> >> 
>> >> ESS describes a different method of computing the message digest:
>> >> it is, instead of H(inner content), computed as:
>> >> H(original-message || Receipt), where original-message is the one
>> >> we are generating the receipt for, and Receipt is the data structure
>> >> of the same name.  Only Receipt is in the actual inner ContentInfo
>> >> of the SignedData being returned to the originator.  This new method
>> >> of computing the message digest (which we use only if the inner
>> >> content is a Receipt) is what I was talking about.  
>> >> 
>> >> Or am I reading ESS wrong?
>> >>  
>> >> > If this is not the case, then I may need some information as to why
>> >> > there is a difference, since I agree -- the signature processing
>should
>> >> > be the same.
>> >> > 
>> >> The actual signature process is the same: sign the digest or the
>> >> authenticatedAttributes.  It's the digest computation that's
>different.
>> >> At a minimum, CMS needs to address this, I think. Or make the
>> >> content type of the outer message (currently SignedData), something
>> >> different (but still with SignedData syntax).  I'd prefer to always
>> >> process
>> >> the digest and signature computation the same for SignedData,
>regardless
>> >> of the inner content type, but that's just my personal opinion...
>> >> 
>> >> > Blake
>> >> > --
>> >> 
>> >> Regards,
>> >> Rich
>> >
>> 
>

From: "Rich Ankney" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 15:29:24 -0500
Sender: [email-masked]

I do think that, if the Receipt mechanism remains as is, we need to fix
the relevant portions of CMS to indicate that the message-digesting
process is dependent upon the type of content being signed.  The
current text works for all types except receipts, which the text in ESS
handles.  This may not be such a bad thing, as we may come up with similar
kinds of constructs that include data in the signature which is not present
in the contentInfo.

Regards,
Rich

----------
> From: John Pawling <[email-masked]>
> To: Trevor Freeman <[email-masked]>; 'Rich Ankney'
<[email-masked]>; Blake Ramsdell <[email-masked]>; 'Larry Layten'
<[email-masked]>; [email-masked]'
> Subject: RE: Receipts vs. SignedData
> Date: Wednesday, November 12, 1997 2:55 PM
> 
> Trevor,
> 
> I respectfully disagree with your proposal to change the ESS
specification
> to move Receipt to an authenticated attribute of the signed data type. 
If
> your proposal was adopted, then the content would be completely absent
from
> the SignedData object including the Receipt attribute.  The ContentInfo
> field of SignedData is not optional, so your proposal implies that a new
OID
> would need to be defined for use in the ContentInfo ContentType
indicating
> that the Content ANY field is absent. In fact, your proposal is less
> efficient than the current ESS strategy, because in the attribute case
you
> would have to include two OIDs (one which identifies the Receipt
attribute
> and another in the contentInfo indicating that the contnet is absent)
> whereas the current ESS strategy requires only one OID (in the
contentInfo
> indicating that a Receipt is encpasulated in the ContentInfo).
> 
> To reply to the other comments in the message trail.  Yes, the
ESS-specified
> processing for a SignedData/Receipt is different than for a regular
> SignedData object because different security services are provided.  The
> SignedData ContentInfo OID will indicate that the SignedData encapsulates
a
> Receipt content, so it will be straightforward for an Application to
> determine when a SignedData includes a Receipt content and to take the
> appropriate actions.
> 
> In summary, I believe that the ESS Receipt strategy should not be changed
> (except to add clarifying text stating that multiple, identical
> ReceiptRequest attributes can be present in a SignedData object as
discussed
> in previous e-mail messages).
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> At 07:20 AM 11/12/97 -0800, Trevor Freeman wrote:
> >I think this is a good reason to change the ESS specification to move
> >receipts to an authenticated attribute of the signed data type. Why do
we
> >need a new data type to convey this receipt information in the first 
place?
> >There is a signed data layer with the receipt with authenticated
attributes
> >so lets use it. 
> >Trevor
> >
> >> -----Original Message-----
> >> From:	Rich Ankney [SMTP:[email-masked]]
> >> Sent:	Tuesday, November 11, 1997 11:01 PM
> >> To:	Blake Ramsdell; 'Larry Layten'; [email-masked]'
> >> Subject:	Re: Receipts vs. SignedData
> >> 
> >> ----------
> >> > From: Blake Ramsdell <[email-masked]>
> >> > To: 'Rich Ankney' <[email-masked]>; 'Larry Layten'
<[email-masked]>;
> >> [email-masked]'
> >> > Subject: RE: Receipts vs. SignedData
> >> > Date: Tuesday, November 11, 1997 4:46 PM
> >> > 
> >> > On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
> >> > [SMTP:[email-masked]] wrote:
> >> > > Agreed; I'm just looking for a way to have common processing of
> >> > > SignedData, regardless of the inner content.  If there's no
secure,
> >> > > clean way to do it, I can live with what's there now.  Perhaps the
> >> > > OUTER content should be Receipt, instead of SignedData, where
> >> > > a Receipt is then the combination of SignedData and (inner)
> >> > > Receipt, processed as defined in ESS?
> >> > 
> >> > I may be confused here, so someone please correct me if I am wrong.
> >> > 
> >> > Rich, my understanding of your comments is that the signature
> >> > verification of S/MIME messages of outer content type SignedData are
> >> > handled inconsistently, depending on whether or not it encloses MIME
> >> > data (identified by the PKCS #7-defined OID "data") or a Receipt
> >> > structure (identified by the newly created "receipt" OID under the
SMIME
> >> > arc).  Is this the case?  My understanding is that the SignedData
> >> > signature computation for both is exactly the same, and that the
only
> >> > processing difference occurs when the inner content (either the MIME
> >> > data or the Receipt structure) is removed and processed.  That is,
the
> >> > MIME data is processed through the MIME engine, and the Receipt
> >> > structure is processed through "other means" that are
> >> > receiver-dependent.
> >> >
> >> Maybe it's me that's confused, but it seems to me that Section 5.3 of
> >> the CMS spec describes how to compute the message digest: on the
> >> DER encoding of the content being signed (the ContentInfo).  This is
> >> then used, if necessary, as the messageDigest attribute (if
> >> authenticatedAttributes are used), else it is signed directly.
> >> 
> >> ESS describes a different method of computing the message digest:
> >> it is, instead of H(inner content), computed as:
> >> H(original-message || Receipt), where original-message is the one
> >> we are generating the receipt for, and Receipt is the data structure
> >> of the same name.  Only Receipt is in the actual inner ContentInfo
> >> of the SignedData being returned to the originator.  This new method
> >> of computing the message digest (which we use only if the inner
> >> content is a Receipt) is what I was talking about.  
> >> 
> >> Or am I reading ESS wrong?
> >>  
> >> > If this is not the case, then I may need some information as to why
> >> > there is a difference, since I agree -- the signature processing
should
> >> > be the same.
> >> > 
> >> The actual signature process is the same: sign the digest or the
> >> authenticatedAttributes.  It's the digest computation that's
different.
> >> At a minimum, CMS needs to address this, I think. Or make the
> >> content type of the outer message (currently SignedData), something
> >> different (but still with SignedData syntax).  I'd prefer to always
> >> process
> >> the digest and signature computation the same for SignedData,
regardless
> >> of the inner content type, but that's just my personal opinion...
> >> 
> >> > Blake
> >> > --
> >> 
> >> Regards,
> >> Rich
> >
> 

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Subject: AuthenticatedData
Date: Wed, 12 Nov 1997 15:45:22 -0500
Sender: [email-masked]

Here's the proposal for authenticated (i.e. MAC'ed) data as a new content
type.

AuthenticatedData ::= SEQUENCE {
  version Version,
  originatorInfo [0] OriginatorInfo OPTIONAL,
  recipientInfos RecipientInfos,
  contentInfo contentInfo,
  macs MACS }

RecipientInfo ::= SEQUENCE {
  version Version,
  rid RecipientIdentifier,
  macAlgorithm AlgorithmIdentifier
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey }

MACS ::= SET OF MAC

MAC ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  authenticator OCTET STRING }

Notes:

1. 	This construct supports provision of an authenticator (MAC) by a single
originator.
2. 	The originator may compute multiple MACs in order to accommodate
multiple recipients who use different algorithms.  For a given algorithm,
the originator will provide a single MAC, and transport the key to all
recipients which use that algorithm.
3. 	Key management is based on that in the new EnvelopedData; the
macAlgorithm field is added to the RecipientInfo field to assist the
recipient in locating the appropriate MAC in the MACS field.
4.   There is no support for multiple originators, or for authenticated or 
      unauthenticated attributes.
5.   Some discussion on deriving both content-encryption and MAC keys from
      the same keying material (DH shared secret, or RSA-encrypted "blob" a
      la SSL) might be in order.

Regards,
Rich

Date: Wed, 12 Nov 1997 14:55:43 -0500
To: Trevor Freeman <[email-masked]>, "'Rich Ankney'" <[email-masked]>, Blake Ramsdell <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Receipts vs. SignedData
Sender: [email-masked]

Trevor,

I respectfully disagree with your proposal to change the ESS specification
to move Receipt to an authenticated attribute of the signed data type.  If
your proposal was adopted, then the content would be completely absent from
the SignedData object including the Receipt attribute.  The ContentInfo
field of SignedData is not optional, so your proposal implies that a new OID
would need to be defined for use in the ContentInfo ContentType indicating
that the Content ANY field is absent. In fact, your proposal is less
efficient than the current ESS strategy, because in the attribute case you
would have to include two OIDs (one which identifies the Receipt attribute
and another in the contentInfo indicating that the contnet is absent)
whereas the current ESS strategy requires only one OID (in the contentInfo
indicating that a Receipt is encpasulated in the ContentInfo).

To reply to the other comments in the message trail.  Yes, the ESS-specified
processing for a SignedData/Receipt is different than for a regular
SignedData object because different security services are provided.  The
SignedData ContentInfo OID will indicate that the SignedData encapsulates a
Receipt content, so it will be straightforward for an Application to
determine when a SignedData includes a Receipt content and to take the
appropriate actions.

In summary, I believe that the ESS Receipt strategy should not be changed
(except to add clarifying text stating that multiple, identical
ReceiptRequest attributes can be present in a SignedData object as discussed
in previous e-mail messages).

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 07:20 AM 11/12/97 -0800, Trevor Freeman wrote:
>I think this is a good reason to change the ESS specification to move
>receipts to an authenticated attribute of the signed data type. Why do we
>need a new data type to convey this receipt information in the first  place?
>There is a signed data layer with the receipt with authenticated attributes
>so lets use it. 
>Trevor
>
>> -----Original Message-----
>> From:	Rich Ankney [SMTP:[email-masked]]
>> Sent:	Tuesday, November 11, 1997 11:01 PM
>> To:	Blake Ramsdell; 'Larry Layten'; [email-masked]'
>> Subject:	Re: Receipts vs. SignedData
>> 
>> ----------
>> > From: Blake Ramsdell <[email-masked]>
>> > To: 'Rich Ankney' <[email-masked]>; 'Larry Layten' <[email-masked]>;
>> [email-masked]'
>> > Subject: RE: Receipts vs. SignedData
>> > Date: Tuesday, November 11, 1997 4:46 PM
>> > 
>> > On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
>> > [SMTP:[email-masked]] wrote:
>> > > Agreed; I'm just looking for a way to have common processing of
>> > > SignedData, regardless of the inner content.  If there's no secure,
>> > > clean way to do it, I can live with what's there now.  Perhaps the
>> > > OUTER content should be Receipt, instead of SignedData, where
>> > > a Receipt is then the combination of SignedData and (inner)
>> > > Receipt, processed as defined in ESS?
>> > 
>> > I may be confused here, so someone please correct me if I am wrong.
>> > 
>> > Rich, my understanding of your comments is that the signature
>> > verification of S/MIME messages of outer content type SignedData are
>> > handled inconsistently, depending on whether or not it encloses MIME
>> > data (identified by the PKCS #7-defined OID "data") or a Receipt
>> > structure (identified by the newly created "receipt" OID under the SMIME
>> > arc).  Is this the case?  My understanding is that the SignedData
>> > signature computation for both is exactly the same, and that the only
>> > processing difference occurs when the inner content (either the MIME
>> > data or the Receipt structure) is removed and processed.  That is, the
>> > MIME data is processed through the MIME engine, and the Receipt
>> > structure is processed through "other means" that are
>> > receiver-dependent.
>> >
>> Maybe it's me that's confused, but it seems to me that Section 5.3 of
>> the CMS spec describes how to compute the message digest: on the
>> DER encoding of the content being signed (the ContentInfo).  This is
>> then used, if necessary, as the messageDigest attribute (if
>> authenticatedAttributes are used), else it is signed directly.
>> 
>> ESS describes a different method of computing the message digest:
>> it is, instead of H(inner content), computed as:
>> H(original-message || Receipt), where original-message is the one
>> we are generating the receipt for, and Receipt is the data structure
>> of the same name.  Only Receipt is in the actual inner ContentInfo
>> of the SignedData being returned to the originator.  This new method
>> of computing the message digest (which we use only if the inner
>> content is a Receipt) is what I was talking about.  
>> 
>> Or am I reading ESS wrong?
>>  
>> > If this is not the case, then I may need some information as to why
>> > there is a difference, since I agree -- the signature processing should
>> > be the same.
>> > 
>> The actual signature process is the same: sign the digest or the
>> authenticatedAttributes.  It's the digest computation that's different.
>> At a minimum, CMS needs to address this, I think. Or make the
>> content type of the outer message (currently SignedData), something
>> different (but still with SignedData syntax).  I'd prefer to always
>> process
>> the digest and signature computation the same for SignedData, regardless
>> of the inner content type, but that's just my personal opinion...
>> 
>> > Blake
>> > --
>> 
>> Regards,
>> Rich
>

From: Trevor Freeman <[email-masked]>
To: "'Rich Ankney'" <[email-masked]>, Blake Ramsdell <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Receipts vs. SignedData
Date: Wed, 12 Nov 1997 07:20:08 -0800
Sender: [email-masked]

I think this is a good reason to change the ESS specification to move
receipts to an authenticated attribute of the signed data type. Why do we
need a new data type to convey this receipt information in the first  place?
There is a signed data layer with the receipt with authenticated attributes
so lets use it. 
Trevor

> -----Original Message-----
> From:	Rich Ankney [SMTP:[email-masked]]
> Sent:	Tuesday, November 11, 1997 11:01 PM
> To:	Blake Ramsdell; 'Larry Layten'; [email-masked]'
> Subject:	Re: Receipts vs. SignedData
> 
> ----------
> > From: Blake Ramsdell <[email-masked]>
> > To: 'Rich Ankney' <[email-masked]>; 'Larry Layten' <[email-masked]>;
> [email-masked]'
> > Subject: RE: Receipts vs. SignedData
> > Date: Tuesday, November 11, 1997 4:46 PM
> > 
> > On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
> > [SMTP:[email-masked]] wrote:
> > > Agreed; I'm just looking for a way to have common processing of
> > > SignedData, regardless of the inner content.  If there's no secure,
> > > clean way to do it, I can live with what's there now.  Perhaps the
> > > OUTER content should be Receipt, instead of SignedData, where
> > > a Receipt is then the combination of SignedData and (inner)
> > > Receipt, processed as defined in ESS?
> > 
> > I may be confused here, so someone please correct me if I am wrong.
> > 
> > Rich, my understanding of your comments is that the signature
> > verification of S/MIME messages of outer content type SignedData are
> > handled inconsistently, depending on whether or not it encloses MIME
> > data (identified by the PKCS #7-defined OID "data") or a Receipt
> > structure (identified by the newly created "receipt" OID under the SMIME
> > arc).  Is this the case?  My understanding is that the SignedData
> > signature computation for both is exactly the same, and that the only
> > processing difference occurs when the inner content (either the MIME
> > data or the Receipt structure) is removed and processed.  That is, the
> > MIME data is processed through the MIME engine, and the Receipt
> > structure is processed through "other means" that are
> > receiver-dependent.
> >
> Maybe it's me that's confused, but it seems to me that Section 5.3 of
> the CMS spec describes how to compute the message digest: on the
> DER encoding of the content being signed (the ContentInfo).  This is
> then used, if necessary, as the messageDigest attribute (if
> authenticatedAttributes are used), else it is signed directly.
> 
> ESS describes a different method of computing the message digest:
> it is, instead of H(inner content), computed as:
> H(original-message || Receipt), where original-message is the one
> we are generating the receipt for, and Receipt is the data structure
> of the same name.  Only Receipt is in the actual inner ContentInfo
> of the SignedData being returned to the originator.  This new method
> of computing the message digest (which we use only if the inner
> content is a Receipt) is what I was talking about.  
> 
> Or am I reading ESS wrong?
>  
> > If this is not the case, then I may need some information as to why
> > there is a difference, since I agree -- the signature processing should
> > be the same.
> > 
> The actual signature process is the same: sign the digest or the
> authenticatedAttributes.  It's the digest computation that's different.
> At a minimum, CMS needs to address this, I think. Or make the
> content type of the outer message (currently SignedData), something
> different (but still with SignedData syntax).  I'd prefer to always
> process
> the digest and signature computation the same for SignedData, regardless
> of the inner content type, but that's just my personal opinion...
> 
> > Blake
> > --
> 
> Regards,
> Rich

Date: Wed, 12 Nov 1997 12:20:16 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: SigningTime
Sender: [email-masked]

All,

The PKCS #9 spec defines the SigningTime attribute to be UTCTime.

Propose that a new attribute should be defined called NewSigningTime that is
defined as a GeneralizedTime.  If the WG agrees, then a new OID would need
to be defined to identify NewSigningTime.  If the WG agrees, then the ESS
spec should be enhanced to include NewSigningTime and recommend its use
instead of SigningTime.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================ 

Date: Wed, 12 Nov 1997 09:04:31 -0500
To: Russ Housley <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comments on the Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Russ and Jim,

I respectfully disagree with proposal #5 in the enclosed message trail that
"originator-certificate-selector" needs to be added to the RecipientInfo
SEQUENCE.  IMHO, there should only be a single originating entity that
protects keys for inclusion in the EnvelopedData ReceipientInfos.  That
single originating entity can include multiple key management certs in the
OriginatorInfo component of EnvelopedData.  For example, if the originator
has included both DH-protected and KEA-protected
copies of the content-encryption key in recipientInfos, then separate
certificates including the originator's KEA and DH public key material would
be present in originatorInfo.  The recieving agent can identify the correct
originator's cert from which to extract the public key to use to form the
pairwise key to decrypt a RecipientInfo encryptedKey by comparing the
keyEncryptionIdentifier with the subjectPublicKeyInfo algorithm identifier
in each of the originator's certs.

IMHO, the addition of "originator-certificate-selector" to the
ReceipientInfo SEQUENCE adds needless complexity.  Furthermore, it allows
the syntax to support different originating entities protecting keys using
the same algorithm.  I don't believe that is a valid requirement.  

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 10:42 PM 11/11/97 -0500, Russ Housley wrote:
>Jim:
>
>>Some comments on the Cryptographic Message Syntax spec:
>>
>>1. ASN.1 Canonical Encoding Rules should be allowed
>>
>>>                                                            Single-
>>>    pass operation has one significant drawback; it is difficult to
>>>    perform encode operations using the Distinguished Encoding Rules
>>>    (DER) encoding in a single pass since the lengths of the various
>>>    components may not be known in advance. Since DER encoding is
>>>    required by the signed-data content type, an extra pass may be
>>>    necessary when a content type other than data is encapsulated.
>>
>>Why does the signed-data content type require DER? Why doesn't it allow
>>the choice of CER or DER, with the digest algorithm-identifier indicating
>>which? For example, SHA-1 on the CER encoding would have a different 
>>algorithm-identifier to SHA-1 on the DER encoding. [For anyone unfamiliar
>>with CER, it is defined in the 1994 version of ASN.1, and is identical to
>>DER except that CER uses indefinite length encoding (which permits 
>>single-pass encoding) and constructed encoding of strings.]
>
>Does CER prohibit definite length encoding?  If not, there would be more
>than one way to enocde the same structure.
>
>>2. There is an ambiguity about which octets are input to hash and
>encryption algorithms
>>
>>>    The message digest calculation process computes a message digest on
>>>    either the content being signed or the content together with the
>>>    signer's authenticated attributes. In either case, the initial input
>>>    to the message digest calculation process is the "value" of the
>>>    content being signed. Specifically, the initial input is the content
>>>    octets of the DER encoding of the content field of the ContentInfo
>>>    value to which the signing process is applied. Only the contents
>>>    octets of the DER encoding of that field are input to the message
>>>    digest algoritm, not the identifier octets or the length octets.
>>> 
>>>    When the content being signed has content type data and the
>>>    authenticatedAttributes field is absent, then just the value of the
>>>    data (e.g., the contents of a file) is input to the message digest
>>>    calculation. This has the advantage that the length of the content
>>>    being signed need not be known in advance of the encryption process.
>>> 
>>>    Although the identifier octets and the length octets are not included
>>>    in the message digest calculation, they are still protected by other
>>>    means. The length octets are protected by the nature of the message
>>>    digest algorithm since it is computationally infeasible to find any
>>>    two distinct messages of any length that have the same message
>>>    digest.
>>> 
>>
>>The first of the three paragraphs above says something different about 
>>which octets are input into the hash function than the implication of 
>>the second and third paragraphs. Consider the encoding of the content 
>>field of the ContentInfo in the following examples:
>>
>>For the data content type:
>>
>>Identifier      Length  Contents
>>[0]             nnn     
>>                        Identifier      Length  Contents
>>                        OctetString     nnn     xxxxxxxxx
>>
>>
>>For the signed-data content type:
>>
>>Identifier      Length  Contents
>>[0]             nnn     
>>                        Identifier      Length  Contents
>>                        Sequence        nnn     
>>                                                Identifier      Length
>Contents
>>                                                Integer         1       1
>>
>>
>>The first paragraph above says that it is the contents octets of the 
>>content field which is input to the hash function - i.e. octets starting
>>with the identifier for OctetString in the case of the data content type
>>- but the second paragraph implies that it is just the contents octets 
>>of this OctetString. Should the first paragraph be changed to replace 
>>"content octets of the DER encoding of the content field" by "DER 
>>encoding of the content octets of the type within the content field"? 
>>That is, does the input to the hash start with the identifier for 
>>Integer in the case of signed-data?
>
>I read the first paragrph three times.  I do not see the issue.  Maybe you
>can try explaining it again....
>
>>3. User Keying Materials
>>
>>Surely these should be included within the parameters component of the
>>algorithm-identifier for algorithms which require such material.
>
>No.  The following structure is present for each recipient:
>
>  RecipientInfo ::= SEQUENCE {
>    version Version,
>    rid RecipientIdentifier,
>    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>    encryptedKey EncryptedKey }
>
>If the UKM is carried in the KeyEncryptionAlgorithmIdentifier, then it is
>carried several times, once for each recipient.  UKMs can be large (128
>bytes), so we want to carry it once for all of the recipients that use that
>form of key management.
>
>>4. RecipientKeyIdentifier
>>
>>RecipientKeyIdentifier is not an adequate identification of a recipient, 
>>since subjectKeyIdentifier is only unique within the scope of an 
>>individual recipient, and it is not accompanied by any other 
>>identification of the recipient. I suggest that the more general 
>>CertificateAssertion syntax from X.509 should be used instead of the 
>>restrictive subjectKeyIdentifier:
>>
>>     RecipientKeyIdentifier ::= SEQUENCE {
>>          recipient-name                  Name,
>>          recipient-certificate-selector  CertificateAssertion}
>
>Within the set of recipients, the subject key identifier should narrow the
>"hits" significantly.  In the unlikely event that there is more than one
>recipinet with the same subject key identifier, then the recipient can try
>each "hit."
>
>>5. Originator Certificate selection
>>
>>Some key agreement algorithms use different originator keys for different
>>recipients. It is therefore necessary to add an originator-certificate-
>>selector to RecipientInfo:
>>
>>     RecipientInfo ::= SEQUENCE {
>>          version Version,
>>          rid RecipientIdentifier,
>>          keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>>          encryptedKey EncryptedKey,
>>          originator-certificate-selector CertificateAssertion OPTIONAL }
>
>Okay, but I think that the location within the structure might be
>incorrect.  It needs to come sooner to accompdate single-pass processing.
>
>Please send me the ASN.1 for CertificateAssertion.
>
>Russ
>

Date: Wed, 12 Nov 1997 08:49:23 -0500
To: Trevor Freeman <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS-00 Multiple Signed Receipts Issue
Cc: [email-masked]
Sender: [email-masked]

Trevor,

Thank you very much for your additional feedback.  I respectfully disagree
with your points as follows:

You stated: 
>> >The signed receipt process as outlined only considers a single type of
>> >receipt. If fact there are more that one type of receipt. Examples of
>> >these types would be
>> >	A message has been delved to a mail box (but not opened).

The delivery of a message to a mail box does not involve any cryptographic
services, so a signed receipt is inappropriate.  This requirement should be
met by an element of the commnication protocol, not the security protocol.
For example, in the X.400 environment, the X.400 receipt (not a signed
receipt) provides this service.  The real solution is to enhance SMTP to
include a SMTP receipt (not a CMS/ESS signed receipt).

>> >A message has been opened

Depending on your definition of "opened", the "opening" of a message does
not necessarily mean that the message signature was verified, so a signed
receipt is inappropriate.  The signed receipt must only be sent if the
recipient can verify the signature of the message.

>> >The recipient acknowledges they have read (and hopefully understood)
>> >the message

This is way beyond the scope of crytographic services, so a signed receipt
is inappropriate.  This requirement would be met by the recipient sending a
message back to the originator stating "I read you message and understood it".

>> >	The recipient has actioned the message

Again, this is way beyond the scope of crytographic services, so a signed
receipt is inappropriate.  This requirement would be met by the recipient
sending a message back to the originator stating "I have acted upon your
message".

>> >Some of these receipts may mandate recipient intervention, such as
>> >acknowledgement and actioned. You may require different receipt types
>> from
>> >different people, therefore I would envisage the requirement for multiple
>> >receipt requests to be contained within the authenticated attributes of a
>> >single message, with different users being asked for different types of
>> >receipt.

I disagree with your proposal that ESS should allow for multiple, different
receipt requests  in a SignedData object, because I disagree with your basic
philosophy to try to solve problems in the communications protocol using
security protocol elements.

>The point is that these other types of receipt also have to be
>cryptographically bound to the receipt request, as such they form part of
>the cryptographic security services.

I disagree with this point because I disagree with your basic philosophy to
try to solve problems in the communications protocol using security protocol
elements.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 01:48 AM 11/12/97 -0800, Trevor Freeman wrote:
>Hi Jon,
>The point is that these other types of receipt also have to be
>cryptographically bound to the receipt request, as such they form part of
>the cryptographic security services. I therefore do not agree with you
>interpretation that these other types of receipt are outside a cryptographic
>security service or the ESS. There seem two way to progress this, 
>	either the receipt type is enhanced to include the capability to
>define other types of receipt 
>	or, even at this early stage of the standard, we start defining the
>addition of an extended receipt type request which would include the receipt
>type attribute along with all the other attributes included in the current
>definition.
>I know which option looks the ugliest.
>I also see no justification for making the receipt a new data type. It can
>just as easy be carried as an authenticated attribute. All it is a piece of
>signed data.
>Trevor
>> -----Original Message-----
>> From:	[email-masked] [SMTP:[email-masked]]
>> Sent:	Friday, November 07, 1997 4:07 PM
>> To:	Trevor Freeman
>> Cc:	[email-masked]
>> Subject:	RE: ESS-00 Multiple Signed Receipts Issue
>> 
>> Trevor,
>> 
>> Thank you very much for your feedback.  The CMS and ESS specifications
>> specify cryptographic security services, so the CMS/ESS signed receipt
>> should only provide cryptographic security services.  The purpose of the
>> CMS/ESS signed receipt is to prove to the originator that the recipient
>> was
>> able to verify the signature of the original message. This is the only
>> purpose for the ESS/CMS signed receipt that is within the scope of the CMS
>> and ESS specifications.  The other types of receipts that you list are
>> outside the scope of CMS and ESS, so they should be documented in separate
>> specifications that are not security-specific specifications.    
>> 
>> A CMS/ESS signed receipt is constructed by encapsulating an ESS Receipt
>> object within a CMS SignedData object.  The Receipt signature value is
>> included in the SignerInfo included in the SignedData object which
>> encapsulates the Receipt object.  The SignerInfo includes
>> autheticatedAttributes and unAuthenticatedAttributes.  Therefore, a
>> CMS/ESS
>> signed receipt can include any of the attributes listed in ESS (and some
>> from PKCS #9) or it could include privately defined attributes.  This
>> provides a lot of flexibility for the recipient to provide information
>> back
>> to the originator of the original message.
>> 
>> In my opinion, there is an open issue regarding whether or not all
>> receiptRequests included in a SignedData object MUST be identical.  I can
>> think of some bizarre scenarios in which different signers may wish to
>> require that signed receipts be sent to specific
>> entities, etc.  However, stating "All SignerInfos MUST contain the same
>> receiptRequest attribute." would simplify processing.  I could go either
>> way.
>> 
>> In summary, I believe that we should not change the signed receipt
>> syntaxes
>> and text included in ESS (other than adding clarifying text regarding
>> multiple receiptRequests included in a signedData object). 
>> 
>> ================================
>> John Pawling   
>> [email-masked]                             
>> J.G. Van Dyke & Associates, Inc.           
>> ================================
>> 
>> 
>> 
>> At 07:25 AM 11/7/97 -0800, Trevor Freeman wrote:
>> >I have a couple of related issues with signed receipts. 
>> >The signed receipt process as outlined only considers a single type of
>> >receipt. If fact there are more that one type of receipt. Examples of
>> these
>> >types would be
>> >	A message has been delved to a mail box (but not opened).
>> >	A message has been opened
>> >	The recipient acknowledges they have read (and hopefully understood)
>> >the message
>> >	The recipient has actioned the message
>> >Some of these receipts may mandate recipient intervention, such as
>> >acknowledgement and actioned. You may require different receipt types
>> from
>> >different people, therefore I would envisage the requirement for multiple
>> >receipt requests to be contained within the authenticated attributes of a
>> >single message, with different users being asked for different types of
>> >receipt.
>> >
>> >Another requirement of the originator is that they may require some
>> >additional information from the recipient to be returned as part of the
>> >receipt. This additional content may be considered mandatory by the
>> >originator. A drawback of defining the receipt as a new data type is that
>> it
>> >does not allow a place for this recipient originated information to be
>> >returned with the receipt. I would therefore submit that the receipt
>> should
>> >therefore be an authenticated attribute of the signed data structure in
>> the
>> >receipt not a new content. This would allow any new content to be
>> returned
>> >as part of the receipt message in the content info of the signed data
>> type
>> >in the normal way.
>> >
>> >To show my thoughts on these requirements may be reflected in the
>> message,
>> >here is my suggestion at what the receipt request should look like.
>> >
>> >ReceiptRequest ::= SEQUENCE {
>> >            reciptType ::= BIT STRING {
>> >                       delivery                     (0),
>> >                       read                         (1),
>> >                       acknowledgement     (2),
>>                        actioned                   (3), }
>> >           recipientAdditionalInformation           BOOLEAN DEFAULT
>> FALSE,
>> >           encapsulatedContentType                EncapsulatedContentType
>> >OPTIONAL,
>> >           signedContentIdentifier                     OCTET STRING,
>> >           receiptsFrom                                   ReceiptsFrom,
>> >           receiptsTo                                       SEQUENCE
>> (SIZE
>> >(1..ub-receiptsTo))
>> >                                       OF GeneralNames OPTIONAL }
>> >           ub-receiptsTo INTEGER ::= 16
>> >
>> >Receipt := SEQUENCE {
>> >    reciptType ::= BIT STRING {
>> >                       delivery                     (0),
>> >                       read                         (1),
>> >                       acknowledgement     (2),
>> >                       actioned                   (3), }
>> >    encapsulatedContentType        EncapsulatedContentType OPTIONAL,
>> >    signedContentIdentifier        OCTET STRING,
>> >    originatorSignatureValue       OCTET STRING }
>> >
>> >Trevor
>> >
>> >> -----Original Message-----
>> >> From:	[email-masked] [SMTP:[email-masked]]
>> >> Sent:	Wednesday, November 05, 1997 11:48 PM
>> >> To:	[email-masked]
>> >> Subject:	ESS-00 Multiple Signed Receipts Issue
>> >> 
>> >> All,
>> >> 
>> >> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>> >> describes the process of an originator requesting signed receipts and a
>> >> recipient returning signed receipts.  There can be multiple SignerInfos
>> >> present within a SignedData object.  Each SignerInfo can include
>> >> authenticatedAttributes.  Therefore, a single SignedData object may
>> >> include
>> >> multiple SignerInfos each of which include a receiptRequest attribute.
>> I
>> >> believe that this should be allowed and should be documented in the
>> ESS.
>> >> 
>> >> 
>> >> For example, if an originator desires to send a signed message
>> requesting
>> >> signed receipts to a set of users composed of RSA-only and DSA-only
>> users.
>> >> The originator's software can include one SignerInfo that includes an
>> RSA
>> >> signature value and a receiptRequest attribute.  The same SignedData
>> >> object
>> >> could include another SignerInfo that includes a DSA signature value
>> and a
>> >> receiptRequest attribute.  In this example, the RSA-capable recipients
>> >> would
>> >> return an RSA signed receipt to the originator and the DSA-capable
>> >> recipients would return a DSA signed receipt to the originator.
>> >> 
>> >> I believe that the general processing rules in ESS should state that a
>> >> receiving agent should build a signed receipt for each SignerInfo in
>> the
>> >> SignedData object for which it verifies the signature and which
>> requests a
>> >> signed receipt.  This may result in multiple signed receipts being
>> >> constructed and returned for a single SignedData object. 
>> >> 
>> >> I also believe that we should add a restriction that only one
>> >> receiptRequest
>> >> attribute can be included in the authenticatedAttributes of a
>> SignerInfo.
>> >> 
>> >> I will include specific comments to ESS-00 in a follow-up message, but
>> I
>> >> wanted to raise this issue separately because I beleive that it
>> deserves
>> >> special attention.
>> >> 
>> >> ================================
>> >> John Pawling   
>> >> [email-masked]                             
>> >> J.G. Van Dyke & Associates, Inc.           
>> >> ================================
>> >> 
>> >
>

Date: Tue, 11 Nov 1997 22:44:10 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: A draft ASN.1 module for Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim:

Thanks.  Can you provide 1988 syntax?

Russ

At 03:54 PM 11/6/97 +0000, Jim Craigie" TEL +44-1635-202124 wrote:
>CryptographicMessageSyntax { iso member-body usa(840) rsadsi(113549)
>                pkcs(1) 7 module(0) version(3) }
>-- Should the module OID be from the RSA branch, or from elsewhere?
>DEFINITIONS IMPLICIT TAGS ::=
>BEGIN
>
>IMPORTS
>
>-- Directory Information Framework
>
>        Attribute, Name
>        ----
>        FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 
>                informationFramework(1) 3 }
>
>-- Directory Authentication Framework
>
>        AlgorithmIdentifier, AttributeCertificate, Certificate, 
>        CertificateList, CertificateSerialNumber, HASHED { }, SIGNED { }
>        ----
>        FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) 
>                authenticationFramework(7) 3 }
>
>-- In Cryptographic Message Syntax the HASHED parameterised type applies
the hash function to the 
>-- contents octets component of a CER or DER encoding of a value of the
parameter.
>
>-- Directory Certificate Extensions
>
>        CertificateAssertion
>        ----
>        FROM CertificateExtensions { joint-iso-itu-t ds(5) module(1) 
>                certificateExtensions(26) 0 };
>
>
>
>-- The ENCRYPTED parameterised type is redefined here because
Cryptographic Message Syntax encrypted values are 
>-- defined as OCTET STRING, instead of BIT STRING as in the Directory
Authentication Framework
>
>ENCRYPTED { ToBeEnciphered } ::= OCTET STRING ( CONSTRAINED BY {
>-- must be the result of applying an encipherment procedure to the
contents octets component --
>-- of a definite-length BER-encoding of a value of -- ToBeEnciphered } )
>
>
>
>ContentInfo ::= SEQUENCE {
>        content-type  CMS-CONTENT-TYPE.&id ({CMSContentTable}),
>        cms-content [0] CMS-CONTENT-TYPE.&Type ({CMSContentTable}
>                                     {@content-type}) OPTIONAL }
>
>CMS-CONTENT-TYPE ::= TYPE-IDENTIFIER
>
>CMSContentTable CMS-CONTENT-TYPE ::= { data, signed-data, enveloped-data,
... }
>
>-- Data
>
>data CMS-CONTENT-TYPE ::= { Data IDENTIFIED BY id-data }
>
>Data ::= OCTET STRING
>
>-- Signed Data
>
>signed-data CMS-CONTENT-TYPE ::= { SignedData IDENTIFIED BY id-signed-data }
>
>SignedData ::= SEQUENCE {
>        version Version, 
>        digestAlgorithms DigestAlgorithmIdentifiers,
>        contentInfo ContentInfo,
>        certificates [0] CertificateSet OPTIONAL,
>        crls [1] CertificateRevocationLists OPTIONAL,
>        signerInfos SignerInfos }
>
>Version ::= INTEGER
>
>DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
>
>DigestAlgorithmIdentifier ::= AlgorithmIdentifier
>
>CertificateSet ::= SET OF CertificateChoice
>
>CertificateChoice ::= CHOICE {
>        certificate Certificate,
>        extendedCertificate [0] ExtendedCertificate,
>        attributeCertificate [1] AttributeCertificate }
>
>CertificateRevocationLists ::= SET OF CertificateList
>
>SignerInfos ::= SET OF SignerInfo
>
>SignerInfo ::= SEQUENCE {
>        version Version,
>        issuerAndSerialNumber IssuerAndSerialNumber,
>        digestAlgorithm DigestAlgorithmIdentifier,
>        authenticatedAttributes [0] Attributes OPTIONAL,
>        signatureAlgorithm SignatureAlgorithmIdentifier,
>        signature SignatureValue,
>        unauthenticatedAttributes [1] Attributes OPTIONAL }
>
>IssuerAndSerialNumber ::= SEQUENCE {
>        issuer Name,
>        serialNumber CertificateSerialNumber }
>
>SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
>
>SignatureValue ::= ENCRYPTED { DigestInfo }
>
>DigestInfo ::= SEQUENCE {
>        digestAlgorithm DigestAlgorithmIdentifier,
>        digest Digest }
>
>Digest ::= HASHED { CHOICE {
>        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
>        authenticated-attributes [0] EXPLICIT Attributes } }
>
>-- Enveloped Data
>
>enveloped-data CMS-CONTENT-TYPE ::= { EnvelopedData
>        IDENTIFIED BY id-enveloped-data }
>
>EnvelopedData ::= SEQUENCE {
>        version Version,
>        originatorInfo [0] OriginatorInfo OPTIONAL,
>        recipientInfos RecipientInfos,
>        encryptedContentInfo EncryptedContentInfo }
>
>OriginatorInfo ::= SEQUENCE {
>        certificates [0] CertificateSet OPTIONAL,
>        crls [1] CertificateRevocationLists OPTIONAL }
>
>RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
>
>RecipientInfo ::= SEQUENCE {
>        version Version,
>        recipientIdentifier RecipientIdentifier,
>        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>        encryptedKey EncryptedKey,
>        originatorCertificateSelector CertificateAssertion OPTIONAL }
>
>RecipientIdentifier ::= CHOICE {
>        issuerAndSerialNumber IssuerAndSerialNumber,
>        recipientKeyIdentifier [0] RecipientKeyIdentifier,
>        mailListKeyIdentifier [1] MailListKeyIdentifier }
>
>RecipientKeyIdentifier ::= SEQUENCE {
>        recipientName Name,
>        recipientCertificateSelector  CertificateAssertion }
>
>MailListKeyIdentifier ::= SEQUENCE {
>        kekIdentifier OCTET STRING,
>        date GeneralizedTime OPTIONAL,
>        otherKeyAttribute Attribute OPTIONAL }
>
>KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
>
>EncryptedKey ::= OCTET STRING
>
>EncryptedContentInfo ::= SEQUENCE {
>        contentType CMS-CONTENT-TYPE.&id ({CMSContentTable}),
>        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
>        encryptedContent [0] ENCRYPTED { CMS-CONTENT-TYPE.&Type 
>                        ({CMSContentTable} {@contentType}) } OPTIONAL }
>
>ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
>
>-- Object Identifiers
>
>id-pkcs-7 OBJECT IDENTIFIER ::=
>        { iso member-body usa(840) rsadsi(113549) pkcs(1) 7 }
>
>id-data OBJECT IDENTIFIER ::= { id-pkcs-7 1 }
>
>id-signed-data OBJECT IDENTIFIER ::= { id-pkcs-7 2 }
>
>id-enveloped-data OBJECT IDENTIFIER ::= { id-pkcs-7 3 }
>
>-- Definitions from PKCS#6
>
>ExtendedCertificate ::= SIGNED { ExtendedCertificateInfo }
>
>ExtendedCertificateInfo ::= SEQUENCE {
>        version Version,
>        certificate Certificate,
>        attributes Attributes }
>
>Attributes ::= SET OF Attribute
>
>END -- of CryptographicMessageSyntax
>
>
>
>

Date: Tue, 11 Nov 1997 22:42:25 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Comments on the Cryptographic Message Syntax
Cc: [email-masked]
Sender: [email-masked]

Jim:

>Some comments on the Cryptographic Message Syntax spec:
>
>1. ASN.1 Canonical Encoding Rules should be allowed
>
>>                                                            Single-
>>    pass operation has one significant drawback; it is difficult to
>>    perform encode operations using the Distinguished Encoding Rules
>>    (DER) encoding in a single pass since the lengths of the various
>>    components may not be known in advance. Since DER encoding is
>>    required by the signed-data content type, an extra pass may be
>>    necessary when a content type other than data is encapsulated.
>
>Why does the signed-data content type require DER? Why doesn't it allow
>the choice of CER or DER, with the digest algorithm-identifier indicating
>which? For example, SHA-1 on the CER encoding would have a different 
>algorithm-identifier to SHA-1 on the DER encoding. [For anyone unfamiliar
>with CER, it is defined in the 1994 version of ASN.1, and is identical to
>DER except that CER uses indefinite length encoding (which permits 
>single-pass encoding) and constructed encoding of strings.]

Does CER prohibit definite length encoding?  If not, there would be more
than one way to enocde the same structure.

>2. There is an ambiguity about which octets are input to hash and
encryption algorithms
>
>>    The message digest calculation process computes a message digest on
>>    either the content being signed or the content together with the
>>    signer's authenticated attributes. In either case, the initial input
>>    to the message digest calculation process is the "value" of the
>>    content being signed. Specifically, the initial input is the content
>>    octets of the DER encoding of the content field of the ContentInfo
>>    value to which the signing process is applied. Only the contents
>>    octets of the DER encoding of that field are input to the message
>>    digest algoritm, not the identifier octets or the length octets.
>> 
>>    When the content being signed has content type data and the
>>    authenticatedAttributes field is absent, then just the value of the
>>    data (e.g., the contents of a file) is input to the message digest
>>    calculation. This has the advantage that the length of the content
>>    being signed need not be known in advance of the encryption process.
>> 
>>    Although the identifier octets and the length octets are not included
>>    in the message digest calculation, they are still protected by other
>>    means. The length octets are protected by the nature of the message
>>    digest algorithm since it is computationally infeasible to find any
>>    two distinct messages of any length that have the same message
>>    digest.
>> 
>
>The first of the three paragraphs above says something different about 
>which octets are input into the hash function than the implication of 
>the second and third paragraphs. Consider the encoding of the content 
>field of the ContentInfo in the following examples:
>
>For the data content type:
>
>Identifier      Length  Contents
>[0]             nnn     
>                        Identifier      Length  Contents
>                        OctetString     nnn     xxxxxxxxx
>
>
>For the signed-data content type:
>
>Identifier      Length  Contents
>[0]             nnn     
>                        Identifier      Length  Contents
>                        Sequence        nnn     
>                                                Identifier      Length
Contents
>                                                Integer         1       1
>
>
>The first paragraph above says that it is the contents octets of the 
>content field which is input to the hash function - i.e. octets starting
>with the identifier for OctetString in the case of the data content type
>- but the second paragraph implies that it is just the contents octets 
>of this OctetString. Should the first paragraph be changed to replace 
>"content octets of the DER encoding of the content field" by "DER 
>encoding of the content octets of the type within the content field"? 
>That is, does the input to the hash start with the identifier for 
>Integer in the case of signed-data?

I read the first paragrph three times.  I do not see the issue.  Maybe you
can try explaining it again....

>3. User Keying Materials
>
>Surely these should be included within the parameters component of the
>algorithm-identifier for algorithms which require such material.

No.  The following structure is present for each recipient:

  RecipientInfo ::= SEQUENCE {
    version Version,
    rid RecipientIdentifier,
    keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
    encryptedKey EncryptedKey }

If the UKM is carried in the KeyEncryptionAlgorithmIdentifier, then it is
carried several times, once for each recipient.  UKMs can be large (128
bytes), so we want to carry it once for all of the recipients that use that
form of key management.

>4. RecipientKeyIdentifier
>
>RecipientKeyIdentifier is not an adequate identification of a recipient, 
>since subjectKeyIdentifier is only unique within the scope of an 
>individual recipient, and it is not accompanied by any other 
>identification of the recipient. I suggest that the more general 
>CertificateAssertion syntax from X.509 should be used instead of the 
>restrictive subjectKeyIdentifier:
>
>     RecipientKeyIdentifier ::= SEQUENCE {
>          recipient-name                  Name,
>          recipient-certificate-selector  CertificateAssertion}

Within the set of recipients, the subject key identifier should narrow the
"hits" significantly.  In the unlikely event that there is more than one
recipinet with the same subject key identifier, then the recipient can try
each "hit."

>5. Originator Certificate selection
>
>Some key agreement algorithms use different originator keys for different
>recipients. It is therefore necessary to add an originator-certificate-
>selector to RecipientInfo:
>
>     RecipientInfo ::= SEQUENCE {
>          version Version,
>          rid RecipientIdentifier,
>          keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>          encryptedKey EncryptedKey,
>          originator-certificate-selector CertificateAssertion OPTIONAL }

Okay, but I think that the location within the structure might be
incorrect.  It needs to come sooner to accompdate single-pass processing.

Please send me the ASN.1 for CertificateAssertion.

Russ

Date: Tue, 11 Nov 1997 10:02:57 -0500
To: Trevor Freeman <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: ESS-00 Multiple Signed Receipts Issue
Cc: [email-masked]
Sender: [email-masked]

Trevor:

Some of the "receipt types" that you discuss cannot be handled by a signed
receipt.  Such receipts require that the recipient decrypt the message (if
it was encrypted) and verify the originator's signature before a receipt
can be generated.  The receipt request is carried in the SignerInfo, so a
receipt cannot be requested without the originaror signing the message in
the first place.

Russ

At 07:25 AM 11/7/97 -0800, Trevor Freeman wrote:
>I have a couple of related issues with signed receipts. 
>The signed receipt process as outlined only considers a single type of
>receipt. If fact there are more that one type of receipt. Examples of these
>types would be
>	A message has been delved to a mail box (but not opened).
>	A message has been opened
>	The recipient acknowledges they have read (and hopefully understood)
>the message
>	The recipient has actioned the message
>Some of these receipts may mandate recipient intervention, such as
>acknowledgement and actioned. You may require different receipt types from
>different people, therefore I would envisage the requirement for multiple
>receipt requests to be contained within the authenticated attributes of a
>single message, with different users being asked for different types of
>receipt.
>
>Another requirement of the originator is that they may require some
>additional information from the recipient to be returned as part of the
>receipt. This additional content may be considered mandatory by the
>originator. A drawback of defining the receipt as a new data type is that it
>does not allow a place for this recipient originated information to be
>returned with the receipt. I would therefore submit that the receipt should
>therefore be an authenticated attribute of the signed data structure in the
>receipt not a new content. This would allow any new content to be returned
>as part of the receipt message in the content info of the signed data type
>in the normal way.
>
>To show my thoughts on these requirements may be reflected in the message,
>here is my suggestion at what the receipt request should look like.
>
>ReceiptRequest ::= SEQUENCE {
>            reciptType ::= BIT STRING {
>                       delivery                     (0),
>                       read                         (1),
>                       acknowledgement     (2),
>                       actioned                   (3), }
>           recipientAdditionalInformation           BOOLEAN DEFAULT FALSE,
>           encapsulatedContentType                EncapsulatedContentType
>OPTIONAL,
>           signedContentIdentifier                     OCTET STRING,
>           receiptsFrom                                   ReceiptsFrom,
>           receiptsTo                                       SEQUENCE (SIZE
>(1..ub-receiptsTo))
>                                       OF GeneralNames OPTIONAL }
>           ub-receiptsTo INTEGER ::= 16
>
>Receipt := SEQUENCE {
>    reciptType ::= BIT STRING {
>                       delivery                     (0),
>                       read                         (1),
>                       acknowledgement     (2),
>                       actioned                   (3), }
>    encapsulatedContentType        EncapsulatedContentType OPTIONAL,
>    signedContentIdentifier        OCTET STRING,
>    originatorSignatureValue       OCTET STRING }
>
>Trevor
>
>> -----Original Message-----
>> From:	[email-masked] [SMTP:[email-masked]]
>> Sent:	Wednesday, November 05, 1997 11:48 PM
>> To:	[email-masked]
>> Subject:	ESS-00 Multiple Signed Receipts Issue
>> 
>> All,
>> 
>> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>> describes the process of an originator requesting signed receipts and a
>> recipient returning signed receipts.  There can be multiple SignerInfos
>> present within a SignedData object.  Each SignerInfo can include
>> authenticatedAttributes.  Therefore, a single SignedData object may
>> include
>> multiple SignerInfos each of which include a receiptRequest attribute.  I
>> believe that this should be allowed and should be documented in the ESS.
>> 
>> 
>> For example, if an originator desires to send a signed message requesting
>> signed receipts to a set of users composed of RSA-only and DSA-only users.
>> The originator's software can include one SignerInfo that includes an RSA
>> signature value and a receiptRequest attribute.  The same SignedData
>> object
>> could include another SignerInfo that includes a DSA signature value and a
>> receiptRequest attribute.  In this example, the RSA-capable recipients
>> would
>> return an RSA signed receipt to the originator and the DSA-capable
>> recipients would return a DSA signed receipt to the originator.
>> 
>> I believe that the general processing rules in ESS should state that a
>> receiving agent should build a signed receipt for each SignerInfo in the
>> SignedData object for which it verifies the signature and which requests a
>> signed receipt.  This may result in multiple signed receipts being
>> constructed and returned for a single SignedData object. 
>> 
>> I also believe that we should add a restriction that only one
>> receiptRequest
>> attribute can be included in the authenticatedAttributes of a SignerInfo.
>> 
>> I will include specific comments to ESS-00 in a follow-up message, but I
>> wanted to raise this issue separately because I beleive that it deserves
>> special attention.
>> 
>> ================================
>> John Pawling   
>> [email-masked]                             
>> J.G. Van Dyke & Associates, Inc.           
>> ================================
>> 
>

Date: Mon, 10 Nov 1997 14:07:16 -0500
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I suggest that we align with X9.42 for Diffie-Hellman.

Russ

At 01:59 PM 11/7/97 -0800, Blake Ramsdell wrote:
>On Friday, November 07, 1997 1:44 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> DH and DSS keys are separately generated.  The public DH and DSS keys are
>> stored in separate X.509 Certificates.
>
>This was something that was being discussed at one point -- the
>possibility of a "combo" certificate that had both signature
>verification and key management properties (the public part of the DH
>encrypting pair and the public part of the DSS pair).
>
>> How about changing the text to the following: "An S/MIME agent or some
>> related administrative utility or function MUST be capable of generating
>> separate DH and DSS public/private key pairs on behalf of the user."
>
>Yup.  Sounds good.  Comments?  Objections?
>
>I will also change the current references to [DH-DSS] to just be [DSS].
>
>What would be the best source to use for the [DH] (Diffie-Hellman
>encryption) and [DSS] (DSS) references?  Are we making a draft for this?
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>

Date: Mon, 10 Nov 1997 14:05:53 -0500
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: DH keypair generation
Cc: [email-masked]
Sender: [email-masked]

Blake:

Usually, two certificates are used, one for key management and one for
signature.  

Diffie-Hellman is a key management algorithm.  DSS is a signature
algorithm.  While the same private/public might be used for both, this not
not usually done.

Russ

At 12:59 PM 11/7/97 -0800, Blake Ramsdell wrote:
>On Thursday, November 06, 1997 11:49 AM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> 4) Sec 4.1, 1rst para, 1rst sent: Please delete "RSA" from: "An S/MIME
agent
>> or some related administrative utility or function MUST be capable of
>> generating RSA key pairs on behalf of the user."
>
>My concern is along the lines of how keypairs work in the DH new world
>order.  Is there always a separate pair for signing and encrypting?
>
>I'd like to get that clarified also, because I think that it belongs in
>this section also.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>

Date: Mon, 10 Nov 1997 13:59:00 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: PKCS #9 Internet Draft??
Cc: [email-masked]
Sender: [email-masked]

At 07:32 PM 11/7/97 -0500, Phillip H. Griffin wrote:
>If you're going to create ASN.1 modules, it helps ASN.1:1994
>implementors 
>to have them defined in the ASN.1, so they can be used to constrain
>types.
>Regardless of whether you publish in ASN.1:1990 or 1994, someone is sure
>to want to implement smime or a derivative, using equivalent ASN.1:1994 
>definitions.
>
>Phil

Agreed.  I will add an appendix to the CMS document that pulls all of the
ASN.1 into a single module.  However, I am going to use the 1988 syntax.
There are more tools for the 1988 version, so I am going to stick with it.

Russ

Date: Mon, 10 Nov 1997 13:54:54 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: PKCS #9 Internet Draft??
Sender: [email-masked]

Perhaps we should add a section to the CMS document that includes the
PKCS#9 attributes.  The ESS document already defines extensiosn to this list.

What do folks think about this approach?

Russ

At 03:28 PM 11/7/97 -0800, Paul Hoffman / IMC wrote:
>At 02:21 PM 11/7/97 -0800, Blake Ramsdell wrote:
>>On Friday, November 07, 1997 1:24 PM, [email-masked]
>>[SMTP:[email-masked]] wrote:
>>> Please note that many of the OID definitions (such as ContentType,
>>> SigningTime, CounterSignature, and MessageDigest attributes) need to be
>>> added to <http://www.imc.org/ietf-smime/oids.html>.
>>
>>If we do this (which I think we should), we should add all of the OIDs
>>that are listed in section A of the message draft.  Right?
>
>It's up to the group. I certainly don't want anything listed in two places:
>that leads to bad mistakes. My own preference is to have everything in the
>registry and strip them out of the documents, but I'm no coder, so I can't
>say whether or not that would help or hurt implementors.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

From: Roger James <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>, Blake Ramsdell <[email-masked]>
Subject: RE: Even newer versions of the drafts
Date: Wed, 12 Nov 1997 12:08:58 -0000
Sender: [email-masked]

I hope I get this right. I think its close ;-)

Type references and module references MUST start with an uppercase
letter. Value references and identifiers MUST start with a lower case
letter.

ThisIsAModuleReference {1 2 3} DEFINITIONS
BEGIN
ThisIsATypeReference ::= SEQUENCE
{
	thisIsAnIdentifier INTEGER (1..10),
	thisIsAnotherIndetifier INTEGER (1..10)
}

thisIsAValueReference ThisIsATypeReference ::=
{
	thisIsAnIdentifier 1,
	thisIsAnotherIndentifier 2
}
END

The name of an OID is by its nature a value reference therefore it MUST
start with lowercase.

Roger

> ----------
> From: 	Blake Ramsdell[SMTP:[email-masked]]
> Sent: 	12 November 1997 00:46
> To: 	'Jim Schaad (Exchange)'; 'Paul Hoffman / IMC';
> [email-masked]'
> Subject: 	RE: Even newer versions of the drafts
> 
> On Tuesday, November 11, 1997 4:29 PM, Jim Schaad (Exchange)
> [SMTP:[email-masked]] wrote:
> > A complete search and replace should be done.  Even the ASN.1
> construct
> > in appends A is lower-cased.  SMIMECapability is uppercased but
> > sMIMECapabilities is not.
> 
> 
> AAAAAAHHHHHH!!!!
> 
> Can someone please, please, PLEASE explain the rules here!
> 
> My understanding is:
> 
> 1. OIDs MUST have an initial lower case letter.  This was cited and
> acknowledged.
> 2. ASN.1 structures such as SMIMECapability and SMIMECapabilities have
> an initial capitalized letter.  I don't know if this is a MUST or not.
> This is consistent with ContentInfo, SignedData, EnvelopedData, etc.
> etc. etc.
> 
> If these two statements are true, then I believe that the changes in
> my
> last message were accurate.
> 
> If this is not the case, then my universe has collapsed and I have to
> start over with the Great ASN.1 Capitalization Understanding.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> 

Date: Wed, 12 Nov 1997 07:06:34 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Blake Ramsdell <[email-masked]>
CC: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Even newer versions of the drafts
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> On Tuesday, November 11, 1997 4:29 PM, Jim Schaad (Exchange)
> [SMTP:[email-masked]] wrote:
> > A complete search and replace should be done.  Even the ASN.1 construct
> > in appends A is lower-cased.  SMIMECapability is uppercased but
> > sMIMECapabilities is not.
> 
> AAAAAAHHHHHH!!!!
> 
> Can someone please, please, PLEASE explain the rules here!
> 
> My understanding is:
> 
> 1. OIDs MUST have an initial lower case letter.  This was cited and
> acknowledged.
> 2. ASN.1 structures such as SMIMECapability and SMIMECapabilities have
> an initial capitalized letter.  I don't know if this is a MUST or not.
> This is consistent with ContentInfo, SignedData, EnvelopedData, etc.
> etc. etc.
> 
> If these two statements are true, then I believe that the changes in my
> last message were accurate.
> 
> If this is not the case, then my universe has collapsed and I have to
> start over with the Great ASN.1 Capitalization Understanding.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Blake is not loosing it. All types must start with an initial
cap, and all identifiers must start with an initial lowercase
letter. Classes (if you do 1994) must be all caps. So an OID
value, say 

   signedData OBJECT IDENTIFIER ::= { stuff }

identifies (names) a value of type OBJECT IDENTIFIER,  but

   SignedData ::= SEQUENCE { stuff } 

defines an ASN.1 type.

Phil
-- 
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: Trevor Freeman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: ESS-00 Multiple Signed Receipts Issue
Date: Wed, 12 Nov 1997 01:48:57 -0800
Sender: [email-masked]

Hi Jon,
The point is that these other types of receipt also have to be
cryptographically bound to the receipt request, as such they form part of
the cryptographic security services. I therefore do not agree with you
interpretation that these other types of receipt are outside a cryptographic
security service or the ESS. There seem two way to progress this, 
	either the receipt type is enhanced to include the capability to
define other types of receipt 
	or, even at this early stage of the standard, we start defining the
addition of an extended receipt type request which would include the receipt
type attribute along with all the other attributes included in the current
definition.
I know which option looks the ugliest.
I also see no justification for making the receipt a new data type. It can
just as easy be carried as an authenticated attribute. All it is a piece of
signed data.
Trevor
> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, November 07, 1997 4:07 PM
> To:	Trevor Freeman
> Cc:	[email-masked]
> Subject:	RE: ESS-00 Multiple Signed Receipts Issue
> 
> Trevor,
> 
> Thank you very much for your feedback.  The CMS and ESS specifications
> specify cryptographic security services, so the CMS/ESS signed receipt
> should only provide cryptographic security services.  The purpose of the
> CMS/ESS signed receipt is to prove to the originator that the recipient
> was
> able to verify the signature of the original message. This is the only
> purpose for the ESS/CMS signed receipt that is within the scope of the CMS
> and ESS specifications.  The other types of receipts that you list are
> outside the scope of CMS and ESS, so they should be documented in separate
> specifications that are not security-specific specifications.    
> 
> A CMS/ESS signed receipt is constructed by encapsulating an ESS Receipt
> object within a CMS SignedData object.  The Receipt signature value is
> included in the SignerInfo included in the SignedData object which
> encapsulates the Receipt object.  The SignerInfo includes
> autheticatedAttributes and unAuthenticatedAttributes.  Therefore, a
> CMS/ESS
> signed receipt can include any of the attributes listed in ESS (and some
> from PKCS #9) or it could include privately defined attributes.  This
> provides a lot of flexibility for the recipient to provide information
> back
> to the originator of the original message.
> 
> In my opinion, there is an open issue regarding whether or not all
> receiptRequests included in a SignedData object MUST be identical.  I can
> think of some bizarre scenarios in which different signers may wish to
> require that signed receipts be sent to specific
> entities, etc.  However, stating "All SignerInfos MUST contain the same
> receiptRequest attribute." would simplify processing.  I could go either
> way.
> 
> In summary, I believe that we should not change the signed receipt
> syntaxes
> and text included in ESS (other than adding clarifying text regarding
> multiple receiptRequests included in a signedData object). 
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> 
> At 07:25 AM 11/7/97 -0800, Trevor Freeman wrote:
> >I have a couple of related issues with signed receipts. 
> >The signed receipt process as outlined only considers a single type of
> >receipt. If fact there are more that one type of receipt. Examples of
> these
> >types would be
> >	A message has been delved to a mail box (but not opened).
> >	A message has been opened
> >	The recipient acknowledges they have read (and hopefully understood)
> >the message
> >	The recipient has actioned the message
> >Some of these receipts may mandate recipient intervention, such as
> >acknowledgement and actioned. You may require different receipt types
> from
> >different people, therefore I would envisage the requirement for multiple
> >receipt requests to be contained within the authenticated attributes of a
> >single message, with different users being asked for different types of
> >receipt.
> >
> >Another requirement of the originator is that they may require some
> >additional information from the recipient to be returned as part of the
> >receipt. This additional content may be considered mandatory by the
> >originator. A drawback of defining the receipt as a new data type is that
> it
> >does not allow a place for this recipient originated information to be
> >returned with the receipt. I would therefore submit that the receipt
> should
> >therefore be an authenticated attribute of the signed data structure in
> the
> >receipt not a new content. This would allow any new content to be
> returned
> >as part of the receipt message in the content info of the signed data
> type
> >in the normal way.
> >
> >To show my thoughts on these requirements may be reflected in the
> message,
> >here is my suggestion at what the receipt request should look like.
> >
> >ReceiptRequest ::= SEQUENCE {
> >            reciptType ::= BIT STRING {
> >                       delivery                     (0),
> >                       read                         (1),
> >                       acknowledgement     (2),
>                        actioned                   (3), }
> >           recipientAdditionalInformation           BOOLEAN DEFAULT
> FALSE,
> >           encapsulatedContentType                EncapsulatedContentType
> >OPTIONAL,
> >           signedContentIdentifier                     OCTET STRING,
> >           receiptsFrom                                   ReceiptsFrom,
> >           receiptsTo                                       SEQUENCE
> (SIZE
> >(1..ub-receiptsTo))
> >                                       OF GeneralNames OPTIONAL }
> >           ub-receiptsTo INTEGER ::= 16
> >
> >Receipt := SEQUENCE {
> >    reciptType ::= BIT STRING {
> >                       delivery                     (0),
> >                       read                         (1),
> >                       acknowledgement     (2),
> >                       actioned                   (3), }
> >    encapsulatedContentType        EncapsulatedContentType OPTIONAL,
> >    signedContentIdentifier        OCTET STRING,
> >    originatorSignatureValue       OCTET STRING }
> >
> >Trevor
> >
> >> -----Original Message-----
> >> From:	[email-masked] [SMTP:[email-masked]]
> >> Sent:	Wednesday, November 05, 1997 11:48 PM
> >> To:	[email-masked]
> >> Subject:	ESS-00 Multiple Signed Receipts Issue
> >> 
> >> All,
> >> 
> >> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
> >> describes the process of an originator requesting signed receipts and a
> >> recipient returning signed receipts.  There can be multiple SignerInfos
> >> present within a SignedData object.  Each SignerInfo can include
> >> authenticatedAttributes.  Therefore, a single SignedData object may
> >> include
> >> multiple SignerInfos each of which include a receiptRequest attribute.
> I
> >> believe that this should be allowed and should be documented in the
> ESS.
> >> 
> >> 
> >> For example, if an originator desires to send a signed message
> requesting
> >> signed receipts to a set of users composed of RSA-only and DSA-only
> users.
> >> The originator's software can include one SignerInfo that includes an
> RSA
> >> signature value and a receiptRequest attribute.  The same SignedData
> >> object
> >> could include another SignerInfo that includes a DSA signature value
> and a
> >> receiptRequest attribute.  In this example, the RSA-capable recipients
> >> would
> >> return an RSA signed receipt to the originator and the DSA-capable
> >> recipients would return a DSA signed receipt to the originator.
> >> 
> >> I believe that the general processing rules in ESS should state that a
> >> receiving agent should build a signed receipt for each SignerInfo in
> the
> >> SignedData object for which it verifies the signature and which
> requests a
> >> signed receipt.  This may result in multiple signed receipts being
> >> constructed and returned for a single SignedData object. 
> >> 
> >> I also believe that we should add a restriction that only one
> >> receiptRequest
> >> attribute can be included in the authenticatedAttributes of a
> SignerInfo.
> >> 
> >> I will include specific comments to ESS-00 in a follow-up message, but
> I
> >> wanted to raise this issue separately because I beleive that it
> deserves
> >> special attention.
> >> 
> >> ================================
> >> John Pawling   
> >> [email-masked]                             
> >> J.G. Van Dyke & Associates, Inc.           
> >> ================================
> >> 
> >

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Even newer versions of the drafts
Date: Tue, 11 Nov 1997 16:46:40 -0800
Sender: [email-masked]

On Tuesday, November 11, 1997 4:29 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> A complete search and replace should be done.  Even the ASN.1 construct
> in appends A is lower-cased.  SMIMECapability is uppercased but
> sMIMECapabilities is not.

AAAAAAHHHHHH!!!!

Can someone please, please, PLEASE explain the rules here!

My understanding is:

1. OIDs MUST have an initial lower case letter.  This was cited and
acknowledged.
2. ASN.1 structures such as SMIMECapability and SMIMECapabilities have
an initial capitalized letter.  I don't know if this is a MUST or not.
This is consistent with ContentInfo, SignedData, EnvelopedData, etc.
etc. etc.

If these two statements are true, then I believe that the changes in my
last message were accurate.

If this is not the case, then my universe has collapsed and I have to
start over with the Great ASN.1 Capitalization Understanding.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Even newer versions of the drafts
Date: Tue, 11 Nov 1997 16:29:29 -0800
Sender: [email-masked]

A complete search and replace should be done.  Even the ASN.1 construct
in appends A is lower-cased.  SMIMECapability is uppercased but
sMIMECapabilities is not.

> -----Original Message-----
> From:	Blake Ramsdell [SMTP:[email-masked]]
> Sent:	Tuesday, November 11, 1997 3:28 PM
> To:	Jim Schaad (Exchange); 'Paul Hoffman / IMC';
> [email-masked]'
> Subject:	RE: Even newer versions of the drafts
> 
> On Tuesday, November 11, 1997 1:37 PM, Jim Schaad (Exchange)
> [SMTP:[email-masked]] wrote:
> > I'm sure if I were to read them again and again I would find other
> > problems, but they look good to me as they stand with 1 minor
> exception.
> > Paul -- You need to be constant in section 2.5.2 about how you
> > captialize sMIMECapabilities.  It is there with both a large and
> small
> > leading S.  
> 
> Third to last paragraph in section 2.5.2 "and a new OID MUST be
> allocated under the SMIMECapabilities OID".  This should be lower case
> first "s", because it is referring to the OID, not the ASN.1
> construct.
> 
> Section A.4 SMIMECapabilites should have a small "s" also.
> 
> Jim, were there any other ones?  The other references to
> SMIMECapabilities refer to the ASN.1 construct, not the OID as far as
> I
> can tell.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Even newer versions of the drafts
Date: Tue, 11 Nov 1997 15:28:14 -0800
Sender: [email-masked]

On Tuesday, November 11, 1997 1:37 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> I'm sure if I were to read them again and again I would find other
> problems, but they look good to me as they stand with 1 minor exception.
> Paul -- You need to be constant in section 2.5.2 about how you
> captialize sMIMECapabilities.  It is there with both a large and small
> leading S.  

Third to last paragraph in section 2.5.2 "and a new OID MUST be
allocated under the SMIMECapabilities OID".  This should be lower case
first "s", because it is referring to the OID, not the ASN.1 construct.

Section A.4 SMIMECapabilites should have a small "s" also.

Jim, were there any other ones?  The other references to
SMIMECapabilities refer to the ASN.1 construct, not the OID as far as I
can tell.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Rich Ankney" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Receipts vs. SignedData
Date: Tue, 11 Nov 1997 18:01:22 -0500
Sender: [email-masked]

----------
> From: Blake Ramsdell <[email-masked]>
> To: 'Rich Ankney' <[email-masked]>; 'Larry Layten' <[email-masked]>;
[email-masked]'
> Subject: RE: Receipts vs. SignedData
> Date: Tuesday, November 11, 1997 4:46 PM
> 
> On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
> [SMTP:[email-masked]] wrote:
> > Agreed; I'm just looking for a way to have common processing of
> > SignedData, regardless of the inner content.  If there's no secure,
> > clean way to do it, I can live with what's there now.  Perhaps the
> > OUTER content should be Receipt, instead of SignedData, where
> > a Receipt is then the combination of SignedData and (inner)
> > Receipt, processed as defined in ESS?
> 
> I may be confused here, so someone please correct me if I am wrong.
> 
> Rich, my understanding of your comments is that the signature
> verification of S/MIME messages of outer content type SignedData are
> handled inconsistently, depending on whether or not it encloses MIME
> data (identified by the PKCS #7-defined OID "data") or a Receipt
> structure (identified by the newly created "receipt" OID under the SMIME
> arc).  Is this the case?  My understanding is that the SignedData
> signature computation for both is exactly the same, and that the only
> processing difference occurs when the inner content (either the MIME
> data or the Receipt structure) is removed and processed.  That is, the
> MIME data is processed through the MIME engine, and the Receipt
> structure is processed through "other means" that are
> receiver-dependent.
>
Maybe it's me that's confused, but it seems to me that Section 5.3 of
the CMS spec describes how to compute the message digest: on the
DER encoding of the content being signed (the ContentInfo).  This is
then used, if necessary, as the messageDigest attribute (if
authenticatedAttributes are used), else it is signed directly.

ESS describes a different method of computing the message digest:
it is, instead of H(inner content), computed as:
H(original-message || Receipt), where original-message is the one
we are generating the receipt for, and Receipt is the data structure
of the same name.  Only Receipt is in the actual inner ContentInfo
of the SignedData being returned to the originator.  This new method
of computing the message digest (which we use only if the inner
content is a Receipt) is what I was talking about.  

Or am I reading ESS wrong?
 
> If this is not the case, then I may need some information as to why
> there is a difference, since I agree -- the signature processing should
> be the same.
> 
The actual signature process is the same: sign the digest or the
authenticatedAttributes.  It's the digest computation that's different.
At a minimum, CMS needs to address this, I think. Or make the
content type of the outer message (currently SignedData), something
different (but still with SignedData syntax).  I'd prefer to always process
the digest and signature computation the same for SignedData, regardless
of the inner content type, but that's just my personal opinion...

> Blake
> --

Regards,
Rich

From: "Blake Ramsdell" <[email-masked]>
To: "'Rich Ankney'" <[email-masked]>, "'Larry Layten'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Receipts vs. SignedData
Date: Tue, 11 Nov 1997 13:46:12 -0800
Sender: [email-masked]

On Tuesday, November 11, 1997 12:18 PM, Rich Ankney
[SMTP:[email-masked]] wrote:
> Agreed; I'm just looking for a way to have common processing of
> SignedData, regardless of the inner content.  If there's no secure,
> clean way to do it, I can live with what's there now.  Perhaps the
> OUTER content should be Receipt, instead of SignedData, where
> a Receipt is then the combination of SignedData and (inner)
> Receipt, processed as defined in ESS?

I may be confused here, so someone please correct me if I am wrong.

Rich, my understanding of your comments is that the signature
verification of S/MIME messages of outer content type SignedData are
handled inconsistently, depending on whether or not it encloses MIME
data (identified by the PKCS #7-defined OID "data") or a Receipt
structure (identified by the newly created "receipt" OID under the SMIME
arc).  Is this the case?  My understanding is that the SignedData
signature computation for both is exactly the same, and that the only
processing difference occurs when the inner content (either the MIME
data or the Receipt structure) is removed and processed.  That is, the
MIME data is processed through the MIME engine, and the Receipt
structure is processed through "other means" that are
receiver-dependent.

If this is not the case, then I may need some information as to why
there is a difference, since I agree -- the signature processing should
be the same.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Even newer versions of the drafts
Date: Tue, 11 Nov 1997 13:37:00 -0800
Sender: [email-masked]

OK -- I got the drafts last night and read them (again).  

I'm sure if I were to read them again and again I would find other
problems, but they look good to me as they stand with 1 minor exception.
Paul -- You need to be constant in section 2.5.2 about how you
captialize sMIMECapabilities.  It is there with both a large and small
leading S.  

Go ahead and submit them as Information drafts with that one small
change.

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Saturday, November 08, 1997 3:44 PM
> To:	[email-masked]
> Subject:	Even newer versions of the drafts
> 
> Again, new versions of the S/MIME v2 drafts are now available. Please
> look them over, and if there's no problems within a week, I'll
> consider
> them final and turn them in to hopefully become informational RFCs.
> 
> ==========
> 
> Message draft: <http://www.imc.org/draft-dusse-smime-msg>
> 
> The following changes were made between the -05 and -06 revisions of
> this
> draft:
> 
> Removed discussion of "application/mime" wrapping because no one has
> implemented it and because the specification for application/mime is
> in
> flux. This entailed removing section 3.4.3.4, a bit of the table near
> the
> end of section 3.8, and text throughout appendix F.
> 
> Changed the case of SMIMECapabilities to sMIMECapabilities everywhere.
> 
> Changed the references for ASN.1, BER, and DER back to their 1988
> documents.
> 
> Fixed error in the MIME examples in 3.1.4 (left off the C-T-E).
> 
> Removed antique text from first paragraph 3.5.
> 
> Fixed section numbering in Appendix A.
> 
> In A.1, changed "other than 32" to "greater than 32".
> 
> Removed "smime-type" from E.2 and E.3, where they appeared by mistake.
> 
> 
> ==========
> 
> Certificates draft: <http://www.imc.org/draft-dusse-smime-cert>
> 
> The following changes were made between the -04 and -05 revisions of
> this
> draft:
> 
> There was general agreement that this draft should reflect reality of
> S/MIME v2 implementations and not what "should be", which is left to
> S/MIME
> v3. The changes listed here are to bring this draft back to what is
> being
> deployed today.
> 
> Changed the end of 2.3 to only require DN chaining.
> 
> Changed the MUST to SHOULD for MD2 hashing in 4.3 and 5.2.
> 
> Made the "certificates" in 2.2 "end entity" certificates.
> 
> Removed certificatePolicies from 4.4.
> 
> In 5.1, changed "Clients MUST handle multiple valid CA certificates"
> to
> "Clients SHOULD...".
> 
> In 5.2, changed the MUST to SHOULD for the certification-request
> attributes.
> 
> In 3.2, changed the SHOULD to MUS for including the email address
> during DN
> creation. Added text in 5.2 to support this.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

From: "Rich Ankney" <[email-masked]>
To: "Larry Layten" <[email-masked]>, <[email-masked]>
Subject: Re: Receipts vs. SignedData
Date: Tue, 11 Nov 1997 15:18:22 -0500
Sender: [email-masked]

Agreed; I'm just looking for a way to have common processing of
SignedData, regardless of the inner content.  If there's no secure,
clean way to do it, I can live with what's there now.  Perhaps the
OUTER content should be Receipt, instead of SignedData, where
a Receipt is then the combination of SignedData and (inner)
Receipt, processed as defined in ESS?

Regards,
Rich

----------
> From: Larry Layten <[email-masked]>
> To: [email-masked]; 'Rich Ankney' <[email-masked]>
> Subject: RE: Receipts vs. SignedData
> Date: Tuesday, November 11, 1997 1:30 PM
> 
> Rich,
> 
> Several points:
> 
> 1. The actual message may have been encrypted, and putting
> the digest "in the clear" provides information on the content of
> the message.
> 
> 2. Verification of the receipt still requires that the recipient of
> the message retain (or re-create) the message digest to verify 
> the signature of the receipt is valid, hence, having it in the 
> message isn't of any value.
> 
> I guess that item 1 could be taken care of by requiring encryption
> of the return receipt if the original message was encrypted.
> 
> Larry
> 
> ----------
> From: 	Rich Ankney[SMTP:[email-masked]]
> Sent: 	Tuesday, November 11, 1997 11:36 AM
> To: 	[email-masked]
> Subject: 	Receipts vs. SignedData
> 
> It appears that, when creating/verifying SignedData, one processes the
> content being signed differently, depending on if it is a Receipt or not.

> I.e., non-receipts are processed per the CMS spec, while receipts digest
> the received message followed by the Receipt structure (the Receipt is
all
> that actually appears in the inner content).  So the messageDigest
> attribute in the Receipt case is not just a digest of the content.
> 
> Is there some other way to do this so SignedData is always processed the
> same?  E.g. include a digest of the original message in the Receipt
> structure or as an additional authenticated attribute?  (Of course these
> mechanisms just prove the recipient has the message digest, not the
actual
> message :-)
> 
> Regards,
> Rich
> 
> 

Date: Tue, 11 Nov 1997 13:45:11 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: ReceiptRequest Comment to ESS-00
Sender: [email-masked]

All,

Propose that the following statement should be added to the Enhanced
Security Services for S/MIME, Section 2.2, intro paragraphs:  "A
ReceiptRequest attribute MUST NOT be included in the attributes of a
SignerInfo in a SignedData object that encapsulates a Receipt content.  In
other words, the user agent MUST NOT request a signed receipt for a signed
receipt."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================ 

Date: Tue, 11 Nov 1997 10:43:06 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Welcome to ietf-smime
Sender: [email-masked]

At 10:36 AM 11/11/97 -0800, [email-masked] wrote:
... all sorts of stuff...

Feel free to ignore that last message. We almost had a mail loop on our
hands, but it was averted. This list seems a bit jinxed for mail loops;
maybe we'd better implement the ESS extensions soon? :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 11 Nov 1997 10:36:02 -0800 (PST)
To: [email-masked], ietf-smime
From: [email-masked]
Subject: Welcome to ietf-smime
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the ietf-smime mailing list!

Please save this message for future reference.  Thank you.

If you ever want to remove yourself from this mailing list,
you can send mail to <[email-masked]> with the following
command in the body of your email message:

    unsubscribe ietf-smime [email-masked] ietf-smime

 Here's the general information for the list you've subscribed to,
 in case you don't already have it:

The ietf-smime mailing list discusses sending MIME messages in an
interoperable, secure fashion using S/MIME. The mailing list is currently an
IETF BOF, but the intention is to have the work become an IETF Working
Group.

To see what has gone on before you subscribed, please see the mailing
list archive at
  http://www.imc.org/ietf-smime/

To unsubscribe from the ietf-smime mailing list, send a message to:
  [email-masked]
with the message:
  unsubscribe

If you need to contact a human about this mailing list, please
send a message to:
  [email-masked]

From: Larry Layten <[email-masked]>
To: "[email-masked]" <[email-masked]>, "'Rich Ankney'" <[email-masked]>
Subject: RE: Receipts vs. SignedData
Date: Tue, 11 Nov 1997 12:30:11 -0600
Sender: [email-masked]

Rich,

Several points:

1. The actual message may have been encrypted, and putting
the digest "in the clear" provides information on the content of
the message.

2. Verification of the receipt still requires that the recipient of
the message retain (or re-create) the message digest to verify 
the signature of the receipt is valid, hence, having it in the 
message isn't of any value.

I guess that item 1 could be taken care of by requiring encryption
of the return receipt if the original message was encrypted.

Larry

----------
From: 	Rich Ankney[SMTP:[email-masked]]
Sent: 	Tuesday, November 11, 1997 11:36 AM
To: 	[email-masked]
Subject: 	Receipts vs. SignedData

It appears that, when creating/verifying SignedData, one processes the
content being signed differently, depending on if it is a Receipt or not. 
I.e., non-receipts are processed per the CMS spec, while receipts digest
the received message followed by the Receipt structure (the Receipt is all
that actually appears in the inner content).  So the messageDigest
attribute in the Receipt case is not just a digest of the content.

Is there some other way to do this so SignedData is always processed the
same?  E.g. include a digest of the original message in the Receipt
structure or as an additional authenticated attribute?  (Of course these
mechanisms just prove the recipient has the message digest, not the actual
message :-)

Regards,
Rich

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Subject: Receipts vs. SignedData
Date: Tue, 11 Nov 1997 12:36:38 -0500
Sender: [email-masked]

It appears that, when creating/verifying SignedData, one processes the
content being signed differently, depending on if it is a Receipt or not. 
I.e., non-receipts are processed per the CMS spec, while receipts digest
the received message followed by the Receipt structure (the Receipt is all
that actually appears in the inner content).  So the messageDigest
attribute in the Receipt case is not just a digest of the content.

Is there some other way to do this so SignedData is always processed the
same?  E.g. include a digest of the original message in the Receipt
structure or as an additional authenticated attribute?  (Of course these
mechanisms just prove the recipient has the message digest, not the actual
message :-)

Regards,
Rich

Date: Tue, 11 Nov 1997 09:03:55 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: ESS-00 countersignature Comment
Sender: [email-masked]

Paul,

I need to change comment #7 in my 11/6 message subject "ESS-00 Comments".  I
erroneously stated that a counterSignature attribute MUST BE authenticated.
In fact, PKCS #9 states that it MUST NOT BE authenticated.  That needs to be
reflected in the list of attributes in ESS-00, Sec 1.3.4.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Tue, 11 Nov 1997 08:21:39 -0500
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Receipts
Sender: [email-masked]

Rich,

The security services provided by the PKCS #9 countersignature attribute and
CMS/ESS signed receipt are very different.   The purpose of the CMS/ESS
signed receipt is to prove to the originator that the recipient was able to
verify the signature of the original message.  In order to verify the
signature of the original message, the recipient must actually receive the
content of the original message.  To form the signed receipt signature, the
recipient must first hash the original content and Receipt content.  When
the originator verifies the signature of the signed receipt, that proves to
the originator that the recipient actually received the content of the
original message because that is the only way that the recipient could have
successfully generated the signed receipt signature.

A PKCS #9 countersignature is calculated solely on the hash of the signature
value of the original message.  The countersignature can be calculated by an
entity that never receives the content of the original message.  That is the
important difference between the security services provided by the PKCS #9
countersignature and CMS/ESS signed receipt.

In summary, I believe that we should not change the signed receipt syntaxes
and text included in ESS (other than adding clarifying text regarding
multiple receiptRequests included in a signedData object as discussed in
previous messages on the list). 

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 08:33 PM 11/10/97 -0500, Rich Ankney wrote:
>The receipt mechanism in ESS appears to be based on the MSP receipt.  There
>are several draft standards in ANSI X9 and ASTM E31.20 (medical
>informatics) that represent a receipt as a countersignature on the
>originator's signature.  In PKCS #7 and PKCS #9 terms, a countersignature
>is just a SignerInfo which signs the encryptedDigest field in another
>SignerInfo.  It is carried as an unauthenticated attribute in this
>enclosing SignerInfo.  While I'm not proposing adding this to ESS, I was
>wondering if anyone sees any problems with this approach.
>
>Regards,
>Rich
>

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Subject: Receipts
Date: Mon, 10 Nov 1997 20:33:57 -0500
Sender: [email-masked]

The receipt mechanism in ESS appears to be based on the MSP receipt.  There
are several draft standards in ANSI X9 and ASTM E31.20 (medical
informatics) that represent a receipt as a countersignature on the
originator's signature.  In PKCS #7 and PKCS #9 terms, a countersignature
is just a SignerInfo which signs the encryptedDigest field in another
SignerInfo.  It is carried as an unauthenticated attribute in this
enclosing SignerInfo.  While I'm not proposing adding this to ESS, I was
wondering if anyone sees any problems with this approach.

Regards,
Rich

From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>
Subject: AuthenticatedData?
Date: Mon, 10 Nov 1997 20:31:11 -0500
Sender: [email-masked]

I've been trying to adopt CMS for use in ANSI X9 (baning standards).  This
is pretty trivial except for the requirement for a symmetric authenticator
(DES-MAC or HMAC).  I've done an AuthenticatedData structure (stealing much
of the new EnvelopedData key management stuff), and was wondering if this
would be useful in S/MIME as well.  I note that it solves many of the
problems associated with using PKCS #7 to protect PKIX-3 CMP messages, for
those who care about that.  If there is any interest, I'll post the
AuthenticatedData definition and we can discuss including it in the next
draft.  (My motivation, of course, is to point to other standards as much
as possible and minimize the amount of new work we do in X9.)

Regards,
Rich

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Certificate request format (was RE: S/MIME V3MsgSpecComment s)
Date: Mon, 10 Nov 1997 12:44:37 -0800
Sender: [email-masked]

On Monday, November 10, 1997 12:15 PM, Debbie Stulberg
[SMTP:[email-masked]] wrote:
> >> Ah.  So maybe this should be worded "IF you implement keypair
> >> generation
> >> AND you are submitting the public key to a CA THEN you MUST use..."
> 
> 
> Sorry to jump in on a conversation half way through. But I'm a little
> worried about the above statement. Is there a compelling issue
> of compatibility here? Is that issue enforceable?

The idea is that if a client supports keypair generation, then there
needs to be a consistent format that every client can use.  Otherwise, I
don't think we will have interoperability between arbitrary client/CA
pairs.

To answer your question, I do think there is a compelling issue of
compatibility, and the enforcement is through the use of MUST language
in the spec.

So it appears that you object to my use of the word "use" vs. the
suggestion of the word "support" in my original wording, in order to
accommodate other schemes that are useful in other S/MIME environments.
I think this is reasonable.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Mon, 10 Nov 1997 18:02:10 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

David Kemp <[email-masked]> writes: (David P. Kemp)
>   I'm not clear on what scenario you have in mind.  DH long-term public
> keys can be certified to allow the sender to authenticate the recipient,
> but do not allow the recipient to authenticate the sender; for that a
> certified signature key is required.
> 
> Can you describe the protocol/usage mode that requires two *certified*
> DH public keys per entity, in addition to the certified signature key?

Is this talking about certification requests which (must?) be self
signed to prevent DoS attacks?

In that case if you have a DH cert the certificate request can not be
signed by the DH key (because it is a key exchange only key).

So you need a pair of keys forming one certificate (a combo cert), one
a signing key (DSA or RSA) and the other the DH key.  Then the signing
key can sign both the DH key and the signing key.

Where are these combo certs described?  Are these combo certs what is
supposed to be used with SSLv3 DH certificates?

Are we also describing the scenario where there are two separate
certs, one signature cert (DSA/RSA) and one encryption only cert (DH)?
If so how are DoS attacks prevented when the user sends the CA his
certficate request asking for the DH key to be certified?

Adam

Date: Mon, 10 Nov 97 19:10:01 UT
From: "Darren Harter" <[email-masked]>
To: [email-masked], "David P. Kemp" <[email-masked]>, [email-masked]
Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

David,

The following is a brief example key exchange mechanism based on D-H that uses 
different key-pairs for sending and receiving.... It's based on a paper 
published by the Royal-Holloway college in the UK a couple of years ago, and 
is known quite widely as R-H.. There is a URL that refers, but I don't have to 
to hand....  Hope it helps...

Presume each user has two key pairs -
	one for sending (Sx and Sy) where Sy = g ^ Sx mod N 
and	one for receiving (Rx and Ry) where Ry = g ^ Rx mod N.

If A wishes to send to B, then A calculates the following KEY to encrypt the 
message key:

KEY(AtoB) = Ry(B) ^ Sx(A) mod N

A's certificate containing Sy(A) is then sent with the message to B.

On Receipt B calculates KEY(AtoB) = Sy(A) ^ Rx(B) mod N and decrypts the 
message key.

However, if B sends to A, the KEY becomes KEY(BtoA) = Ry(A) ^ Sx(B) mod N = 
Sy(B) ^ Rx(A) mod N which clearly has a different value.

Obviously, the KEY's produced in each case would be reduced to a sensible key 
size for the key encryption algorithm by using something like SHA-1, which 
would also ensure good entropy in the resultant key, and extracting n bits of 
key.

Hope this helps,

Darren Harter
[email-masked]

-----Original Message-----
From:	[email-masked]  On Behalf Of David P. Kemp
Sent:	Monday, November 10, 1997 02:49
To:	[email-masked]
Subject:	RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)

> From: "Darren Harter" <[email-masked]>
> 
> John,
> 
> We should also take care to ensure that DH derivatives that have
> separate key-pairs (and thus certificates) for sending and receiving
> are not ignored.
> 
> Darren Harter
> [email-masked]

Darren,
  I'm not clear on what scenario you have in mind.  DH long-term public
keys can be certified to allow the sender to authenticate the recipient,
but do not allow the recipient to authenticate the sender; for that a
certified signature key is required.

Can you describe the protocol/usage mode that requires two *certified*
DH public keys per entity, in addition to the certified signature key?

Date: Mon, 10 Nov 1997 12:35:27 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Certificate request format (was RE: S/MIME V3 MsgSpecComment s)
Sender: [email-masked]

> From: "Debbie Stulberg" <[email-masked]>
> 
> I would not like to see support for our OnSite or other shipping 
> solutions suddenly make a product inelligible to call itself S/MIME.
> 
> The statement "Clients supporting key generation MUST support..."
> appears nearer to what people intend.
> 
>         Phill
> 
> Phillip M Hallam-Baker
> Principal Consultant
> VeriSign Inc

Yes, "must use" is technically incorrect; "must support the use of" or
"must be able to use, at the user's option" is what we assume Blake meant.
That is the standard interpretation for IETF requirement levels.

  (Now if this message had been signed, we might know who *really* sent it -
  Debbie claiming to be Phill, or Phill borrowing Debbie's machine :-).
  Debbie does exercise due diligence to protect her private key,
  correct? :-)

From: "Phill Hallam-Baker" <[email-masked]>
To: "Debbie Stulberg" <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate request format (was RE: S/MIME V3 MsgSpecComment s)
Date: Mon, 10 Nov 1997 12:35:23 -0800
Sender: [email-masked]

ooops,

    Sent message from wrong account by mistake. I'm really
[email-masked]. Debbie is the person whose workstation
and office I borrowed and may not be interested in S/MIME.

            Phill

>Sorry to jump in on a conversation half way through. But I'm a little
>worried about the above statement. Is there a compelling issue
>of compatibility here? Is that issue enforceable?

>Phillip M Hallam-Baker
>Principal Consultant
>VeriSign Inc

From: "Debbie Stulberg" <[email-masked]>
To: "Jim Schaad (Exchange)" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>, <[email-masked]>
Subject: Re: Certificate request format (was RE: S/MIME V3 MsgSpecComment s)
Date: Mon, 10 Nov 1997 12:15:13 -0800
Sender: [email-masked]

>> Ah.  So maybe this should be worded "IF you implement keypair
>> generation
>> AND you are submitting the public key to a CA THEN you MUST use..."

Sorry to jump in on a conversation half way through. But I'm a little
worried about the above statement. Is there a compelling issue
of compatibility here? Is that issue enforceable?

In general a MUST refers to something that must be supported. MUST
use is a pretty infrequent requirement. I am somewhat concerned that
in an enterprise environment there might be a good need to 
support use of some other certificate request mechanism and yet
still produce a product that is 100% interoperable with other S/MIME
implementations.

I would not like to see support for our OnSite or other shipping 
solutions suddenly make a product inelligible to call itself S/MIME.

The statement "Clients supporting key generation MUST support..."
appears nearer to what people intend.

        Phill

Phillip M Hallam-Baker
Principal Consultant
VeriSign Inc

P.S. As people might notice I'm no longer at MIT, the AI lab or the
Web consortium.

From: "Rich Ankney" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Date: Mon, 10 Nov 1997 11:39:24 -0500
Sender: [email-masked]

I'd be glad to do appendices for DSS and for D-H (X9.42).

Regards,
Rich Ankney

----------
> From: John Pawling <[email-masked]>
> To: Blake Ramsdell <[email-masked]>; [email-masked]'
> Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
> Date: Monday, November 10, 1997 8:30 AM
> 
> Blake,
> 
> IMHO, the S/MIME v3 Message Spec doesn't need to say anything about combo
> certs.  The S/MIME v3 Certificate Handling spec probably should same
> something about combo certs (i.e. allowed or prohibited).
> 
> The PKIX I document lists X9.42 and X9.57 as reference documents for D-H
and
> DSS, respectively.  Also, there is a NIST document entitled "Stable
> Implementation Agreements for Open Systems Interconnection Protocols:
Part
> 12 - OS Security, Output from the June 1995 Open Systems Environment
> Implementors' Workshop (OIW)".  I will send you all three documents.
> 
> I believe that there should be separate appendices to the CMS spec that
> provide the gory details (e.g. padding, key length, mode, etc) regarding
the
> use of DSS, SHA-1, KEA, Skipjack, D-H, and RSA algorithms.  If the WG is
in
> favor of this strategy, I would be happy to draft some of these
appendices
> (e.g. KEA and Skipjack). 
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 
> 
> At 01:59 PM 11/7/97 -0800, Blake Ramsdell wrote:
> >On Friday, November 07, 1997 1:44 PM, [email-masked]
> >[SMTP:[email-masked]] wrote:
> >> DH and DSS keys are separately generated.  The public DH and DSS keys
are
> >> stored in separate X.509 Certificates.
> >
> >This was something that was being discussed at one point -- the
> >possibility of a "combo" certificate that had both signature
> >verification and key management properties (the public part of the DH
> >encrypting pair and the public part of the DSS pair).
> >
> >> How about changing the text to the following: "An S/MIME agent or some
> >> related administrative utility or function MUST be capable of
generating
> >> separate DH and DSS public/private key pairs on behalf of the user."
> >
> >Yup.  Sounds good.  Comments?  Objections?
> >
> >I will also change the current references to [DH-DSS] to just be [DSS].
> >
> >What would be the best source to use for the [DH] (Diffie-Hellman
> >encryption) and [DSS] (DSS) references?  Are we making a draft for this?
> >
> >Blake
> >--
> >Blake C. Ramsdell
> >Worldtalk Corporation
> >For current info, check http://www.deming.com/users/blaker
> >Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> >
> >
> 

Date: Mon, 10 Nov 1997 11:24:53 -0500
To: [email-masked] (David P. Kemp), [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Certificate request format (was RE: S/MIME V3 MsgSpecComment s)
Sender: [email-masked]

All,

Does this mean that the S/MIME v3 Msg Spec will state: "IF you implement
keypair generation AND you are submitting the public key to a CA THEN you
MUST use PKIX 3 as follows..."

- John Pawling

At 10:34 AM 11/10/97 -0500, David P. Kemp wrote:
>> > From:	Blake Ramsdell [SMTP:[email-masked]]
>> > 
>> > Ah.  So maybe this should be worded "IF you implement keypair generation
>> > AND you are submitting the public key to a CA THEN you MUST use..."
>> > 
>> > Does this sound right?
>
>
>> From: "Jim Schaad (Exchange)" <[email-masked]>
>> 
>> That sounds reasonable.
>> 
>
>Agreed.
>

Date: Mon, 10 Nov 1997 10:34:12 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: Certificate request format (was RE: S/MIME V3 MsgSpecComment  s)
Sender: [email-masked]

> > From:	Blake Ramsdell [SMTP:[email-masked]]
> > 
> > Ah.  So maybe this should be worded "IF you implement keypair generation
> > AND you are submitting the public key to a CA THEN you MUST use..."
> > 
> > Does this sound right?

> From: "Jim Schaad (Exchange)" <[email-masked]>
> 
> That sounds reasonable.
> 

Agreed.

Date: Mon, 10 Nov 1997 09:48:57 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

> From: "Darren Harter" <[email-masked]>
> 
> John,
> 
> We should also take care to ensure that DH derivatives that have
> separate key-pairs (and thus certificates) for sending and receiving
> are not ignored.
> 
> Darren Harter
> [email-masked]

Darren,
  I'm not clear on what scenario you have in mind.  DH long-term public
keys can be certified to allow the sender to authenticate the recipient,
but do not allow the recipient to authenticate the sender; for that a
certified signature key is required.

Can you describe the protocol/usage mode that requires two *certified*
DH public keys per entity, in addition to the certified signature key?

Date: Mon, 10 Nov 1997 09:46:53 -0500
To: Paul Hoffman / IMC <[email-masked]>, "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: PKCS #9 Internet Draft??
Sender: [email-masked]

Paul,

It would be fine with me if the OIDS and ASN.1 syntaxes for all attributes
are added to the S/MIME registry (http://www.imc.org/ietf-smime/oids.html).
Please ensure that the ContentType, SigningTime, CounterSignature, and
MessageDigest OIDs and ASN.1 sytaxes are copied from PKCS #9 to the registry.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 03:28 PM 11/7/97 -0800, Paul Hoffman / IMC wrote:
>At 02:21 PM 11/7/97 -0800, Blake Ramsdell wrote:
>>On Friday, November 07, 1997 1:24 PM, [email-masked]
>>[SMTP:[email-masked]] wrote:
>>> Please note that many of the OID definitions (such as ContentType,
>>> SigningTime, CounterSignature, and MessageDigest attributes) need to be
>>> added to <http://www.imc.org/ietf-smime/oids.html>.
>>
>>If we do this (which I think we should), we should add all of the OIDs
>>that are listed in section A of the message draft.  Right?
>
>It's up to the group. I certainly don't want anything listed in two places:
>that leads to bad mistakes. My own preference is to have everything in the
>registry and strip them out of the documents, but I'm no coder, so I can't
>say whether or not that would help or hurt implementors.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Date: Mon, 10 Nov 1997 09:14:11 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-00 Comments
Cc: [email-masked]
Sender: [email-masked]

Russ,

Your wording is fine with me.  And to make it crystal clear, also recommend
inserting text in Sec 2.2, last para that states: "If multiple
receiptRequest attributes are present in a SignedData object, than they MUST
all be identical."

In an earlier message, you stated:
>>>"There can be multiple SignerInfos within a SignedData object.  Each
>>>SignerInfo may include authenticatedAttributes.  Therefore, a single
>>>SignedData object may include multiple SignerInfos each with a
>>>receiptRequest attribute.   For example, an originator can send a signed
>>>message with two SignerInfos, one containing a DSS signature and the other
>>>containing a RSA signature.  Both SignerInfos can contain the same
>>>receiptRequest attribute.  Each recipient should return one signed receipt."

Recommend changing the second from last sentence in your paragraph to state:
"Both SignerInfos MUST contain the same receiptRequest attribute." 

Based on the fact that receiptRequests in a SignedData must all be
identical, I need to modify comment #11 in my original "ESS-00 Comments"
message to be:

"11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
examine the authenticatedAttributes field of the innermost SignerInfo object
to determine if a receipt is requested." To "Processing software SHOULD
examine the authenticatedAttributes field of each of the SignerInfos for
which it verifies a signature in the innermost signedData object to
determine if a receipt is requested.  This may result in the receiving agent
processing multiple receiptRequest attributes included in a single
SignedData object.  Because all receiptRequest attributes in a SignedData
object must be identical, then the receiving application fully processes (as
described in the following paragraphs) the first receiptRequest that it
encounters in a SignerInfo that it can verify and then ensures that all
other receiptRequests are identical to the first one encountered."

Also, I withdraw the following comments that I made in my original "ESS-00
Comments" message:

12) Sec 2.3, 2nd para, first sent: Please change: "then a signed receipt has
not been requested from any of the message recipients and MUST NOT be
created." To "then a signed receipt has not been requested for this
signerInfo from any of the message recipients and MUST NOT be created for
this signerInfo."

15) Sec 2.3, bullet 2.1: "then a signed receipt MUST NOT be created." To
"then a signed receipt MUST NOT be created for this signerInfo."

16) Sec 2.3, bullet 2.3.1: "and a signed receipt MUST NOT be created." To
"and a signed receipt MUST NOT be created for this signerInfo."

17) Sec 2.3, bullet 3.2: "then a signed receipt MUST NOT be created." To
"then a signed receipt MUST NOT be created for this signerInfo.

21) sec 2.4, intro: Please add: "Note that multiple signed receipts may have
to be created and sent, if applicable (see "Receipt Request Creation" section)."

24) sec 2.5, intro: Please add: "If multiple signed receipts are being sent,
then the following process must be repeated for each signed receipt created."

Also, delete the following sentence for my comment #32, because it is not
needed if all security labels must be identical:   "2) There can't be
multiple SignerInfos containing the same signatureAlgorithm that all include
securityLabels.  In other words, there can only be one securityLabel per
signatureAlgorithm applied to the SignedData."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 04:30 PM 11/7/97 -0500, Russ Housley wrote:
>JOhn:
>
>When the signature is used for co-signing, it would not necessarily contain
>a receipt request at all.  We need to pick careful wording to allow these
>practices to continue.  Perhaps we need to say that not all of the
>SignerInfos need to include receipt requests, but all of that do conatin
>receipt requests mut match.
>
>Russ
>
>At 05:12 PM 11/6/97 -0500, John Pawling wrote:
>>All,
>>
>>I like Russ' paragraph in the enclosed message.  Russ stated: "Both
>>SignerInfos can contain the same receiptRequest attribute."  Does this mean
>>MUST or SHOULD?  I could think of some bizarre scenarios in which different
>>signers may wish to require that signed receipts be sent to specific
>>entities, etc.  However, stating "All SignerInfos MUST contain the same
>>receiptRequest attribute." would simplify processing.  I could go either
>way. 
>>
>>I agree that a similar paragraph could be applied to the multiple
>>SecurityLabel and MLExpansionHistory attributes with the exception that we
>>are requiring that those attributes MUST be identical within a SignedData
>>object. 
>>
>>Russ stated:
>>>Should we also have a warning here about the receipt policy in the
>>>mlExpansionHistory of the outer signed-data?
>>
>>I believe that warning is already covered in ESS-00 Section 2.3.
>>
>>- John Pawling
>>
>>
>>At 03:28 PM 11/6/97 -0500, Russ Housley wrote:
>>>John:
>>>
>>>See a few comments below.
>>>
>>>>10) Sec 2.2: Please add as last para:
>>>>
>>>>"There can be multiple SignerInfos present within a SignedData object.
>Each
>>>>SignerInfo can include authenticatedAttributes.  Therefore, the syntax
>>>>allows a single SignedData object to include multiple SignerInfos each of
>>>>which could include a receiptRequest attribute.   For example, if an
>>>>originator desires to send a signed message requesting signed receipts to a
>>>>set of users composed of RSA-only and DSA-only users.  The originator's
>>>>software can include one SignerInfo that includes an RSA signature value
>and
>>>>a receiptRequest attribute.  The same SignedData object could include
>>>>another SignerInfo that includes a DSA signature value and a receiptRequest
>>>>attribute.  In this example, the RSA-capable recipients should return an
>RSA
>>>>signed receipt to the originator and the DSA-capable recipients should
>>>>return a DSA signed receipt to the originator."
>>>
>>>I like the thrust of your paragraph, but prefer a slightly different
>>>approach.  Does this make all of your points?
>>>
>>>"There can be multiple SignerInfos within a SignedData object.  Each
>>>SignerInfo may include authenticatedAttributes.  Therefore, a single
>>>SignedData object may include multiple SignerInfos each with a
>>>receiptRequest attribute.   For example, an originator can send a signed
>>>message with two SignerInfos, one containing a DSS signature and the other
>>>containing a RSA signature.  Both SignerInfos can contain the same
>>>receiptRequest attribute.  Each recipient should return one signed receipt."
>>>
>>>If you like my paragraph, then similar words should be used in for comments
>>>32 and 36.
>>>
>>>
>>>>11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
>>>>examine the authenticatedAttributes field of the innermost SignerInfo
>object
>>>>to determine if a receipt is requested." To "Processing software SHOULD
>>>>examine the authenticatedAttributes field of each of the SignerInfos for
>>>>which it verifies a signature in the innermost signedData object to
>>>>determine if a receipt is requested.  A receiving agent SHOULD build a
>>>>signed receipt for each SignerInfo in the SignedData object for which it
>>>>verifies the signature and which requests a signed receipt.  This may
>result
>>>>in multiple signed receipts being constructed and sent for a single
>>>>SignedData object."
>>>
>>>Should we also have a warning here about the receipt policy in the
>>>mlExpansionHistory of the outer signed-data?
>>>
>>>
>>>Russ
>>>
>>
>

Date: Mon, 10 Nov 1997 08:30:35 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

Blake,

IMHO, the S/MIME v3 Message Spec doesn't need to say anything about combo
certs.  The S/MIME v3 Certificate Handling spec probably should same
something about combo certs (i.e. allowed or prohibited).

The PKIX I document lists X9.42 and X9.57 as reference documents for D-H and
DSS, respectively.  Also, there is a NIST document entitled "Stable
Implementation Agreements for Open Systems Interconnection Protocols: Part
12 - OS Security, Output from the June 1995 Open Systems Environment
Implementors' Workshop (OIW)".  I will send you all three documents.

I believe that there should be separate appendices to the CMS spec that
provide the gory details (e.g. padding, key length, mode, etc) regarding the
use of DSS, SHA-1, KEA, Skipjack, D-H, and RSA algorithms.  If the WG is in
favor of this strategy, I would be happy to draft some of these appendices
(e.g. KEA and Skipjack). 

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 01:59 PM 11/7/97 -0800, Blake Ramsdell wrote:
>On Friday, November 07, 1997 1:44 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> DH and DSS keys are separately generated.  The public DH and DSS keys are
>> stored in separate X.509 Certificates.
>
>This was something that was being discussed at one point -- the
>possibility of a "combo" certificate that had both signature
>verification and key management properties (the public part of the DH
>encrypting pair and the public part of the DSS pair).
>
>> How about changing the text to the following: "An S/MIME agent or some
>> related administrative utility or function MUST be capable of generating
>> separate DH and DSS public/private key pairs on behalf of the user."
>
>Yup.  Sounds good.  Comments?  Objections?
>
>I will also change the current references to [DH-DSS] to just be [DSS].
>
>What would be the best source to use for the [DH] (Diffie-Hellman
>encryption) and [DSS] (DSS) references?  Are we making a draft for this?
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Sat, 08 Nov 1997 15:43:46 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Even newer versions of the drafts
Sender: [email-masked]

Again, new versions of the S/MIME v2 drafts are now available. Please
look them over, and if there's no problems within a week, I'll consider
them final and turn them in to hopefully become informational RFCs.

==========

Message draft: <http://www.imc.org/draft-dusse-smime-msg>

The following changes were made between the -05 and -06 revisions of this
draft:

Removed discussion of "application/mime" wrapping because no one has
implemented it and because the specification for application/mime is in
flux. This entailed removing section 3.4.3.4, a bit of the table near the
end of section 3.8, and text throughout appendix F.

Changed the case of SMIMECapabilities to sMIMECapabilities everywhere.

Changed the references for ASN.1, BER, and DER back to their 1988
documents.

Fixed error in the MIME examples in 3.1.4 (left off the C-T-E).

Removed antique text from first paragraph 3.5.

Fixed section numbering in Appendix A.

In A.1, changed "other than 32" to "greater than 32".

Removed "smime-type" from E.2 and E.3, where they appeared by mistake.

==========

Certificates draft: <http://www.imc.org/draft-dusse-smime-cert>

The following changes were made between the -04 and -05 revisions of this
draft:

There was general agreement that this draft should reflect reality of
S/MIME v2 implementations and not what "should be", which is left to S/MIME
v3. The changes listed here are to bring this draft back to what is being
deployed today.

Changed the end of 2.3 to only require DN chaining.

Changed the MUST to SHOULD for MD2 hashing in 4.3 and 5.2.

Made the "certificates" in 2.2 "end entity" certificates.

Removed certificatePolicies from 4.4.

In 5.1, changed "Clients MUST handle multiple valid CA certificates" to
"Clients SHOULD...".

In 5.2, changed the MUST to SHOULD for the certification-request
attributes.

In 3.2, changed the SHOULD to MUS for including the email address during DN
creation. Added text in 5.2 to support this.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Sat, 8 Nov 97 10:45:50 UT
From: "Darren Harter" <[email-masked]>
To: "John Pawling" <[email-masked]>, "Blake Ramsdell" <[email-masked]>, [email-masked]
Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

John,

We should also take care to ensure that DH derivatives that have
separate key-pairs (and thus certificates) for sending and receiving
are not ignored.

Darren Harter
[email-masked]

-----Original Message-----
From:	[email-masked]  On Behalf Of John Pawling
Sent:	Friday, November 07, 1997 09:44
To:	Blake Ramsdell; [email-masked]'
Subject:	Re: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)

Blake,

Yes, there are always separate key pairs for signing and encrypting.

.... snipped ....
 
================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Fri, 07 Nov 1997 19:32:48 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: "[email-masked]'" <[email-masked]>
Subject: Re: PKCS #9 Internet Draft??
Sender: [email-masked]

Paul Hoffman / IMC wrote:
> 
> At 02:21 PM 11/7/97 -0800, Blake Ramsdell wrote:
> >On Friday, November 07, 1997 1:24 PM, [email-masked]
> >[SMTP:[email-masked]] wrote:
> >> Please note that many of the OID definitions (such as ContentType,
> >> SigningTime, CounterSignature, and MessageDigest attributes) need to be
> >> added to <http://www.imc.org/ietf-smime/oids.html>.
> >
> >If we do this (which I think we should), we should add all of the OIDs
> >that are listed in section A of the message draft.  Right?
> 
> It's up to the group. I certainly don't want anything listed in two places:
> that leads to bad mistakes. My own preference is to have everything in the
> registry and strip them out of the documents, but I'm no coder, so I can't
> say whether or not that would help or hurt implementors.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

If you're going to create ASN.1 modules, it helps ASN.1:1994
implementors 
to have them defined in the ASN.1, so they can be used to constrain
types.
Regardless of whether you publish in ASN.1:1990 or 1994, someone is sure
to want to implement smime or a derivative, using equivalent ASN.1:1994 
definitions.

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Fri, 07 Nov 1997 16:10:41 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: WG ACTION: S/MIME Mail Security (smime)
Sender: [email-masked]

It's official: we're a Working Group. <noises of celebration are heard>
<party hats appear> <euphoria grips the nation>

OK, now get back to work! We've got standards to create! :-)

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce: ;
Subject: WG ACTION: S/MIME Mail Security (smime)
Date: Fri, 07 Nov 1997 18:19:29 -0500
From: Steve Coya <[email-masked]>

A new working group has been approved in the Security Area of the
IETF. Contact the Area Director or Working Group Chair for more
information.

S/MIME Mail Security (smime)
----------------------------

 Chair(s):
     Russ Housley <[email-masked]>
 
 Security Area Director(s): 
     Jeffrey Schiller  <[email-masked]>
 
 Security Area Advisor: 
     Jeffrey Schiller  <[email-masked]>
 
 Mailing Lists: 
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
     Archive:           http://www.imc.org/ietf-smime/
 
Description of Working Group:
 
The S/MIME Working Group will define MIME encapsulation of digitally 
signed and encrypted objects whose format is based on PKCS #7. [1] X.509
Certificates and CRLs as profiled by the existing PKIX Working Group 
will be used to support authentication and key management. The Working 
Group will base its work on the S/MIME version 2 specification 
(available from RSA Data Security), but the Working Group will be free 
to change any part of that specification. In particular, the Working 
Group will prepare a new document that allows algorithm independence, 
based on PKCS #7 1.5.

The message syntax specification, based on PKCS #7 version 1.5, will be
expanded to allow additional key signature and key exchange algorithms. 
The message and certificate specifications will be revised to allow them 
to become standards. The optional security extensions document will 
specify protocols that allow for additional security features, such as 
signed message receipts.

The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap,
particularly in specification of cryptographic algorithms and MIME 
structure.

[1] RSA Data Security publishes the PKCS Series of documents. RSA Data
Security has permitted the IETF to publish them as Informational RFCs as
well as to extend and enhance them.
 
 Goals and Milestones: 
 
   Nov 97       Submit First draft of message syntax specification as an
I-D.  

   Nov 97       Submit First draft of S/MIME v3 message specification as an 
                I-D.

   Nov 97       Submit First draft of S/MIME optional security extensions
as an
                I-D.

   Nov 97       Submit First draft of S/MIME v3 certificate specification
as an
                I-D

   Dec 97       WG Last Call on Message Syntax.

   Dec 97       WG Last Call on Certifiticate Specification.

   Dec 97       WG Last Call on Message specification.

   Jan 98       WG Last Call on Optional Security Extensions.

   Jan 98       Submit Message Syntax I-D to IESG for consideration as a 

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Certificate request format (was RE: S/MIME V3 MsgSpecComment  s)
Date: Fri, 7 Nov 1997 15:57:35 -0800 
Sender: [email-masked]

That sounds reasonable.

> -----Original Message-----
> From:	Blake Ramsdell [SMTP:[email-masked]]
> Sent:	Friday, November 07, 1997 3:52 PM
> To:	Jim Schaad (Exchange); [email-masked]'
> Subject:	RE: Certificate request format (was RE: S/MIME V3
> MsgSpecComment s)
> 
> On Friday, November 07, 1997 3:36 PM, Jim Schaad (Exchange)
> [SMTP:[email-masked]] wrote:
> > I don't know that there should be a MUST implement for this.  Not
> every
> > S/MIME product will have the generation of keys inside of the
> product
> > nor should it be required.  In the case of Microsoft Outlook
> Express, we
> > don't do any key enrollment in the product itself, that is done by
> an
> > external program (Microsoft Internet Explorer) and we just pick up
> its
> > output later.   It would make sense for there to be a MUST on the CA
> > side, but not on the client side.
> 
> Ah.  So maybe this should be worded "IF you implement keypair
> generation
> AND you are submitting the public key to a CA THEN you MUST use..."
> 
> Does this sound right?
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Certificate request format (was RE: S/MIME V3 MsgSpecComment s)
Date: Fri, 7 Nov 1997 15:52:14 -0800
Sender: [email-masked]

On Friday, November 07, 1997 3:36 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> I don't know that there should be a MUST implement for this.  Not every
> S/MIME product will have the generation of keys inside of the product
> nor should it be required.  In the case of Microsoft Outlook Express, we
> don't do any key enrollment in the product itself, that is done by an
> external program (Microsoft Internet Explorer) and we just pick up its
> output later.   It would make sense for there to be a MUST on the CA
> side, but not on the client side.

Ah.  So maybe this should be worded "IF you implement keypair generation
AND you are submitting the public key to a CA THEN you MUST use..."

Does this sound right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Certificate request format (was RE: S/MIME V3 Msg SpecComment s)
Date: Fri, 7 Nov 1997 15:36:28 -0800 
Sender: [email-masked]

I don't know that there should be a MUST implement for this.  Not every
S/MIME product will have the generation of keys inside of the product
nor should it be required.  In the case of Microsoft Outlook Express, we
don't do any key enrollment in the product itself, that is done by an
external program (Microsoft Internet Explorer) and we just pick up its
output later.   It would make sense for there to be a MUST on the CA
side, but not on the client side.

> -----Original Message-----
> From:	Blake Ramsdell [SMTP:[email-masked]]
> Sent:	Friday, November 07, 1997 2:16 PM
> To:	[email-masked]'; [email-masked]'
> Subject:	RE: Certificate request format (was RE: S/MIME V3 Msg
> SpecComments)
> 
> On Friday, November 07, 1997 11:58 AM, [email-masked]
> [SMTP:[email-masked]] wrote:
> > But IMO, IETF S/MIME should specify a single certificate management
> > message format as a MUST-implement, and that should be the syntax
> > specified by PKIX CMP.  Implementors are always free to include
> > additional functionality over and above that required by the spec.
> > I expect most vendors will offer both S/MIME v2 and legacy PKCS-10
> > support even if S/MIME v3 does not require them.
> 
> I agree that there should be a single MUST implement.  However, my
> understanding of CMP is that it is quite broad in its format (there
> are
> several options to choose from, one of which is PKCS #10 encapsulated
> in
> the CMP format).
> 
> Do I misunderstand CMP (that is, does CMP define something other than
> the big CHOICE for PKIBody that has as one choice the PKCS #10)?
> 
> It sounds like we have to do a separate document to constrain a MUST
> profile for CMP down to size, if I understand this right.
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 07 Nov 1997 15:28:28 -0800
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: PKCS #9 Internet Draft??
Sender: [email-masked]

At 02:21 PM 11/7/97 -0800, Blake Ramsdell wrote:
>On Friday, November 07, 1997 1:24 PM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> Please note that many of the OID definitions (such as ContentType,
>> SigningTime, CounterSignature, and MessageDigest attributes) need to be
>> added to <http://www.imc.org/ietf-smime/oids.html>.
>
>If we do this (which I think we should), we should add all of the OIDs
>that are listed in section A of the message draft.  Right?

It's up to the group. I certainly don't want anything listed in two places:
that leads to bad mistakes. My own preference is to have everything in the
registry and strip them out of the documents, but I'm no coder, so I can't
say whether or not that would help or hurt implementors.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 07 Nov 1997 15:26:28 -0800
To: [email-masked] (John Pawling), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: PKCS #9 Internet Draft??
Sender: [email-masked]

At 04:24 PM 11/7/97 -0500, John Pawling wrote:
>When you say "The latter is our only choice", I assume that you mean that
>the ASN.1 syntaxes and accompanying text for the ContentType, SigningTime,
>CounterSignature, and MessageDigest attributes will be added to either the
>ESS or CMS documents.  Am I correctly interpreting your statement?

Almost. We can define them in the documents, or in the registry. I'm
certainly open to either. Our decision to start the OIDs registry was so
that the arcs would be defined in one place. Since the above attributes
already have definitions, it's fine to put them in the documents, I believe.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: PKCS #9 Internet Draft??
Date: Fri, 7 Nov 1997 14:21:25 -0800
Sender: [email-masked]

On Friday, November 07, 1997 1:24 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> Please note that many of the OID definitions (such as ContentType,
> SigningTime, CounterSignature, and MessageDigest attributes) need to be
> added to <http://www.imc.org/ietf-smime/oids.html>.

If we do this (which I think we should), we should add all of the OIDs
that are listed in section A of the message draft.  Right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Certificate request format (was RE: S/MIME V3 Msg SpecComments)
Date: Fri, 7 Nov 1997 14:16:29 -0800
Sender: [email-masked]

On Friday, November 07, 1997 11:58 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> But IMO, IETF S/MIME should specify a single certificate management
> message format as a MUST-implement, and that should be the syntax
> specified by PKIX CMP.  Implementors are always free to include
> additional functionality over and above that required by the spec.
> I expect most vendors will offer both S/MIME v2 and legacy PKCS-10
> support even if S/MIME v3 does not require them.

I agree that there should be a single MUST implement.  However, my
understanding of CMP is that it is quite broad in its format (there are
several options to choose from, one of which is PKCS #10 encapsulated in
the CMP format).

Do I misunderstand CMP (that is, does CMP define something other than
the big CHOICE for PKIBody that has as one choice the PKCS #10)?

It sounds like we have to do a separate document to constrain a MUST
profile for CMP down to size, if I understand this right.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 07 Nov 1997 16:30:24 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS-00 Comments
Cc: [email-masked]
Sender: [email-masked]

JOhn:

When the signature is used for co-signing, it would not necessarily contain
a receipt request at all.  We need to pick careful wording to allow these
practices to continue.  Perhaps we need to say that not all of the
SignerInfos need to include receipt requests, but all of that do conatin
receipt requests mut match.

Russ

At 05:12 PM 11/6/97 -0500, John Pawling wrote:
>All,
>
>I like Russ' paragraph in the enclosed message.  Russ stated: "Both
>SignerInfos can contain the same receiptRequest attribute."  Does this mean
>MUST or SHOULD?  I could think of some bizarre scenarios in which different
>signers may wish to require that signed receipts be sent to specific
>entities, etc.  However, stating "All SignerInfos MUST contain the same
>receiptRequest attribute." would simplify processing.  I could go either
way. 
>
>I agree that a similar paragraph could be applied to the multiple
>SecurityLabel and MLExpansionHistory attributes with the exception that we
>are requiring that those attributes MUST be identical within a SignedData
>object. 
>
>Russ stated:
>>Should we also have a warning here about the receipt policy in the
>>mlExpansionHistory of the outer signed-data?
>
>I believe that warning is already covered in ESS-00 Section 2.3.
>
>- John Pawling
>
>
>At 03:28 PM 11/6/97 -0500, Russ Housley wrote:
>>John:
>>
>>See a few comments below.
>>
>>>10) Sec 2.2: Please add as last para:
>>>
>>>"There can be multiple SignerInfos present within a SignedData object.
Each
>>>SignerInfo can include authenticatedAttributes.  Therefore, the syntax
>>>allows a single SignedData object to include multiple SignerInfos each of
>>>which could include a receiptRequest attribute.   For example, if an
>>>originator desires to send a signed message requesting signed receipts to a
>>>set of users composed of RSA-only and DSA-only users.  The originator's
>>>software can include one SignerInfo that includes an RSA signature value
and
>>>a receiptRequest attribute.  The same SignedData object could include
>>>another SignerInfo that includes a DSA signature value and a receiptRequest
>>>attribute.  In this example, the RSA-capable recipients should return an
RSA
>>>signed receipt to the originator and the DSA-capable recipients should
>>>return a DSA signed receipt to the originator."
>>
>>I like the thrust of your paragraph, but prefer a slightly different
>>approach.  Does this make all of your points?
>>
>>"There can be multiple SignerInfos within a SignedData object.  Each
>>SignerInfo may include authenticatedAttributes.  Therefore, a single
>>SignedData object may include multiple SignerInfos each with a
>>receiptRequest attribute.   For example, an originator can send a signed
>>message with two SignerInfos, one containing a DSS signature and the other
>>containing a RSA signature.  Both SignerInfos can contain the same
>>receiptRequest attribute.  Each recipient should return one signed receipt."
>>
>>If you like my paragraph, then similar words should be used in for comments
>>32 and 36.
>>
>>
>>>11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
>>>examine the authenticatedAttributes field of the innermost SignerInfo
object
>>>to determine if a receipt is requested." To "Processing software SHOULD
>>>examine the authenticatedAttributes field of each of the SignerInfos for
>>>which it verifies a signature in the innermost signedData object to
>>>determine if a receipt is requested.  A receiving agent SHOULD build a
>>>signed receipt for each SignerInfo in the SignedData object for which it
>>>verifies the signature and which requests a signed receipt.  This may
result
>>>in multiple signed receipts being constructed and sent for a single
>>>SignedData object."
>>
>>Should we also have a warning here about the receipt policy in the
>>mlExpansionHistory of the outer signed-data?
>>
>>
>>Russ
>>
>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Date: Fri, 7 Nov 1997 13:59:25 -0800
Sender: [email-masked]

On Friday, November 07, 1997 1:44 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> DH and DSS keys are separately generated.  The public DH and DSS keys are
> stored in separate X.509 Certificates.

This was something that was being discussed at one point -- the
possibility of a "combo" certificate that had both signature
verification and key management properties (the public part of the DH
encrypting pair and the public part of the DSS pair).

> How about changing the text to the following: "An S/MIME agent or some
> related administrative utility or function MUST be capable of generating
> separate DH and DSS public/private key pairs on behalf of the user."

Yup.  Sounds good.  Comments?  Objections?

I will also change the current references to [DH-DSS] to just be [DSS].

What would be the best source to use for the [DH] (Diffie-Hellman
encryption) and [DSS] (DSS) references?  Are we making a draft for this?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 7 Nov 1997 16:56:34 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: DigestEncryptionAlgorithmIdentifiers for DSS / DSA (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

Blake,

IMHO, id-dsa should be used in the DigestEncryptionAlgorithmIdentifier (with
parameters absent) when a DSS signature is included in the SignerInfo.
Recommend that an appendix to S/MIME v3 Message Spec entitled should be
generated which includes all of the details of using the id-dsa OID and
accompanying data structures.  For example, the format of the DSS signature
value should be the ASN.1 encoded data structure as follows:

DSASignature ::= SEQUENCE  {
   r          INTEGER
   s          INTEGER }

This definition is already used with the id-dsa-with-sha1 OID, but we would
need to specify its use in conjunction with id-dsa.  (Note: I would prefer
to use OCTET STRINGs to represent r and s, but there are many
implementations already in existence that use INTEGERs, so we should stick
with that standard.)

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:51 PM 11/7/97 -0800, Blake Ramsdell wrote:
>On Thursday, November 06, 1997 11:49 AM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> 2) Sec 2.2, I am not sure what you mean by "DH/DSS" as the "MUST support"
>> DigestEncryptionAlgorithmIdentifier.  The PKIX X.509 Certificate and CRL
>> Profile (aka PKIX I), Section 7.2.2, recommends using the Digital Signature
>> Algorithm (DSA) OID (and asscoiated ASN.1 syntaxes) defined in the X9.57
>> specification as follows: id-dsa-with-sha1 ID  ::=  {iso(1) member-body(2)
>> us(840) x9-57 (10040) x9cm(4) 3 }.  The problem with this OID is that
>> combines the SHA-1 and DSA into one value.  The X9.57 id-dsa OID {1 2 840
>> 10040 4 1} is intended for use in the X.509 Certificate subjectPublicKeyInfo
>> algorithmIdentifier field to identify a DSA public key, but I assume that it
>> could also be used as a DigestEncryptionAlgorithmIdentifier (with parameters
>> absent).  I recommend using id-dsa with text explaining that the algorithm
>> parameters will always be absent.
>
>Most errors like this are because of my current ignorance of DSA, DH,
>etc. and their OIDs and parameters.  Thanks for finding this.
>
>So logically, what should appear in the
>DigestEncryptionAlgorithmIdentifier?  Is it the DSA OID?  It should
>*not* be the signature algorithm identifier (id-dsa-with-sha1).  I
>personally agree that it should be id-dsa as you pointed out, since
>rsaEncryption is used in a certificate to identify an RSA public key.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Fri, 7 Nov 1997 16:43:52 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

Blake,

Yes, there are always separate key pairs for signing and encrypting.

DH and DSS are separate algorithms.  DH is used for key exchange associated
with the content encryption process.  Specifically, a random message
encryption key (MEK) is generated and used to encrypt the content.  The
originator then uses her private DH key in conjunction with the recipient's
public DH key to generate a pairwise key which is used to uniquely encrypt
the MEK for the recipient.  This process is repeated for each recipient.

DSS is used for digital signature.  The originator uses her private DSS key
to sign a hash (usually SHA-1) of the data and the recipient uses the
originator's public DSS key to verify the originator's signature.

DH and DSS keys are separately generated.  The public DH and DSS keys are
stored in separate X.509 Certificates.

A pair of DSS private and public keys are generated for each user's
identity.  The DSS public key is included in an X.509 Certificate using the
X9.57 id-dsa OID in the SubjectPublicKeyInfo AlgorithmIdentifier field as
stated in PKIX I, Sec 7.3.3.

A separate pair of DH private and public keys are generated.  The DH public
key is included in a separate X.509 Certificate using the X9.42
dhpublicnumber OID in the SubjectPublicKeyInfo AlgorithmIdentifier field as
stated in PKIX I, Sec 7.3.2.

How about changing the text to the following: "An S/MIME agent or some
related administrative utility or function MUST be capable of generating
separate DH and DSS public/private key pairs on behalf of the user."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:59 PM 11/7/97 -0800, Blake Ramsdell wrote:
>On Thursday, November 06, 1997 11:49 AM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> 4) Sec 4.1, 1rst para, 1rst sent: Please delete "RSA" from: "An S/MIME agent
>> or some related administrative utility or function MUST be capable of
>> generating RSA key pairs on behalf of the user."
>
>My concern is along the lines of how keypairs work in the DH new world
>order.  Is there always a separate pair for signing and encrypting?
>
>I'd like to get that clarified also, because I think that it belongs in
>this section also.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Fri, 7 Nov 1997 16:24:05 -0500
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: PKCS #9 Internet Draft??
Sender: [email-masked]

Paul,

Please note that many of the OID definitions (such as ContentType,
SigningTime, CounterSignature, and MessageDigest attributes) need to be
added to <http://www.imc.org/ietf-smime/oids.html>.

When you say "The latter is our only choice", I assume that you mean that
the ASN.1 syntaxes and accompanying text for the ContentType, SigningTime,
CounterSignature, and MessageDigest attributes will be added to either the
ESS or CMS documents.  Am I correctly interpreting your statement?
 
================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:29 PM 11/7/97 -0800, Paul Hoffman / IMC wrote:
>>The CMS and ESS specs mention attribute types defined in the RSA-copyrighted
>>"PKCS #9: Selected Attribute Types" specification.  These include:
>>ContentType, SigningTime, CounterSignature, and MessageDigest.
>
>These are actually defined by us, the S/MIME folk. The definitions are at
><http://www.imc.org/ietf-smime/oids.html>.
>
>>I can't find
>>an Internet Draft for PKCS #9.  IMHO, either PKCS #9 needs to be re-produced
>>as an Internet Draft or the aforementioned PKCS #9 attributeTypes need to be
>>defined in ESS or CMS.
>
>The latter is our only choice.
>
>>Paul Hoffman: do you know of any plans to re-define PKCS #9 as an Internet
>>Draft?
>
>Last I heard from RSA, they didn't want to do this because PKCS #9 is a
>"living document" that they want to be able to change at will. They update
>it when they feel like it. So, it would not be appropriate for this to
>become an informational RFC. That's why we set up our own OIDs registry.
>
>Depending on the feeling of this group and of IANA, this registry might
>transition to IANA if we can come up with clear enough rules for how things
>get added to it or changed in it. I'll be making a stab at that wording in
>the near future, but it might be problematic. For instance, who decides
>which OID to register for a new key algorithm? What if someone wants to add
>a private attribute type? The naming issue rears its ugly head again.
>However, I believe we can handle it.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: DH keypair generation (was RE: S/MIME V3 Msg Spec Comments)
Date: Fri, 7 Nov 1997 12:59:47 -0800
Sender: [email-masked]

On Thursday, November 06, 1997 11:49 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> 4) Sec 4.1, 1rst para, 1rst sent: Please delete "RSA" from: "An S/MIME agent
> or some related administrative utility or function MUST be capable of
> generating RSA key pairs on behalf of the user."

My concern is along the lines of how keypairs work in the DH new world
order.  Is there always a separate pair for signing and encrypting?

I'd like to get that clarified also, because I think that it belongs in
this section also.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Section 2.6.1-2.6.3 (40-bit crypto) (was RE: S/MIME V3 Msg Spec Comments)
Date: Fri, 7 Nov 1997 12:57:36 -0800
Sender: [email-masked]

On Thursday, November 06, 1997 11:49 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> 3) Sec 2.6.1-2.6.3: IMHO, the text regarding the process by which the
> applications chooses the encryption algorithm to use to encrypt data was
> useful and should be reinstated with the few text changes required to make
> RC2 optional and 3DES the default.

I've gotten a couple of comments about this offline, and I am thinking
about putting these sections back in, with some language revision.  I
think that talking about 40-bit crypto issues is a good idea, and helps
us stay out of trouble since we have the optional use of 40-bit crypto.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: DigestEncryptionAlgorithmIdentifiers for DSS / DSA (was RE: S/MIME V3 Msg Spec Comments)
Date: Fri, 7 Nov 1997 12:51:35 -0800
Sender: [email-masked]

On Thursday, November 06, 1997 11:49 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> 2) Sec 2.2, I am not sure what you mean by "DH/DSS" as the "MUST support"
> DigestEncryptionAlgorithmIdentifier.  The PKIX X.509 Certificate and CRL
> Profile (aka PKIX I), Section 7.2.2, recommends using the Digital Signature
> Algorithm (DSA) OID (and asscoiated ASN.1 syntaxes) defined in the X9.57
> specification as follows: id-dsa-with-sha1 ID  ::=  {iso(1) member-body(2)
> us(840) x9-57 (10040) x9cm(4) 3 }.  The problem with this OID is that
> combines the SHA-1 and DSA into one value.  The X9.57 id-dsa OID {1 2 840
> 10040 4 1} is intended for use in the X.509 Certificate subjectPublicKeyInfo
> algorithmIdentifier field to identify a DSA public key, but I assume that it
> could also be used as a DigestEncryptionAlgorithmIdentifier (with parameters
> absent).  I recommend using id-dsa with text explaining that the algorithm
> parameters will always be absent.

Most errors like this are because of my current ignorance of DSA, DH,
etc. and their OIDs and parameters.  Thanks for finding this.

So logically, what should appear in the
DigestEncryptionAlgorithmIdentifier?  Is it the DSA OID?  It should
*not* be the signature algorithm identifier (id-dsa-with-sha1).  I
personally agree that it should be id-dsa as you pointed out, since
rsaEncryption is used in a certificate to identify an RSA public key.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 07 Nov 1997 12:29:58 -0800
To: [email-masked] (John Pawling), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: PKCS #9 Internet Draft??
Sender: [email-masked]

>The CMS and ESS specs mention attribute types defined in the RSA-copyrighted
>"PKCS #9: Selected Attribute Types" specification.  These include:
>ContentType, SigningTime, CounterSignature, and MessageDigest.

These are actually defined by us, the S/MIME folk. The definitions are at
<http://www.imc.org/ietf-smime/oids.html>.

>I can't find
>an Internet Draft for PKCS #9.  IMHO, either PKCS #9 needs to be re-produced
>as an Internet Draft or the aforementioned PKCS #9 attributeTypes need to be
>defined in ESS or CMS.

The latter is our only choice.

>Paul Hoffman: do you know of any plans to re-define PKCS #9 as an Internet
>Draft?

Last I heard from RSA, they didn't want to do this because PKCS #9 is a
"living document" that they want to be able to change at will. They update
it when they feel like it. So, it would not be appropriate for this to
become an informational RFC. That's why we set up our own OIDs registry.

Depending on the feeling of this group and of IANA, this registry might
transition to IANA if we can come up with clear enough rules for how things
get added to it or changed in it. I'll be making a stab at that wording in
the near future, but it might be problematic. For instance, who decides
which OID to register for a new key algorithm? What if someone wants to add
a private attribute type? The naming issue rears its ugly head again.
However, I believe we can handle it.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 7 Nov 1997 14:58:20 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Certificate request format (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

> From: "Anil R. Gangolli" <[email-masked]>
> 
> Since there are a number of mechanisms in use today that allow PKCS-10
> submitted over other certificate management protocol schemes (e.g. ones
> using
> HTTP and HTML forms).  I think there is value in separating these and
> including both, as well as in indicating the acceptability of e-mail and
> other submission schemes incorporating PKCS-10 but not necessarily
> PKIX CMP.
> 
> I also think that the level of support for PKIX CMP is not adequate
> to merit its specification as the sole means of certification request
> in the S/MIME v3 timeframe.

Anil,

You are, as usual, correct.  S/MIME may specify the optional use of any
number of certificate management request message formats and transport
mechanisms, including various combinations of PKCS-7, PKCS-10, HTML,
HTTP, SMTP, FTP, etc.

But IMO, IETF S/MIME should specify a single certificate management
message format as a MUST-implement, and that should be the syntax
specified by PKIX CMP.  Implementors are always free to include
additional functionality over and above that required by the spec.
I expect most vendors will offer both S/MIME v2 and legacy PKCS-10
support even if S/MIME v3 does not require them.

Date: Fri, 07 Nov 1997 11:19:49 -0800
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: Blake Ramsdell <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: Certificate request format (was RE: S/MIME V3 Msg Spec Comments)
Sender: [email-masked]

Blake Ramsdell wrote:
> 
> On Thursday, November 06, 1997 12:05 PM, [email-masked]
> [SMTP:[email-masked]] wrote:
> > Given that this document describes the IETF version of S/MIME, I
> think
> > *also* is the wrong word.  The S/MIME v3 spec should define how to
> create
> > certification requests using the IETF Certificate Management
> Protocol,
> > period.  PKCS #10-format requests are included as an option within
> CMP.
> 
> I agree -- since the alliance is expressly towards PKIX, then we
> should
> do this.
> 
> If we just define the use of p10cr for the purpose of requesting a
> certificate, would that be adequate for Diffie-Hellman and friends?
> Are
> there any other ways of requesting that are useful to S/MIME that
> aren't
> achievable using PKCS #10 in CMP?
> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Since there are a number of mechanisms in use today that allow PKCS-10
submitted over other certificate management protocol schemes (e.g. ones
using
HTTP and HTML forms).  I think there is value in separating these and
including both, as well as in indicating the acceptability of e-mail and
other submission schemes incorporating PKCS-10 but not necessarily
PKIX CMP.

I also think that the level of support for PKIX CMP is not adequate
to merit its specification as the sole means of certification request
in the S/MIME v3 timeframe.

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

Date: Fri, 7 Nov 1997 13:34:13 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: PKCS #9 Internet Draft??
Sender: [email-masked]

All,

The CMS and ESS specs mention attribute types defined in the RSA-copyrighted
"PKCS #9: Selected Attribute Types" specification.  These include:
ContentType, SigningTime, CounterSignature, and MessageDigest.  I can't find
an Internet Draft for PKCS #9.  IMHO, either PKCS #9 needs to be re-produced
as an Internet Draft or the aforementioned PKCS #9 attributeTypes need to be
defined in ESS or CMS.

Paul Hoffman: do you know of any plans to re-define PKCS #9 as an Internet
Draft?

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Fri, 07 Nov 1997 10:19:30 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Jim Craigie TEL +44-1635-202124 <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on the Cryptographic Message Syntax
Sender: [email-masked]

Jim Craigie TEL +44-1635-202124 wrote:
> 
> Some comments on the Cryptographic Message Syntax spec:
> 
> 1. ASN.1 Canonical Encoding Rules should be allowed
> 

Yes, but DER rules. CER would seem the more logical choice, and
I looked at this issue some time back earlier this year, but I 
could find not one single ASN.1 specification that had adopted
CER. And I know of no free or commercial products that support 
CER at this time. CER is a relatively recent event, and did not
exist when the PKCS standards were created. (At that time, DER 
was an invention of the X.50* folks, and was considered of such
general utility, that it was later moved into X.690.)

I've toyed with Packed Encoding Rules (PER - X.691) for a while,
since Certs are tag heavy, and PER offers typical 20-40% savings
in encoded size, but using PER takes some planning in how your
ASN.1 is defined, especially if you need to compute hashes. Unless
you use the open type notation properly, an object ToBeSigned is
not guaranteed to either start or end on a byte boundary. 

Some new standards, like the multimedia work in h.245, h.235, h.323,
etc. use PER effectively to reduce their message sizes, but are
just now adding security enhancements. It would take a lot of
bandwidth to convert a standard as far along as smime to use some
other encoding rules. I believe a change from DER would greatly
distract from the more important aspects of the work.

[snip]

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Fri, 7 Nov 1997 11:06:54 -0500
To: Trevor Freeman <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS-00 Multiple Signed Receipts Issue
Cc: [email-masked]
Sender: [email-masked]

Trevor,

Thank you very much for your feedback.  The CMS and ESS specifications
specify cryptographic security services, so the CMS/ESS signed receipt
should only provide cryptographic security services.  The purpose of the
CMS/ESS signed receipt is to prove to the originator that the recipient was
able to verify the signature of the original message. This is the only
purpose for the ESS/CMS signed receipt that is within the scope of the CMS
and ESS specifications.  The other types of receipts that you list are
outside the scope of CMS and ESS, so they should be documented in separate
specifications that are not security-specific specifications.    

A CMS/ESS signed receipt is constructed by encapsulating an ESS Receipt
object within a CMS SignedData object.  The Receipt signature value is
included in the SignerInfo included in the SignedData object which
encapsulates the Receipt object.  The SignerInfo includes
autheticatedAttributes and unAuthenticatedAttributes.  Therefore, a CMS/ESS
signed receipt can include any of the attributes listed in ESS (and some
from PKCS #9) or it could include privately defined attributes.  This
provides a lot of flexibility for the recipient to provide information back
to the originator of the original message.

In my opinion, there is an open issue regarding whether or not all
receiptRequests included in a SignedData object MUST be identical.  I can
think of some bizarre scenarios in which different signers may wish to
require that signed receipts be sent to specific
entities, etc.  However, stating "All SignerInfos MUST contain the same
receiptRequest attribute." would simplify processing.  I could go either way.

In summary, I believe that we should not change the signed receipt syntaxes
and text included in ESS (other than adding clarifying text regarding
multiple receiptRequests included in a signedData object). 

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 07:25 AM 11/7/97 -0800, Trevor Freeman wrote:
>I have a couple of related issues with signed receipts. 
>The signed receipt process as outlined only considers a single type of
>receipt. If fact there are more that one type of receipt. Examples of these
>types would be
>	A message has been delved to a mail box (but not opened).
>	A message has been opened
>	The recipient acknowledges they have read (and hopefully understood)
>the message
>	The recipient has actioned the message
>Some of these receipts may mandate recipient intervention, such as
>acknowledgement and actioned. You may require different receipt types from
>different people, therefore I would envisage the requirement for multiple
>receipt requests to be contained within the authenticated attributes of a
>single message, with different users being asked for different types of
>receipt.
>
>Another requirement of the originator is that they may require some
>additional information from the recipient to be returned as part of the
>receipt. This additional content may be considered mandatory by the
>originator. A drawback of defining the receipt as a new data type is that it
>does not allow a place for this recipient originated information to be
>returned with the receipt. I would therefore submit that the receipt should
>therefore be an authenticated attribute of the signed data structure in the
>receipt not a new content. This would allow any new content to be returned
>as part of the receipt message in the content info of the signed data type
>in the normal way.
>
>To show my thoughts on these requirements may be reflected in the message,
>here is my suggestion at what the receipt request should look like.
>
>ReceiptRequest ::= SEQUENCE {
>            reciptType ::= BIT STRING {
>                       delivery                     (0),
>                       read                         (1),
>                       acknowledgement     (2),
                       actioned                   (3), }
>           recipientAdditionalInformation           BOOLEAN DEFAULT FALSE,
>           encapsulatedContentType                EncapsulatedContentType
>OPTIONAL,
>           signedContentIdentifier                     OCTET STRING,
>           receiptsFrom                                   ReceiptsFrom,
>           receiptsTo                                       SEQUENCE (SIZE
>(1..ub-receiptsTo))
>                                       OF GeneralNames OPTIONAL }
>           ub-receiptsTo INTEGER ::= 16
>
>Receipt := SEQUENCE {
>    reciptType ::= BIT STRING {
>                       delivery                     (0),
>                       read                         (1),
>                       acknowledgement     (2),
>                       actioned                   (3), }
>    encapsulatedContentType        EncapsulatedContentType OPTIONAL,
>    signedContentIdentifier        OCTET STRING,
>    originatorSignatureValue       OCTET STRING }
>
>Trevor
>
>> -----Original Message-----
>> From:	[email-masked] [SMTP:[email-masked]]
>> Sent:	Wednesday, November 05, 1997 11:48 PM
>> To:	[email-masked]
>> Subject:	ESS-00 Multiple Signed Receipts Issue
>> 
>> All,
>> 
>> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>> describes the process of an originator requesting signed receipts and a
>> recipient returning signed receipts.  There can be multiple SignerInfos
>> present within a SignedData object.  Each SignerInfo can include
>> authenticatedAttributes.  Therefore, a single SignedData object may
>> include
>> multiple SignerInfos each of which include a receiptRequest attribute.  I
>> believe that this should be allowed and should be documented in the ESS.
>> 
>> 
>> For example, if an originator desires to send a signed message requesting
>> signed receipts to a set of users composed of RSA-only and DSA-only users.
>> The originator's software can include one SignerInfo that includes an RSA
>> signature value and a receiptRequest attribute.  The same SignedData
>> object
>> could include another SignerInfo that includes a DSA signature value and a
>> receiptRequest attribute.  In this example, the RSA-capable recipients
>> would
>> return an RSA signed receipt to the originator and the DSA-capable
>> recipients would return a DSA signed receipt to the originator.
>> 
>> I believe that the general processing rules in ESS should state that a
>> receiving agent should build a signed receipt for each SignerInfo in the
>> SignedData object for which it verifies the signature and which requests a
>> signed receipt.  This may result in multiple signed receipts being
>> constructed and returned for a single SignedData object. 
>> 
>> I also believe that we should add a restriction that only one
>> receiptRequest
>> attribute can be included in the authenticatedAttributes of a SignerInfo.
>> 
>> I will include specific comments to ESS-00 in a follow-up message, but I
>> wanted to raise this issue separately because I beleive that it deserves
>> special attention.
>> 
>> ================================
>> John Pawling   
>> [email-masked]                             
>> J.G. Van Dyke & Associates, Inc.           
>> ================================
>> 
>

From: Trevor Freeman <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: ESS-00 Multiple Signed Receipts Issue
Date: Fri, 7 Nov 1997 07:25:39 -0800 
Sender: [email-masked]

I have a couple of related issues with signed receipts. 
The signed receipt process as outlined only considers a single type of
receipt. If fact there are more that one type of receipt. Examples of these
types would be
	A message has been delved to a mail box (but not opened).
	A message has been opened
	The recipient acknowledges they have read (and hopefully understood)
the message
	The recipient has actioned the message
Some of these receipts may mandate recipient intervention, such as
acknowledgement and actioned. You may require different receipt types from
different people, therefore I would envisage the requirement for multiple
receipt requests to be contained within the authenticated attributes of a
single message, with different users being asked for different types of
receipt.

Another requirement of the originator is that they may require some
additional information from the recipient to be returned as part of the
receipt. This additional content may be considered mandatory by the
originator. A drawback of defining the receipt as a new data type is that it
does not allow a place for this recipient originated information to be
returned with the receipt. I would therefore submit that the receipt should
therefore be an authenticated attribute of the signed data structure in the
receipt not a new content. This would allow any new content to be returned
as part of the receipt message in the content info of the signed data type
in the normal way.

To show my thoughts on these requirements may be reflected in the message,
here is my suggestion at what the receipt request should look like.

ReceiptRequest ::= SEQUENCE {
            reciptType ::= BIT STRING {
                       delivery                     (0),
                       read                         (1),
                       acknowledgement     (2),
                       actioned                   (3), }
           recipientAdditionalInformation           BOOLEAN DEFAULT FALSE,
           encapsulatedContentType                EncapsulatedContentType
OPTIONAL,
           signedContentIdentifier                     OCTET STRING,
           receiptsFrom                                   ReceiptsFrom,
           receiptsTo                                       SEQUENCE (SIZE
(1..ub-receiptsTo))
                                       OF GeneralNames OPTIONAL }
           ub-receiptsTo INTEGER ::= 16

Receipt := SEQUENCE {
    reciptType ::= BIT STRING {
                       delivery                     (0),
                       read                         (1),
                       acknowledgement     (2),
                       actioned                   (3), }
    encapsulatedContentType        EncapsulatedContentType OPTIONAL,
    signedContentIdentifier        OCTET STRING,
    originatorSignatureValue       OCTET STRING }

Trevor

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Wednesday, November 05, 1997 11:48 PM
> To:	[email-masked]
> Subject:	ESS-00 Multiple Signed Receipts Issue
> 
> All,
> 
> The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
> describes the process of an originator requesting signed receipts and a
> recipient returning signed receipts.  There can be multiple SignerInfos
> present within a SignedData object.  Each SignerInfo can include
> authenticatedAttributes.  Therefore, a single SignedData object may
> include
> multiple SignerInfos each of which include a receiptRequest attribute.  I
> believe that this should be allowed and should be documented in the ESS.
> 
> 
> For example, if an originator desires to send a signed message requesting
> signed receipts to a set of users composed of RSA-only and DSA-only users.
> The originator's software can include one SignerInfo that includes an RSA
> signature value and a receiptRequest attribute.  The same SignedData
> object
> could include another SignerInfo that includes a DSA signature value and a
> receiptRequest attribute.  In this example, the RSA-capable recipients
> would
> return an RSA signed receipt to the originator and the DSA-capable
> recipients would return a DSA signed receipt to the originator.
> 
> I believe that the general processing rules in ESS should state that a
> receiving agent should build a signed receipt for each SignerInfo in the
> SignedData object for which it verifies the signature and which requests a
> signed receipt.  This may result in multiple signed receipts being
> constructed and returned for a single SignedData object. 
> 
> I also believe that we should add a restriction that only one
> receiptRequest
> attribute can be included in the authenticatedAttributes of a SignerInfo.
> 
> I will include specific comments to ESS-00 in a follow-up message, but I
> wanted to raise this issue separately because I beleive that it deserves
> special attention.
> 
> ================================
> John Pawling   
> [email-masked]                             
> J.G. Van Dyke & Associates, Inc.           
> ================================
> 

From: Scott Hollenbeck <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Comments To ESS-00
Date: Fri, 7 Nov 1997 05:57:20 PST
Sender: [email-masked]

-----Original Message-----
From:	Phillip H. Griffin [SMTP:[email-masked]]
Sent:	Tuesday, November 04, 1997 4:14 PM
To:	[email-masked]
Subject:	Re: Comments To ESS-00

The reference to DirectoryString {}, a parameterized type 
as defined in  X.683, is missing a parameter in ...

  ContentHints ::= SEQUENCE {
     contentDescription  DirectoryString OPTIONAL,
     receipt             BOOLEAN DEFAULT FALSE 
  }
 
and should contain an integer value, such as in...

  ContentHints ::= SEQUENCE {
     contentDescription  DirectoryString { ub-conDesc } OPTIONAL,
     receipt             BOOLEAN DEFAULT FALSE 
  }

  ub-conDesc INTEGER ::= 72

Phil

[SAH]  Phil is correct.  The value we've used in the MSP world for
a maximum content description length is 128 decimal.  We do need
to modify the ContentHints description and add an INTEGER to bound
the size, but using 128 as the upper bound:

  ub-conDesc INTEGER ::= 128

Scott Hollenbeck
Xerox Corporation

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Certificate request format (was RE: S/MIME V3 Msg Spec Comments )
Date: Thu, 6 Nov 1997 14:54:39 -0800
Sender: [email-masked]

On Thursday, November 06, 1997 12:05 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> Given that this document describes the IETF version of S/MIME, I think
> *also* is the wrong word.  The S/MIME v3 spec should define how to create
> certification requests using the IETF Certificate Management Protocol,
> period.  PKCS #10-format requests are included as an option within CMP.

I agree -- since the alliance is expressly towards PKIX, then we should
do this.

If we just define the use of p10cr for the purpose of requesting a
certificate, would that be adequate for Diffie-Hellman and friends?  Are
there any other ways of requesting that are useful to S/MIME that aren't
achievable using PKCS #10 in CMP?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 6 Nov 1997 17:12:15 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-00 Comments
Cc: [email-masked]
Sender: [email-masked]

All,

I like Russ' paragraph in the enclosed message.  Russ stated: "Both
SignerInfos can contain the same receiptRequest attribute."  Does this mean
MUST or SHOULD?  I could think of some bizarre scenarios in which different
signers may wish to require that signed receipts be sent to specific
entities, etc.  However, stating "All SignerInfos MUST contain the same
receiptRequest attribute." would simplify processing.  I could go either way. 

I agree that a similar paragraph could be applied to the multiple
SecurityLabel and MLExpansionHistory attributes with the exception that we
are requiring that those attributes MUST be identical within a SignedData
object. 

Russ stated:
>Should we also have a warning here about the receipt policy in the
>mlExpansionHistory of the outer signed-data?

I believe that warning is already covered in ESS-00 Section 2.3.

- John Pawling

At 03:28 PM 11/6/97 -0500, Russ Housley wrote:
>John:
>
>See a few comments below.
>
>>10) Sec 2.2: Please add as last para:
>>
>>"There can be multiple SignerInfos present within a SignedData object.  Each
>>SignerInfo can include authenticatedAttributes.  Therefore, the syntax
>>allows a single SignedData object to include multiple SignerInfos each of
>>which could include a receiptRequest attribute.   For example, if an
>>originator desires to send a signed message requesting signed receipts to a
>>set of users composed of RSA-only and DSA-only users.  The originator's
>>software can include one SignerInfo that includes an RSA signature value and
>>a receiptRequest attribute.  The same SignedData object could include
>>another SignerInfo that includes a DSA signature value and a receiptRequest
>>attribute.  In this example, the RSA-capable recipients should return an RSA
>>signed receipt to the originator and the DSA-capable recipients should
>>return a DSA signed receipt to the originator."
>
>I like the thrust of your paragraph, but prefer a slightly different
>approach.  Does this make all of your points?
>
>"There can be multiple SignerInfos within a SignedData object.  Each
>SignerInfo may include authenticatedAttributes.  Therefore, a single
>SignedData object may include multiple SignerInfos each with a
>receiptRequest attribute.   For example, an originator can send a signed
>message with two SignerInfos, one containing a DSS signature and the other
>containing a RSA signature.  Both SignerInfos can contain the same
>receiptRequest attribute.  Each recipient should return one signed receipt."
>
>If you like my paragraph, then similar words should be used in for comments
>32 and 36.
>
>
>>11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
>>examine the authenticatedAttributes field of the innermost SignerInfo object
>>to determine if a receipt is requested." To "Processing software SHOULD
>>examine the authenticatedAttributes field of each of the SignerInfos for
>>which it verifies a signature in the innermost signedData object to
>>determine if a receipt is requested.  A receiving agent SHOULD build a
>>signed receipt for each SignerInfo in the SignedData object for which it
>>verifies the signature and which requests a signed receipt.  This may result
>>in multiple signed receipts being constructed and sent for a single
>>SignedData object."
>
>Should we also have a warning here about the receipt policy in the
>mlExpansionHistory of the outer signed-data?
>
>
>Russ
>

Date: Thu, 6 Nov 1997 16:57:33 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-00 Security Labels Issue
Cc: [email-masked]
Sender: [email-masked]

All,

I agree with Russ.

- John Pawling

At 04:24 PM 11/6/97 -0500, Russ Housley wrote:
>I agree with John.  However, we need to add a bit of complexity.  All of
>the security labels in the outer SignedData must match each other.  All of
>the security labels in the inner SignedData must match each other.  The
>security labels in the outer SignedData and the inner SignedData will
>probably not match.
>
>Russ
>
>At 01:39 PM 11/6/97 -0500, John Pawling wrote:
>>All,
>>
>>I am re-sending this because it was not included in Paul's summary message.
>>
>>The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>>describes the process of including security label attributes in a SignedData
>>SignerInfo authenticatedAttributes.  There can be multiple SignerInfos
>>present within a SignedData object.  Each SignerInfo can include
>>authenticatedAttributes.  Therefore, a single SignedData object may include
>>multiple SignerInfos each of which may include a securityLabel attribute.  I
>>recommend that multiple security labels should be allowed in a single
>>signedData object (please read the entire message before judging the
>>proposal).    
>>
>>For example, if an originator desires to send a signed message including a
>>security label to a set of users composed of RSA-only and DSA-only users.
>>The originator's software can include one SignerInfo that includes an RSA
>>signature value and a securityLabel attribute.  The same SignedData object
>>could include another SignerInfo that includes a DSA signature value and a
>>securityLabel attribute.  In this example, the RSA-capable recipients would
>>process the security label in the RSA-signed signerInfo and the DSA-capable
>>recipients would process the security label in the DSA-signed signerInfo.
>>This is true because a recipient should only process a securityLabel
>>attribute if the recipient can verify the signature of the SignerInfo which
>>covers the securityLabel attribute.  A recipient should not use a security
>>label which she can't authenticate.
>>
>>If multiple security labels are allowed in a signedData object, then we may
>>want to define some additional rules such as:
>>
>>1) All security labels included in a SignedData object must be identical.
>>(Note that this would limit the flexibility, but also limit the complexity
>>of constructing and processing security labels.)
>>
>>2) There can't be multiple SignerInfos containing the same
>>signatureAlgorithm that all include securityLabels.  In other words, there
>>can only be one securityLabel per signatureAlgorithm applied to the
>>SignedData.  (Note that this would limit the flexibility, but also limit the
>>complexity of constructing and processing security labels.)
>>
>>3) A receiving agent should process the securityLabel attribute, if present,
>>in each SignerInfo in the SignedData object for which it verifies the
>>signature.  This may result in the receiving agent processing multiple
>>security labels included in a single SignedData object.  If we adopt the
>>rule that all security labels must be identical, then this would imply that
>>the receiving application would perform access control based on the first
>>securityLabel that it encounters in a SignerInfo that it can verify and then
>>simply ensure that all other securityLabels are identical to the first one
>>encountered. 
>>
>>
>>Another alternative would be to prohibit multiple security labels in a
>>SignedData object.  If this solution is selected, then the sending agent
>>would need to check every SignerInfo that has already been constructed for
>>the SignedData to ensure that a securityLabel attribute has not already been
>>included.  If this solution is selected, then the receiving agent would need
>>to search every SignerInfo to determine if a securityLabel attribute is
>>present.  The problem with this alternative is that a receiving agent should
>>not process a securityLabel attribute unless it has been authenticated, so
>>if the receiving agent obtains a securityLabel from a signerInfo for which
>>it can't verify the signature, then it can't authenticate the security
>>label, so it should not use it.  This would happen in the aforementioned
>>example if only one securityLabel were allowed in the SignedData object.
>>The security label would be included in either the RSA-signed SignerInfo or
>>DSA-signed signerInfo, but not both.  For example, if the label was included
>>in the RSA-signed SignerInfo, then the DSA-only recipient wouldn't be able
>>to verify the signature covering the securityLabel attribute.
>>
>>
>>I will include specific comments to ESS-00 in a follow-up message, but I
>>wanted to raise this issue separately because I believe that it deserves
>>special attention.
>>
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>================================
>>
>>
>>
>

Date: Thu, 6 Nov 1997 16:56:19 -0500
To: Russ Housley <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: ESS-00 ML Expansion History Issue
Cc: [email-masked]
Sender: [email-masked]

Russ,

Yes, that is the gist of my message.

- John

At 04:26 PM 11/6/97 -0500, Russ Housley wrote:
>John:
>
>I think that you are saying that in the outer SignedData, if the
>mlExpansionHistory is present in one SignerInfo, then it must be present in
>all of them. And, it must be the same in each.
>
>If this is your message, then I agree.
>
>Russ
>
> At 01:40 PM 11/6/97 -0500, John Pawling wrote:
>>All,
>>
>>I am also re-sending this because it was not included in Paul's summary
>message.
>>
>>The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>>describes the process of a Mail List Agent (MLA) including a Mail List (ML)
>>Expansion History attribute in a SignedData object and a receiving agent
>>processing that attribute.  A single SignedData object can include multiple
>>SignerInfos each of which could include a ML Expansion History attribute.  I
>>believe that this should be allowed and should be documented in the ESS.    
>>
>>For example, if an MLA needs to relay a message to a ML composed of RSA-only
>>and DSA-only users.  The MLA can include one SignerInfo that includes an RSA
>>signature value and a MLExpansionHistory attribute.  The same SignedData
>>object could include another SignerInfo that includes a DSA signature value
>>and a MLExpansionHistory attribute.  In this example, the RSA-capable ML
>>recipients would process the MLExpansionHistory attribute in the RSA-signed
>>signerInfo and the DSA-capable ML recipients would process the
>>MLExpansionHistory attribute in the DSA-signed signerInfo.  This is true
>>because a recipient should only process a MLExpansionHistory attribute if
>>the recipient can verify the signature of the SignerInfo which covers the
>>attribute.  A recipient should not use an MLExpansionHistory attribute which
>>she can't authenticate.
>>
>>If multiple MLExpansionHistory attributes are allowed in a signedData
>>object, then we may want to define some additional rules such as:
>>
>>1) All MLExpansionHistory attributes included in a SignedData object must be
>>identical. 
>>
>>2) There can't be multiple SignerInfos containing the same
>>signatureAlgorithm that all include MLExpansionHistory attributes.  In other
>>words, there can only be one MLExpansionHistory attribute per
>>signatureAlgorithm applied to the SignedData.  
>>
>>3) A receiving agent should process the MLExpansionHistory attribute, if
>>present, in each SignerInfo in the SignedData object for which it verifies
>>the signature.  This may result in the receiving agent processing multiple
>>MLExpansionHistory attributes included in a single SignedData object.  If we
>>adopt the rule that all MLExpansionHistory attributes must be identical,
>>then this would imply that the receiving application would process the first
>>MLExpansionHistory attribute that it encounters in a SignerInfo that it can
>>verify and then simply ensure that all other MLExpansionHistory attributes
>>are identical to the first one encountered. 
>>
>>I also believe that we should add a restriction that only one
>>MLExpansionHistory attribute can be included in the authenticatedAttributes
>>of a SignerInfo.
>>
>>I will include specific comments to ESS-00 in a follow-up message, but I
>>wanted to raise this issue separately because I believe that it deserves
>>special attention.
>>
>>================================
>>John Pawling   
>>[email-masked]                             
>>J.G. Van Dyke & Associates, Inc.           
>>================================
>>
>>
>>
>

Date: Thu, 06 Nov 1997 16:26:41 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS-00 ML Expansion History Issue
Cc: [email-masked]
Sender: [email-masked]

John:

I think that you are saying that in the outer SignedData, if the
mlExpansionHistory is present in one SignerInfo, then it must be present in
all of them. And, it must be the same in each.

If this is your message, then I agree.

Russ

 At 01:40 PM 11/6/97 -0500, John Pawling wrote:
>All,
>
>I am also re-sending this because it was not included in Paul's summary
message.
>
>The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>describes the process of a Mail List Agent (MLA) including a Mail List (ML)
>Expansion History attribute in a SignedData object and a receiving agent
>processing that attribute.  A single SignedData object can include multiple
>SignerInfos each of which could include a ML Expansion History attribute.  I
>believe that this should be allowed and should be documented in the ESS.    
>
>For example, if an MLA needs to relay a message to a ML composed of RSA-only
>and DSA-only users.  The MLA can include one SignerInfo that includes an RSA
>signature value and a MLExpansionHistory attribute.  The same SignedData
>object could include another SignerInfo that includes a DSA signature value
>and a MLExpansionHistory attribute.  In this example, the RSA-capable ML
>recipients would process the MLExpansionHistory attribute in the RSA-signed
>signerInfo and the DSA-capable ML recipients would process the
>MLExpansionHistory attribute in the DSA-signed signerInfo.  This is true
>because a recipient should only process a MLExpansionHistory attribute if
>the recipient can verify the signature of the SignerInfo which covers the
>attribute.  A recipient should not use an MLExpansionHistory attribute which
>she can't authenticate.
>
>If multiple MLExpansionHistory attributes are allowed in a signedData
>object, then we may want to define some additional rules such as:
>
>1) All MLExpansionHistory attributes included in a SignedData object must be
>identical. 
>
>2) There can't be multiple SignerInfos containing the same
>signatureAlgorithm that all include MLExpansionHistory attributes.  In other
>words, there can only be one MLExpansionHistory attribute per
>signatureAlgorithm applied to the SignedData.  
>
>3) A receiving agent should process the MLExpansionHistory attribute, if
>present, in each SignerInfo in the SignedData object for which it verifies
>the signature.  This may result in the receiving agent processing multiple
>MLExpansionHistory attributes included in a single SignedData object.  If we
>adopt the rule that all MLExpansionHistory attributes must be identical,
>then this would imply that the receiving application would process the first
>MLExpansionHistory attribute that it encounters in a SignerInfo that it can
>verify and then simply ensure that all other MLExpansionHistory attributes
>are identical to the first one encountered. 
>
>I also believe that we should add a restriction that only one
>MLExpansionHistory attribute can be included in the authenticatedAttributes
>of a SignerInfo.
>
>I will include specific comments to ESS-00 in a follow-up message, but I
>wanted to raise this issue separately because I believe that it deserves
>special attention.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>

Date: Thu, 06 Nov 1997 16:24:08 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS-00 Security Labels Issue
Cc: [email-masked]
Sender: [email-masked]

I agree with John.  However, we need to add a bit of complexity.  All of
the security labels in the outer SignedData must match each other.  All of
the security labels in the inner SignedData must match each other.  The
security labels in the outer SignedData and the inner SignedData will
probably not match.

Russ

At 01:39 PM 11/6/97 -0500, John Pawling wrote:
>All,
>
>I am re-sending this because it was not included in Paul's summary message.
>
>The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
>describes the process of including security label attributes in a SignedData
>SignerInfo authenticatedAttributes.  There can be multiple SignerInfos
>present within a SignedData object.  Each SignerInfo can include
>authenticatedAttributes.  Therefore, a single SignedData object may include
>multiple SignerInfos each of which may include a securityLabel attribute.  I
>recommend that multiple security labels should be allowed in a single
>signedData object (please read the entire message before judging the
>proposal).    
>
>For example, if an originator desires to send a signed message including a
>security label to a set of users composed of RSA-only and DSA-only users.
>The originator's software can include one SignerInfo that includes an RSA
>signature value and a securityLabel attribute.  The same SignedData object
>could include another SignerInfo that includes a DSA signature value and a
>securityLabel attribute.  In this example, the RSA-capable recipients would
>process the security label in the RSA-signed signerInfo and the DSA-capable
>recipients would process the security label in the DSA-signed signerInfo.
>This is true because a recipient should only process a securityLabel
>attribute if the recipient can verify the signature of the SignerInfo which
>covers the securityLabel attribute.  A recipient should not use a security
>label which she can't authenticate.
>
>If multiple security labels are allowed in a signedData object, then we may
>want to define some additional rules such as:
>
>1) All security labels included in a SignedData object must be identical.
>(Note that this would limit the flexibility, but also limit the complexity
>of constructing and processing security labels.)
>
>2) There can't be multiple SignerInfos containing the same
>signatureAlgorithm that all include securityLabels.  In other words, there
>can only be one securityLabel per signatureAlgorithm applied to the
>SignedData.  (Note that this would limit the flexibility, but also limit the
>complexity of constructing and processing security labels.)
>
>3) A receiving agent should process the securityLabel attribute, if present,
>in each SignerInfo in the SignedData object for which it verifies the
>signature.  This may result in the receiving agent processing multiple
>security labels included in a single SignedData object.  If we adopt the
>rule that all security labels must be identical, then this would imply that
>the receiving application would perform access control based on the first
>securityLabel that it encounters in a SignerInfo that it can verify and then
>simply ensure that all other securityLabels are identical to the first one
>encountered. 
>
>
>Another alternative would be to prohibit multiple security labels in a
>SignedData object.  If this solution is selected, then the sending agent
>would need to check every SignerInfo that has already been constructed for
>the SignedData to ensure that a securityLabel attribute has not already been
>included.  If this solution is selected, then the receiving agent would need
>to search every SignerInfo to determine if a securityLabel attribute is
>present.  The problem with this alternative is that a receiving agent should
>not process a securityLabel attribute unless it has been authenticated, so
>if the receiving agent obtains a securityLabel from a signerInfo for which
>it can't verify the signature, then it can't authenticate the security
>label, so it should not use it.  This would happen in the aforementioned
>example if only one securityLabel were allowed in the SignedData object.
>The security label would be included in either the RSA-signed SignerInfo or
>DSA-signed signerInfo, but not both.  For example, if the label was included
>in the RSA-signed SignerInfo, then the DSA-only recipient wouldn't be able
>to verify the signature covering the securityLabel attribute.
>
>
>I will include specific comments to ESS-00 in a follow-up message, but I
>wanted to raise this issue separately because I believe that it deserves
>special attention.
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>

Date: Thu, 06 Nov 1997 15:28:22 -0500
To: [email-masked] (John Pawling)
From: Russ Housley <[email-masked]>
Subject: Re: ESS-00 Comments
Cc: [email-masked]
Sender: [email-masked]

John:

See a few comments below.

>10) Sec 2.2: Please add as last para:
>
>"There can be multiple SignerInfos present within a SignedData object.  Each
>SignerInfo can include authenticatedAttributes.  Therefore, the syntax
>allows a single SignedData object to include multiple SignerInfos each of
>which could include a receiptRequest attribute.   For example, if an
>originator desires to send a signed message requesting signed receipts to a
>set of users composed of RSA-only and DSA-only users.  The originator's
>software can include one SignerInfo that includes an RSA signature value and
>a receiptRequest attribute.  The same SignedData object could include
>another SignerInfo that includes a DSA signature value and a receiptRequest
>attribute.  In this example, the RSA-capable recipients should return an RSA
>signed receipt to the originator and the DSA-capable recipients should
>return a DSA signed receipt to the originator."

I like the thrust of your paragraph, but prefer a slightly different
approach.  Does this make all of your points?

"There can be multiple SignerInfos within a SignedData object.  Each
SignerInfo may include authenticatedAttributes.  Therefore, a single
SignedData object may include multiple SignerInfos each with a
receiptRequest attribute.   For example, an originator can send a signed
message with two SignerInfos, one containing a DSS signature and the other
containing a RSA signature.  Both SignerInfos can contain the same
receiptRequest attribute.  Each recipient should return one signed receipt."

If you like my paragraph, then similar words should be used in for comments
32 and 36.

>11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
>examine the authenticatedAttributes field of the innermost SignerInfo object
>to determine if a receipt is requested." To "Processing software SHOULD
>examine the authenticatedAttributes field of each of the SignerInfos for
>which it verifies a signature in the innermost signedData object to
>determine if a receipt is requested.  A receiving agent SHOULD build a
>signed receipt for each SignerInfo in the SignedData object for which it
>verifies the signature and which requests a signed receipt.  This may result
>in multiple signed receipts being constructed and sent for a single
>SignedData object."

Should we also have a warning here about the receipt policy in the
mlExpansionHistory of the outer signed-data?

Russ

Date: Thu, 6 Nov 1997 15:04:37 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: S/MIME V3 Msg Spec Comments
Sender: [email-masked]

> From: [email-masked] (John Pawling)
> 
> 1) The spec "defines how to create certification requests that conform to
> PKCS #10 [PKCS-10], and the application/pkcs10 MIME type for transporting
> those requests."  Shouldn't the spec also define how to create certification
> requests that conform to the PKIX Certificate Management Protocol spec?

Given that this document describes the IETF version of S/MIME, I think
*also* is the wrong word.  The S/MIME v3 spec should define how to create
certification requests using the IETF Certificate Management Protocol,
period.  PKCS #10-format requests are included as an option within CMP.

Date: Thu, 6 Nov 1997 14:48:51 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: S/MIME V3 Msg Spec Comments
Sender: [email-masked]

All,

IMHO, Blake did an outstanding job of drafting the "4 Nov 97 S/MIME Version
3 Message Specification" document.  I have a few comments:

1) The spec "defines how to create certification requests that conform to
PKCS #10 [PKCS-10], and the application/pkcs10 MIME type for transporting
those requests."  Shouldn't the spec also define how to create certification
requests that conform to the PKIX Certificate Management Protocol spec?

2) Sec 2.2, I am not sure what you mean by "DH/DSS" as the "MUST support"
DigestEncryptionAlgorithmIdentifier.  The PKIX X.509 Certificate and CRL
Profile (aka PKIX I), Section 7.2.2, recommends using the Digital Signature
Algorithm (DSA) OID (and asscoiated ASN.1 syntaxes) defined in the X9.57
specification as follows: id-dsa-with-sha1 ID  ::=  {iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }.  The problem with this OID is that
combines the SHA-1 and DSA into one value.  The X9.57 id-dsa OID {1 2 840
10040 4 1} is intended for use in the X.509 Certificate subjectPublicKeyInfo
algorithmIdentifier field to identify a DSA public key, but I assume that it
could also be used as a DigestEncryptionAlgorithmIdentifier (with parameters
absent).  I recommend using id-dsa with text explaining that the algorithm
parameters will always be absent.

3) Sec 2.6.1-2.6.3: IMHO, the text regarding the process by which the
applications chooses the encryption algorithm to use to encrypt data was
useful and should be reinstated with the few text changes required to make
RC2 optional and 3DES the default.

4) Sec 4.1, 1rst para, 1rst sent: Please delete "RSA" from: "An S/MIME agent
or some related administrative utility or function MUST be capable of
generating RSA key pairs on behalf of the user."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 6 Nov 1997 13:40:11 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 ML Expansion History Issue
Sender: [email-masked]

All,

I am also re-sending this because it was not included in Paul's summary message.

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of a Mail List Agent (MLA) including a Mail List (ML)
Expansion History attribute in a SignedData object and a receiving agent
processing that attribute.  A single SignedData object can include multiple
SignerInfos each of which could include a ML Expansion History attribute.  I
believe that this should be allowed and should be documented in the ESS.    

For example, if an MLA needs to relay a message to a ML composed of RSA-only
and DSA-only users.  The MLA can include one SignerInfo that includes an RSA
signature value and a MLExpansionHistory attribute.  The same SignedData
object could include another SignerInfo that includes a DSA signature value
and a MLExpansionHistory attribute.  In this example, the RSA-capable ML
recipients would process the MLExpansionHistory attribute in the RSA-signed
signerInfo and the DSA-capable ML recipients would process the
MLExpansionHistory attribute in the DSA-signed signerInfo.  This is true
because a recipient should only process a MLExpansionHistory attribute if
the recipient can verify the signature of the SignerInfo which covers the
attribute.  A recipient should not use an MLExpansionHistory attribute which
she can't authenticate.

If multiple MLExpansionHistory attributes are allowed in a signedData
object, then we may want to define some additional rules such as:

1) All MLExpansionHistory attributes included in a SignedData object must be
identical. 

2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include MLExpansionHistory attributes.  In other
words, there can only be one MLExpansionHistory attribute per
signatureAlgorithm applied to the SignedData.  

3) A receiving agent should process the MLExpansionHistory attribute, if
present, in each SignerInfo in the SignedData object for which it verifies
the signature.  This may result in the receiving agent processing multiple
MLExpansionHistory attributes included in a single SignedData object.  If we
adopt the rule that all MLExpansionHistory attributes must be identical,
then this would imply that the receiving application would process the first
MLExpansionHistory attribute that it encounters in a SignerInfo that it can
verify and then simply ensure that all other MLExpansionHistory attributes
are identical to the first one encountered. 

I also believe that we should add a restriction that only one
MLExpansionHistory attribute can be included in the authenticatedAttributes
of a SignerInfo.

I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I believe that it deserves
special attention.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 6 Nov 1997 13:39:42 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 Security Labels Issue
Sender: [email-masked]

All,

I am re-sending this because it was not included in Paul's summary message.

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of including security label attributes in a SignedData
SignerInfo authenticatedAttributes.  There can be multiple SignerInfos
present within a SignedData object.  Each SignerInfo can include
authenticatedAttributes.  Therefore, a single SignedData object may include
multiple SignerInfos each of which may include a securityLabel attribute.  I
recommend that multiple security labels should be allowed in a single
signedData object (please read the entire message before judging the
proposal).    

For example, if an originator desires to send a signed message including a
security label to a set of users composed of RSA-only and DSA-only users.
The originator's software can include one SignerInfo that includes an RSA
signature value and a securityLabel attribute.  The same SignedData object
could include another SignerInfo that includes a DSA signature value and a
securityLabel attribute.  In this example, the RSA-capable recipients would
process the security label in the RSA-signed signerInfo and the DSA-capable
recipients would process the security label in the DSA-signed signerInfo.
This is true because a recipient should only process a securityLabel
attribute if the recipient can verify the signature of the SignerInfo which
covers the securityLabel attribute.  A recipient should not use a security
label which she can't authenticate.

If multiple security labels are allowed in a signedData object, then we may
want to define some additional rules such as:

1) All security labels included in a SignedData object must be identical.
(Note that this would limit the flexibility, but also limit the complexity
of constructing and processing security labels.)

2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include securityLabels.  In other words, there
can only be one securityLabel per signatureAlgorithm applied to the
SignedData.  (Note that this would limit the flexibility, but also limit the
complexity of constructing and processing security labels.)

3) A receiving agent should process the securityLabel attribute, if present,
in each SignerInfo in the SignedData object for which it verifies the
signature.  This may result in the receiving agent processing multiple
security labels included in a single SignedData object.  If we adopt the
rule that all security labels must be identical, then this would imply that
the receiving application would perform access control based on the first
securityLabel that it encounters in a SignerInfo that it can verify and then
simply ensure that all other securityLabels are identical to the first one
encountered. 

Another alternative would be to prohibit multiple security labels in a
SignedData object.  If this solution is selected, then the sending agent
would need to check every SignerInfo that has already been constructed for
the SignedData to ensure that a securityLabel attribute has not already been
included.  If this solution is selected, then the receiving agent would need
to search every SignerInfo to determine if a securityLabel attribute is
present.  The problem with this alternative is that a receiving agent should
not process a securityLabel attribute unless it has been authenticated, so
if the receiving agent obtains a securityLabel from a signerInfo for which
it can't verify the signature, then it can't authenticate the security
label, so it should not use it.  This would happen in the aforementioned
example if only one securityLabel were allowed in the SignedData object.
The security label would be included in either the RSA-signed SignerInfo or
DSA-signed signerInfo, but not both.  For example, if the label was included
in the RSA-signed SignerInfo, then the DSA-only recipient wouldn't be able
to verify the signature covering the securityLabel attribute.

I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I believe that it deserves
special attention.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 06 Nov 1997 09:54:13 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Post-looping resend of yesterday's messages
Sender: [email-masked]

Greetings. Well, that should teach those of use using antique broken
gateways to upgrade. :-) Because it was hard to follow what happened
yesterday, I've collected unrepeated copies of all of the messages and
reproduced them below.

Please do *not* reply to this message. Instead, if you want to reply to one
part of what was said, start a new thread with a descriptive subject line.
Doing this will greatly enhance the discussion. Thanks!

--Paul Hoffman, Director
--Internet Mail Consortium

==============================

Date: Wed, 5 Nov 1997 09:31:29 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
X-Sun-Charset: US-ASCII
Sender: [email-masked]

> From: "Phillip H. Griffin" <[email-masked]>
> 
> In all of the following OBJECT IDENTIFIER values, US is invalid
> since it does not begin with a lowercase letter. Same for S in
> SMIMECapabilities. 
> 
>   2.8 Receipt Request Syntax
> 
>   receiptRequest OBJECT IDENTIFIER ::=
>     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
>         SMIMECapabilities(15) 3}

I think a little common sense is required when interpreting capitalization
conventions.  Can you cite a reference that REQUIRES the initial letter
of OID arcs to be lower case?  And if you want to change US to uS, I think
you'll have to petition ISO, not the S/MIME working group - country codes
were defined long ago in a forum far far away.

It is helpful to have a convention that distinguishes between structure
element names (initial lower) and the syntax definitions they refer to
(initial upper).  But as far as I know, there is no ASN.1 module which
defines a syntax associated with any of the iso or joint country codes,
thus there is no danger of confusion or collision between name and
syntax.

Date: Wed, 05 Nov 1997 11:12:53 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
X-Mailer: Mozilla 3.0 (Win95; U)
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: "Phillip H. Griffin" <[email-masked]>
> >
> > In all of the following OBJECT IDENTIFIER values, US is invalid
> > since it does not begin with a lowercase letter. Same for S in
> > SMIMECapabilities.
> >
> >   2.8 Receipt Request Syntax
> >
> >   receiptRequest OBJECT IDENTIFIER ::=
> >     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> >         SMIMECapabilities(15) 3}
> 
> I think a little common sense is required when interpreting capitalization
> conventions.  Can you cite a reference that REQUIRES the initial letter
> of OID arcs to be lower case?  And if you want to change US to uS, I think
> you'll have to petition ISO, not the S/MIME working group - country codes
> were defined long ago in a forum far far away.

In the context of an ASN.1 value of type OBJECT IDENTIFIER, "us" 
really has nothing to do with country codes. It is merely an ASN.1
identifier, the name of some value. (ref below)

> 
> It is helpful to have a convention that distinguishes between structure
> element names (initial lower) and the syntax definitions they refer to
> (initial upper).  But as far as I know, there is no ASN.1 module which
> defines a syntax associated with any of the iso or joint country codes,
> thus there is no danger of confusion or collision between name and
> syntax.

X.680 provides the following definition of values of type OBJECT
IDENTIFIER. In the NameAndNumberForm, each arc has an ASN.1 identifier,
which must begin with a lowercase letter, followed by the constraint
notation applied to a number or a defined value. In the NameForm, just
a valid ASN.1 identifier is present...

  ObjectIdentifierType  ::= OBJECT IDENTIFIER

  ObjectIdentifierValue ::= "{" ObjIdComponentList "}"  |
               "{" DefinedValue ObjIdComponentList "}"

   ObjIdComponentList ::= ObjIdComponent |
                          ObjIdComponent ObjIdComponentList

   ObjIdComponent ::= NameForm   |
                      NumberForm |
                      NameAndNumberForm

   NameForm          ::= identifier

   NumberForm        ::= number | DefinedValue

   NameAndNumberForm ::= identifier "(" NumberForm ")"

Either "uS" or "us" is correct.

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
X-Mailer: ccMail Link to SMTP R6.0
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

Date: Wed, 5 Nov 1997 12:45:26 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
Cc: [email-masked]
X-Sun-Charset: US-ASCII
Sender: [email-masked]

> From: "Phillip H. Griffin" <[email-masked]>
> 
> X.680 provides the following definition of values of type OBJECT
> IDENTIFIER. In the NameAndNumberForm, each arc has an ASN.1 identifier,
> which must begin with a lowercase letter, ...

I stand corrected.  It's right there in black and white, X.680
section 9.3.

Learn something every day.  Thanks.

Date: Wed, 5 Nov 1997 14:06:14 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

Phil,

The X.411 SecurityLabel syntax is included in ESS-00 because it is an
international standard representation of security label and it is used by
many existing programs.  The X.411 SecurityLabel syntax includes
SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
with X.411, it should not be changed.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
>The type defined as
>
>  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
>                             SecurityCategory
>
>requires sorting under DER that would not be required if the
>type were defined as a SEQUENCE OF. 
>
>X.690, which defines DER restrictions in section 11, "Restrictions 
>on BER employed by both CER and DER", states that for components of
>type SET OF, "The encodings of the component values of a set-of 
>value shall appear in ascending order, the encodings being compared
>as octet strings."
>
>Under DER, with SEQUENCE OF, the sender can control the order
>of components, but with SET OF, the final sort requirement rules,
>and sometimes may add unanticipated overhead to message processing.
>It was primarily for this reason, the the SET specification is
>based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
>types like
>
>  Certificates ::= SEQUENCE OF Certificate
>
>and avoid sorting what (hopefully) might be efficiently
>organized certificate chains in SignedData. Same for the CRLs
>and Attributes definitions.
>
>Phil
>-- 
>Phillip H. Griffin         
>ASN.1-SET-Java-Security    Griffin Consulting
>[email-masked]        1625 Glenwood Avenue
>919.828.7114               Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>
>

Date: Wed, 5 Nov 1997 14:50:39 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: Scott Hollenbeck <[email-masked]>,
        "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments To ESS-00
Sender: [email-masked]

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 11:04 AM 11/4/97 PST, Scott Hollenbeck wrote:
>Thanks, Paul, for taking the draft document this far.  Let the fun begin!
>
>Section 1.3.4:
>The attribute names should reflect the name associated with the attribute
>OID, not the syntax of the attribute value.  In general, this means that
>the named attribute should begin with a lower case letter.  So, I suggest
>these changes:
>
>ContentHints -> contentHints
>ReceiptRequest -> receiptRequest
>SecurityLabel -> securityLabel
>
>Also, I don't believe that (signed?) ContentIdentifier and
>EncapsulatedContentType are intended to be used as attributes.  They're
>part of the receiptRequest attribute and are copied to a Receipt structure.
>If I missed something on this point then the OIDs for these "attributes" are
>missing...
>
>Section 2.10
>The last line of the DirectoryString definition includes an extra double
>quote character (") after the closing brace.
>
>Section 3.2
>An OID for the securityLabel attribute is missing.
>
>Section 4.3
>The syntax for EntityIdentifier is missing.  When I wrote the first cut
>at this text we put this definition in the EnvelopedData2 spec that Russ
>Housley was writing, but it ought to be included here for completeness.
>
>EntityIdentifier ::= CHOICE {
>  issuerAndSerialNumber  IssuerAndSerialNumber, -- From PKCS #7
>  subjectKeyIdentifier   KeyIdentifier }
>
>KeyIdentifier ::= OCTET STRING
>
>----->
>Scott Hollenbeck (mailto: [email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>
>

Date: Wed, 5 Nov 1997 14:58:42 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CMS-00 ASN.1 Module
Sender: [email-masked]

All,

An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
that consolidates all of the ASN.1 syntaxes defined throughout the spec.
For example, The OriginatorInfo SEQUENCE includes two tags that are marked
IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
is for all tags to be IMPLICIT.  This situation is resolved by including all
syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
That would mandate that all tags in the module are IMPLICIT.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: Scott Hollenbeck <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
Subject: RE: Comments To ESS-00
Date: Wed, 5 Nov 1997 12:05:32 PST
Sender: [email-masked]

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Wednesday, November 05, 1997 2:51 PM
To:	Scott Hollenbeck; 'IETF S/MIME'
Subject:	Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,
        "'Paul Hoffman (E-mail)'" <[email-masked]>
Subject: OIDs for ESS
Date: Wed, 5 Nov 1997 12:11:35 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
 4.0.993.5
X-WSS-ID: 187E0D7243180-187E0D7243181-01

receiptRequest, receipt, contentHints and mlExpansionHistory should all
be under the SMIME (pkcs-9 16) arc, not the SMIMECapabilities (pkcs-9
15) arc.

Paul, are you going to be managing the OIDS page at IMC with the new
SMIME arc on it also?  I'd say we can use the same page as the
SMIMECapabilities.  Russ has the current list, I believe.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>,
        "[email-masked]'"
 <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Date: Wed, 5 Nov 1997 12:12:29 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
 4.0.993.5
X-WSS-ID: 187E0CA443196-187E0CA443200-01
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 5 Nov 1997 15:23:51 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: Scott Hollenbeck <[email-masked]>,
        "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Comments To ESS-00
Sender: [email-masked]

All,

I agree with Scott's recommendations.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:05 PM 11/5/97 PST, Scott Hollenbeck wrote:
>-----Original Message-----
>From:	John Pawling [SMTP:[email-masked]]
>Sent:	Wednesday, November 05, 1997 2:51 PM
>To:	Scott Hollenbeck; 'IETF S/MIME'
>Subject:	Re: Comments To ESS-00
>
>All,
>
>I agree with all of Scott's comments, except that I strongly believe that
>the ContentIdentifier and EncapsulatedContentType attributes must be allowed
>to be used as attributes included in the authenticatedAttributes of a
>SignerInfo.  They are required to replicate the MSP signedContentIdentifier
>and encapsulatedContentType fields included in the MSP SignatureBlock
>SignatureInformation.  They are most useful in SignerInfos that do not
>request signed receipts.  I agree with Scott's comments that OIDs must be
>defined for these attributes.
>
>[SAH]  OK, now I recall where they came from.  That being the case,
>ContentIdentifier needs to be defined.  How about this:
>
>ContentIdentifier ::= OCTET STRING
>
>Then, the following should happen:
>
>Section 1.3.4
>Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
>to encapsulatedContentType to reference the to-be-defined OIDs.
>
>Section 2.8
>Change the definition of signedContentIdentifier from OCTET STRING to
>ContentIdentifier.
>
>I think that closes the loop.
>
>Scott
>

Date: Wed, 5 Nov 1997 15:25:13 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: "Blake Ramsdell" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

Blake,

Yes.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:12 PM 11/5/97 -0800, Blake Ramsdell wrote:
>On Wednesday, November 05, 1997 11:59 AM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> An ASN.1 module needs to be added to the "Cryptographic Message Syntax"
spec
>> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
>> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
>> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the
intent
>> is for all tags to be IMPLICIT.  This situation is resolved by including
all
>> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
>> That would mandate that all tags in the module are IMPLICIT.
>
>I think we need to do the same thing for ESS, right?
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Wed, 05 Nov 1997 16:00:18 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
X-Mailer: Mozilla 3.0 (Win95; U)
To: [email-masked]
Subject: ESS-00 Integers
Sender: [email-masked]

The following integer value definitions...

  ub-integer-options ::= 256
  ub-privacy-mark-length ::= 128
  ub-security-categories ::= 64

should be

  ub-integer-options INTEGER ::= 256
  ub-privacy-mark-length INTEGER ::= 128
  ub-security-categories INTEGER ::= 64

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Wed, 05 Nov 1997 16:20:57 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
X-Mailer: Mozilla 3.0 (Win95; U)
To: John Pawling <[email-masked]>
CC: [email-masked]
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
X-Mailer: ccMail Link to SMTP R6.0
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Wed, 5 Nov 1997 16:39:37 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comments To ESS-00 - SET OF
Cc: [email-masked]
Sender: [email-masked]

Phil,

IMHO, it is not worth the added complexity of defining a CHOICE for
SecurityCategories.  There is no way to predict how securityCategories will
be used within organizations' security policies, so I can't tell you that
they will always be small sets or easy to sort.  However, S/MIME-enabled
applications must be capable of implementing DER anyway, so I don't believe
that the securityCategories SET OF adds a new requirement.  If this were the
only occurrence of "SET" or "SET OF" in the required ASN.1 syntaxes, then I
would have a different opinion.  However, there are other occurrences of SET
and SET OF in syntaxes such as in the Attribute, RDN and GeneralName
ORAddress components.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 04:20 PM 11/5/97 -0500, [email-masked] wrote:
>John Pawling wrote:
>> 
>> Phil,
>> 
>> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
>> international standard representation of security label and it is used by
>> many existing programs.  The X.411 SecurityLabel syntax includes
>> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
>> with X.411, it should not be changed.
>> 
>> ================================
>> John Pawling
>> [email-masked]
>> J.G. Van Dyke & Associates, Inc.
>> ================================
>> 
>
>I agree that no change should be made that breaks backwards 
>compatibility, but it would be possible, if accompanied with 
>a change in version, to alter the definition to
>
>  SecurityCategories ::= CHOICE {
>    setOf  SET SIZE (1..ub-security-categories) OF
>                               SecurityCategory,
>    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
>                               SecurityCategory
>  }
>
>  ub-security-categories INTEGER ::= 64
>
>so that no additional tagging were needed to distinguish 
>between the two types. If typically the SET OF size is
>small and the data easy to sort, it probably wouldn't 
>be worth the effort.
>
>> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
>> >The type defined as
>> >
>> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
>> >                             SecurityCategory
>> >
>> >requires sorting under DER that would not be required if the
>> >type were defined as a SEQUENCE OF.
>> >
>> >X.690, which defines DER restrictions in section 11, "Restrictions
>> >on BER employed by both CER and DER", states that for components of
>> >type SET OF, "The encodings of the component values of a set-of
>> >value shall appear in ascending order, the encodings being compared
>> >as octet strings."
>> >
>> >Under DER, with SEQUENCE OF, the sender can control the order
>> >of components, but with SET OF, the final sort requirement rules,
>> >and sometimes may add unanticipated overhead to message processing.
>> >It was primarily for this reason, the the SET specification is
>> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
>> >types like
>> >
>> >  Certificates ::= SEQUENCE OF Certificate
>> >
>> >and avoid sorting what (hopefully) might be efficiently
>> >organized certificate chains in SignedData. Same for the CRLs
>> >and Attributes definitions.
>> >
>> >Phil
>
>Phil
>-- 
>Phillip H. Griffin         
>ASN.1-SET-Java-Security    Griffin Consulting
>[email-masked]        1625 Glenwood Avenue
>919.828.7114               Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>
>

Date: Wed, 5 Nov 1997 18:47:54 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 Multiple Signed Receipts Issue
Sender: [email-masked]

All,

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of an originator requesting signed receipts and a
recipient returning signed receipts.  There can be multiple SignerInfos
present within a SignedData object.  Each SignerInfo can include
authenticatedAttributes.  Therefore, a single SignedData object may include
multiple SignerInfos each of which include a receiptRequest attribute.  I
believe that this should be allowed and should be documented in the ESS.    

For example, if an originator desires to send a signed message requesting
signed receipts to a set of users composed of RSA-only and DSA-only users.
The originator's software can include one SignerInfo that includes an RSA
signature value and a receiptRequest attribute.  The same SignedData object
could include another SignerInfo that includes a DSA signature value and a
receiptRequest attribute.  In this example, the RSA-capable recipients would
return an RSA signed receipt to the originator and the DSA-capable
recipients would return a DSA signed receipt to the originator.

I believe that the general processing rules in ESS should state that a
receiving agent should build a signed receipt for each SignerInfo in the
SignedData object for which it verifies the signature and which requests a
signed receipt.  This may result in multiple signed receipts being
constructed and returned for a single SignedData object. 

I also believe that we should add a restriction that only one receiptRequest
attribute can be included in the authenticatedAttributes of a SignerInfo.

I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I beleive that it deserves
special attention.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME Version 3 Message Specification draft is now available
Date: Wed, 5 Nov 1997 16:22:23 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
 4.0.993.5
X-WSS-ID: 187FD24A1518-187FD24A1519-01
Sender: [email-masked]

The first draft of "S/MIME Version 3 Message Specification" is now
available at
<ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt> (Paul
will copy it to the IMC site later.  This draft describes the S/MIME v3
usage of the Cryptographic Message Syntax draft.  There is an appendix
with the changes from S/MIME v2.

Have at it.  Here are the open issues that I know about, and any insight
would be welcome.

Section 2.5.2 Add certs as an authenticatedAttribute
[DH] is undefined in section 2.3
[DH-DSS] is undefined in section 2.2
Need OIDs for Diffie-Hellman and Diffie-Hellman/DSS
Is the terminology correct for Diffie-Hellman for encryption vs.
signing?
What do we need to do for 4.1 in order to make it Diffie-Hellman?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 5 Nov 1997 19:52:00 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Very Sorry For the Looping
Sender: [email-masked]

All,

I apologize for the inconvenience caused by my company's mail system.  Our
system admin staff is working on this problem right now.  The ccMail gateway
at our company seems to be repeating the message that I sent.

Sorry,
John Pawling

>Return-Path: <[email-masked]>
>X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
>From: "Blake Ramsdell" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: FW: CMS-00 ASN.1 Module
>Date: Wed, 5 Nov 1997 16:05:40 -0800
>Return-Receipt-To: <[email-masked]>
>X-Wss-Id: 187FD65C1338-187FD65C1339-01
>
>You mail server seems to be freaking out a bit -- I have seen several
>copies of my message come through, with headers as follows:
>
>> Received: from host9.deming.com by cane.deming.com with SMTP (Microsoft
>Exchange Internet Mail Connector Version 4.0.993.5)
>> 	id Z3XTSAFN; Wed, 5 Nov 1997 15:55:30 -0800
>> Received: from 206.86.127.224 by cane.deming.com with SMTP (WorldSecure
>>  Server SMTP Relay v2.01); Wed, 05 Nov 97 15:55:29 -0800
>> X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
>> Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id
>>  PAA09991 for ietf-smime-bks; Wed, 5 Nov 1997 15:42:01 -0800 (PST)
>> Received: from mail3.access.digex.net (mail3.access.digex.net
>>  [205.197.247.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id
>>  PAA09987 for <[email-masked]>; Wed, 5 Nov 1997 15:41:57 -0800 (PST)
>> From: <[email-masked]>
>> Received: from apollo (apollo.jgvandyke.com [158.189.10.100]) by
>>  mail3.access.digex.net (8.8.5/8.8.5) with SMTP id SAA05572 for
>>  <[email-masked]>; Wed, 5 Nov 1997 18:41:52 -0500 (EST)
>> Received: from vda-gateway.jgvandyke.com by apollo (5.x/SMI-SVR4) id
>>  AA00951; Wed, 5 Nov 1997 18:55:50 -0500
>> Received: from POP3 Client by vda-gateway.jgvandyke.com (ccMail Link to
>>  SMTP R6.0) id AA878773376; Wed, 05 Nov 97 18:43:03 -0500
>> Message-ID: <[email-masked]>
>> X-Mailer: ccMail Link to SMTP R6.0
>> Date: Wed, 05 Nov 97 12:12:29 -0500
>> To: <[email-masked]>, <[email-masked]>
>> Subject: RE: CMS-00 ASN.1 Module
>> MIME-Version: 1.0
>> Sender: <[email-masked]>
>> Precedence: bulk
>> X-WSS-ID: 187FD8E41202-187FD8E41203-01
>> Content-Type: text/plain; 
>>  charset=us-ascii
>> Content-Transfer-Encoding: 7bit
>
>This seems to indicate that your ccMail gateway is doing something a
>little whacky with the message.
>
>Let me know if you have any insight.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>>-----Original Message-----
>>From:	Blake Ramsdell 
>>Sent:	Wednesday, November 05, 1997 9:12 AM
>>To:	[email-masked]; [email-masked]
>>Subject:	RE: CMS-00 ASN.1 Module
>>
>>
>>
>>
>>
>>On Wednesday, November 05, 1997 11:59 AM, [email-masked]
>>[SMTP:[email-masked]] wrote:
>>> An ASN.1 module needs to be added to the "Cryptographic Message Syntax"
>>>spec
>>> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
>>> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
>>> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the
>>>intent
>>> is for all tags to be IMPLICIT.  This situation is resolved by including
>>>all
>>> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
>>> That would mandate that all tags in the module are IMPLICIT.
>>
>>I think we need to do the same thing for ESS, right?
>>
>>Blake
>>--
>>Blake C. Ramsdell
>>Worldtalk Corporation
>>For current info, check http://www.deming.com/users/blaker
>>Voice +1 425 882 8861 x103  Fax +1 425 882 8060

X-Sender: [email-masked]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 05 Nov 1997 17:57:31 -0800
To: "Blake Ramsdell" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME Version 3 Message Specification draft is now
  available
Sender: [email-masked]

>The first draft of "S/MIME Version 3 Message Specification" is now
>available at
><ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt> (Paul
>will copy it to the IMC site later.

Jeez, give me a minute or two to get it up on the IMC site! :-) It's now
available as <http://www.imc.org/draft-ramsdell-smime-msg>. For those of
you new to the IMC way of doing things, we don't include the "-00.txt" in
the names. When a new version of any draft comes out, it is automatically
updated on the site, so you don't need to know which version is the most
recent.

--Paul Hoffman, Director
--Internet Mail Consortium

Original-Encoded-Information-Types: IA5-Text
Date: Thu,  6 Nov 97  2:56:20 +0000
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: ESS-00 Mixing X.208 and X.680
Sender: [email-masked]

> Such ASN.1 usage will certainly break tools that correctly implement 
> the ASN.1 standards. I'm not sure why there's so much reluctance to
> migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
> specifications than X.208-X.209. 
> 

Is the reluctance simply fear of the unknown? Anyone who has invested the
effort to understand the 1994 version of ASN.1 realises that it provides a
significantly more powerful tool which creates much more precise syntactic
specifications. To illustrate this I will produce modules conforming to the
1994 ASN.1 version, and circulate these to this list.

Jim

X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
From: "Blake Ramsdell" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>,
        "[email-masked]'"
 <[email-masked]>,
        "'Paul Hoffman (E-mail)'" <[email-masked]>
Subject: RE: OIDs for ESS
Date: Wed, 5 Nov 1997 20:45:28 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
 4.0.993.5
X-WSS-ID: 187F94E12916-187F94E12917-01
Sender: [email-masked]

On Wednesday, November 05, 1997 12:12 PM, Blake Ramsdell  wrote:
> Paul, are you going to be managing the OIDS page at IMC with the new
> SMIME arc on it also?  I'd say we can use the same page as the
> SMIMECapabilities.  Russ has the current list, I believe.

Ah, it appears that I am a moron.  These are already up on
http://www.imc.org/ietf-smime/oids.html

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 6 Nov 1997 07:45:39 -0500
X-Sender: jsp@ajsn101
X-Mailer: Windows Eudora Version 1.4.4
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Shutting Down ccMail GW
Sender: [email-masked]

All,

Again, I aplogize for the looping messages sent by the ccMail gateway
installed at our company.  Our system admin people are now shutting down our
ccMail gateway (which they should have done last night).  The messages
should be stopping any minute now. 

Again, I apologize for this extreme inconvenience

- John Pawling

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 6 Nov 1997 12:49:57 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 Comments
Sender: [email-masked]

All,

IMHO, Paul has done an excellent job of editing the 31 Oct 97 "Enhanced
Security Services (ESS) for S/MIME" document.  I have the following comments:

1) Sec 1.1.1, 1rst para, last sent: In a secure mailing list, all recipients
are supposed to be able to read every message sent to the mail list.  Please
delete the following sentence because it doesn't make sense: "This is
typically the case in a secure mailing list where some of the messages are
not meant to be readable by all of the recipients."  

2) Sec 1.2, last para: Please add as the second sent: "As defined in
[PKCS7-1.5] and [CMS], each SignedData and EnvelopedData object MUST be
encapsulated by a ContentInfo SEQUENCE."

3) Sec 1.3.1, 1rst para, 1rst sent: Please change "A signed receipt may be
requested in any signed body part." to "A signed receipt may be requested in
any SignedData object."

4) Sec 1.3.2, 3rd para, 1rst sent: Please change: "A security label in
authenticated attributes may also be included in the outer SignedData block"
to "A security label may also be included in the authenticated attributes of
the outer SignedData block"

5) Sec 1.3.3, last sent: Please change "In all cases, the agent adds or
updates an mlExpansionHistory attribute to document the agent's processing,
and ultimately replaces the outer signature on the message to be
distributed." To "In all cases, the agent adds or updates an
mlExpansionHistory attribute to document the agent's processing, and
ultimately adds or replaces the outer signature on the message to be
distributed."

6) Sec 1.3.4, 1rst para, 1rst sent: Please change "SignerInfo" to "SignedData".

7) Sec 1.3.4: For completeness, please add the following attributes to the list:

Attribute         Inner or outer  MUST BE authenticated
counterSignature     either               yes
contentType          either               no  
messageDigest        either               yes

8) Sec 2.2, 1rst para: Please add as the third sentence:  "Only one
receiptRequest attribute can be included in the authenticatedAttributes of a
SignerInfo."

9) Sec 2.2, 1rst para, last sent: Please change "signed message" to
"signerInfo" in the following: "A sender requests receipts by placing a
receiptRequest attribute in the authenticated attributes of a signed message
as follows:" 

10) Sec 2.2: Please add as last para:

"There can be multiple SignerInfos present within a SignedData object.  Each
SignerInfo can include authenticatedAttributes.  Therefore, the syntax
allows a single SignedData object to include multiple SignerInfos each of
which could include a receiptRequest attribute.   For example, if an
originator desires to send a signed message requesting signed receipts to a
set of users composed of RSA-only and DSA-only users.  The originator's
software can include one SignerInfo that includes an RSA signature value and
a receiptRequest attribute.  The same SignedData object could include
another SignerInfo that includes a DSA signature value and a receiptRequest
attribute.  In this example, the RSA-capable recipients should return an RSA
signed receipt to the originator and the DSA-capable recipients should
return a DSA signed receipt to the originator."

11) Sec 2.3, 1rst para, 2nd sent: Please change "Processing software SHOULD
examine the authenticatedAttributes field of the innermost SignerInfo object
to determine if a receipt is requested." To "Processing software SHOULD
examine the authenticatedAttributes field of each of the SignerInfos for
which it verifies a signature in the innermost signedData object to
determine if a receipt is requested.  A receiving agent SHOULD build a
signed receipt for each SignerInfo in the SignedData object for which it
verifies the signature and which requests a signed receipt.  This may result
in multiple signed receipts being constructed and sent for a single
SignedData object."

12) Sec 2.3, 2nd para, first sent: Please change: "then a signed receipt has
not been requested from any of the message recipients and MUST NOT be
created." To "then a signed receipt has not been requested for this
signerInfo from any of the message recipients and MUST NOT be created for
this signerInfo."

13) Sec 2.3, 2nd para, last sent: Please replace "In this case, the
receiving agent may choose whether or not to send a receipt." With "In this
case, the receiving agent SHOULD construct and send a signed receipt for the
message that requests a signed receipt."

14) Sec 2.3, bullet 1: Please change: "If an mlExpansionHistory attribute is
present in the outermost authenticatedAttributes block.." to "If an
mlExpansionHistory attribute is present in the outermost signedData block"

15) Sec 2.3, bullet 2.1: "then a signed receipt MUST NOT be created." To
"then a signed receipt MUST NOT be created for this signerInfo."

16) Sec 2.3, bullet 2.3.1: "and a signed receipt MUST NOT be created." To
"and a signed receipt MUST NOT be created for this signerInfo."

17) Sec 2.3, bullet 3.2: "then a signed receipt MUST NOT be created." To
"then a signed receipt MUST NOT be created for this signerInfo."

18) Sec 2.3, flow chart: Please change "A flow chart for the above steps
would be:" to "A flow chart for the above steps to be executed for each
signerInfo for which the receiving agent verifies the signature would be:"

19) Sec 2.3, flow chart 2.3.1: Please change "2.3.1. Create a receipt, then
-> STOP." To "2.3.1.  STOP".

20) sec 2.3, flow chart 2.3.2: Please change "2.3.2. STOP" to "2.3.2. Create
a receipt, then -> STOP."

21) sec 2.4, intro: Please add: "Note that multiple signed receipts may have
to be created and sent, if applicable (see "Receipt Request Creation" section)."

22) sec 2.4, bullet 2.2: Please change "The encapsulatedContentType and
signedContentIdentifier values are copied from the original message's
receiptRequest.." to "The encapsulatedContentType and
signedContentIdentifier values are copied from the SignerInfo's receiptRequest"

23) sec 2.4, bullet 2.3: Please change "protectionValue" to "signatureValue".

24) sec 2.5, intro: Please add: "If multiple signed receipts are being sent,
then the following process must be repeated for each signed receipt created."

25) sec 2.6, bullet 4: Please change "protectionValue" to "signatureValue".

26) sec 2.7, bullet 1: Please change "The encapsulated content type, signed
content identifier, and encrypted digest value (signature value) derived
from the message content are copied from the original message into a Receipt
structure." To "The encapsulated content type, signed content identifier,
and encrypted digest value (signature value) derived from the message
content are copied from the SignerInfo including the receiptRequest into a
Receipt structure."

27) sec 2.7, bullet 3: Please add: "(as described in the "Receipt Creation"
section)."

28) sec 2.9, last para: Please change to: "The encapsulatedContentType and
signedContentIdentifier fields are copied from the receiptRequest attribute
of the SignerInfo contained within the message being receipted, and are used
to link the receipt to the original signed message. The
originatorSignatureValue field contains the
signatureValue copied from the SignerInfo requesting the signed receipt."

29) Sec 3.1, 1rst para, 1rst sent: Please change "signed message" to
"signedData object".

30) Sec 3.1.1, 1rst para, 4th sent: Please change "SignedData signature
value" to "SignerInfo signature value".

31) Sec 3.1.1, 3rd para, last sent: Please change: "signed message" to
"signedData object".

32) Sec 3.1.1, please add as 5th and 6th paras:  "There may be multiple
SignerInfos present within a SignedData object.  Each SignerInfo can include
authenticatedAttributes.  Therefore, the syntax allows a single SignedData
object to include multiple SignerInfos each of which could include a
securityLabel attribute.  For example, if an originator desires to send a
signed message including a security label to a set of users composed of
RSA-only and DSA-only users. The originator's software can include one
SignerInfo that includes an RSA signature value and a securityLabel
attribute.  The same SignedData object could include another SignerInfo that
includes a DSA signature value and a securityLabel attribute.  In this
example, the RSA-capable recipients would process the security label in the
RSA-signed signerInfo and the DSA-capable recipients would process the
security label in the DSA-signed signerInfo. This is true because a
recipient should only process a securityLabel attribute if the recipient can
verify the signature of the SignerInfo which covers the securityLabel
attribute.  A recipient should not use a security label which the recipient
can't authenticate.

The following rules MUST be followed be sending agents:

1) All security labels included in a SignedData object must be identical. 

2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include securityLabels.  In other words, there
can only be one securityLabel per signatureAlgorithm applied to the SignedData."

33) Second Sec 3.1.1 (note that there are two Sections marked 3.1.1):
Please change the first sentence to be:  "A receiving agent that processes
security labels MUST process the securityLabel attribute, if present, in
each SignerInfo in the SignedData object for which it verifies the
signature.  This may result in the receiving agent processing multiple
security labels included in a single SignedData object.  Because all
security labels in a SignedData object must be identical, then the receiving
application processes (e.g. performs access control) the first securityLabel
that it encounters in a SignerInfo that it can verify and then ensures that
all other securityLabels are identical to the first one encountered."

34) Sec 3.3.1: Please add as last sentence:  "If the receiving agent does
not recognize the securityLabel security-policy-identifier value, then it
should stop processing the message and indicate an error."

35) Sec 4.1, intro, 2nd para: Please add as last sent:  "Only one
MLExpansionHistory attribute can be included in the authenticatedAttributes
of a SignerInfo."

36) Sec 4.1, intro: Please add as 3rd para: "The syntax allows a single
SignedData object to include multiple SignerInfos each of which could
include an ML Expansion History attribute.  For example, if an MLA needs to
relay a message to a ML composed of RSA-only and DSA-only users.  The MLA
can include one SignerInfo that includes an RSA signature value and a
MLExpansionHistory attribute.  The same SignedData object could include
another SignerInfo that includes a DSA signature value and a
MLExpansionHistory attribute.  In this example, the RSA-capable ML
recipients would process the MLExpansionHistory attribute in the RSA-signed
signerInfo and the DSA-capable ML recipients would process the
MLExpansionHistory attribute in the DSA-signed signerInfo.  This is true
because a recipient should only process a MLExpansionHistory attribute if
the recipient can verify the signature of the SignerInfo which covers the
attribute.  A recipient should not use an MLExpansionHistory attribute which
the recipient can't authenticate.

When constructing the outer SignedData object, the MLA MUST follow these rules:

1) All MLExpansionHistory attributes included in a SignedData object must be
identical. 

2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include MLExpansionHistory attributes.  In other
words, there can only be one MLExpansionHistory attribute per
signatureAlgorithm applied to the SignedData.

When receiving a message that includes an outer SignedData object, a
receiving agent that processes MLExpansionHistory attributes MUST process
the MLExpansionHistory attribute, if present, in each SignerInfo in the
SignedData object for which it verifies the signature.  This may result in
the receiving agent processing multiple MLExpansionHistory attributes
included in a single SignedData object.  Because all MLExpansionHistory
attributes must be identical, then the receiving application processes the
first MLExpansionHistory attribute that it encounters in a SignerInfo that
it can verify and then ensures that all other MLExpansionHistory attributes
are identical to the first one encountered."

37) Sec 4.2, 1rst para, last sent: Please change "signature of the
signedData" to "signature of the signerInfo".

38) Sec 4.2, 1rst para: Please add as 4th sent:  "The MLA should continue
parsing the MIME-encapsulated message to determine if there is a security
label associated with an encapsulated SignedData object.  This may include
decrypting an EnvelopedData object to determine if an encapsulated
SignedData object includes a securityLabel attribute."

39) Sec 4.2, intro: recommend deleting "or digestedData" because it is not
included in [CMS].

40) Sec 4.2.1, bullet 1: Please delete "record".

41) sec 4.2.1, bullet 3.3.1: Please change: "The MLA encapsulates the signed
data in a Si1gnedData layer, and adds an mlExpansionHistory attribute
containing the current ML expansion information as described in the "Mail
List Expansion" section." To "The MLA encapsulates the received signedData
object in an SignedData object, and adds an mlExpansionHistory attribute to
the outer SignedData object containing the current ML expansion information
as described in the "Mail List Expansion" section."

42) Sec 4.2.3: recommend deleting "digestedData" because it is not included
in [CMS].

43) Reference ACP120: Please change "21 May 97 Final Draft" to "28 Oct 97".
ACP120 has been finalized.

44) Reference MTSABS: Please move the following to sec 3.2, intro, 2nd sent:
"(The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS ::=".)"

45) Please add an ASN.1 module that consolidates all of the ASN.1 syntaxes
defined throughout the spec.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Thu, 06 Nov 1997 12:00:37 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: Jim Craigie TEL +44-1635-202124 <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on the Cryptographic Message Syntax
Sender: [email-masked]

Hi Jim,

RSA has already addressed some of your concerns in PKCS #7 v1.6, which
rewrites v1.5, and replaces all of v1.5's "ANY DEFINED BY"s with 
ASN.1:1994 notation for information objects in a backwards compatible
way that does not affect the bits on the wire representation of these
messages. 

PKCS #7 v1.6 also uses CHOICE types to allow users to opt for PKCS #7
v1.5 SET OFs or v1.6 SEQUENCE OFs, to eliminate the sorting requirement
in v1.5 on types such as Attributes, Certificates, and CRLs. (Who wants
their application to sort some CRLs?)

RSA is already working on PKCS #7 v2.0, a new version of the standards,
and I understand there are some WIP ASN.1 definitions available, though 
I've not yet seen them.

Phil

Jim Craigie TEL +44-1635-202124 wrote:
> 
> Some comments on the Cryptographic Message Syntax spec:
> 
> 1. ASN.1 Canonical Encoding Rules should be allowed
> 
> >                                                            Single-
> >    pass operation has one significant drawback; it is difficult to
> >    perform encode operations using the Distinguished Encoding Rules
> >    (DER) encoding in a single pass since the lengths of the various
> >    components may not be known in advance. Since DER encoding is
> >    required by the signed-data content type, an extra pass may be
> >    necessary when a content type other than data is encapsulated.
> 
> Why does the signed-data content type require DER? Why doesn't it allow the choice of CER or DER, with the digest algorithm-identifier indicating which? For example, SHA-1 on the CER encoding would have a different algorithm-identifier to SHA-1 on the DER encoding. [For anyone unfamiliar with CER, it is defined in the 1994 version of ASN.1, and is identical to DER except that CER uses indefinite length encoding (which permits single-pass encoding) and constructed encoding of strings.]
> 
> 2. There is an ambiguity about which octets are input to hash and encryption algorithms
> 
> >    The message digest calculation process computes a message digest on
> >    either the content being signed or the content together with the
> >    signer's authenticated attributes. In either case, the initial input
> >    to the message digest calculation process is the "value" of the
> >    content being signed. Specifically, the initial input is the content
> >    octets of the DER encoding of the content field of the ContentInfo
> >    value to which the signing process is applied. Only the contents
> >    octets of the DER encoding of that field are input to the message
> >    digest algoritm, not the identifier octets or the length octets.
> >
> >    When the content being signed has content type data and the
> >    authenticatedAttributes field is absent, then just the value of the
> >    data (e.g., the contents of a file) is input to the message digest
> >    calculation. This has the advantage that the length of the content
> >    being signed need not be known in advance of the encryption process.
> >
> >    Although the identifier octets and the length octets are not included
> >    in the message digest calculation, they are still protected by other
> >    means. The length octets are protected by the nature of the message
> >    digest algorithm since it is computationally infeasible to find any
> >    two distinct messages of any length that have the same message
> >    digest.
> >
> 
> The first of the three paragraphs above says something different about which octets are input into the hash function than the implication of the second and third paragraphs. Consider the encoding of the content field of the ContentInfo in the following examples:
> 
> For the data content type:
> 
> Identifier      Length  Contents
> [0]             nnn
>                         Identifier      Length  Contents
>                         OctetString     nnn     xxxxxxxxx
> 
> For the signed-data content type:
> 
> Identifier      Length  Contents
> [0]             nnn
>                         Identifier      Length  Contents
>                         Sequence        nnn
>                                                 Identifier      Length  Contents
>                                                 Integer         1       1
> 
> The first paragraph above says that it is the contents octets of the content field which is input to the hash function - i.e. octets starting with the identifier for OctetString in the case of the data content type - but the second paragraph implies that it is just the contents octets of this OctetString. Should the first paragraph be changed to replace "content octets of the DER encoding of the content field" by "DER encoding of the content octets of the type within the content field"? That is,
> 
> 3. User Keying Materials
> 
> Surely these should be included within the parameters component of the algorithm-identifier for algorithms which require such material.
> 
> 4. RecipientKeyIdentifier
> 
> RecipientKeyIdentifier is not an adequate identification of a recipient, since subjectKeyIdentifier is only unique within the scope of an individual recipient, and it is not accompanied by any other identification of the recipient. I suggest that the more general CertificateAssertion syntax from X.509 should be used instead of the restrictive subjectKeyIdentifier:
> 
>      RecipientKeyIdentifier ::= SEQUENCE {
>           recipient-name                  Name,
>           recipient-certificate-selector  CertificateAssertion}
> 
> 5. Originator Certificate selection
> 
> Some key agreement algorithms use different originator keys for different recipients. It is therefore necessary to add an originator-certificate-selector to RecipientInfo:
> 
>      RecipientInfo ::= SEQUENCE {
>           version Version,
>           rid RecipientIdentifier,
>           keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>           encryptedKey EncryptedKey,
>           originator-certificate-selector CertificateAssertion OPTIONAL }
> 
> Jim Craigie
> 
> NET-TEL Computer Systems Ltd
> 1 Wyld Farm, Hampstead Norreys, Newbury, Berkshire, RG18 0TF, UK
> Tel:  +44 1635 202124          Fax:  +44 1635 201424
> X400: G=Jim; S=Craigie; O=Net-Tel Computer Systems Ltd; P=Net-Tel; A=Gold 400; C=GB
> Internet: [email-masked]

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu,  6 Nov 97 15:54:35 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu,  6 Nov 97 15:54:34 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971106155434-3498]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [email-masked]
Date: Thu,  6 Nov 97 15:54:34 +0000
X400-Content-Identifier: A draft ASN.1 mo
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked]
Subject: A draft ASN.1 module for Cryptographic Message Syntax
Sender: [email-masked]

CryptographicMessageSyntax { iso member-body usa(840) rsadsi(113549)
                pkcs(1) 7 module(0) version(3) }
-- Should the module OID be from the RSA branch, or from elsewhere?
DEFINITIONS IMPLICIT TAGS ::=
BEGIN

IMPORTS

-- Directory Information Framework

        Attribute, Name
        ----
        FROM InformationFramework { joint-iso-itu-t ds(5) modules(1) 
                informationFramework(1) 3 }

-- Directory Authentication Framework

        AlgorithmIdentifier, AttributeCertificate, Certificate, 
        CertificateList, CertificateSerialNumber, HASHED { }, SIGNED { }
        ----
        FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) 
                authenticationFramework(7) 3 }

-- In Cryptographic Message Syntax the HASHED parameterised type applies the hash function to the 
-- contents octets component of a CER or DER encoding of a value of the parameter.

-- Directory Certificate Extensions

        CertificateAssertion
        ----
        FROM CertificateExtensions { joint-iso-itu-t ds(5) module(1) 
                certificateExtensions(26) 0 };

-- The ENCRYPTED parameterised type is redefined here because Cryptographic Message Syntax encrypted values are 
-- defined as OCTET STRING, instead of BIT STRING as in the Directory Authentication Framework

ENCRYPTED { ToBeEnciphered } ::= OCTET STRING ( CONSTRAINED BY {
-- must be the result of applying an encipherment procedure to the contents octets component --
-- of a definite-length BER-encoding of a value of -- ToBeEnciphered } )

ContentInfo ::= SEQUENCE {
        content-type  CMS-CONTENT-TYPE.&id ({CMSContentTable}),
        cms-content [0] CMS-CONTENT-TYPE.&Type ({CMSContentTable}
                                     {@content-type}) OPTIONAL }

CMS-CONTENT-TYPE ::= TYPE-IDENTIFIER

CMSContentTable CMS-CONTENT-TYPE ::= { data, signed-data, enveloped-data, ... }

-- Data

data CMS-CONTENT-TYPE ::= { Data IDENTIFIED BY id-data }

Data ::= OCTET STRING

-- Signed Data

signed-data CMS-CONTENT-TYPE ::= { SignedData IDENTIFIED BY id-signed-data }

SignedData ::= SEQUENCE {
        version Version, 
        digestAlgorithms DigestAlgorithmIdentifiers,
        contentInfo ContentInfo,
        certificates [0] CertificateSet OPTIONAL,
        crls [1] CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

Version ::= INTEGER

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

CertificateSet ::= SET OF CertificateChoice

CertificateChoice ::= CHOICE {
        certificate Certificate,
        extendedCertificate [0] ExtendedCertificate,
        attributeCertificate [1] AttributeCertificate }

CertificateRevocationLists ::= SET OF CertificateList

SignerInfos ::= SET OF SignerInfo

SignerInfo ::= SEQUENCE {
        version Version,
        issuerAndSerialNumber IssuerAndSerialNumber,
        digestAlgorithm DigestAlgorithmIdentifier,
        authenticatedAttributes [0] Attributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unauthenticatedAttributes [1] Attributes OPTIONAL }

IssuerAndSerialNumber ::= SEQUENCE {
        issuer Name,
        serialNumber CertificateSerialNumber }

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

SignatureValue ::= ENCRYPTED { DigestInfo }

DigestInfo ::= SEQUENCE {
        digestAlgorithm DigestAlgorithmIdentifier,
        digest Digest }

Digest ::= HASHED { CHOICE {
        content CMS-CONTENT-TYPE.&Type ({CMSContentTable}),
        authenticated-attributes [0] EXPLICIT Attributes } }

-- Enveloped Data

enveloped-data CMS-CONTENT-TYPE ::= { EnvelopedData
        IDENTIFIED BY id-enveloped-data }

EnvelopedData ::= SEQUENCE {
        version Version,
        originatorInfo [0] OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        encryptedContentInfo EncryptedContentInfo }

OriginatorInfo ::= SEQUENCE {
        certificates [0] CertificateSet OPTIONAL,
        crls [1] CertificateRevocationLists OPTIONAL }

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= SEQUENCE {
        version Version,
        recipientIdentifier RecipientIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        encryptedKey EncryptedKey,
        originatorCertificateSelector CertificateAssertion OPTIONAL }

RecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        recipientKeyIdentifier [0] RecipientKeyIdentifier,
        mailListKeyIdentifier [1] MailListKeyIdentifier }

RecipientKeyIdentifier ::= SEQUENCE {
        recipientName Name,
        recipientCertificateSelector  CertificateAssertion }

MailListKeyIdentifier ::= SEQUENCE {
        kekIdentifier OCTET STRING,
        date GeneralizedTime OPTIONAL,
        otherKeyAttribute Attribute OPTIONAL }

KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

EncryptedKey ::= OCTET STRING

EncryptedContentInfo ::= SEQUENCE {
        contentType CMS-CONTENT-TYPE.&id ({CMSContentTable}),
        contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
        encryptedContent [0] ENCRYPTED { CMS-CONTENT-TYPE.&Type 
                        ({CMSContentTable} {@contentType}) } OPTIONAL }

ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

-- Object Identifiers

id-pkcs-7 OBJECT IDENTIFIER ::=
        { iso member-body usa(840) rsadsi(113549) pkcs(1) 7 }

id-data OBJECT IDENTIFIER ::= { id-pkcs-7 1 }

id-signed-data OBJECT IDENTIFIER ::= { id-pkcs-7 2 }

id-enveloped-data OBJECT IDENTIFIER ::= { id-pkcs-7 3 }

-- Definitions from PKCS#6

ExtendedCertificate ::= SIGNED { ExtendedCertificateInfo }

ExtendedCertificateInfo ::= SEQUENCE {
        version Version,
        certificate Certificate,
        attributes Attributes }

Attributes ::= SET OF Attribute

END -- of CryptographicMessageSyntax

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu,  6 Nov 97 15:31:13 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu,  6 Nov 97 15:31:12 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971106153112-4517]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: [email-masked]
Date: Thu,  6 Nov 97 15:31:12 +0000
X400-Content-Identifier: Comments on the 
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked]
Subject: Comments on the Cryptographic Message Syntax
Sender: [email-masked]

Some comments on the Cryptographic Message Syntax spec:

1. ASN.1 Canonical Encoding Rules should be allowed

>                                                            Single-
>    pass operation has one significant drawback; it is difficult to
>    perform encode operations using the Distinguished Encoding Rules
>    (DER) encoding in a single pass since the lengths of the various
>    components may not be known in advance. Since DER encoding is
>    required by the signed-data content type, an extra pass may be
>    necessary when a content type other than data is encapsulated.

Why does the signed-data content type require DER? Why doesn't it allow the choice of CER or DER, with the digest algorithm-identifier indicating which? For example, SHA-1 on the CER encoding would have a different algorithm-identifier to SHA-1 on the DER encoding. [For anyone unfamiliar with CER, it is defined in the 1994 version of ASN.1, and is identical to DER except that CER uses indefinite length encoding (which permits single-pass encoding) and constructed encoding of strings.]

2. There is an ambiguity about which octets are input to hash and encryption algorithms

>    The message digest calculation process computes a message digest on
>    either the content being signed or the content together with the
>    signer's authenticated attributes. In either case, the initial input
>    to the message digest calculation process is the "value" of the
>    content being signed. Specifically, the initial input is the content
>    octets of the DER encoding of the content field of the ContentInfo
>    value to which the signing process is applied. Only the contents
>    octets of the DER encoding of that field are input to the message
>    digest algoritm, not the identifier octets or the length octets.
> 
>    When the content being signed has content type data and the
>    authenticatedAttributes field is absent, then just the value of the
>    data (e.g., the contents of a file) is input to the message digest
>    calculation. This has the advantage that the length of the content
>    being signed need not be known in advance of the encryption process.
> 
>    Although the identifier octets and the length octets are not included
>    in the message digest calculation, they are still protected by other
>    means. The length octets are protected by the nature of the message
>    digest algorithm since it is computationally infeasible to find any
>    two distinct messages of any length that have the same message
>    digest.
> 

The first of the three paragraphs above says something different about which octets are input into the hash function than the implication of the second and third paragraphs. Consider the encoding of the content field of the ContentInfo in the following examples:

For the data content type:

Identifier      Length  Contents
[0]             nnn     
                        Identifier      Length  Contents
                        OctetString     nnn     xxxxxxxxx

For the signed-data content type:

Identifier      Length  Contents
[0]             nnn     
                        Identifier      Length  Contents
                        Sequence        nnn     
                                                Identifier      Length  Contents
                                                Integer         1       1

The first paragraph above says that it is the contents octets of the content field which is input to the hash function - i.e. octets starting with the identifier for OctetString in the case of the data content type - but the second paragraph implies that it is just the contents octets of this OctetString. Should the first paragraph be changed to replace "content octets of the DER encoding of the content field" by "DER encoding of the content octets of the type within the content field"? That is, does the input to the hash start with the identifier for Integer in the case of signed-data?

3. User Keying Materials

Surely these should be included within the parameters component of the algorithm-identifier for algorithms which require such material.

4. RecipientKeyIdentifier

RecipientKeyIdentifier is not an adequate identification of a recipient, since subjectKeyIdentifier is only unique within the scope of an individual recipient, and it is not accompanied by any other identification of the recipient. I suggest that the more general CertificateAssertion syntax from X.509 should be used instead of the restrictive subjectKeyIdentifier:

     RecipientKeyIdentifier ::= SEQUENCE {
          recipient-name                  Name,
          recipient-certificate-selector  CertificateAssertion}

5. Originator Certificate selection

Some key agreement algorithms use different originator keys for different recipients. It is therefore necessary to add an originator-certificate-selector to RecipientInfo:

     RecipientInfo ::= SEQUENCE {
          version Version,
          rid RecipientIdentifier,
          keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
          encryptedKey EncryptedKey,
          originator-certificate-selector CertificateAssertion OPTIONAL }

Jim Craigie

NET-TEL Computer Systems Ltd
1 Wyld Farm, Hampstead Norreys, Newbury, Berkshire, RG18 0TF, UK
Tel:  +44 1635 202124          Fax:  +44 1635 201424
X400: G=Jim; S=Craigie; O=Net-Tel Computer Systems Ltd; P=Net-Tel; A=Gold 400; C=GB
Internet: [email-masked]

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 6 Nov 1997 07:45:39 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Shutting Down ccMail GW
Sender: [email-masked]

All,

Again, I aplogize for the looping messages sent by the ccMail gateway
installed at our company.  Our system admin people are now shutting down our
ccMail gateway (which they should have done last night).  The messages
should be stopping any minute now. 

Again, I apologize for this extreme inconvenience

- John Pawling

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: Stefan Kelm <[email-masked]>
Date: Thu, 6 Nov 1997 10:44:27 +0100 (MET)
To: [email-masked]
Subject: Re: Enhanced Security Services for S/MIME draft now available
Reply-To: [email-masked]
Sender: [email-masked]

Paul,

> The first draft of "Enhanced Security Services for S/MIME" is now available
> at <http://www.imc.org/draft-hoffman-smime-ess>. This draft describes
> extensions to S/MIME v2 and S/MIME v3 for security labels, signed receipts,
> and secure mailing lists.

could you please give a pointer to the following refernce:

>
> A. References
>
> [ACP120] 21 May 97 Final Draft Allied Communication Publication (ACP)
> 120 Communication Security Protocol (CSP) Specification.
>

TIA,

        Stefan.

______________________________________________________________________________
Stefan Kelm                                                  <[email-masked]>
DFN-PCA, University of Hamburg                    http://www.pca.dfn.de/~kelm/
Vogt-Koelln-Str. 30             "finger [email-masked]" to get my PGP key
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Thu, 6 Nov 1997 00:34:05 -0800 (PST)
From: Jeff Thompson <[email-masked]>
To: [email-masked]
Subject: Re: Comments To ESS-00
Sender: [email-masked]

> I agree with all of Scott's comments, except that I strongly believe that
> I agree with all of Scott's comments, except that I strongly believe that
> I agree with all of Scott's comments, except that I strongly believe that
> I agree with all of Scott's comments, except that I strongly believe that
> I agree with all of Scott's comments, except that I strongly believe that
> I agree with all of Scott's comments, except that I strongly believe that
> I agree with all of Scott's comments, except that I strongly believe that

I think I prefer being spammed to this.    (smiley face)

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Paul Hoffman (E-mail)'" <[email-masked]>
Subject: RE: OIDs for ESS
Date: Wed, 5 Nov 1997 20:45:28 -0800
Sender: [email-masked]

On Wednesday, November 05, 1997 12:12 PM, Blake Ramsdell  wrote:
> Paul, are you going to be managing the OIDS page at IMC with the new
> SMIME arc on it also?  I'd say we can use the same page as the
> SMIMECapabilities.  Russ has the current list, I believe.

Ah, it appears that I am a moron.  These are already up on
http://www.imc.org/ietf-smime/oids.html

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,

    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,

ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Thu,  6 Nov 97  2:56:22 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Thu,  6 Nov 97  2:56:20 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971106025620-1B0C]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Thu,  6 Nov 97  2:56:20 +0000
X400-Content-Identifier: Re: ESS-00 Mixin
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: ESS-00 Mixing X.208 and X.680
Sender: [email-masked]

> Such ASN.1 usage will certainly break tools that correctly implement 
> the ASN.1 standards. I'm not sure why there's so much reluctance to
> migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
> specifications than X.208-X.209. 
> 

Is the reluctance simply fear of the unknown? Anyone who has invested the effort to understand the 1994 version of ASN.1 realises that it provides a significantly more powerful tool which creates much more precise syntactic specifications. To illustrate this I will produce modules conforming to the 1994 ASN.1 version, and circulate these to this list.

Jim

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

Date: Wed, 05 Nov 1997 17:57:31 -0800
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: S/MIME Version 3 Message Specification draft is now available
Sender: [email-masked]

>The first draft of "S/MIME Version 3 Message Specification" is now
>available at
><ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt> (Paul
>will copy it to the IMC site later.

Jeez, give me a minute or two to get it up on the IMC site! :-) It's now
available as <http://www.imc.org/draft-ramsdell-smime-msg>. For those of
you new to the IMC way of doing things, we don't include the "-00.txt" in
the names. When a new version of any draft comes out, it is automatically
updated on the site, so you don't need to know which version is the most
recent.

--Paul Hoffman, Director
--Internet Mail Consortium

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

Date: Wed, 5 Nov 1997 19:52:00 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Very Sorry For the Looping
Sender: [email-masked]

All,

I apologize for the inconvenience caused by my company's mail system.  Our
system admin staff is working on this problem right now.  The ccMail gateway
at our company seems to be repeating the message that I sent.

Sorry,
John Pawling

>Return-Path: <[email-masked]>
>X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
>From: "Blake Ramsdell" <[email-masked]>
>To: "[email-masked]'" <[email-masked]>
>Subject: FW: CMS-00 ASN.1 Module
>Date: Wed, 5 Nov 1997 16:05:40 -0800
>Return-Receipt-To: <[email-masked]>
>X-Wss-Id: 187FD65C1338-187FD65C1339-01
>
>You mail server seems to be freaking out a bit -- I have seen several
>copies of my message come through, with headers as follows:
>
>> Received: from host9.deming.com by cane.deming.com with SMTP (Microsoft
>Exchange Internet Mail Connector Version 4.0.993.5)
>> 	id Z3XTSAFN; Wed, 5 Nov 1997 15:55:30 -0800
>> Received: from 206.86.127.224 by cane.deming.com with SMTP (WorldSecure
>>  Server SMTP Relay v2.01); Wed, 05 Nov 97 15:55:29 -0800
>> X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
>> Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id
>>  PAA09991 for ietf-smime-bks; Wed, 5 Nov 1997 15:42:01 -0800 (PST)
>> Received: from mail3.access.digex.net (mail3.access.digex.net
>>  [205.197.247.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id
>>  PAA09987 for <[email-masked]>; Wed, 5 Nov 1997 15:41:57 -0800 (PST)
>> From: <[email-masked]>
>> Received: from apollo (apollo.jgvandyke.com [158.189.10.100]) by
>>  mail3.access.digex.net (8.8.5/8.8.5) with SMTP id SAA05572 for
>>  <[email-masked]>; Wed, 5 Nov 1997 18:41:52 -0500 (EST)
>> Received: from vda-gateway.jgvandyke.com by apollo (5.x/SMI-SVR4) id
>>  AA00951; Wed, 5 Nov 1997 18:55:50 -0500
>> Received: from POP3 Client by vda-gateway.jgvandyke.com (ccMail Link to
>>  SMTP R6.0) id AA878773376; Wed, 05 Nov 97 18:43:03 -0500
>> Message-ID: <[email-masked]>
>> X-Mailer: ccMail Link to SMTP R6.0
>> Date: Wed, 05 Nov 97 12:12:29 -0500
>> To: <[email-masked]>, <[email-masked]>
>> Subject: RE: CMS-00 ASN.1 Module
>> MIME-Version: 1.0
>> Sender: <[email-masked]>
>> Precedence: bulk
>> X-WSS-ID: 187FD8E41202-187FD8E41203-01
>> Content-Type: text/plain; 
>>  charset=us-ascii
>> Content-Transfer-Encoding: 7bit
>
>This seems to indicate that your ccMail gateway is doing something a
>little whacky with the message.
>
>Let me know if you have any insight.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>>-----Original Message-----
>>From:	Blake Ramsdell 
>>Sent:	Wednesday, November 05, 1997 9:12 AM
>>To:	[email-masked]; [email-masked]
>>Subject:	RE: CMS-00 ASN.1 Module
>>
>>
>>
>>
>>
>>On Wednesday, November 05, 1997 11:59 AM, [email-masked]
>>[SMTP:[email-masked]] wrote:
>>> An ASN.1 module needs to be added to the "Cryptographic Message Syntax"
>>>spec
>>> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
>>> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
>>> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the
>>>intent
>>> is for all tags to be IMPLICIT.  This situation is resolved by including
>>>all
>>> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
>>> That would mandate that all tags in the module are IMPLICIT.
>>
>>I think we need to do the same thing for ESS, right?
>>
>>Blake
>>--
>>Blake C. Ramsdell
>>Worldtalk Corporation
>>For current info, check http://www.deming.com/users/blaker
>>Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

Date: Wed, 5 Nov 1997 19:32:25 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 ML Expansion History Issue
Sender: [email-masked]

All,

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of a Mail List Agent (MLA) including a Mail List (ML)
Expansion History attribute in a SignedData object and a receiving agent
processing that attribute.  A single SignedData object can include multiple
SignerInfos each of which could include a ML Expansion History attribute.  I
believe that this should be allowed and should be documented in the ESS.    

For example, if an MLA needs to relay a message to a ML composed of RSA-only
and DSA-only users.  The MLA can include one SignerInfo that includes an RSA
signature value and a MLExpansionHistory attribute.  The same SignedData
object could include another SignerInfo that includes a DSA signature value
and a MLExpansionHistory attribute.  In this example, the RSA-capable ML
recipients would process the MLExpansionHistory attribute in the RSA-signed
signerInfo and the DSA-capable ML recipients would process the
MLExpansionHistory attribute in the DSA-signed signerInfo.  This is true
because a recipient should only process a MLExpansionHistory attribute if
the recipient can verify the signature of the SignerInfo which covers the
attribute.  A recipient should not use an MLExpansionHistory attribute which
she can't authenticate.

If multiple MLExpansionHistory attributes are allowed in a signedData
object, then we may want to define some additional rules such as:

1) All MLExpansionHistory attributes included in a SignedData object must be
identical. 

2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include MLExpansionHistory attributes.  In other
words, there can only be one MLExpansionHistory attribute per
signatureAlgorithm applied to the SignedData.  

3) A receiving agent should process the MLExpansionHistory attribute, if
present, in each SignerInfo in the SignedData object for which it verifies
the signature.  This may result in the receiving agent processing multiple
MLExpansionHistory attributes included in a single SignedData object.  If we
adopt the rule that all MLExpansionHistory attributes must be identical,
then this would imply that the receiving application would process the first
MLExpansionHistory attribute that it encounters in a SignerInfo that it can
verify and then simply ensure that all other MLExpansionHistory attributes
are identical to the first one encountered. 

I also believe that we should add a restriction that only one
MLExpansionHistory attribute can be included in the authenticatedAttributes
of a SignerInfo.

I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I believe that it deserves
special attention.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: S/MIME Version 3 Message Specification draft is now available
Date: Wed, 5 Nov 1997 16:22:23 -0800
Sender: [email-masked]

The first draft of "S/MIME Version 3 Message Specification" is now
available at
<ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt> (Paul
will copy it to the IMC site later.  This draft describes the S/MIME v3
usage of the Cryptographic Message Syntax draft.  There is an appendix
with the changes from S/MIME v2.

Have at it.  Here are the open issues that I know about, and any insight
would be welcome.

Section 2.5.2 Add certs as an authenticatedAttribute
[DH] is undefined in section 2.3
[DH-DSS] is undefined in section 2.2
Need OIDs for Diffie-Hellman and Diffie-Hellman/DSS
Is the terminology correct for Diffie-Hellman for encryption vs.
signing?
What do we need to do for 4.1 in order to make it Diffie-Hellman?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 5 Nov 1997 19:16:52 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 Security Labels Issue
Sender: [email-masked]

All,

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of including security label attributes in a SignedData
SignerInfo authenticatedAttributes.  There can be multiple SignerInfos
present within a SignedData object.  Each SignerInfo can include
authenticatedAttributes.  Therefore, a single SignedData object may include
multiple SignerInfos each of which may include a securityLabel attribute.  I
recommend that multiple security labels should be allowed in a single
signedData object (please read the entire message before judging the
proposal).    

For example, if an originator desires to send a signed message including a
security label to a set of users composed of RSA-only and DSA-only users.
The originator's software can include one SignerInfo that includes an RSA
signature value and a securityLabel attribute.  The same SignedData object
could include another SignerInfo that includes a DSA signature value and a
securityLabel attribute.  In this example, the RSA-capable recipients would
process the security label in the RSA-signed signerInfo and the DSA-capable
recipients would process the security label in the DSA-signed signerInfo.
This is true because a recipient should only process a securityLabel
attribute if the recipient can verify the signature of the SignerInfo which
covers the securityLabel attribute.  A recipient should not use a security
label which she can't authenticate.

If multiple security labels are allowed in a signedData object, then we may
want to define some additional rules such as:

1) All security labels included in a SignedData object must be identical.
(Note that this would limit the flexibility, but also limit the complexity
of constructing and processing security labels.)

2) There can't be multiple SignerInfos containing the same
signatureAlgorithm that all include securityLabels.  In other words, there
can only be one securityLabel per signatureAlgorithm applied to the
SignedData.  (Note that this would limit the flexibility, but also limit the
complexity of constructing and processing security labels.)

3) A receiving agent should process the securityLabel attribute, if present,
in each SignerInfo in the SignedData object for which it verifies the
signature.  This may result in the receiving agent processing multiple
security labels included in a single SignedData object.  If we adopt the
rule that all security labels must be identical, then this would imply that
the receiving application would perform access control based on the first
securityLabel that it encounters in a SignerInfo that it can verify and then
simply ensure that all other securityLabels are identical to the first one
encountered. 

Another alternative would be to prohibit multiple security labels in a
SignedData object.  If this solution is selected, then the sending agent
would need to check every SignerInfo that has already been constructed for
the SignedData to ensure that a securityLabel attribute has not already been
included.  If this solution is selected, then the receiving agent would need
to search every SignerInfo to determine if a securityLabel attribute is
present.  The problem with this alternative is that a receiving agent should
not process a securityLabel attribute unless it has been authenticated, so
if the receiving agent obtains a securityLabel from a signerInfo for which
it can't verify the signature, then it can't authenticate the security
label, so it should not use it.  This would happen in the aforementioned
example if only one securityLabel were allowed in the SignedData object.
The security label would be included in either the RSA-signed SignerInfo or
DSA-signed signerInfo, but not both.  For example, if the label was included
in the RSA-signed SignerInfo, then the DSA-only recipient wouldn't be able
to verify the signature covering the securityLabel attribute.

I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I believe that it deserves
special attention.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

Date: Wed, 5 Nov 1997 18:47:54 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-00 Multiple Signed Receipts Issue
Sender: [email-masked]

All,

The "Enhanced Security Services for S/MIME" Internet Draft (ESS-00)
describes the process of an originator requesting signed receipts and a
recipient returning signed receipts.  There can be multiple SignerInfos
present within a SignedData object.  Each SignerInfo can include
authenticatedAttributes.  Therefore, a single SignedData object may include
multiple SignerInfos each of which include a receiptRequest attribute.  I
believe that this should be allowed and should be documented in the ESS.    

For example, if an originator desires to send a signed message requesting
signed receipts to a set of users composed of RSA-only and DSA-only users.
The originator's software can include one SignerInfo that includes an RSA
signature value and a receiptRequest attribute.  The same SignedData object
could include another SignerInfo that includes a DSA signature value and a
receiptRequest attribute.  In this example, the RSA-capable recipients would
return an RSA signed receipt to the originator and the DSA-capable
recipients would return a DSA signed receipt to the originator.

I believe that the general processing rules in ESS should state that a
receiving agent should build a signed receipt for each SignerInfo in the
SignedData object for which it verifies the signature and which requests a
signed receipt.  This may result in multiple signed receipts being
constructed and returned for a single SignedData object. 

I also believe that we should add a restriction that only one receiptRequest
attribute can be included in the authenticatedAttributes of a SignerInfo.

I will include specific comments to ESS-00 in a follow-up message, but I
wanted to raise this issue separately because I beleive that it deserves
special attention.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: 4 Nov 1997 9:46:1 GMT
From: Lindsay Mathieson <[email-masked]>
Subject: Re: S/MIME and the IETF
To: [email-masked]
Sender: [email-masked]

> We were merely
>trying to sum up the positive work that has taken place over the last
>few months in a manner that would answer the questions frequently put 
>to
>us by the press.
>
>So, first, nomenclature.  The word "applied" was used only to convey
>that the appropriate letters, drafts, and charter has been discussed 
>and
published.

? Let me quote from the RSA Press Release headline:

>RSA Data Security Formally Applies to IETF to
>Establish S/MIME as Electronic Messaging Standard
>Publication of RC2 Algorithm, Creation of IETF Working
>Group Facilitate Development of S/MIME as Industry's
>Preferred Standard for E-Mail Encryption
...[snip]
>RSA Data Security, Inc., a wholly owned
>subsidiary of Security Dynamics Technologies, Inc. (Nasdaq: SDTI), today
>announced that it has formally applied to the Internet Engineering Task
Force
>(IETF) to establish S/MIME as a security standard for electronic messaging
...[snip]
>The proposed S/MIME charter, now under consideration by the IETF, is
>expected to lead to the formation of an IETF-sponsored S/MIME Working
>Group.

>Second, we in no way intended to take credit for the good work of the
>authors and editors.  RSA has been the focal point for S/MIME
>development and comment for some time, so we took the step of 
>announcing
>all of the good progress.  Anyone who feels miffed has my apology.

I wont bother quoting the rest of the release, but it extensively references
RSA as the developer's of S/MIME and gives the impression that they are
solely responsible for it. Netscape & Microsoft are mentioned as supporting
*RSA*'s efforts.

The intent and meaning of the press release seems quite clear and unambiguous
- S/MIME is the province of RSA and they are running it.

This prevailing attitude, and RSA's intransigeant attitude re the encumbered
algorithms etc in S/MIME is what lead us to drop S/MIME development and
switch to OpenPGP, and move to merely monitoring S/MIME occasionally.

By the way - is RSA still a part of S/MIME, and do RSA (the company) still
claim copyright on it?

Yours Sincerely,

Lindsay Mathieson
Black Paw Communications

--
Lindsay Mathieson
Black Paw Communications
	Using MailCat for Win32 Beta Vs 2.6.1.2, on November 6, 1997, in Win95 4.0
	http://www.blackpaw.com/

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 16:20:57 -0500
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: [email-masked]
Date: Wed, 05 Nov 97 12:05:32 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: Comments To ESS-00
Sender: [email-masked]

-----Original Message-----
From:        John Pawling [SMTP:[email-masked]]
Sent:        Wednesday, November 05, 1997 2:51 PM
To:        Scott Hollenbeck; 'IETF S/MIME'
Subject:        Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

From: [email-masked]
Date: Wed, 05 Nov 97 12:12:29 -0500
To: <[email-masked]>, <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Wed, 5 Nov 1997 16:39:37 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comments To ESS-00 - SET OF
Cc: [email-masked]
Sender: [email-masked]

Phil,

IMHO, it is not worth the added complexity of defining a CHOICE for
SecurityCategories.  There is no way to predict how securityCategories will
be used within organizations' security policies, so I can't tell you that
they will always be small sets or easy to sort.  However, S/MIME-enabled
applications must be capable of implementing DER anyway, so I don't believe
that the securityCategories SET OF adds a new requirement.  If this were the
only occurrence of "SET" or "SET OF" in the required ASN.1 syntaxes, then I
would have a different opinion.  However, there are other occurrences of SET
and SET OF in syntaxes such as in the Attribute, RDN and GeneralName
ORAddress components.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 04:20 PM 11/5/97 -0500, [email-masked] wrote:
>John Pawling wrote:
>> 
>> Phil,
>> 
>> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
>> international standard representation of security label and it is used by
>> many existing programs.  The X.411 SecurityLabel syntax includes
>> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
>> with X.411, it should not be changed.
>> 
>> ================================
>> John Pawling
>> [email-masked]
>> J.G. Van Dyke & Associates, Inc.
>> ================================
>> 
>
>I agree that no change should be made that breaks backwards 
>compatibility, but it would be possible, if accompanied with 
>a change in version, to alter the definition to
>
>  SecurityCategories ::= CHOICE {
>    setOf  SET SIZE (1..ub-security-categories) OF
>                               SecurityCategory,
>    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
>                               SecurityCategory
>  }
>
>  ub-security-categories INTEGER ::= 64
>
>so that no additional tagging were needed to distinguish 
>between the two types. If typically the SET OF size is
>small and the data easy to sort, it probably wouldn't 
>be worth the effort.
>
>> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
>> >The type defined as
>> >
>> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
>> >                             SecurityCategory
>> >
>> >requires sorting under DER that would not be required if the
>> >type were defined as a SEQUENCE OF.
>> >
>> >X.690, which defines DER restrictions in section 11, "Restrictions
>> >on BER employed by both CER and DER", states that for components of
>> >type SET OF, "The encodings of the component values of a set-of
>> >value shall appear in ascending order, the encodings being compared
>> >as octet strings."
>> >
>> >Under DER, with SEQUENCE OF, the sender can control the order
>> >of components, but with SET OF, the final sort requirement rules,
>> >and sometimes may add unanticipated overhead to message processing.
>> >It was primarily for this reason, the the SET specification is
>> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
>> >types like
>> >
>> >  Certificates ::= SEQUENCE OF Certificate
>> >
>> >and avoid sorting what (hopefully) might be efficiently
>> >organized certificate chains in SignedData. Same for the CRLs
>> >and Attributes definitions.
>> >
>> >Phil
>
>Phil
>-- 
>Phillip H. Griffin         
>ASN.1-SET-Java-Security    Griffin Consulting
>[email-masked]        1625 Glenwood Avenue
>919.828.7114               Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>
>

Date: Wed, 05 Nov 1997 16:20:57 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: John Pawling <[email-masked]>
CC: [email-masked]
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

John Pawling wrote:
> 
> Phil,
> 
> The X.411 SecurityLabel syntax is included in ESS-00 because it is an
> international standard representation of security label and it is used by
> many existing programs.  The X.411 SecurityLabel syntax includes
> SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
> with X.411, it should not be changed.
> 
> ================================
> John Pawling
> [email-masked]
> J.G. Van Dyke & Associates, Inc.
> ================================
> 

I agree that no change should be made that breaks backwards 
compatibility, but it would be possible, if accompanied with 
a change in version, to alter the definition to

  SecurityCategories ::= CHOICE {
    setOf  SET SIZE (1..ub-security-categories) OF
                               SecurityCategory,
    seqOf  SEQUENCE SIZE (1..ub-security-categories) OF
                               SecurityCategory
  }

  ub-security-categories INTEGER ::= 64

so that no additional tagging were needed to distinguish 
between the two types. If typically the SET OF size is
small and the data easy to sort, it probably wouldn't 
be worth the effort.

> At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
> >The type defined as
> >
> >  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
> >                             SecurityCategory
> >
> >requires sorting under DER that would not be required if the
> >type were defined as a SEQUENCE OF.
> >
> >X.690, which defines DER restrictions in section 11, "Restrictions
> >on BER employed by both CER and DER", states that for components of
> >type SET OF, "The encodings of the component values of a set-of
> >value shall appear in ascending order, the encodings being compared
> >as octet strings."
> >
> >Under DER, with SEQUENCE OF, the sender can control the order
> >of components, but with SET OF, the final sort requirement rules,
> >and sometimes may add unanticipated overhead to message processing.
> >It was primarily for this reason, the the SET specification is
> >based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
> >types like
> >
> >  Certificates ::= SEQUENCE OF Certificate
> >
> >and avoid sorting what (hopefully) might be efficiently
> >organized certificate chains in SignedData. Same for the CRLs
> >and Attributes definitions.
> >
> >Phil

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Wed, 05 Nov 1997 16:00:18 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: ESS-00 Integers
Sender: [email-masked]

The following integer value definitions...

  ub-integer-options ::= 256
  ub-privacy-mark-length ::= 128
  ub-security-categories ::= 64

should be

  ub-integer-options INTEGER ::= 256
  ub-privacy-mark-length INTEGER ::= 128
  ub-security-categories INTEGER ::= 64

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Wed, 5 Nov 1997 15:25:13 -0500
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: CMS-00 ASN.1 Module
Sender: [email-masked]

Blake,

Yes.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:12 PM 11/5/97 -0800, Blake Ramsdell wrote:
>On Wednesday, November 05, 1997 11:59 AM, [email-masked]
>[SMTP:[email-masked]] wrote:
>> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
>> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
>> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
>> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
>> is for all tags to be IMPLICIT.  This situation is resolved by including all
>> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
>> That would mandate that all tags in the module are IMPLICIT.
>
>I think we need to do the same thing for ESS, right?
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

Date: Wed, 5 Nov 1997 15:23:51 -0500
To: Scott Hollenbeck <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: Comments To ESS-00
Sender: [email-masked]

All,

I agree with Scott's recommendations.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 12:05 PM 11/5/97 PST, Scott Hollenbeck wrote:
>-----Original Message-----
>From:	John Pawling [SMTP:[email-masked]]
>Sent:	Wednesday, November 05, 1997 2:51 PM
>To:	Scott Hollenbeck; 'IETF S/MIME'
>Subject:	Re: Comments To ESS-00
>
>All,
>
>I agree with all of Scott's comments, except that I strongly believe that
>the ContentIdentifier and EncapsulatedContentType attributes must be allowed
>to be used as attributes included in the authenticatedAttributes of a
>SignerInfo.  They are required to replicate the MSP signedContentIdentifier
>and encapsulatedContentType fields included in the MSP SignatureBlock
>SignatureInformation.  They are most useful in SignerInfos that do not
>request signed receipts.  I agree with Scott's comments that OIDs must be
>defined for these attributes.
>
>[SAH]  OK, now I recall where they came from.  That being the case,
>ContentIdentifier needs to be defined.  How about this:
>
>ContentIdentifier ::= OCTET STRING
>
>Then, the following should happen:
>
>Section 1.3.4
>Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
>to encapsulatedContentType to reference the to-be-defined OIDs.
>
>Section 2.8
>Change the definition of signedContentIdentifier from OCTET STRING to
>ContentIdentifier.
>
>I think that closes the loop.
>
>Scott
>

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: CMS-00 ASN.1 Module
Date: Wed, 5 Nov 1997 12:12:29 -0800
Sender: [email-masked]

On Wednesday, November 05, 1997 11:59 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
> that consolidates all of the ASN.1 syntaxes defined throughout the spec.
> For example, The OriginatorInfo SEQUENCE includes two tags that are marked
> IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
> is for all tags to be IMPLICIT.  This situation is resolved by including all
> syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
> That would mandate that all tags in the module are IMPLICIT.

I think we need to do the same thing for ESS, right?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Paul Hoffman (E-mail)'" <[email-masked]>
Subject: OIDs for ESS
Date: Wed, 5 Nov 1997 12:11:35 -0800
Sender: [email-masked]

receiptRequest, receipt, contentHints and mlExpansionHistory should all
be under the SMIME (pkcs-9 16) arc, not the SMIMECapabilities (pkcs-9
15) arc.

Paul, are you going to be managing the OIDS page at IMC with the new
SMIME arc on it also?  I'd say we can use the same page as the
SMIMECapabilities.  Russ has the current list, I believe.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: Scott Hollenbeck <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
Subject: RE: Comments To ESS-00
Date: Wed, 5 Nov 1997 12:05:32 PST
Sender: [email-masked]

-----Original Message-----
From:	John Pawling [SMTP:[email-masked]]
Sent:	Wednesday, November 05, 1997 2:51 PM
To:	Scott Hollenbeck; 'IETF S/MIME'
Subject:	Re: Comments To ESS-00

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

[SAH]  OK, now I recall where they came from.  That being the case,
ContentIdentifier needs to be defined.  How about this:

ContentIdentifier ::= OCTET STRING

Then, the following should happen:

Section 1.3.4
Change ContentIdentifier to contentIdentifier and EncapsulatedContentType
to encapsulatedContentType to reference the to-be-defined OIDs.

Section 2.8
Change the definition of signedContentIdentifier from OCTET STRING to
ContentIdentifier.

I think that closes the loop.

Scott

Date: Wed, 5 Nov 1997 14:58:42 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: CMS-00 ASN.1 Module
Sender: [email-masked]

All,

An ASN.1 module needs to be added to the "Cryptographic Message Syntax" spec
that consolidates all of the ASN.1 syntaxes defined throughout the spec.
For example, The OriginatorInfo SEQUENCE includes two tags that are marked
IMPLICIT and a third that is not marked IMPLICIT.  I believe that the intent
is for all tags to be IMPLICIT.  This situation is resolved by including all
syntaxes in an ASN.1 module that begins with "DEFINITIONS IMPLICIT TAGS".
That would mandate that all tags in the module are IMPLICIT.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

Date: Wed, 5 Nov 1997 14:50:39 -0500
To: Scott Hollenbeck <[email-masked]>, "'IETF S/MIME'" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Comments To ESS-00
Sender: [email-masked]

All,

I agree with all of Scott's comments, except that I strongly believe that
the ContentIdentifier and EncapsulatedContentType attributes must be allowed
to be used as attributes included in the authenticatedAttributes of a
SignerInfo.  They are required to replicate the MSP signedContentIdentifier
and encapsulatedContentType fields included in the MSP SignatureBlock
SignatureInformation.  They are most useful in SignerInfos that do not
request signed receipts.  I agree with Scott's comments that OIDs must be
defined for these attributes.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 11:04 AM 11/4/97 PST, Scott Hollenbeck wrote:
>Thanks, Paul, for taking the draft document this far.  Let the fun begin!
>
>Section 1.3.4:
>The attribute names should reflect the name associated with the attribute
>OID, not the syntax of the attribute value.  In general, this means that
>the named attribute should begin with a lower case letter.  So, I suggest
>these changes:
>
>ContentHints -> contentHints
>ReceiptRequest -> receiptRequest
>SecurityLabel -> securityLabel
>
>Also, I don't believe that (signed?) ContentIdentifier and
>EncapsulatedContentType are intended to be used as attributes.  They're
>part of the receiptRequest attribute and are copied to a Receipt structure.
>If I missed something on this point then the OIDs for these "attributes" are
>missing...
>
>Section 2.10
>The last line of the DirectoryString definition includes an extra double
>quote character (") after the closing brace.
>
>Section 3.2
>An OID for the securityLabel attribute is missing.
>
>Section 4.3
>The syntax for EntityIdentifier is missing.  When I wrote the first cut
>at this text we put this definition in the EnvelopedData2 spec that Russ
>Housley was writing, but it ought to be included here for completeness.
>
>EntityIdentifier ::= CHOICE {
>  issuerAndSerialNumber  IssuerAndSerialNumber, -- From PKCS #7
>  subjectKeyIdentifier   KeyIdentifier }
>
>KeyIdentifier ::= OCTET STRING
>
>----->
>Scott Hollenbeck (mailto: [email-masked])
>Xerox Special Information Systems
>Arlington, Virginia, USA
>
>

Date: Wed, 5 Nov 1997 14:06:14 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

Phil,

The X.411 SecurityLabel syntax is included in ESS-00 because it is an
international standard representation of security label and it is used by
many existing programs.  The X.411 SecurityLabel syntax includes
SecurityCategories as a SET OF SecurityCategory.  To maintain compatibility
with X.411, it should not be changed.

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 08:20 PM 11/4/97 -0500, [email-masked] wrote:
>The type defined as
>
>  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
>                             SecurityCategory
>
>requires sorting under DER that would not be required if the
>type were defined as a SEQUENCE OF. 
>
>X.690, which defines DER restrictions in section 11, "Restrictions 
>on BER employed by both CER and DER", states that for components of
>type SET OF, "The encodings of the component values of a set-of 
>value shall appear in ascending order, the encodings being compared
>as octet strings."
>
>Under DER, with SEQUENCE OF, the sender can control the order
>of components, but with SET OF, the final sort requirement rules,
>and sometimes may add unanticipated overhead to message processing.
>It was primarily for this reason, the the SET specification is
>based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
>types like
>
>  Certificates ::= SEQUENCE OF Certificate
>
>and avoid sorting what (hopefully) might be efficiently
>organized certificate chains in SignedData. Same for the CRLs
>and Attributes definitions.
>
>Phil
>-- 
>Phillip H. Griffin         
>ASN.1-SET-Java-Security    Griffin Consulting
>[email-masked]        1625 Glenwood Avenue
>919.828.7114               Raleigh, North Carolina 27608 USA
>------------------------------------------------------------
>          Visit  http://www.fivepointsfestival.com
>------------------------------------------------------------
>
>

Date: Wed, 5 Nov 1997 12:45:26 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
Cc: [email-masked]
Sender: [email-masked]

> From: "Phillip H. Griffin" <[email-masked]>
> 
> X.680 provides the following definition of values of type OBJECT
> IDENTIFIER. In the NameAndNumberForm, each arc has an ASN.1 identifier,
> which must begin with a lowercase letter, ...

I stand corrected.  It's right there in black and white, X.680
section 9.3.

Learn something every day.  Thanks.

Date: Wed, 05 Nov 1997 11:12:53 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: "David P. Kemp" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
Sender: [email-masked]

David P. Kemp wrote:
> 
> > From: "Phillip H. Griffin" <[email-masked]>
> >
> > In all of the following OBJECT IDENTIFIER values, US is invalid
> > since it does not begin with a lowercase letter. Same for S in
> > SMIMECapabilities.
> >
> >   2.8 Receipt Request Syntax
> >
> >   receiptRequest OBJECT IDENTIFIER ::=
> >     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
> >         SMIMECapabilities(15) 3}
> 
> I think a little common sense is required when interpreting capitalization
> conventions.  Can you cite a reference that REQUIRES the initial letter
> of OID arcs to be lower case?  And if you want to change US to uS, I think
> you'll have to petition ISO, not the S/MIME working group - country codes
> were defined long ago in a forum far far away.

In the context of an ASN.1 value of type OBJECT IDENTIFIER, "us" 
really has nothing to do with country codes. It is merely an ASN.1
identifier, the name of some value. (ref below)

> 
> It is helpful to have a convention that distinguishes between structure
> element names (initial lower) and the syntax definitions they refer to
> (initial upper).  But as far as I know, there is no ASN.1 module which
> defines a syntax associated with any of the iso or joint country codes,
> thus there is no danger of confusion or collision between name and
> syntax.

X.680 provides the following definition of values of type OBJECT
IDENTIFIER. In the NameAndNumberForm, each arc has an ASN.1 identifier,
which must begin with a lowercase letter, followed by the constraint
notation applied to a number or a defined value. In the NameForm, just
a valid ASN.1 identifier is present...

  ObjectIdentifierType  ::= OBJECT IDENTIFIER

  ObjectIdentifierValue ::= "{" ObjIdComponentList "}"  |
               "{" DefinedValue ObjIdComponentList "}"

   ObjIdComponentList ::= ObjIdComponent |
                          ObjIdComponent ObjIdComponentList

   ObjIdComponent ::= NameForm   |
                      NumberForm |
                      NameAndNumberForm

   NameForm          ::= identifier

   NumberForm        ::= number | DefinedValue

   NameAndNumberForm ::= identifier "(" NumberForm ")"

Either "uS" or "us" is correct.

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Wed, 5 Nov 1997 09:31:29 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
Sender: [email-masked]

> From: "Phillip H. Griffin" <[email-masked]>
> 
> In all of the following OBJECT IDENTIFIER values, US is invalid
> since it does not begin with a lowercase letter. Same for S in
> SMIMECapabilities. 
> 
>   2.8 Receipt Request Syntax
> 
>   receiptRequest OBJECT IDENTIFIER ::=
>     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
>         SMIMECapabilities(15) 3}

I think a little common sense is required when interpreting capitalization
conventions.  Can you cite a reference that REQUIRES the initial letter
of OID arcs to be lower case?  And if you want to change US to uS, I think
you'll have to petition ISO, not the S/MIME working group - country codes
were defined long ago in a forum far far away.

It is helpful to have a convention that distinguishes between structure
element names (initial lower) and the syntax definitions they refer to
(initial upper).  But as far as I know, there is no ASN.1 module which
defines a syntax associated with any of the iso or joint country codes,
thus there is no danger of confusion or collision between name and
syntax.

Date: Tue, 04 Nov 1997 20:20:02 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: Comments To ESS-00 - SET OF
Sender: [email-masked]

The type defined as

  SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
                             SecurityCategory

requires sorting under DER that would not be required if the
type were defined as a SEQUENCE OF. 

X.690, which defines DER restrictions in section 11, "Restrictions 
on BER employed by both CER and DER", states that for components of
type SET OF, "The encodings of the component values of a set-of 
value shall appear in ascending order, the encodings being compared
as octet strings."

Under DER, with SEQUENCE OF, the sender can control the order
of components, but with SET OF, the final sort requirement rules,
and sometimes may add unanticipated overhead to message processing.
It was primarily for this reason, the the SET specification is
based on PKCS #7 v1.6, and not v1.5. SET needed to use PKCS #7
types like

  Certificates ::= SEQUENCE OF Certificate

and avoid sorting what (hopefully) might be efficiently
organized certificate chains in SignedData. Same for the CRLs
and Attributes definitions.

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Tue, 4 Nov 1997 18:23:48 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: More Comments to CMS-00
Sender: [email-masked]

All,

I need to enhance my previous comment #8 to be:

8) sec 6.1: Please add the following text to the description of the fields
of type EnvelopedData:  "originatorInfo includes information regarding the
originator.  It is present in EnvelopedData only if required by the key
management algorithm (e.g. Diffie-Hellman (DH), Key Exchange Algorithm
(KEA)).  At a minimum, originatorInfo must include the certificate
containing the originator's key management public key material required by
the recipient to form the pairwise key required to decrypt the recipient's
copy of the content-encryption key.  originatorInfo may include multiple key
management certificates for the same subject (i.e. originator).  For
example, if the originator has included both DH-protected and KEA-protected
copies of the content-encryption key in recipientInfos, then separate
certificates including the originator's KEA and DH public key material would
be required in originatorInfo."  

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

>To: [email-masked]
>From: [email-masked] (John Pawling)
>Subject: Comments to CMS-00
>Cc: 
>Bcc: 
>X-Attachments: 
>
>All,
>
>IMHO Russ Housley has done a most excellent job of drafting the
"Cryptographic Message Syntax" spec.  I have the following minor comments:
>
>1) Abstract: Please change "deriveded" to "derived".
>
>2) Sec 3: Please change "in 3 The methods below" to "The methods below".
>
>3) Sec 5: Please change: "The signer's public key is either contained in a
certificate included in the signer information, or is referenced by an
issuer distinguished name and an issuer-specific serial number that uniquely
identify the certificate containing the public key." to "The signer's public
key is referenced by an issuer distinguished name and an issuer-specific
serial number that uniquely identify the certificate containing the public
key.  The signer's certificate may be included in the SignedData
certificates field."
>
>4) Sec 5, last sentence: Please change "signiture" to "signature".
>
>5) sec 5.1, version description: Please change "version shall 1" to
"version shall be 1"
>
>6) sec 5.1, certificates description: Please change "version shall 1" to
"version shall be 1"
>
>7) sec 5.4: Please change two occurrences of "algorithm deployed" to
"algorithm employed".
>
>8) sec 6.1: Please add the following text to the description of the fields
of type EnvelopedData:  "originatorInfo includes information regarding the
originator.  It is present in EnvelopedData only if required by the key
management algorithm (e.g. Diffie-Hellman)."
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>  
>
>
>
>
>At 06:01 PM 11/1/97 -0800, Paul Hoffman / IMC wrote:
>>The Internet Draft for the message format to be used in S/MIME 3 is now
>>available; please see <http://www.imc.org/draft-housley-smime-cms>. This is
>>the replacement for PKCS #7 1.5, and is only slightly different. Strap on
>>your ASN.1 goggles and enjoy!
>>
>>Two other parts of S/MIME 3 (the message spec and the optional security
>>enhancements) will be appearing shortly. The certs spec will appear in a
>>few weeks, once we finish with the v2 certs definition.
>>
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>>
>

Date: Tue, 04 Nov 1997 18:19:00 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: Comments To ESS-00 - OIDs
Sender: [email-masked]

Scott Hollenbeck wrote:
> 
> Thanks, Paul, for taking the draft document this far.  Let the fun begin!
> 

In all of the following OBJECT IDENTIFIER values, US is invalid
since it does not begin with a lowercase letter. Same for S in
SMIMECapabilities. 

  2.8 Receipt Request Syntax

  receiptRequest OBJECT IDENTIFIER ::=
    {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        SMIMECapabilities(15) 3}

  2.9 Receipt Syntax

  receipt OBJECT IDENTIFIER ::=       
    {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        SMIMECapabilities(15) 4}

  2.10 Content Hints

  contentHints OBJECT IDENTIFIER ::=       
    {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        SMIMECapabilities(15) 5}

   4.3 Mail List Expansion History Syntax

   mlExpansionHistory OBJECT IDENTIFIER ::=                           
    {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        SMIMECapabilities(15) 6}

[snip]

> 
> ----->
> Scott Hollenbeck (mailto: [email-masked])
> Xerox Special Information Systems
> Arlington, Virginia, USA

Phil

-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Tue, 04 Nov 1997 16:14:24 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: Re: Comments To ESS-00
Sender: [email-masked]

Scott Hollenbeck wrote:
> 
> Thanks, Paul, for taking the draft document this far.  Let the fun begin!
> 

[snip]

> 
> Section 2.10
> The last line of the DirectoryString definition includes an extra double
> quote character (") after the closing brace.
> 

[snip]

> ----->
> Scott Hollenbeck (mailto: [email-masked])
> Xerox Special Information Systems
> Arlington, Virginia, USA

The reference to DirectoryString {}, a parameterized type 
as defined in  X.683, is missing a parameter in ...

  ContentHints ::= SEQUENCE {
     contentDescription  DirectoryString OPTIONAL,
     receipt             BOOLEAN DEFAULT FALSE 
  }
 
and should contain an integer value, such as in...

  ContentHints ::= SEQUENCE {
     contentDescription  DirectoryString { ub-conDesc } OPTIONAL,
     receipt             BOOLEAN DEFAULT FALSE 
  }

  ub-conDesc INTEGER ::= 72

Phil

-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Date: Tue, 04 Nov 1997 15:54:47 -0500
From: "Phillip H. Griffin" <[email-masked]>
Reply-To: [email-masked]
Organization: Griffin Consulting
To: [email-masked]
Subject: ESS-00 Mixing X.208 and X.680
Sender: [email-masked]

There are a few syntax errors in the ASN.1, a draft and WIP, but my
real concern is the mixing of ASN.1:1988/90 and the current standard,
ASN.1:1994. By my reading, the current standard states that the two 
can not be mixed in X.680, section A.2, "Mixing ASN.1-88/90 and 
current ASN.1 notation":

 "Both the ASN.1-88/90 and the current ASN.1 notation specify a
 top-level syntactic construct which is an ASN.1 module. A user of 
 ASN.1 writes a collection of ASN.1 modules, and may import 
 definitions from other ASN.1 modules."

[snip PHG]

 "Where a module conforms to the ASN.1-88/90 notation, type and value 
 references may be imported from a module that was defined using the
 current notation. Such types and values must be associated with types 
 that can be defined using only the ASN.1-88/90 notation. For example, 
 a module written using the ASN.1-88/90 notation cannot import a value 
 of type UniversalString, since this type is defined in the current 
 notation but not in ASN.1-88/90;  it can, however, import values whose 
 types are, for example, INTEGER, IA5String, etc."

Both BMPString and UniversalString are types defined only in the 
current standard, ASN.1:1994. The S/MIME work is not alone in this
problem. I've just finished creating ASN.1:1994 definitions for PKCS
#12. It too attempts to use BMPString in code that uses the 
superceded ANY DEFINED BY, which is described in Annex I (not an 
intgral part of the ASN.1 standards). The current PKIX work also
attempts to merge the standards.

Such ASN.1 usage will certainly break tools that correctly implement 
the ASN.1 standards. I'm not sure why there's so much reluctance to
migrate to ASN.1:1994. It's a better tool, in my opinion, for designing
specifications than X.208-X.209. 

An alternative would be to drop national language support and keep
using ASN.1:1988/90. 

Phil
-- 
Phillip H. Griffin         
ASN.1-SET-Java-Security    Griffin Consulting
[email-masked]        1625 Glenwood Avenue
919.828.7114               Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: Comments To ESS-00
Date: Tue, 4 Nov 1997 11:04:18 PST
Sender: [email-masked]

Thanks, Paul, for taking the draft document this far.  Let the fun begin!

Section 1.3.4:
The attribute names should reflect the name associated with the attribute
OID, not the syntax of the attribute value.  In general, this means that
the named attribute should begin with a lower case letter.  So, I suggest
these changes:

ContentHints -> contentHints
ReceiptRequest -> receiptRequest
SecurityLabel -> securityLabel

Also, I don't believe that (signed?) ContentIdentifier and
EncapsulatedContentType are intended to be used as attributes.  They're
part of the receiptRequest attribute and are copied to a Receipt structure.
If I missed something on this point then the OIDs for these "attributes" are
missing...

Section 2.10
The last line of the DirectoryString definition includes an extra double
quote character (") after the closing brace.

Section 3.2
An OID for the securityLabel attribute is missing.

Section 4.3
The syntax for EntityIdentifier is missing.  When I wrote the first cut
at this text we put this definition in the EnvelopedData2 spec that Russ
Housley was writing, but it ought to be included here for completeness.

EntityIdentifier ::= CHOICE {
  issuerAndSerialNumber  IssuerAndSerialNumber, -- From PKCS #7
  subjectKeyIdentifier   KeyIdentifier }

KeyIdentifier ::= OCTET STRING

----->
Scott Hollenbeck (mailto: [email-masked])
Xerox Special Information Systems
Arlington, Virginia, USA

Date: Tue, 04 Nov 1997 08:30:37 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Enhanced Security Services for S/MIME draft now available
Sender: [email-masked]

The first draft of "Enhanced Security Services for S/MIME" is now available
at <http://www.imc.org/draft-hoffman-smime-ess>. This draft describes
extensions to S/MIME v2 and S/MIME v3 for security labels, signed receipts,
and secure mailing lists.

For those of you following the press, this is the draft that some have been
mistakenly been calling "S/MIME v3" or "the MSP extensions". To be clear,
this is an optional set of extensions, not mandatory in any way. Also, the
extensions for security labels and signed receipts will work in S/MIME v2;
the secure mailing list extension requires bits from CMS, which is only
part of S/MIME v3. More importantly, there are reasons for non-defense
people to be interested in the extensions.

Enjoy!

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 03 Nov 1997 16:37:15 -0800
To: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: More comments on the certs draft
Sender: [email-masked]

At 10:06 AM 10/31/97 -0800, Jim Schaad (Exchange) wrote:
>Suggested Changes:
>
>Section 2.3
>Receiving agenst [sic] MUST support chaining based on the distinguished
>name fields.  Other methods of building certificate chains may be
>supported but are not currently recommended.

That looks fine to me.

Also at MailConnect, the S/MIME folks there agreed that S/MIME v2 really
should document what's out there today, not what "should be" out there. As
such, the above makes sense. If we're trying to document just what's in v2
(that is, reality), is that one change sufficient? Do I need to change any
other part of the certs spec? If not, I'll put out another round on
Wednesday for one more last call, and if no one objects, will send it in
for informational RFC over the weekend.

--Paul Hoffman, Director
--Internet Mail Consortium

From: Tim Matthews <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: S/MIME and the IETF
Date: Mon, 3 Nov 1997 09:25:58 -0800
Sender: [email-masked]

All,

We seem to have inadvertantly touched a nerve with the release that went
out last week.  This was certainly not our intention.  We were merely
trying to sum up the positive work that has taken place over the last
few months in a manner that would answer the questions frequently put to
us by the press.

So, first, nomenclature.  The word "applied" was used only to convey
that the appropriate letters, drafts, and charter has been discussed and
published.  I realize that there is not really an application form, so
perhaps another word would have been better.

Second, we in no way intended to take credit for the good work of the
authors and editors.  RSA has been the focal point for S/MIME
development and comment for some time, so we took the step of announcing
all of the good progress.  Anyone who feels miffed has my apology.

Lastly, I think it is safe to say that S/MIME is moving forward in the
IETF.  This is important to all of us, and we should continue to work in
this direction.  

Regards,

Tim

Tim Matthews
Product Manager
RSA Data Security, Inc.
p. 650/595-8782
f.  650/595-1873
e. [email-masked]

Date: Mon, 3 Nov 1997 10:57:15 -0500
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Comments to CMS-00
Sender: [email-masked]

All,

IMHO Russ Housley has done a most excellent job of drafting the
"Cryptographic Message Syntax" spec.  I have the following minor comments:

1) Abstract: Please change "deriveded" to "derived".

2) Sec 3: Please change "in 3 The methods below" to "The methods below".

3) Sec 5: Please change: "The signer's public key is either contained in a
certificate included in the signer information, or is referenced by an
issuer distinguished name and an issuer-specific serial number that uniquely
identify the certificate containing the public key." to "The signer's public
key is referenced by an issuer distinguished name and an issuer-specific
serial number that uniquely identify the certificate containing the public
key.  The signer's certificate may be included in the SignedData
certificates field."

4) Sec 5, last sentence: Please change "signiture" to "signature".

5) sec 5.1, version description: Please change "version shall 1" to "version
shall be 1"

6) sec 5.1, certificates description: Please change "version shall 1" to
"version shall be 1"

7) sec 5.4: Please change two occurrences of "algorithm deployed" to
"algorithm employed".

8) sec 6.1: Please add the following text to the description of the fields
of type EnvelopedData:  "originatorInfo includes information regarding the
originator.  It is present in EnvelopedData only if required by the key
management algorithm (e.g. Diffie-Hellman)."

================================
John Pawling   
[email-masked]                             
J.G. Van Dyke & Associates, Inc.           
================================

At 06:01 PM 11/1/97 -0800, Paul Hoffman / IMC wrote:
>The Internet Draft for the message format to be used in S/MIME 3 is now
>available; please see <http://www.imc.org/draft-housley-smime-cms>. This is
>the replacement for PKCS #7 1.5, and is only slightly different. Strap on
>your ASN.1 goggles and enjoy!
>
>Two other parts of S/MIME 3 (the message spec and the optional security
>enhancements) will be appearing shortly. The certs spec will appear in a
>few weeks, once we finish with the v2 certs definition.
>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

From: Scott Hollenbeck <[email-masked]>
To: "'IETF S/MIME'" <[email-masked]>
Subject: Initial S/MIME 3 CMS Comments
Date: Mon, 3 Nov 1997 06:20:35 PST
Sender: [email-masked]

After a quick look at the ASN.1 I've noticed the following:

1. The definition of SignedData includes

crls [1] IMPLICIT CRLs OPTIONAL

but no definition for CRLs is provided.  A definition for the old PKCS #7
CertificateRevocationLists is provided in section 7.1.  Either section
7.1 should be changed to define CRLs or the SignedData definition should be
changed to use CertificateRevocationLists.  I suggest changing the SignedData
definition to use the existing PKCS #7 definition.

2. Section 5.2 includes

signatureAlgorithm   signatureAlgorithmIdentifier

"signatureAlgorithmIdentifier" should be SignatureAlgorithmIdentifier, with
an upper case "S".

3. Section 7.7 includes

serialNumber  CertificateSerialNumber

PKCS #7 says that CertificateSerialNumber is imported from X.509, but the
1988 X.509 spec doesn't include a definition for CertificateSerialNumber.
It defines "SerialNumber".  This should be changed to SerialNumber unless
CertificateSerialNumber is defined in a later version of X.509.

4. In section 7.9 a definition for Version is included.  Version is defined
in X.509, so maybe it could be included from X.509 instead of adding a
definition here.

FWIW,
----->
Scott Hollenbeck
Xerox Special Information Systems
Arlington, Virginia USA

Date: Mon, 3 Nov 1997 09:18:56 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RSA Blows Smoke
Sender: [email-masked]

Rodney, sorry for forwarding this to ietf-smime, but there may be a few
people there who aren't cypherpunks, yet would find it interesting.
I'm not, and I did.

            dpk

----- Begin Included Message -----

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 02 Nov 97 06:37:59 -0600
To: [email-masked]
Cc: [email-masked]
Subject: RSA Blows Smoke

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

Wierd News
RSA Blows Standards Smoke
James Glave [email-masked]"
6:16pm 31.Oct.97.PST
http://www.wired.com/news/news/business/story/8196.html

Today's announcement "http://www.rsa.com/smimelive/html/9710311.html" by
RSA Data Security stating that the company has formally applied to the
Internet Engineering Task Force to establish an email security standard is
a blatant lie rooted in greed, allege sources close to the process.

"RSA is lying, and I am really livid," said Paul Hoffman of the Internet
Mail Coalition. "RSA has not submitted anything."

The flap centers around the company's ongoing efforts to get its
proprietary S/MIME email encryption technology endorsed as a standard by
the task force. Such an endorsement would give the company credibility,
and potentially, an increased market share over rival Pretty Good Privacy.
PGP submitted a competing protocol for standards consideration last month.

The Internet standards process is lengthy and complicated at best. The
sticking point in RSA's efforts to date is that the task force will only
consider non-proprietary technologies for the standards track. But S/MIME
2, the protocol at the heart of the effort, includes core RSA technologies
that must be licensed.

To be considered for standardization, RSA must relinquish "change
control," or the ability to modify the technology, to the task force. And
the portion the task force is most interested in altering is the portion
that requires RSA technology. As a result, getting change control "has
been like pulling teeth," claims Jeff Schiller, the organization's
security director. 

"Their goal has always been get this into the IETF but don't really give
up control," said Schiller. "[They want to] make sure that when the
standard comes down, if an anyone wants to implement it then they have to
be a licensee."

Schiller says that until change control is secured, RSA has no hope of
coming near a formal application - as they had claimed to have already
done this morning. RSA, however, claims that it has granted change
control.

"They are trying to get more market share by claiming that the IETF is
endorsing their commercial product," alleged Schiller.

RSA, in fact, is only one of five groups that have worked on S/MIME 2,
which is about to be submitted by the Internet Mail Coalition to the IETF
as an informational request for comments. Now, in order to retain its hold
on the S/MIME technology, RSA is taking sole credit for submitting it to
the task force, some observers claim.

"It's totally disacknowledging the work of a lot of other people," said
Hoffman. A request for comments is one of the initial steps in the
certification process, and Hoffman says that the Internet Mail Coalition
has yet to put S/MIME 2 forward.

Further, Schiller says, "When we do, it is not trying to get it as an
Internet standard. It won't go - and therefore we are not going to try."

Hoffman reiterated that S/MIME 2 won't be an Internet standard because it
relies on proprietary security technology and weak encryption. The
Internet Mail Coalition is about to begin work on S/MIME 3, which will use
stronger encryption and true open standards.

Tim Matthews, product manager for RSA, acknowledged that the announcement
may be open to misinterpretation. "It's basically a summation of all the
work we've been doing over the past month," he said.

Instead of helping its own cause, and gaining public mindshare, RSA's
announcement may end up flying back in its face.

"If it fragments the S/MIME camp it could help PGP a bit," said Charles
Breed, director of technology for competitor PGP.

"I hope [the announcement] hasn't sunk their chances because there are
still a lot of people who want to do S/MIME," said Hoffman. "RSA's
greediness could sink this, but I really hope it doesn't."

----- End Included Message -----

Date: Sat, 01 Nov 1997 18:01:25 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: S/MIME 3 begins
Sender: [email-masked]

The Internet Draft for the message format to be used in S/MIME 3 is now
available; please see <http://www.imc.org/draft-housley-smime-cms>. This is
the replacement for PKCS #7 1.5, and is only slightly different. Strap on
your ASN.1 goggles and enjoy!

Two other parts of S/MIME 3 (the message spec and the optional security
enhancements) will be appearing shortly. The certs spec will appear in a
few weeks, once we finish with the v2 certs definition.

--Paul Hoffman, Director
--Internet Mail Consortium