Subject: Re: SMIMECapabilities OID
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Cc: [email-masked]
Date: Sat, 1 Nov 1997 19:15:08 (NZDT)

>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?
 
Yes, it should be lowercase (I had to change the sarcastic comment I'd made 
about "iPAddress" in my X.509 guide when I was notified of this rule for ASN.1 
identifiers).
 
Peter.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SMIMECapabilities OID
Date: Fri, 31 Oct 1997 21:38:19 -0800
Sender: [email-masked]

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

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Object Identifiers: Confusion now hath made his masterpiece
Date: Fri, 31 Oct 1997 21:31:28 -0800
Sender: [email-masked]

On Thursday, October 30, 1997 11:18 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> 3. PKCS #9 OID (1 2 840 113549 1 9) is assigned to both
symmetricCapabilities
> 
>    and SMIMECapabilities.

Two things.  symmetricCapabilities was the "old" name, and
"SMIMECapabilities" is the new name.  There is no symmetricCapabilities
any more, and it was used in an old S/MIME draft.

Second thing -- you said "PKCS #9 OID (1 2 840 113549 1 9) is assigned
to both...".  You gave the actual PKCS #9 OID, but did you mean 1 2 840
113549 1 9 *15* which is SMIMECapabilities (which happens to live under
PKCS #9)?

As an aside -- I believe I have seen two sha-1WithRSAEncryption OIDs --
one under the oiw arc, and one under the PKCS #1 arc.  Anyone know about
the oiw one?  The PKCS #1 version is the one listed in the S/MIME spec.

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, 31 Oct 1997 12:25:11 -0800
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on Certs Draft
Sender: [email-masked]

Jim Schaad's recent messages agree with my originally
expressed sentiments both on the MD2 issue and on the
issue of only requiring support for chaining on
DNs + key identifiers.

My recent message was trying to echo the original motivation
for the pushback on these counts.   But are there really any 
proponents of that position left?

--a.

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: More comments on the certs draft
Date: Fri, 31 Oct 1997 10:06:01 -0800
Sender: [email-masked]

I have been debating this with myself for a couple of weeks now, and
after talking to some of the other S/MIME developers at the IMC S/MIME
interop event I am going to raise this issue.

It is unclear to me that we should be suggesting/requring support for
building certificate chains on any thing other than the Subject/Issuer
DN chaining.  This means that I am proposing that we will eliminate all
text which is refering to the use of subjectAltName and issureAltName
for the building of certificate chains.

I think that for the S/MIME V3 spec. we need to look closer at the set
of certificate chaining models which are proposed by the PKIX people.
However at this time I think that the set of models is sufficiently
unclear that we don't want to push any given model.  Given that the DN
chaining is a MUST under the current spec and any other methods do not
provide ensured compatability I think that we should remove them. 

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.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Comments on Certs Draft
Date: Fri, 31 Oct 1997 10:06:00 -0800
Sender: [email-masked]

From: Anil R. Gangolli [SMTP:[email-masked]]

[email-masked] wrote:
> 
> 
> 1.  I don't like the use of MD2 and I know of no Cryptographer who
> does.   I realize that some companies are still using it and that is
> why I am not suggesting a complete elimiation of it from the document,
> however I would like the have the following changes made:
> 
> 
> Section 4.3 changed the second sentence to:
> A receiving agent MUST be capable of verifying the signatures on
> certificates andCRLs made with md5WithRSAEncryption and
> sha-1WithRSAEncryption signature algorithms with key sizes from 512
> bits to 2048 bits described in [SMIME-MSG].  A receiving agent SHOULD
> be capable of verifying the signatures on certificates and CRLs made
> with the md2WithRSAEncryption signature algorithm with key sizes from
> 512 bits to 2048 bits.
> 
> 
> Section 5.2 Third paragraph, second sentence to:
> Certification authorities MUST support sha-1WithRSAEncryption and
> md5WithRSAEncryption and SHOULD support MD2WithRSAEncryption for
> verification of signatures on certificate requests as described in
> [SMIME-MSG].
> 
> 
> Section 5.2 Fourth paragraph is replace with:
> For the creation and submission of certification-requests, RSA keys
> SHOULD be identified with the rsaEncryption OID and signed with the
> sha-1WithRSAEncryption signature algorithm.  Certification-request
> MUST NOT be signed with the md2WithRSAEncryption signature algorithm.
> 
> 

Part of the reason for still accepting MD2-based signatures at
all is because there are hardware devices still in use that only
support this.  The MUST NOT above is antithetical to the purpose
of supporting it at all.  Anyone that can avoid MD2 should.
I think SHOULD NOT fits better above.

[Jim Schaad] I disagree with this.  The argument that you are using is
why I am pushing MD2 to should for certificates and CRLs.  There is NO
GOOD reason that a PKCS#10 message should be generated using MD2.  I
know of no USER END software or hardware in wide distribution which uses
MD2 as the client signature algorithm.  I agree that MD2 is used by
several distributers of certificates and CRLs, but that is not an
argument for keeping MD2 in PKCS#10 requests.

Date: Thu, 30 Oct 1997 19:02:56 -0800 (PST)
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Moving ahead with S/MIME 3
Sender: [email-masked]

A few folks have asked questions regarding the status of the S/MIME 
Working Group and the drafts for S/MIME 3. This message will hopefully 
clear up the questions you may have.

The draft charter was sent to Jeff Schiller, the area director for 
security, a few weeks ago. He was not able to present it at the last IESG 
meeting because he wasn't able to participate in that meeting. He will 
bring it up at the meeting coming up next week. If the IESG approves, 
we'll be a working group in about a week and a half from now. It seems 
likely (but certainly not definite) that they will approve the request, 
or that they will ask us to make a change that will be just fine with the 
group. If we become a working group, I certainly expect us to meet 
face-to-face at the IETF meeting in Washington DC in December.

Because we're at least a week off from becoming a working group, there is
no reason we shouldn't start considering the drafts for S/MIME 3 now. 
Russ Housley has already submitted the first draft of the message format
changes to the Internet Drafts editor, so we should see that in a few
days. Blake Ramsdell expects to submit the first draft of the message 
format spec this weekend, and I expect to submit the first draft of the 
optional security extensions this weekend as well. So, we'll have plenty 
to discuss soon.

There is still an ongoing discussion of the S/MIME 2 certs draft that 
looks like it might take at least another week, so I think it would be 
good if we *didn't* start discussiong the S/MIME 3 certs draft unitl the 
S/MIME 2 certs draft was finished.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 30 Oct 1997 10:41:07 -0600
To: [email-masked]
From: Paul Robichaux <[email-masked]>
Subject: More cert draft comments
Sender: [email-masked]

1. Section 5.2 of the cert draft specifies that CAs must allow use of
optional attributes:

<italic>>Certification authorities MUST support parsing of zero or one
instance

>of each of the following set of certification-request attributes on

>incoming messages. Inclusion of the following attributes during the

>creation and submission of a certification-request will most likely
be

>dictated by the policies associated with the certification service

>which will certify the corresponding name and public key.

</italic>However, the second sentence says that these attributes may be
used, or not, according to the CA owner's CPS. I suggest changing this
requirement from a MUST to a SHOULD as follows:

<italic>>Certification authorities SHOULD support parsing of zero or
one instance

>of each of the following set of certification-request attributes on

>incoming messages. Attributes which a particular implementation

>does not support may generate a warning message to the requestor or
may be

>silently ignored. [...]

</italic>2. Para 5 of section 3.1 says "End-entity certificates MUST
contain an Internet mail address as described in [RFC-822]."  Para 2 of
section 3.2 says "Sending agents SHOULD include the Internet mail
address during DN creation." Para 7 of section 3.2 says that receiving
agents MUST compare the From and cert addresses for a match.

This seems inconsistent; if the end-entity cert must contain an
Internet mail address, it has to come as part of the initial
certificate request. I don't think you can't depend on the CA to
correctly infer the address from the request it receives, so the
address must be part of either the DN or the PKCS #10 request.

I suggest changing para 2 of section 3.2 to "Sending agents MUST..."
and adding the following text to section 5.2:

<italic>>Certification requests MUST include a valid Internet mail
address, either as part of the certificate (as 

>described in 3.2) or as part of the PKCS #10 attribute list.
Certification authorities MUST check that the 

>address in the From header matches either of these addresses. CAs
SHOULD allow the CA operator to configure >processing of messages whose
addresses do not match.

</italic>3. Section 5.3 says CAs SHOULD use sha-1WithRSAEncryption. I
suggest changing this to MUST, unless there's a good argument against
it.

Cheers,

-Paul

--

Paul Robichaux  | [email-masked]  |  LJL Enterprises, Inc. |
<<http://www.ljl.com> 

Author,	_Jazz Up Your Web Site In A Weekend_ (ISBN 0761511377)

	 _Windows NT Server 4 Administrator's Guide_ (ISBN 0761507515)

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Object Identifiers: Confusion now hath made his masterpiece
Reply-To: [email-masked]
Date: Thu, 30 Oct 1997 19:17:42 (NZDT)
Sender: [email-masked]

I've been updating my ASN.1 dump/diagnostic program 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c) over the past few days and 
have started cross-referencing the various OIDs it knows about.  While doing 
this I've become a bit disturbed at the number of redundant, multiply defined, 
incorrectly used, and ambiguous OIDs which are floating around.  For example 
there are no less than a dozen OIDs for the various DSA and SHA combinations, 
including ones used incorrectly (JDK 1.1 uses SHA-1 but denotes its use with 
an SHA OID).
 
Below is a list of some of the problem OIDs or problem areas, if anyone has 
any comments on these or can clear things up, please let me know.  Before 
anyone asks, I didn't record the exact sources for all of this information, 
but in general it came from sundry standards, drafts, RFC's, online 
information, and moles and spies in standards bodies and companies :-).
 
1. DSA and SHA combinations have multiple redundant definitions (X9.57, some 
   old OIW OIDs, and a DMS OID).  Which one is the recommended one?
 
2. PKCS #1 OID (1 2 840 113549 1 1 6) is assigned to both 
   ripemd160WithRSAEncryption and rsaOAEPEncryptionSET.
                                                      
3. PKCS #9 OID (1 2 840 113549 1 9) is assigned to both symmetricCapabilities 
   and SMIMECapabilities.
   
4. There are a whole series of strange OIDs at (1 3 14) which don't make much 
   sense and which are incompatible with or conflict with other OIDs (see the 
   dumpasn1.c code for more information on these).  Any comments on these 
   would be appreciated.
   
5. (1 3 14 3 2 27) is assigned to both ripemd-160 and yet another dsaWithSHA1.
   (This means there are no ripemd-160 OIDs which aren't also assigned to 
   something else.  If noone knows what the situation is with these, I'll 
   issue some RIPEMD-160 OIDs myself just to clear up the confusion).
 
6. X.509v3 cert extensions - what a mess!  There are often multiple 
   generations of superseded and redundant OIDs for extensions, again see the 
   dumpasn1 code comments.
 
7. Most of the SET cert extensions are defined as both (2 23 42 7 x) and 
   (2 54 1775 x+2).
 
There are a couple of European e-commerce and certification initiatives which 
are planning to issue their own OIDs for everything as well (yippee!), if 
anyone knows more about these please let me know.  So far all I've seen are 
general comments to the effect that the OIDs for operations of type X will be 
allocated on branch Y, but no details on which OIDs are actually assigned (the 
BSI is (not surprisingly) quite keen on RIPEMD so maybe we'll see a series of 
proper OIDs issued for that).
             
Peter.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Last call on S/MIME 2
Date: Wed, 29 Oct 1997 14:30:16 -0800
Sender: [email-masked]

I agree that the Message draft is ready for submission.  I want to see a
couple of changes (as per my earlier mail) and perhaps another read
through on the Certs draft.

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Tuesday, October 28, 1997 10:26 AM
> To:	[email-masked]
> Subject:	Last call on S/MIME 2
> 
> Greetings one more time. There has been almost no discussion of the
> S/MIME
> 2 drafts posted last week, which I take to be a Very Good Sign. If
> there is
> nothing more to do on the drafts, I would like to submit them as
> "final" to
> the IESG for consideration as informational RFCs. I'd like to do this
> over
> the weekend, after any face-to-face discussion that might happen at
> MailConnect 3 among the implementors there.
> 
> So, if you have any more issues about what is in S/MIME 2, please
> speak up.
> Also, you should expect the first drafts of S/MIME 3 later this week,
> or
> early next week at the very latest.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Comments on Certs Draft
Date: Wed, 29 Oct 1997 14:29:24 -0800
Sender: [email-masked]

I think that we should be consistant with the PKIX names -- thus End
Entity is the correct wording

> -----Original Message-----
> From:	Blake Ramsdell [SMTP:[email-masked]]
> Sent:	Wednesday, October 29, 1997 2:01 PM
> To:	[email-masked]'; Jim Schaad (Exchange);
> [email-masked]'
> Subject:	RE: Comments on Certs Draft
> 
> On Wednesday, October 29, 1997 12:21 PM, Anil R. Gangolli
> [SMTP:[email-masked]] wrote:
> > > 2.  I don't think that any certificates other than End-User
> > > certificates should be required to have an Internet mail address.
> > > 
> > > 
> > > Section 2.2  Change Certificates to End-User certificates in the
> > > second sentence.
> > 
> > I think this was the intent, and deserves this clarification.
> 
> A nit -- should this be End Entity (consistent with PKIX)?  I agree
> that
> the intent was to have the email address in the leaf certificate.
> 
> 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: Comments on Certs Draft
Date: Wed, 29 Oct 1997 14:00:54 -0800
Sender: [email-masked]

On Wednesday, October 29, 1997 12:21 PM, Anil R. Gangolli
[SMTP:[email-masked]] wrote:
> > 2.  I don't think that any certificates other than End-User
> > certificates should be required to have an Internet mail address.
> > 
> > 
> > Section 2.2  Change Certificates to End-User certificates in the
> > second sentence.
> 
> I think this was the intent, and deserves this clarification.

A nit -- should this be End Entity (consistent with PKIX)?  I agree that
the intent was to have the email address in the leaf certificate.

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, 29 Oct 1997 12:20:53 -0800
From: "Anil R. Gangolli" <[email-masked]>
Reply-To: [email-masked]
Organization: Structured Arts Consulting Group
To: [email-masked], [email-masked]
Subject: Re: Comments on Certs Draft
Sender: [email-masked]

[email-masked] wrote:
> 
> Sorry this took so long, they keep trying to get me to ship something
> here.
> 
> 1.  I don't like the use of MD2 and I know of no Cryptographer who
> does.   I realize that some companies are still using it and that is
> why I am not suggesting a complete elimiation of it from the document,
> however I would like the have the following changes made:
> 
> 
> Section 4.3 changed the second sentence to:
> A receiving agent MUST be capable of verifying the signatures on
> certificates andCRLs made with md5WithRSAEncryption and
> sha-1WithRSAEncryption signature algorithms with key sizes from 512
> bits to 2048 bits described in [SMIME-MSG].  A receiving agent SHOULD
> be capable of verifying the signatures on certificates and CRLs made
> with the md2WithRSAEncryption signature algorithm with key sizes from
> 512 bits to 2048 bits.
> 
> 
> Section 5.2 Third paragraph, second sentence to:
> Certification authorities MUST support sha-1WithRSAEncryption and
> md5WithRSAEncryption and SHOULD support MD2WithRSAEncryption for
> verification of signatures on certificate requests as described in
> [SMIME-MSG].
> 
> 
> Section 5.2 Fourth paragraph is replace with:
> For the creation and submission of certification-requests, RSA keys
> SHOULD be identified with the rsaEncryption OID and signed with the
> sha-1WithRSAEncryption signature algorithm.  Certification-request
> MUST NOT be signed with the md2WithRSAEncryption signature algorithm.
> 
> 

Part of the reason for still accepting MD2-based signatures at
all is because there are hardware devices still in use that only
support this.  The MUST NOT above is antithetical to the purpose
of supporting it at all.  Anyone that can avoid MD2 should.
I think SHOULD NOT fits better above.

> 2.  I don't think that any certificates other than End-User
> certificates should be required to have an Internet mail address.
> 
> 
> Section 2.2  Change Certificates to End-User certificates in the
> second sentence.

I think this was the intent, and deserves this clarification.

> 
> 3.  I don't have a good idea for how to change this, but I don't like
> the fact that sections 2.2 and 2.3 are so related and appear at first
> glance to have the same title, but are not the same.  Perhaps section
> 2.2 and 2.2.1 should become subsections in 2.3.
> 
> 
> 4.  Delete paragraph 2 in section 2.3.  This has already been covered
> in section 2.2 and is also covered in 3.1.
> 
> 5.  Section 4.4  Since we have removed all of the other references to
> certificatePolices, it should also be removed from the last sentence
> of the first paragraph.  Nobody knows how to correctly deal with
> certificatePolices anyway.
> 
> 
> 6.  Section 5.1
> It appears to me that the last two paragraphs are contradictory with
> respect to MUST and SHOULD.  I suggest that the MUST in the next to
> last paragraph be changed to a SHOULD to make them match.  I don't see
> how a client application can do a good job of supporting multiple
> valid CA certificates with different keys without supporting the
> AuthorityKeyIdentificer extension.
> 

Yes, I pushed for the MUST position initially at the pre-draft meeting
that happened at Netscape, but I think the argument raised was that one
could do trial and error and maybe there are some other means as well.
I backed down to SHOULD based on this pushback.

I noted either at that meeting or in a subsequent e-mail exchange
that an implementation not using key identifiers for chain
formation loses the ability to distinguish (with reasonable accuracy)
between a signature verification failure and not having a required
CA cert.

--a.

> 
> Jim Schaad
> 

-- 
Anil R. Gangolli
Structured Arts Consulting Group
mailto:[email-masked]
http://www.StructuredArts.com

Date: Wed, 29 Oct 1997 15:17:29 -0500
From: Yves Theriault <[email-masked]>
Reply-To: [email-masked]
Organization: National Defence Headquarters/PMO Defence Message Handling System
To: Jim Craigie TEL +44-1635-202124 <[email-masked]>, [email-masked]
Subject: Re: Definitions: ref to X.680-9
Sender: [email-masked]

If S/MIME 2 uses X.680-3 notation versus X.208, the following notation
does reflect the SMIMECapability type definition the best:

> If the parameters field should be optional then the definitions should become:
> 
> SMIMECapability ::= SEQUENCE {
>     capabilityID CAPABILITY.&id ({SupportedCapabilities}),
>     parameters CAPABILITY.&Type ({SupportedCapabilities}{@capabilityID}) OPTIONAL }
> 
> CAPABILITY ::= CLASS {
>     &id OBJECT IDENTIFIER UNIQUE,
>     &Type OPTIONAL }
> WITH SYNTAX { [&Type] IDENTIFIED BY &id }
> 
> and the examples become:
> 
> rc2-CBC CAPABILITY ::= { SMIMECapabilitiesParametersForRC2CBC IDENTIFIED BY id-rc2-cbc }
> des-cbc CAPABILITY ::= { IDENTIFIED BY id-des-cbc }

Jim, thank you for fixing my ASN.1 errors.
-- 
Y. Theriault, Capt
Hardware Engineer
Project Management Office
Defence Message Handling System
Department of National Defence
phone:  995-6476
fax  :  995-6456
e-mail: [email-masked]

Date: Wed, 29 Oct 1997 10:00:10 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Comments on Certs Draft
Sender: [email-masked]

Jim makes some good comments, and I would like to hear from other
cert-savvy implementors on his proposed changes. Of course, you can feel
free not to send them with superfluous HTML.... :-)

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 29 Oct 1997 09:45:03 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: SignedAndEnveloped content type
Sender: [email-masked]

At 10:46 AM 10/29/97 +0100, Volker Spiegel wrote:
>I have the impression that the proposal not to support the
>SignedAndEnveloped content type is actually withdrawn, but can come up
>in the final smime v3-spec.

There is no final S/MIME v3 spec. Heck, there isn't even an *initial*
S/MIME v3 spec yet. That will appear on this mailing list within days.

The wording in the v2 spec is (hopefully) clear: to send something that is
signed and encrypted, you use nesting, not the SignedAndEnveloped data
type. Nesting is described in section 3.5 in the spec; SignedAndEnveloped
is not described anywhere in the spec other than in section 2.4 which
allows it but does not require receiving agents to even understand it.

The wording in the first draft of the v3 spec will be identical.

There is nothing prohibiting you from using SignedAndEnveloped (although
there are known security problems with it), but it is not part of S/MIME.

--Paul Hoffman, Director
--Internet Mail Consortium

X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 29 Oct 97 13:34:50 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Wed, 29 Oct 97 13:34:48 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:282-971029133448-5C76]
X400-Content-Type: P2-1984 (2)
X400-Originator: [email-masked]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Wed, 29 Oct 97 13:34:48 +0000
X400-Content-Identifier: Re: Definitions:
From: "Jim Craigie" TEL +44-1635-202124 <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Definitions: ref to X.680-9
Sender: [email-masked]

> Section 1.3 ASN.1 definition should read as follows:  
> 
> ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-3. 

Since ASN.1 is common text published by ISO, IEC and ITU, the correct reference is "ISO/IEC 8824 | ITU-T X.680-3".

> 
> the following would be used (according to X.680-2):
> 
> SMIMECapability ::= SEQUENCE {
>     capabilityID CAPABILITY.&id ({SupportedCapabilities}),
>     parameters CAPABILITY.&Parameter
> ({SupportedCapabilities}{@capabilityID}) }      
> 
> First, the following information object class would be defined:
> 
> CAPABILITY CLASS ::= {
>         &id     OBJECT IDENTIFIER UNIQUE,
>         &Parameter      
> }
> WITH SYNTAX
> {
>         ID      &id
>         [PARAMETER &Parameter]
> }

The above has the &Parameter field mandatory in the class but optional in the syntax, which is inconsistent, and the syntax of the CLASS definition is incorrect. If it should be mandatory then it is better to use the built-in replacement for ANY DEFINED BY, which is called TYPE-IDENTIFIER (see Annex A in 8824-2|X.681), to give:

SMIMECapability ::= SEQUENCE {
    capabilityID CAPABILITY.&id ({SupportedCapabilities}),
    parameters CAPABILITY.&Type ({SupportedCapabilities}{@capabilityID}) }

CAPABILITY ::= TYPE-IDENTIFIER

> 
> Each capability would then be defined:
> 
> RC2-CBC OBJECT IDENTIFIER ::=
>     {iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) 2}

As the above is a value definition its identifier must start with a lower case letter. To avoid confusion with the value of the CAPABILITY information object class, I suggest:

id-rc2-cbc OBJECT IDENTIFIER ::=
    {iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) 2}

The examples then become:

rc2-CBC CAPABILITY ::= { SMIMECapabilitiesParametersForRC2CBC IDENTIFIED BY id-rc2-cbc }
des-cbc CAPABILITY ::= { NULL IDENTIFIED BY id-des-cbc }

If the parameters field should be optional then the definitions should become:

SMIMECapability ::= SEQUENCE {
    capabilityID CAPABILITY.&id ({SupportedCapabilities}),
    parameters CAPABILITY.&Type ({SupportedCapabilities}{@capabilityID}) OPTIONAL }

CAPABILITY ::= CLASS {
    &id OBJECT IDENTIFIER UNIQUE,
    &Type OPTIONAL }
WITH SYNTAX { [&Type] IDENTIFIED BY &id }

and the examples become:

rc2-CBC CAPABILITY ::= { SMIMECapabilitiesParametersForRC2CBC IDENTIFIED BY id-rc2-cbc }
des-cbc CAPABILITY ::= { IDENTIFIED BY id-des-cbc }

Date: Wed, 29 Oct 1997 10:46:47 +0100
From: Volker Spiegel <[email-masked]>
Reply-To: [email-masked]
Organization: Department of Medical Informatics
To: [email-masked]
Subject: SignedAndEnveloped content type
Sender: [email-masked]

Hello,

I have read the s/mime draft (draft-dusse-smime-msg-05.txt) and looked
at the discussion (at www.imc.org).

I have the impression that the proposal not to support the
SignedAndEnveloped content type is actually withdrawn, but can come up
in the final smime v3-spec.

In our department we intend to use s/mime. At the moment we use PKCS#7
with the SignedAndEnveloped content type. To make a quick implementation
we decided not to perform a "nesting" as described in section 3.5 of the
current s/mime-draft.

My first Question is:
Concerning the future v3-spec of smime, will we "fall out of the
standard" ?

Second Question:
If we use the SignedAndEveloped type, what smime-type has to be
specified in the content-type field?
The type "enveloped-data" is for an encrypted PKCS#7-Object and the type
"signed-data" for an signed PKCS#7-Object.
So it may be "signed-and-eveloped-data"??

Last question:
Concering "nesting" of MIME-Entities using the "multipart"-type, what is
the exact message structure when using signed AND eveloped data?

The content-type can't be "multipart/signed", or is it?
What fillers have other parameter and fields (like the
"protocol"-parameter, and so on)?

Please give us an example of the usage (by sending a example message).

Section 3.4.3.3. of the s/mime-draft gives an example of the
"signed"-type only.

Thanks for helping,

Volker Spiegel

------------------------------------------------------------------------------
Volker Spiegel                                      Phone: ++49 391 67
13547
Dept. of Medical Informatics                        FAX  : ++49 391 67
13536
University of Magdeburg
Leipziger Strasse 44
39120 Magdeburg, Germany

email:    [email-masked]
homepage: http://www.uni-hildesheim.de/~vspi0124
------------------------------------------------------------------------------

Date: Wed, 29 Oct 1997 00:27:42 -0800 (PST)
From: [email-masked]
Subject: Comments on Certs Draft
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BCE3FF.F92F17F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sorry this took so long, they keep trying to get me to ship something =
here.

1.  I don't like the use of MD2 and I know of no Cryptographer who =
does.   I realize that some companies are still using it and that is =
why I am not suggesting a complete elimiation of it from the document, =
however I would like the have the following changes made:
=20
Section 4.3 changed the second sentence to:
A receiving agent MUST be capable of verifying the signatures on =
certificates andCRLs made with md5WithRSAEncryption and =
sha-1WithRSAEncryption signature algorithms with key sizes from 512 =
bits to 2048 bits described in [SMIME-MSG].  A receiving agent SHOULD =
be capable of verifying the signatures on certificates and CRLs made =
with the md2WithRSAEncryption signature algorithm with key sizes from =
512 bits to 2048 bits.
=20
Section 5.2 Third paragraph, second sentence to:
Certification authorities MUST support sha-1WithRSAEncryption and =
md5WithRSAEncryption and SHOULD support MD2WithRSAEncryption for =
verification of signatures on certificate requests as described in =
[SMIME-MSG].
=20
Section 5.2 Fourth paragraph is replace with:
For the creation and submission of certification-requests, RSA keys =
SHOULD be identified with the rsaEncryption OID and signed with the =
sha-1WithRSAEncryption signature algorithm.  Certification-request MUST =
NOT be signed with the md2WithRSAEncryption signature algorithm.
=20
2.  I don't think that any certificates other than End-User =
certificates should be required to have an Internet mail address.
=20
Section 2.2  Change Certificates to End-User certificates in the second =
sentence.
=20
3.  I don't have a good idea for how to change this, but I don't like =
the fact that sections 2.2 and 2.3 are so related and appear at first =
glance to have the same title, but are not the same.  Perhaps section =
2.2 and 2.2.1 should become subsections in 2.3.
=20
4.  Delete paragraph 2 in section 2.3.  This has already been covered =
in section 2.2 and is also covered in 3.1.
=20
5.  Section 4.4  Since we have removed all of the other references to =
certificatePolices, it should also be removed from the last sentence of =
the first paragraph.  Nobody knows how to correctly deal with =
certificatePolices anyway.
 =20
6.  Section 5.1
It appears to me that the last two paragraphs are contradictory with =
respect to MUST and SHOULD.  I suggest that the MUST in the next to =
last paragraph be changed to a SHOULD to make them match.  I don't see =
how a client application can do a good job of supporting multiple valid =
CA certificates with different keys without supporting the =
AuthorityKeyIdentificer extension.
=20
Jim Schaad
=20

------=_NextPart_000_0005_01BCE3FF.F92F17F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Comments on Certs Draft</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sorry this took so =
long, they keep trying to get me to ship something here.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">1.=A0 I don't like =
the use of MD2 and I know of no Cryptographer who does.=A0=A0 I realize =
that some companies are still using it and that is why I am not =
suggesting a complete elimiation of it from the document, however I =
would like the have the following changes made:</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Section 4.3 changed =
the second sentence to:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">A receiving agent =
MUST be capable of verifying the signatures on certificates andCRLs =
made with md5WithRSAEncryption and sha-1WithRSAEncryption signature =
algorithms with key sizes from 512 bits to 2048 bits described in =
[SMIME-MSG].=A0 A receiving agent SHOULD be capable of verifying the =
signatures on certificates and CRLs made with the md2WithRSAEncryption =
signature algorithm with key sizes from 512 bits to 2048 =
bits.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Section 5.2 Third =
paragraph, second sentence to:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Certification =
authorities MUST support sha-1WithRSAEncryption and =
md5WithRSAEncryption and SHOULD support MD2WithRSAEncryption for =
verification of signatures on certificate requests as described in =
[SMIME-MSG].</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Section 5.2 Fourth =
paragraph is replace with:</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">For the creation =
and submission of certification-requests, RSA keys SHOULD be identified =
with the rsaEncryption OID and signed with the sha-1WithRSAEncryption =
signature algorithm.=A0 Certification-request MUST NOT be signed with =
the md2WithRSAEncryption signature algorithm.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">2.=A0 I don't think =
that any certificates other than End-User certificates should be =
required to have an Internet mail address.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Section 2.2=A0 =
Change Certificates to End-User certificates in the second =
sentence.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">3.=A0 I don't have =
a good idea for how to change this, but I don't like the fact that =
sections 2.2 and 2.3 are so related and appear at first glance to have =
the same title, but are not the same.=A0 Perhaps section 2.2 and 2.2.1 =
should become subsections in 2.3.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">4.=A0 Delete =
paragraph 2 in section 2.3.=A0 This has already been covered in section =
2.2 and is also covered in 3.1.</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">5.=A0 Section =
4.4=A0 Since we have removed all of the other references to =
certificatePolices, it should also be removed from the last sentence of =
the first paragraph.=A0 Nobody knows how to correctly deal with =
certificatePolices anyway.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">6.=A0 Section =
5.1</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">It appears to me =
that the last two paragraphs are contradictory with respect to MUST and =
SHOULD.=A0 I suggest that the MUST in the next to last paragraph be =
changed to a SHOULD to make them match.=A0 I don't see how a client =
application can do a good job of supporting multiple valid CA =
certificates with different keys without supporting the =
AuthorityKeyIdentificer extension.</FONT></P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Jim Schaad</FONT>
<BR><FONT COLOR=3D"#000000" FACE=3D"Arial">=A0</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0005_01BCE3FF.F92F17F0--

Date: Tue, 28 Oct 1997 10:25:48 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Last call on S/MIME 2
Sender: [email-masked]

Greetings one more time. There has been almost no discussion of the S/MIME
2 drafts posted last week, which I take to be a Very Good Sign. If there is
nothing more to do on the drafts, I would like to submit them as "final" to
the IESG for consideration as informational RFCs. I'd like to do this over
the weekend, after any face-to-face discussion that might happen at
MailConnect 3 among the implementors there.

So, if you have any more issues about what is in S/MIME 2, please speak up.
Also, you should expect the first drafts of S/MIME 3 later this week, or
early next week at the very latest.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 23 Oct 1997 16:27:09 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: New versions of the drafts
Sender: [email-masked]

At 01:43 PM 10/23/97 -0700, Jim Schaad (Exchange) wrote:
>1. In Section 3.1.4, unless there is something special that I don't
>know, a CTE is required in the example for the image/jpeg.   Recommend:
>Adding "Content-Transfer-Encoding: base64" to the example.

Er, yes. Whoops!

>2.  In section 3.4.33 and section F2,  the application/pkcs7-signature
>lines do not have an smime-type parameter.  I believe that this is
>correct behavior, however it would appear from section E.2 that
>smime-type is an optional parameter for this type.   I recommend that we
>remove smime-type as an optional parameter in section E.2 and E.3.

It should not have gone in sections E.2 and E.3. I have just punished my
fingers for doing that.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: New versions of the drafts
Date: Thu, 23 Oct 1997 15:39:17 -0700
Sender: [email-masked]

On Thursday, October 23, 1997 1:44 PM, Jim Schaad (Exchange)
[SMTP:[email-masked]] wrote:
> 2.  In section 3.4.33 and section F2,  the application/pkcs7-signature
> lines do not have an smime-type parameter.  I believe that this is
> correct behavior, however it would appear from section E.2 that
> smime-type is an optional parameter for this type.   I recommend that we
> remove smime-type as an optional parameter in section E.2 and E.3.
> (Failing that I believe that we need to specify a value(s) for it and
> use it in our examples.)

I agree smime-type is not useful for detached signatures or for
certificate requests.  This should get yanked.  I think this got in by
mistake.

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: New versions of the drafts
Date: Thu, 23 Oct 1997 13:43:50 -0700
Sender: [email-masked]

The following are, to some degree, nitpicks, but here they are:

In the S/MIME Message Specification draft:

1. In Section 3.1.4, unless there is something special that I don't
know, a CTE is required in the example for the image/jpeg.   Recommend:
Adding "Content-Transfer-Encoding: base64" to the example.

2.  In section 3.4.33 and section F2,  the application/pkcs7-signature
lines do not have an smime-type parameter.  I believe that this is
correct behavior, however it would appear from section E.2 that
smime-type is an optional parameter for this type.   I recommend that we
remove smime-type as an optional parameter in section E.2 and E.3.
(Failing that I believe that we need to specify a value(s) for it and
use it in our examples.)

Jim Schaad

Date: Thu, 23 Oct 1997 08:37:47 -0400
From: "G.T. Vienneau" <[email-masked]>
Reply-To: [email-masked]
Organization: National Defence Headquarters/PMO Defence Message Handling System
To: [email-masked]
Subject: Definitions: ref to X.680-9
Sender: [email-masked]

One minor observation concerning the draft-dusse-smime-msg-05:

Section 1.3 ASN.1 definition should read as follows:  

ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-3. 
(versus CCITT X.680-9)

But,

1) X.683 should not be referenced since parameterized types are not
used.

2) X.680-2 do not support anymore "ANY" or "ANY DEFINED BY".  These
notations were replaced by the information object class notation.  The
draft may be rewritten to align itself to X.680-2 (see below) or the
draft would indicate that ASN.1 is defined according to X.208.

Instead of having (see section A):

SMIMECapability ::= SEQUENCE {
    capabilityID OBJECT IDENTIFIER,
    parameters OPTIONAL ANY DEFINED BY capabilityID }  

the following would be used (according to X.680-2):

SMIMECapability ::= SEQUENCE {
    capabilityID CAPABILITY.&id ({SupportedCapabilities}),
    parameters CAPABILITY.&Parameter
({SupportedCapabilities}{@capabilityID}) }      

First, the following information object class would be defined:

CAPABILITY CLASS ::= {
        &id     OBJECT IDENTIFIER UNIQUE,
        &Parameter      
}
WITH SYNTAX
{
        ID      &id
        [PARAMETER &Parameter]
}

Each capability would then be defined:

RC2-CBC OBJECT IDENTIFIER ::=
    {iso(1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3)
2}

SMIMECapabilitiesParametersForRC2CBC ::= INTEGER

rc2-CBC CAPABILITY ::= {
        ID              RC2-CBC
        PARAMETER       SMIMECapabilitiesParametersForRC2CBC
}

an other example:

DES-CBC OBJECT IDENTIFIER ::=
    {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 7}

des-cbc CAPABILITY ::= {
        ID              DES-CBC
-- no parameter
}

Finally, you would have something like:

SupportedCapabilities CAPABILITY ::= {rc2-CBC | des-cbc}  -- more
capabilities would exist...
-- 
Y. Theriault, Capt
Hardware Engineer
Project Management Office
Defence Message Handling System
Department of National Defence
phone:  995-6476
fax  :  995-6456
e-mail: [email-masked]

Date: Wed, 22 Oct 1997 18:52:34 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New versions of the drafts
Sender: [email-masked]

One more time, with feeling. New versions of the S/MIME v2 drafts are now
available.

==========

Message draft: <http://www.imc.org/draft-dusse-smime-msg>

I believe that we're done with this. John Myers objections to our use of
application/mime caused the application/mime draft to be changed.

The following changes were made between the -04 and -05 revisions of
this draft based on comments from Kazuhiko Yamamoto:

Fixed errors in the MIME examples in 3.1.4, 3.4.3.3, and F.2 where the
base64 text didn't have a blank line before the separator.

In 3.1.1, changed "character set" to "charset" and added a reference to
the list of registered charsets.

==========

Certificates draft: <http://www.imc.org/draft-dusse-smime-cert>

I do *not* believe that we're done here. I incorporated the changes that
people who commented seemed to agree on, but there were other comments that
I couldn't incorporate. Let's do (at least) one more round on this. Of
course, we can't be completely specific here because it is based on PKIX
which is still a bit of a moving target. However, let's make sure all v 2
implementors can implement from this spec to the best of our abilities.

Also, instead of commenting with questions, please make all your comments
suggested wording changes. It's OK if others object to your changes, but
starting from a question won't get a change in if no one answers.

The following changes were made between the -03 and -04 revisions of
this draft:

In 2.1, changed "revocation time" to "nextUpdate time".

In 2.1, removed the somewhat ambiguous sentence about agents retrieving
CRLs in any fashion they are provided.

In 2.3, added "Clients MUST support chaining based on the
distinguished name and SHOULD support chaining based on the
subjectAltName field."

In 4.4, replaced last paragraph with explanation of what should and
shouldn't be marked as critical.

In 4.4.1, added "Certificates SHOULD contain a basicContstraints
extension."

Open issue: what is the OID being referred to in 5.2?
--Paul Hoffman, Director
--Internet Mail Consortium

Date: Mon, 20 Oct 1997 08:05:21 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Simplifying S/MIME v3
Sender: [email-masked]

All,

I withdraw my proposal to eliminate support for "signedAndEnvelopedData" in
the future S/MIME v3 Message Specification.  My proposal was premature since
the first draft S/MIME v3 set of specs have not yet been submitted to the
mail list (or future IETF S/MIME WG).  If appropriate, I will re-submit the
proposal after the first draft set of S/MIME v3 specs have been submitted.

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

At 08:30 AM 10/15/97, [email-masked] wrote:
>All,
>
>Based on Russ Housley's message and the minimal value added by
signedAndEnvelopedData, I re-submit my proposal as follows:
>
>When the new S/MIME v3 Message Specification is written, I propose that
>Section 2.4 should be replaced by the following:  "The PKCS #7 v1.5
>specification defines six distinct content types: "data", "signedData",
>"envelopedData", "signedAndEnvelopedData", "digestedData", and
>"encryptedData".  The "signedAndEnvelopedData" content type is not
supported as part of the S/MIME 3 set of specifications.  Sending agents
MUST NOT send the "signedAndEnvelopedData" content type, but may they may
send any of the other content types depending on the services that the agent
supports.  Receiving agents MUST support the "data", "signedData" and
"envelopedData" content types.  Receiving agents are not required to support
the "signedAndEnvelopedData" content type."
>
>Does anybody disagree with this proposal to eliminate support for the
"signedAndEnvelopedData" content type?
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>At 02:24 PM 10/14/97 -0400, Russ Housley wrote:
>>signedandEnvelopedData has a flaw.  An attacker can stip the signature from
>>the message, then by changing the OID, the recipient will think that the
>>message we encrypted.
>>
>>This attack is mitigated by using signedData and envelopedData independently.
>>
>>Russ
>>
>

From: Steve Dusse <[email-masked]>
To: [email-masked], "'Russ Housley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposed charter for a S/MIME working group
Date: Thu, 16 Oct 1997 10:12:19 -0700
Sender: [email-masked]

> >1. What is the "message syntax specification" listed above for
> October 97?
> 
> PKCS#7 v1.7.  However, RSADSI does not want the IETF derivative work
> to be
> called PKCS.  We need a name.  Suggestions welcome.
> 
	How about MSP ?

Date: Wed, 15 Oct 1997 16:40:01 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Proposed charter for a S/MIME working group
Cc: [email-masked]
Sender: [email-masked]

Dave:

>1. What is the "message syntax specification" listed above for October 97?

PKCS#7 v1.7.  However, RSADSI does not want the IETF derivative work to be
called PKCS.  We need a name.  Suggestions welcome.

>2. Will IETF-S/MIME v3 refer to PKCS#7 v2 before becoming a Proposed Standard
>    in Jan 98?

No.  S/MIME v3 will be based on PKCS#7 v1.7, regardless of the final name
of the document.

>3. If not 2, will IETF-S/MIME ever be based on PKCS#7 v2?

No.  Backward compatibility was determined to be more important that PKCS#7
v2.0 conformance.

>4. If not 3, what purpose is served by continuing to develop PKCS#7 to v2
>    and beyond, and encouraging it to use techniques compatible with the
>    MSP-S/MIME work?

S/MIME is not the only user of PKCS#7.  Some of the other users need PKCS#7
v2.0 features.

>5. Will PKCS#7 v2 be submitted to the IETF in any form (Informational
>    or Standards Track), in any forum (IETF-S/MIME or elsewhere)?

This is up to RSADSI.  It is their work.  They can do as they wish.

Russ

Date: Wed, 15 Oct 1997 08:51:09 -0400
To: "Jim Schaad (Exchange)" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: SMIMECapabilities Attribute
Cc: "Blake Ramsdell" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Jim:

I agree.  Pointing to a certificate in the existing PKCS#7 "bag of
certificates" is better.

Russ

At 12:56 AM 10/8/97 -0700, Jim Schaad (Exchange) wrote:
>I have massive complaints about having two (or more) cert chains for the
>purpose of conveying the difference between key exchange and signing
>certs.  The overhead of carrying multiple chains (almost a certanty for
>some products) is really bad in terms of message size.  This is
>especially true given the current size and expected size of
>certificates.  
>
>I have no specific objection to an authenticated property which say --
>this is what you should use for my key exchange certificate, but I see
>no real value in any more than this.  The process of building
>certificate chains for verification needs to be done any event as one
>cannot rely that the chain provided will be either correct or useful any
>more  (certificates in the chain may have expired or been revoked).  
>
>jim
>
>
>> -----Original Message-----
>> From:	Blake Ramsdell [SMTP:[email-masked]]
>> Sent:	Tuesday, October 07, 1997 4:10 PM
>> To:	'Russ Housley'
>> Cc:	[email-masked]'
>> Subject:	RE: SMIMECapabilities Attribute
>> 
>> On Tuesday, October 07, 1997 7:15 AM, Russ Housley
>> [SMTP:[email-masked]] wrote:
>> > So, you suggest that key management certificates be carried in the
>> existing
>> > SET OF ExtendedCertificateOrCertificate.  This is fine with me.
>> 
>> I had to think about this for a couple of minutes (I'm thick
>> sometimes).
>>  The optional certificates field in SignedData can contain any
>> certificates -- it is not limited to the signing cert chain at all, so
>> it is perfectly acceptable to put your key exchange cert chain in here
>> also.  We can change the language in the spec to specify this also.
>> 
>> What made me start thinking was that a criticism in the past has been
>> that dumping a bunch of certificates in a pile is not as useful as
>> assigning some kind of structure.  I think it bears thinking about
>> having two separate authenticated attributes, one for the key exchange
>> cert chain and one for the signing cert chain.  For instance:
>> 
>> SMIMESigningCertChain ::= SEQUENCE OF Certificate
>> SMIMEKeyExchangeCertChain ::= SEQUENCE OF Certificate
>> 
>> This way, there is a clear separation between the certs that are used
>> for signing and the certs used for enveloping.  The downside is that
>> if
>> there are any common certs in the chain (for the same PCA in a
>> hierarchy, for instance), then these will be transmitted redundantly.
>> 
>> Jeff's point is a valid one also (not the one I was trying to make,
>> however...  I'll take credit for it, though.) -- if the goal is to be
>> able to specify what exactly is the enveloping cert for the signer of
>> the message, you can dump that cert in the existing certificates
>> member
>> of SignedData, and then have an authenticatedAttribute that specifies
>> the issuerAndSerialNumber (or whatever -- that's something else that
>> needs to be finalized) of the cert to use for enveloping.  My original
>> point was to include the actual certs (as I mentioned above) -- not a
>> reference.
>> 
>> 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, 15 Oct 1997 08:40:18 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Simplifying S/MIME v3
Sender: [email-masked]

All,

Based on Russ Housley's message and the minimal value added by
signedAndEnvelopedData, I re-submit my proposal as follows:

When the new S/MIME v3 Message Specification is written, I propose that
Section 2.4 should be replaced by the following:  "The PKCS #7 v1.5
specification defines six distinct content types: "data", "signedData",
"envelopedData", "signedAndEnvelopedData", "digestedData", and
"encryptedData".  The "signedAndEnvelopedData" content type is not supported
as part of the S/MIME 3 set of specifications.  Sending agents MUST NOT send
the "signedAndEnvelopedData" content type, but may they may send any of the
other content types depending on the services that the agent supports.
Receiving agents MUST support the "data", "signedData" and "envelopedData"
content types.  Receiving agents are not required to support the
"signedAndEnvelopedData" content type."

Does anybody disagree with this proposal to eliminate support for the
"signedAndEnvelopedData" content type?

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

At 02:24 PM 10/14/97 -0400, Russ Housley wrote:
>signedandEnvelopedData has a flaw.  An attacker can stip the signature from
>the message, then by changing the OID, the recipient will think that the
>message we encrypted.
>
>This attack is mitigated by using signedData and envelopedData independently.
>
>Russ
>

Date: Wed, 15 Oct 1997 12:19:08 +0100
To: [email-masked] (John Pawling)
From: Graham Klyne <[email-masked]>
Subject: Re: Simplifying S/MIME v3
Cc: [email-masked]
Sender: [email-masked]

At 04:21 PM 10/14/97 -0400, John Pawling wrote:
>All,
>
>I am forwarding Peter Williams' response to my earlier message because I
>believe that it important for everyone to know of his reasons for requesting
>continued support of the SignedAndEnvelopedData content type in the "S/MIME
>v3" set of specifications.  Please respect his request that he no longer
>wishes to take part directly in the debate of this issue.
>
>Is there anybody else who has an opinion regarding the continued support of
>the SignedAndEnvelopedData content type in the "S/MIME v3" set of
>specifications??

I have scanned through that, and feel there are some very important issues
being raised.  But I do not understand enough of what is being said to make
a judgement.  Can anyone point me to a reasonably concise tutorial
(preferably on the 'net) of the issues being discussed here?

GK.
---

------------
Graham Klyne
[email-masked]

Date: Tue, 14 Oct 1997 14:24:17 -0400
To: "Peter Williams" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Simplifying S/MIME v3
Cc: [email-masked], [email-masked]
Sender: [email-masked]

signedandEnvelopedData has a flaw.  An attacker can stip the signature from
the message, then by changing the OID, the recipient will think that the
message we encrypted.

This attack is mitigated by using signedData and envelopedData independently.

Russ

Date: Tue, 14 Oct 1997 16:21:54 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Simplifying S/MIME v3
Sender: [email-masked]

All,

I am forwarding Peter Williams' response to my earlier message because I
believe that it important for everyone to know of his reasons for requesting
continued support of the SignedAndEnvelopedData content type in the "S/MIME
v3" set of specifications.  Please respect his request that he no longer
wishes to take part directly in the debate of this issue.

Is there anybody else who has an opinion regarding the continued support of
the SignedAndEnvelopedData content type in the "S/MIME v3" set of
specifications??

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

>Return-Path: <[email-masked]>
>Reply-To: "Peter Williams" <[email-masked]>
>From: "Peter Williams" <[email-masked]>
>To: "John Pawling" <[email-masked]>
>Subject: Re: Simplifying S/MIME v3
>Date: Tue, 14 Oct 1997 11:02:14 -0700
>X-Msmail-Priority: Normal
>X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
>
>John,
>
>This is the last mail Im sending on the topic, so as to avoid any argument.
>Those who are building UAs or relaying MTAs should really define these
>messaging needs, not CA vendors. Its only because the msging semantic
>involves advanced legal-signing semantics, guaranteed by the
>CA policy, that I even mention it. My aim was to encourage people to look
>out
>two years towards the needs of real business users for signing and
>EDI  message-release semantics, and allow feature options to accomodate
>future needs.
>
>I have argued for 24 months that the existing, optionally-deployed
>SignedAndEnveloped capability offers an unparalleled semantic. It
>ensure that the originator **always** controls **authorized reliance** on
>the
>signature; this is not true of any other construct, to my knowledge.
>
>The semantic is particularly useful when a signed message
>(for an offer "to sell at price p" letter, say) is to be distributed over
>public networks, but the offer is only intended to be
>applicable to a nominated set of preferred recipients/buyers.
>
>This vital  commercial semantic cannot be protected by any other
>S/MIME construct. A recipient of an encrypted mail may at any time forward
>an inner bodypart, independent of its outer wrapper. While we
>cannot prevent anyone forwarding the eventual payload of
>a commercial implemenation's S/MIME message, or attributes of signedData
>envelopes, we can prevent these bearing a legally-binding signature
>except under legal reliance controls defined by the originator (and enforced
>by conforming SignedandEnveloped implementations)  on a per-recipient
>basis.
>
>Remember, S/MIME signing is not only about ensuring identification of msg
>origin; its also about automating long-standing commercial protocols
>involving
>authorization and release of  signed payload -- because of the legal act or
>consequences which origination inherently represents.
>
>You can summarize this argument on the list if you wish; I no longer
>wish to take part directly.
>
>-----Original Message-----
>From: John Pawling <[email-masked]>
>To: Peter Williams <[email-masked]>; [email-masked]
><[email-masked]>
>Date: Tuesday, October 14, 1997 6:51 AM
>Subject: Re: Simplifying S/MIME v3
>
>
>>Peter,
>>
>>Thank you very much for your responses.
>>
>>I agree that digestedData and EncryptedData offer unique services that may
>>be required by some S/MIME-enabled applications, so they should not be
>>prohibited by the "S/MIME v3" set of specs.
>>
>>I respectfully disagree that signedAndEnvelopedData should be supported in
>>the "S/MIME v3" set of specs.
>>
>>You made the following point:
>>>signedandEnvelopedData is very useful as it offers a service
>>>not available otherwise - as only the intendedRecipient
>>>is authorised to verify the signatures. The property is a function
>>>of the integrated nature of the signing/encryption. This is a specialised
>>>service.
>>
>>There are two options provided by PKCS #7 v1.5 for signing and encrypting
>data:
>>
>>1) sign the data using signedData and then encrypt the signedData using
>>EnvelopedData.
>>
>>2) sign the data and encrypt the data using signedAndEnvelopedData.
>>
>>In my opinion, signedAndEnvelopedData does not add any value over the
>>signedData/EnvelopedData option.  In both cases, only the intended
>>recipients can verify the signature.  In the signedAndEnvelopedData option,
>>the signature value is encrypted using the MEK, but (IMHO) that feature
>>doesn't add any value.  The recipient of the signedAndEnvelopedData object
>>can decrypt the content and signature value and then convert that
>>information into a signedData object which can then be forwarded to a third
>>party just as if the signedData were received encapsulated within an
>>EnvelopedData object.  Therefore, I don't see any benefit provided by the
>>signedAndEnvelopedData regarding the "integrated nature of the
>>signing/encryption".
>>
>>
>>You stated:
>>>The current language is clear; no-one need implement the optional
>elements,
>>
>>However, if one vendor chooses to send only signedAndEnvelopedData objects
>>(as allowed by the current S/MIME spec) and another vendor chooses not to
>>implement signedAndEnvelopedData at all (as also allowed by the current
>>S/MIME spec), then there is not going to be interoperability between the
>two
>>products.  Both vendors can claim compliance to the spec, but their
>products
>>are not interoperable.  In my opinion, that is a condition that is
>>unacceptable and needs to be rectified in the "S/MIME v3" set of specs.
>>
>>In summary, I believe that the signedAndEnvelopedData option adds compexity
>>to the S/MIME v3 environment without adding any value and should be
>>prohibited in the S/MIME v3 set of specs.
>>
>>================================
>>John Pawling
>>[email-masked]
>>J.G. Van Dyke & Associates, Inc.
>>================================
>>
>>
>>At 10:08 AM 10/9/97 -0700, Peter Williams wrote:
>>>
>>>-----Original Message-----
>>>From: John Pawling <[email-masked]>
>>>To: [email-masked] <[email-masked]>
>>>Date: Thursday, October 09, 1997 5:49 AM
>>>Subject: Simplifying S/MIME v3
>>>
>>>
>>>>All,
>>>>
>>>>The draft charter for the proposed IETF S/MIME Working Group includes
>plans
>>>>for developing a new S/MIME v3 Message Specification as a separate
>document
>>>>from the 23 Sep 1997 Internet Draft S/MIME Message Specification (also
>>>known
>>>>as S/MIME v2 Message Specification).  This message includes a proposal
>for
>>>>simplifying the future S/MIME v3 Message Specification.
>>>>
>>>>The 23 Sep 97 S/MIME Message Specification, Section 2.4, General Syntax,
>>>>states:  "The PKCS #7 defines six distinct content types: "data",
>>>>"signedData", "envelopedData", "signedAndEnvelopedData", "digestedData",
>>>and
>>>>"encryptedData". Receiving agents MUST support the "data", "signedData"
>and
>>>>"envelopedData" content types. Sending agents may or may not send out any
>>>of
>>>>the content types, depending on the services that the agent supports."
>>>>
>>>>This paragraph implies that an agent SHOULD support receiving the
>>>>"digestedData", "encryptedData" and "signedAndEnvelopedData" content
>types.
>>>>If a sending agent were to send one of these content types to a receiving
>>>>agent that did not support that type, then that receiving agent would
>>>>encounter an error condition.
>>>>
>>>>
>>>>When the new S/MIME v3 Message Specification is written, we propose that
>>>>Section 2.4 should be replaced by the following:  "The PKCS #7 v1.5
>>>>specification defines six distinct content types: "data", "signedData",
>>>>"envelopedData", "signedAndEnvelopedData", "digestedData", and
>>>>"encryptedData".  Sending agents may send the "data", "signedData" and
>>>>"envelopedData" content types, depending on the services that the agent
>>>>supports.  Receiving agents MUST support the "data", "signedData" and
>>>>"envelopedData" content types.  The "digestedData", "encryptedData" and
>>>>"signedAndEnvelopedData" content types are not supported as part of the
>>>>S/MIME 3 set of specifications.  Sending agents MUST NOT send the
>>>>"digestedData", "encryptedData"  or "signedAndEnvelopedData" content
>types.
>>>>Receiving agents are not required to support the "digestedData",
>>>>"encryptedData"  or "signedAndEnvelopedData" content types."
>>>>
>>>>Does anybody object to removing support for sending and receiving the
>>>>"digestedData", "encryptedData"  or "signedAndEnvelopedData" content
>types?
>>>>Please provide comments.
>>>>
>>>
>>>Yes.
>>>
>>>Encrypted Data is a value-add option for S/MIME implementations: having
>>>established pairwise keys, an encrypted msg may simply reuse keying
>>>material without having the overhead of indicating/agreeing/transporting
>>>keys.
>>>
>>>signedandEnvelopedData is very useful as it offers a service
>>>not available otherwise - as only the intendedRecipient
>>>is authorised to verify the signatures. The property is a function
>>>of the integrated nature of the signing/encryption. This is a specialised
>>>service.
>>>
>>>DigestedData is used heavily in SET to address linking attacks
>>>in multi-phase, multi-party messenging protocols, and shows lots of
>>>potential to be used much as Encrypted Data - where an integrity
>>>key has been previously established, subsequent mails may
>>>be sent using digestedData, rather than signedData.
>>>
>>>These functions are not "current" in the sort of emailish privacy-centric
>>>notion of S/MIME that we have around in the market at the current time.
>>>Where
>>>S/MIME is used in http or SSL however, it is more than likely that should
>a
>>>party
>>>define a custom SSL3 record-layer protocol (as they are entitlted) in
>which
>>>the current keys of the state/connection are used, then the S/MIME
>>>mechanisms
>>>(including the above) may well be used as the message formats. Why invent
>a
>>>new
>>>one, one might ask.
>>>
>>>The current language is clear; no-one need implement the optional
>elements,
>>> particulary where there is yet little momentum for more refined
>>>business-like
>>>S/MIME applications dealing with secure relay-centric messenging, versus
>>>merely secure inter-personal mail or end-end EDI. Denying
>>>the use would seem harsh, and prevent S/MIME evolving to
>>>satisfy other uses/enviornments  that personal or EDI mail services.
>>>
>>>>
>>>>==============================================================
>>>>John Pawling                               (301) 953-3600
>>>>J.G. Van Dyke & Associates, Inc.           (410) 880-6095
>>>>141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
>>>>Annapolis Junction, MD  20701              [email-masked]
>>>>
>>>>
>>>
>>>
>>
>>
>
>

From: [email-masked]
Date: Tue, 14 Oct 1997 07:47:15 -0600
To: [email-masked] (John Pawling), [email-masked]
Subject: RE: Simplifying S/MIME v3
Sender: [email-masked]

I second the motion.  Speaking from this end of the key pair, we're seeing
uses of PKCS-7 encapsulation that have nothing to do with secure electronic
mail.

At 10:11 AM 10/14/97 -0400, John Pawling wrote:
>All,
>
>I believe that Blake makes a good point that the S/MIME specs specify how to
>use PKCS #7 to protect MIME-encapsulated data.  There needs to be separate
>specs that specify how to use PKCS #7 to protect non-MIME-encapsulated
data.  
>
>================================
>John Pawling   
>[email-masked]                             
>J.G. Van Dyke & Associates, Inc.           
>================================
>
>
>At 12:52 PM 10/9/97 -0700, Blake Ramsdell wrote:
>>On Thursday, October 09, 1997 10:09 AM, Peter Williams
>>[SMTP:[email-masked]] wrote:
>>> These functions are not "current" in the sort of emailish privacy-centric
>>> notion of S/MIME that we have around in the market at the current time.
>>> Where
>>> S/MIME is used in http or SSL however, it is more than likely that
should a
>>> party
>>> define a custom SSL3 record-layer protocol (as they are entitlted) in
which
>>> the current keys of the state/connection are used, then the S/MIME
>>> mechanisms
>>> (including the above) may well be used as the message formats. Why
invent a
>>> new
>>> one, one might ask.
>>
>>I don't disagree with the argument that these constructs serve a purpose
>>in the universe.  The question is, do they serve a purpose in all of the
>>problem domain that we are working on (that being defined as security
>>services for MIME entities, regardless of transport), or are they only
>>useful in a subset of the problem domain (HTTP / SSL-specific
>>transport).  I think the answer is the latter, and so to the extent that
>>we would like to support these constructs, we should create a separate
>>draft that explains their use for that particular transport.
>>
>>You may have a point about signedAndEnvelopedData (forcing the fact that
>>only a recipient may validate the signature), and I welcome more
>>discussion about that.  My gut feeling is that no one is going to care
>>about that particular semantic, so it boils down to implementation
>>complexity vs. utility.
>>
>>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: Tue, 14 Oct 1997 10:11:20 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: RE: Simplifying S/MIME v3
Sender: [email-masked]

All,

I believe that Blake makes a good point that the S/MIME specs specify how to
use PKCS #7 to protect MIME-encapsulated data.  There needs to be separate
specs that specify how to use PKCS #7 to protect non-MIME-encapsulated data.  

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

At 12:52 PM 10/9/97 -0700, Blake Ramsdell wrote:
>On Thursday, October 09, 1997 10:09 AM, Peter Williams
>[SMTP:[email-masked]] wrote:
>> These functions are not "current" in the sort of emailish privacy-centric
>> notion of S/MIME that we have around in the market at the current time.
>> Where
>> S/MIME is used in http or SSL however, it is more than likely that should a
>> party
>> define a custom SSL3 record-layer protocol (as they are entitlted) in which
>> the current keys of the state/connection are used, then the S/MIME
>> mechanisms
>> (including the above) may well be used as the message formats. Why invent a
>> new
>> one, one might ask.
>
>I don't disagree with the argument that these constructs serve a purpose
>in the universe.  The question is, do they serve a purpose in all of the
>problem domain that we are working on (that being defined as security
>services for MIME entities, regardless of transport), or are they only
>useful in a subset of the problem domain (HTTP / SSL-specific
>transport).  I think the answer is the latter, and so to the extent that
>we would like to support these constructs, we should create a separate
>draft that explains their use for that particular transport.
>
>You may have a point about signedAndEnvelopedData (forcing the fact that
>only a recipient may validate the signature), and I welcome more
>discussion about that.  My gut feeling is that no one is going to care
>about that particular semantic, so it boils down to implementation
>complexity vs. utility.
>
>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: Tue, 14 Oct 1997 10:04:58 -0400
To: "Peter Williams" <[email-masked]>, <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Simplifying S/MIME v3
Sender: [email-masked]

Peter,

Thank you very much for your responses.  

I agree that digestedData and EncryptedData offer unique services that may
be required by some S/MIME-enabled applications, so they should not be
prohibited by the "S/MIME v3" set of specs.

I respectfully disagree that signedAndEnvelopedData should be supported in
the "S/MIME v3" set of specs.

You made the following point:
>signedandEnvelopedData is very useful as it offers a service
>not available otherwise - as only the intendedRecipient
>is authorised to verify the signatures. The property is a function
>of the integrated nature of the signing/encryption. This is a specialised
>service.

There are two options provided by PKCS #7 v1.5 for signing and encrypting data:

1) sign the data using signedData and then encrypt the signedData using
EnvelopedData.

2) sign the data and encrypt the data using signedAndEnvelopedData.

In my opinion, signedAndEnvelopedData does not add any value over the
signedData/EnvelopedData option.  In both cases, only the intended
recipients can verify the signature.  In the signedAndEnvelopedData option,
the signature value is encrypted using the MEK, but (IMHO) that feature
doesn't add any value.  The recipient of the signedAndEnvelopedData object
can decrypt the content and signature value and then convert that
information into a signedData object which can then be forwarded to a third
party just as if the signedData were received encapsulated within an
EnvelopedData object.  Therefore, I don't see any benefit provided by the
signedAndEnvelopedData regarding the "integrated nature of the
signing/encryption".

You stated:
>The current language is clear; no-one need implement the optional elements,

However, if one vendor chooses to send only signedAndEnvelopedData objects
(as allowed by the current S/MIME spec) and another vendor chooses not to
implement signedAndEnvelopedData at all (as also allowed by the current
S/MIME spec), then there is not going to be interoperability between the two
products.  Both vendors can claim compliance to the spec, but their products
are not interoperable.  In my opinion, that is a condition that is
unacceptable and needs to be rectified in the "S/MIME v3" set of specs.

In summary, I believe that the signedAndEnvelopedData option adds compexity
to the S/MIME v3 environment without adding any value and should be
prohibited in the S/MIME v3 set of specs.

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

At 10:08 AM 10/9/97 -0700, Peter Williams wrote:
>
>-----Original Message-----
>From: John Pawling <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Thursday, October 09, 1997 5:49 AM
>Subject: Simplifying S/MIME v3
>
>
>>All,
>>
>>The draft charter for the proposed IETF S/MIME Working Group includes plans
>>for developing a new S/MIME v3 Message Specification as a separate document
>>from the 23 Sep 1997 Internet Draft S/MIME Message Specification (also
>known
>>as S/MIME v2 Message Specification).  This message includes a proposal for
>>simplifying the future S/MIME v3 Message Specification.
>>
>>The 23 Sep 97 S/MIME Message Specification, Section 2.4, General Syntax,
>>states:  "The PKCS #7 defines six distinct content types: "data",
>>"signedData", "envelopedData", "signedAndEnvelopedData", "digestedData",
>and
>>"encryptedData". Receiving agents MUST support the "data", "signedData" and
>>"envelopedData" content types. Sending agents may or may not send out any
>of
>>the content types, depending on the services that the agent supports."
>>
>>This paragraph implies that an agent SHOULD support receiving the
>>"digestedData", "encryptedData" and "signedAndEnvelopedData" content types.
>>If a sending agent were to send one of these content types to a receiving
>>agent that did not support that type, then that receiving agent would
>>encounter an error condition.
>>
>>
>>When the new S/MIME v3 Message Specification is written, we propose that
>>Section 2.4 should be replaced by the following:  "The PKCS #7 v1.5
>>specification defines six distinct content types: "data", "signedData",
>>"envelopedData", "signedAndEnvelopedData", "digestedData", and
>>"encryptedData".  Sending agents may send the "data", "signedData" and
>>"envelopedData" content types, depending on the services that the agent
>>supports.  Receiving agents MUST support the "data", "signedData" and
>>"envelopedData" content types.  The "digestedData", "encryptedData" and
>>"signedAndEnvelopedData" content types are not supported as part of the
>>S/MIME 3 set of specifications.  Sending agents MUST NOT send the
>>"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types.
>>Receiving agents are not required to support the "digestedData",
>>"encryptedData"  or "signedAndEnvelopedData" content types."
>>
>>Does anybody object to removing support for sending and receiving the
>>"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types?
>>Please provide comments.
>>
>
>Yes.
>
>Encrypted Data is a value-add option for S/MIME implementations: having
>established pairwise keys, an encrypted msg may simply reuse keying
>material without having the overhead of indicating/agreeing/transporting
>keys.
>
>signedandEnvelopedData is very useful as it offers a service
>not available otherwise - as only the intendedRecipient
>is authorised to verify the signatures. The property is a function
>of the integrated nature of the signing/encryption. This is a specialised
>service.
>
>DigestedData is used heavily in SET to address linking attacks
>in multi-phase, multi-party messenging protocols, and shows lots of
>potential to be used much as Encrypted Data - where an integrity
>key has been previously established, subsequent mails may
>be sent using digestedData, rather than signedData.
>
>These functions are not "current" in the sort of emailish privacy-centric
>notion of S/MIME that we have around in the market at the current time.
>Where
>S/MIME is used in http or SSL however, it is more than likely that should a
>party
>define a custom SSL3 record-layer protocol (as they are entitlted) in which
>the current keys of the state/connection are used, then the S/MIME
>mechanisms
>(including the above) may well be used as the message formats. Why invent a
>new
>one, one might ask.
>
>The current language is clear; no-one need implement the optional elements,
> particulary where there is yet little momentum for more refined
>business-like
>S/MIME applications dealing with secure relay-centric messenging, versus
>merely secure inter-personal mail or end-end EDI. Denying
>the use would seem harsh, and prevent S/MIME evolving to
>satisfy other uses/enviornments  that personal or EDI mail services.
>
>>
>>==============================================================
>>John Pawling                               (301) 953-3600
>>J.G. Van Dyke & Associates, Inc.           (410) 880-6095
>>141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
>>Annapolis Junction, MD  20701              [email-masked]
>>
>>
>
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked]
Subject: RE: Proposed charter for a S/MIME working group
Date: Tue, 14 Oct 1997 01:17:19 -0700
Sender: [email-masked]

I'm happy with the charter as it currently stands.  The only possible
problem is the rather aggressive schedule for putting out the documets,
but that will take care of itself as necessary.

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[email-masked]]
> Sent:	Tuesday, September 30, 1997 12:37 PM
> To:	[email-masked]
> Subject:	Proposed charter for a S/MIME working group
> 
> Greetings, all. As you saw last week, RSA has sent the ISOC material
> that
> (hopefully) meets the IESG's requirements for what must happen before
> we
> form an S/MIME working group. So, our next task is to agree on a
> charter
> and submit it to Jeff Schiller, the area director for security. If
> Jeff
> agrees, he'll take it to the IESG for their consideration.
> 
> Below is what I think a reasonable charter should look like. All
> comments
> are welcome.
> 
> = = = = = = = = =
> 
> S/MIME Mail Security (smime)
> 
> Chair:
>      Russ Housley <[email-masked]>
> 
> Security Area Director:
>      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. 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, 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 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.
> 
> 
> Goals and Milestones:
> 
> History:
>      PKCS #7 version 1.5 specification submitted as Informational RFC.
>      S/MIME v2 message specification submitted as Informational RFC.
>      S/MIME v2 certificate specification submitted as Informational
> RFC.
> 
> October 97:
>      First draft of message syntax specification.
>      First draft of S/MIME v3 message specification.
>      First draft of S/MIME v3 certificate specification.
>      First draft of S/MIME optional security extensions.
> 
> December 97:
>      Last call on message syntax specification.
>      Last call on S/MIME v3 message specification.
>      Last call on S/MIME v3 certificate specification.
> 
> January 98:
>      Last call on S/MIME optional security extensions.
>      Submit  message syntax specification as a Proposed Standard.
>      Submit S/MIME v3 message specification as a Proposed Standard.
>      Submit S/MIME v3 certificate specification as a Proposed
> Standard.
> 
> February 98:
>      Submit S/MIME optional security extensions as a Proposed
> Standard.
> 
> --Paul E. Hoffman, Director
> --Internet Mail Consortium
> 

Posted-Date: Thu, 9 Oct 1997 20:36:48 -0500 (CDT)
Date: Thu, 9 Oct 1997 20:42:22 -0500
To: [email-masked], [email-masked]
From: Bruce Schneier <[email-masked]>
Subject: 40-bit RC2 S/MIME cracking Windows 95 screen saver
Sender: [email-masked]

The code is finally available on my website.  Sorry about the delay.

Bruce

**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis,MN  55419       Fax: 612-823-1590
                                            http://www.counterpane.com

From: "Blake Ramsdell" <[email-masked]>
To: "'Peter Williams'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'John Pawling'" <[email-masked]>
Subject: RE: Simplifying S/MIME v3
Date: Thu, 9 Oct 1997 12:52:28 -0700
Sender: [email-masked]

On Thursday, October 09, 1997 10:09 AM, Peter Williams
[SMTP:[email-masked]] wrote:
> These functions are not "current" in the sort of emailish privacy-centric
> notion of S/MIME that we have around in the market at the current time.
> Where
> S/MIME is used in http or SSL however, it is more than likely that should a
> party
> define a custom SSL3 record-layer protocol (as they are entitlted) in which
> the current keys of the state/connection are used, then the S/MIME
> mechanisms
> (including the above) may well be used as the message formats. Why invent a
> new
> one, one might ask.

I don't disagree with the argument that these constructs serve a purpose
in the universe.  The question is, do they serve a purpose in all of the
problem domain that we are working on (that being defined as security
services for MIME entities, regardless of transport), or are they only
useful in a subset of the problem domain (HTTP / SSL-specific
transport).  I think the answer is the latter, and so to the extent that
we would like to support these constructs, we should create a separate
draft that explains their use for that particular transport.

You may have a point about signedAndEnvelopedData (forcing the fact that
only a recipient may validate the signature), and I welcome more
discussion about that.  My gut feeling is that no one is going to care
about that particular semantic, so it boils down to implementation
complexity vs. utility.

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

Reply-To: "Peter Williams" <[email-masked]>
From: "Peter Williams" <[email-masked]>
To: <[email-masked]>, "John Pawling" <[email-masked]>
Subject: Re: Simplifying S/MIME v3
Date: Thu, 9 Oct 1997 10:08:50 -0700
Sender: [email-masked]

-----Original Message-----
From: John Pawling <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, October 09, 1997 5:49 AM
Subject: Simplifying S/MIME v3

>All,
>
>The draft charter for the proposed IETF S/MIME Working Group includes plans
>for developing a new S/MIME v3 Message Specification as a separate document
>from the 23 Sep 1997 Internet Draft S/MIME Message Specification (also
known
>as S/MIME v2 Message Specification).  This message includes a proposal for
>simplifying the future S/MIME v3 Message Specification.
>
>The 23 Sep 97 S/MIME Message Specification, Section 2.4, General Syntax,
>states:  "The PKCS #7 defines six distinct content types: "data",
>"signedData", "envelopedData", "signedAndEnvelopedData", "digestedData",
and
>"encryptedData". Receiving agents MUST support the "data", "signedData" and
>"envelopedData" content types. Sending agents may or may not send out any
of
>the content types, depending on the services that the agent supports."
>
>This paragraph implies that an agent SHOULD support receiving the
>"digestedData", "encryptedData" and "signedAndEnvelopedData" content types.
>If a sending agent were to send one of these content types to a receiving
>agent that did not support that type, then that receiving agent would
>encounter an error condition.
>
>
>When the new S/MIME v3 Message Specification is written, we propose that
>Section 2.4 should be replaced by the following:  "The PKCS #7 v1.5
>specification defines six distinct content types: "data", "signedData",
>"envelopedData", "signedAndEnvelopedData", "digestedData", and
>"encryptedData".  Sending agents may send the "data", "signedData" and
>"envelopedData" content types, depending on the services that the agent
>supports.  Receiving agents MUST support the "data", "signedData" and
>"envelopedData" content types.  The "digestedData", "encryptedData" and
>"signedAndEnvelopedData" content types are not supported as part of the
>S/MIME 3 set of specifications.  Sending agents MUST NOT send the
>"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types.
>Receiving agents are not required to support the "digestedData",
>"encryptedData"  or "signedAndEnvelopedData" content types."
>
>Does anybody object to removing support for sending and receiving the
>"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types?
>Please provide comments.
>

Yes.

Encrypted Data is a value-add option for S/MIME implementations: having
established pairwise keys, an encrypted msg may simply reuse keying
material without having the overhead of indicating/agreeing/transporting
keys.

signedandEnvelopedData is very useful as it offers a service
not available otherwise - as only the intendedRecipient
is authorised to verify the signatures. The property is a function
of the integrated nature of the signing/encryption. This is a specialised
service.

DigestedData is used heavily in SET to address linking attacks
in multi-phase, multi-party messenging protocols, and shows lots of
potential to be used much as Encrypted Data - where an integrity
key has been previously established, subsequent mails may
be sent using digestedData, rather than signedData.

These functions are not "current" in the sort of emailish privacy-centric
notion of S/MIME that we have around in the market at the current time.
Where
S/MIME is used in http or SSL however, it is more than likely that should a
party
define a custom SSL3 record-layer protocol (as they are entitlted) in which
the current keys of the state/connection are used, then the S/MIME
mechanisms
(including the above) may well be used as the message formats. Why invent a
new
one, one might ask.

The current language is clear; no-one need implement the optional elements,
 particulary where there is yet little momentum for more refined
business-like
S/MIME applications dealing with secure relay-centric messenging, versus
merely secure inter-personal mail or end-end EDI. Denying
the use would seem harsh, and prevent S/MIME evolving to
satisfy other uses/enviornments  that personal or EDI mail services.

>
>==============================================================
>John Pawling                               (301) 953-3600
>J.G. Van Dyke & Associates, Inc.           (410) 880-6095
>141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
>Annapolis Junction, MD  20701              [email-masked]
>
>

Date: Thu, 9 Oct 1997 09:01:11 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Simplifying S/MIME v3
Sender: [email-masked]

All,

The draft charter for the proposed IETF S/MIME Working Group includes plans
for developing a new S/MIME v3 Message Specification as a separate document
from the 23 Sep 1997 Internet Draft S/MIME Message Specification (also known
as S/MIME v2 Message Specification).  This message includes a proposal for
simplifying the future S/MIME v3 Message Specification.

The 23 Sep 97 S/MIME Message Specification, Section 2.4, General Syntax,
states:  "The PKCS #7 defines six distinct content types: "data",
"signedData", "envelopedData", "signedAndEnvelopedData", "digestedData", and
"encryptedData". Receiving agents MUST support the "data", "signedData" and
"envelopedData" content types. Sending agents may or may not send out any of
the content types, depending on the services that the agent supports."

This paragraph implies that an agent SHOULD support receiving the
"digestedData", "encryptedData" and "signedAndEnvelopedData" content types.
If a sending agent were to send one of these content types to a receiving
agent that did not support that type, then that receiving agent would
encounter an error condition.

When the new S/MIME v3 Message Specification is written, we propose that
Section 2.4 should be replaced by the following:  "The PKCS #7 v1.5
specification defines six distinct content types: "data", "signedData",
"envelopedData", "signedAndEnvelopedData", "digestedData", and
"encryptedData".  Sending agents may send the "data", "signedData" and
"envelopedData" content types, depending on the services that the agent
supports.  Receiving agents MUST support the "data", "signedData" and
"envelopedData" content types.  The "digestedData", "encryptedData" and
"signedAndEnvelopedData" content types are not supported as part of the
S/MIME 3 set of specifications.  Sending agents MUST NOT send the
"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types.
Receiving agents are not required to support the "digestedData",
"encryptedData"  or "signedAndEnvelopedData" content types."

Does anybody object to removing support for sending and receiving the
"digestedData", "encryptedData"  or "signedAndEnvelopedData" content types?
Please provide comments.

==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              [email-masked]

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Jim Schaad (Exchange)'" <[email-masked]>
cc: "'Russ Housley'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SMIMECapabilities Attribute
Date: Wed, 8 Oct 1997 14:15:09 -0700
Sender: [email-masked]

On Wednesday, October 08, 1997 4:22 AM, [email-masked]
[SMTP:[email-masked]] wrote:
> I agree.  Most of the time the two chains will be mostly the same.  We
> don't want to duplicate the certs.  Lets just keep them where they are,
> and add the attribute to indicate the key exchange cert.

I sense a trend here...

I wanted to fly the separate SEQUENCE OF certificates to see if there
was any interest.  I think that having an encryption cert hint
(something that identifies the certificate to use for encrypting, not
the certificate itself) would be useful as an authenticatedAttribute.

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

Comments: Authenticated sender is <ieca2@[205.252.27.1]>
From: "Bonatti Chris" <[email-masked]>
Organization: IECA, Inc.
To: "Blake Ramsdell" <[email-masked]>
Date: Wed, 8 Oct 1997 09:06:24 -0500
Subject: RE: SMIMECapabilities Attribute
Reply-to: [email-masked]
CC: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

On 7 Oct 1997, "Blake Ramsdell" <[email-masked]> said:

> This way, there is a clear separation between the certs that
> are used for signing and the certs used for enveloping.  The
> downside is that if there are any common certs in the chain
> (for the same PCA in a hierarchy, for instance), then these
> will be transmitted redundantly.

Blake,

     This doesn't necessarily have to be a problem either.  
Since you will need to have some kind of procedural text for use 
of the attribute anyway, simply state that any certificate need 
be included "at most once" in the attribute.  This will require 
that products keep all the certs from the first path until they 
are finished validating the second, but that is probably not 
much of a burden.  (Other views on this? :-)

Chris

 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  [email-masked]   Tel: 301-212-9428   Fax: 703-506-8377  |
 |  PGP public key available from "http://www.ieca.com/"       |
 ---------------------------------------------------------------

Date: Wed, 08 Oct 1997 04:22:23 -0700
From: [email-masked] (Jeff Weinstein)
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "'Blake Ramsdell'" <[email-masked]>, "'Russ Housley'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SMIMECapabilities Attribute
Sender: [email-masked]

I agree.  Most of the time the two chains will be mostly the same.  We
don't want to duplicate the certs.  Lets just keep them where they are,
and add the attribute to indicate the key exchange cert.

	--Jeff

Jim Schaad (Exchange) wrote:
> 
> I have massive complaints about having two (or more) cert chains for the
> purpose of conveying the difference between key exchange and signing
> certs.  The overhead of carrying multiple chains (almost a certanty for
> some products) is really bad in terms of message size.  This is
> especially true given the current size and expected size of
> certificates.
> 
> I have no specific objection to an authenticated property which say --
> this is what you should use for my key exchange certificate, but I see
> no real value in any more than this.  The process of building
> certificate chains for verification needs to be done any event as one
> cannot rely that the chain provided will be either correct or useful any
> more  (certificates in the chain may have expired or been revoked).

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "'Russ Housley'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: SMIMECapabilities Attribute
Date: Wed, 8 Oct 1997 00:56:05 -0700 
Sender: [email-masked]

I have massive complaints about having two (or more) cert chains for the
purpose of conveying the difference between key exchange and signing
certs.  The overhead of carrying multiple chains (almost a certanty for
some products) is really bad in terms of message size.  This is
especially true given the current size and expected size of
certificates.  

I have no specific objection to an authenticated property which say --
this is what you should use for my key exchange certificate, but I see
no real value in any more than this.  The process of building
certificate chains for verification needs to be done any event as one
cannot rely that the chain provided will be either correct or useful any
more  (certificates in the chain may have expired or been revoked).  

jim

> -----Original Message-----
> From:	Blake Ramsdell [SMTP:[email-masked]]
> Sent:	Tuesday, October 07, 1997 4:10 PM
> To:	'Russ Housley'
> Cc:	[email-masked]'
> Subject:	RE: SMIMECapabilities Attribute
> 
> On Tuesday, October 07, 1997 7:15 AM, Russ Housley
> [SMTP:[email-masked]] wrote:
> > So, you suggest that key management certificates be carried in the
> existing
> > SET OF ExtendedCertificateOrCertificate.  This is fine with me.
> 
> I had to think about this for a couple of minutes (I'm thick
> sometimes).
>  The optional certificates field in SignedData can contain any
> certificates -- it is not limited to the signing cert chain at all, so
> it is perfectly acceptable to put your key exchange cert chain in here
> also.  We can change the language in the spec to specify this also.
> 
> What made me start thinking was that a criticism in the past has been
> that dumping a bunch of certificates in a pile is not as useful as
> assigning some kind of structure.  I think it bears thinking about
> having two separate authenticated attributes, one for the key exchange
> cert chain and one for the signing cert chain.  For instance:
> 
> SMIMESigningCertChain ::= SEQUENCE OF Certificate
> SMIMEKeyExchangeCertChain ::= SEQUENCE OF Certificate
> 
> This way, there is a clear separation between the certs that are used
> for signing and the certs used for enveloping.  The downside is that
> if
> there are any common certs in the chain (for the same PCA in a
> hierarchy, for instance), then these will be transmitted redundantly.
> 
> Jeff's point is a valid one also (not the one I was trying to make,
> however...  I'll take credit for it, though.) -- if the goal is to be
> able to specify what exactly is the enveloping cert for the signer of
> the message, you can dump that cert in the existing certificates
> member
> of SignedData, and then have an authenticatedAttribute that specifies
> the issuerAndSerialNumber (or whatever -- that's something else that
> needs to be finalized) of the cert to use for enveloping.  My original
> point was to include the actual certs (as I mentioned above) -- not a
> reference.
> 
> 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 Attribute
Date: Tue, 7 Oct 1997 16:09:40 -0700
Sender: [email-masked]

On Tuesday, October 07, 1997 7:15 AM, Russ Housley
[SMTP:[email-masked]] wrote:
> So, you suggest that key management certificates be carried in the existing
> SET OF ExtendedCertificateOrCertificate.  This is fine with me.

I had to think about this for a couple of minutes (I'm thick sometimes).
 The optional certificates field in SignedData can contain any
certificates -- it is not limited to the signing cert chain at all, so
it is perfectly acceptable to put your key exchange cert chain in here
also.  We can change the language in the spec to specify this also.

What made me start thinking was that a criticism in the past has been
that dumping a bunch of certificates in a pile is not as useful as
assigning some kind of structure.  I think it bears thinking about
having two separate authenticated attributes, one for the key exchange
cert chain and one for the signing cert chain.  For instance:

SMIMESigningCertChain ::= SEQUENCE OF Certificate
SMIMEKeyExchangeCertChain ::= SEQUENCE OF Certificate

This way, there is a clear separation between the certs that are used
for signing and the certs used for enveloping.  The downside is that if
there are any common certs in the chain (for the same PCA in a
hierarchy, for instance), then these will be transmitted redundantly.

Jeff's point is a valid one also (not the one I was trying to make,
however...  I'll take credit for it, though.) -- if the goal is to be
able to specify what exactly is the enveloping cert for the signer of
the message, you can dump that cert in the existing certificates member
of SignedData, and then have an authenticatedAttribute that specifies
the issuerAndSerialNumber (or whatever -- that's something else that
needs to be finalized) of the cert to use for enveloping.  My original
point was to include the actual certs (as I mentioned above) -- not a
reference.

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: Tue, 07 Oct 1997 15:01:45 -0700
From: [email-masked] (Jeff Weinstein)
To: Russ Housley <[email-masked]>
CC: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: SMIMECapabilities Attribute
Sender: [email-masked]

I agree with Blake also.  It might make sense to add another authenticated
attribute that specifies exactly which cert of the SET is the key management
cert.  This could be done with an issuerAndSerialNumber, as is done to
identify the signing cert.

	--Jeff

Russ Housley wrote:
> 
> Blake:
> 
> So, you suggest that key management certificates be carried in the existing
> SET OF ExtendedCertificateOrCertificate.  This is fine with me.
> 
> We need to say that this SHOULD be done.

Date: Tue, 07 Oct 1997 10:14:31 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: SMIMECapabilities Attribute
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Blake:

So, you suggest that key management certificates be carried in the existing
SET OF ExtendedCertificateOrCertificate.  This is fine with me.

We need to say that this SHOULD be done.

Russ

At 09:57 PM 10/5/97 -0700, Blake Ramsdell wrote:
>I agree that from a convenience point of view, an authenticatedAttribute
>containing the key exchange certificate would be a useful thing.
>However, it can be accomplished (however clumsily) by using the generic
>"bag o' certs".
>
>We are free to implement other authenticatedAttributes, and perhaps the
>use of the "bag o' certs" should be deprecated in favor of specifying
>two new authenticatedAttributes that can each contain a "bags o' certs"
>-- one containing the chain of certificates for validating signed
>messages for this sender, and one containing the chain of certificates
>for enveloping messages for this sender.  Of course, we would specify
>this as a SEQUENCE OF and not a SET OF.  Don't go there.
>
>Placing this under SMIMECapabilities makes me feel a bit icky, but we
>can do it that way if desired.  I like the general idea, however, of
>placing these somewhere in the authenticatedAttributes.
>
>Blake
>
>>-----Original Message-----
>>From:	Russ Housley [SMTP:[email-masked]]
>>Sent:	Saturday, October 04, 1997 2:53 PM
>>To:	[email-masked]
>>Subject:	SMIMECapabilities Attribute
>>
>>The current definition of the SMIMECapabilities Attribute allows the user
>>to state their preference for key management algorithm.  I think that it
>>would be very useful for the user to OPTINALLY include their key management
>>certificate with this preference.
>>
>>Today, there is not a ubiquitous Directory available, so people need to
>>distribute their certificates by other means.  By including the key
>>management certificate in the SMIMECapabilities Attribute, sending a signed
>>message allows the recipient to respond with a signed and encrypted
>>message.  This is a nice bootstrap mechanism that works will in a Directory
>>impaired environment.
>>
>>What do ya think?
>>
>>Russ
>

Date: Tue, 07 Oct 1997 10:11:42 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: What version of PKCS #7?
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

To me, backward compatibiltiy of signatures is more importnat than any of
the new capabilities that are embodied in PKCS#7 v2.0.

Russ

At 09:24 PM 10/5/97 -0700, Blake Ramsdell wrote:
>There have been some interesting points that have been raised in other
>threads about moving forward with PKCS #7 v2.0 and vSomethingElse.  Some
>background (please feel free to correct any inaccuracies -- this is from
>memory):
>
>At one point, it was decided to make as few modifications to PKCS #7
>v1.5 in order to fix some of the problems with PKCS #7 that were brought
>to light when it was being considered if MSP would fit into the current
>S/MIME framework.  These changes were along the lines of key management,
>key identifiers and some other things such as security labels and
>mailing list expansion histories.  I believe that this discussion took
>place around the IETF meeting in Memphis.
>
>During the PKCS #7 workshop that was put on by RSADSI, the question was
>raised "does anyone care if the MSP-friendly version of S/MIME uses PKCS
>#7 v2.0 or should we stick with 1.5?"  I have been told that at the time
>there was no objection, so the direction shifted to using PKCS #7 v2.0.
>I was not present at the meeting, so if someone else has a different
>recollection feel free to correct me.
>
>During the S/MIME Developer Workshop that was held recently, I brought
>up the following point:  To the extent that backwards compatibility is
>desired with existing S/MIME clients, it would be best to extend PKCS #7
>v1.5 in such a way that IF the algorithm suites fit into the S/MIME v2
>profile AND keys could be identified using the current means of
>IssuerAndSerialNumber AND any new features that were used did not affect
>existing S/MIME clients (such as security labels), THEN we should use
>PKCS #7 v1.5.  It then became clear that having the ability to use PKCS
>#7 v2.0 wasn't useful, since implementors had to implement PKCS #7 v1.5
>for compatibility with older S/MIME v2 products, so we might as well
>modify PKCS #7 v1.5 a little bit to accommodate the new features and
>dump the use of PKCS #7 v2.0.
>
>The bottom line is that however clean it would be to move to PKCS #7
>v2.0 (and I agree 100% that it will be cleaner), you break compatibility
>with the (growing!!) installed base.  This scares the hell out of me.  I
>am in NO WAY saying that this direction shouldn't be explored.
>
>I am also in NO WAY saying that I represent everyone, and I completely
>qualified my statements at the time as being the opinion of a single
>vendor (and not necessarily the most prominent vendor, either.  Maybe
>the noisiest...).
>
>The point is that we need to come up with a migration strategy of some
>sort.  I'm not sure that Flipping the Big Switch to PKCS #7 v2.0 is the
>best way to go.
>
>There are certainly people that are more qualified than I am to discuss
>the issues of "backwards compatibility" vs. "progressing forward", and I
>invite those people to step forward now and speak their piece.  My bias
>as a developer of S/MIME products is along the lines of protecting my
>customer's investments in technology, so certainly my opinions are not
>necessarily objective in this area.
>
>This note really isn't meant to be inflammatory, and isn't directed at
>anyone in particular.  dpkemp's comments served as the catalyst, and I
>hope that some discussion happens about this, because it is an important
>issue.
>
>Blake
>

Date: Tue, 07 Oct 1997 10:07:19 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Creation of new SMIME OID
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

OIDs from any arc are fine with me.

Russ

At 07:04 PM 10/3/97 -0700, Blake Ramsdell wrote:
>Originally an OID was registered under the PKCS #9 tree for
>SMIMECapabilities.  Going forward, we will be presented with other OIDs
>that need to be created and managed that do not seem like they should be
>placed under SMIMECapabilities.  Instead of cluttering up PKCS #9, I
>propose that we create a new OID called SMIME under the PKCS #9 tree,
>and all NEW S/MIME OIDs are created under that.  This is something that
>has been discussed in the authors group, and I think this is a good way
>to go.
>
>SMIMECapabilities and any capabilities-related OIDs will stay under the
>existing SMIMECapabilities OID.  Anything else will go under SMIME.
>
>Any objections?  By leaving the SMIMECapabilities where it is, we don't
>disrupt the existing vendors that are using it.
>
>I don't think that this is anything to panic about, and it's a pretty
>minor point, so silence indicates approval.
>
>The new OID will be posted next week, assuming there aren't any major
>objections.
>
>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, 06 Oct 1997 11:55:59 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: application/mime objections
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

> >         From the discussion which ensued when you raised this point, I did not see
> > a consensus view which agreed with either your assessment that there is a
> > violation or that the specification would need changing.

> I certainly don't see a consensus view which disagrees with my
> assessment.  For example, Ned Freed states in his message of July 28
> 12:11:52 that "The current application/mime proposal is in clear
> violation of the MIME specification." [In the context of section 6.4 of
> RFC 2045.]

FWIW, it was my understanding that the document was to be changed to restrict
the encoding to one of 7bit, 8bit, or binary. However, the document doesn't
appear to have been reposted since July, so this has not been done.

> >         that was not what the author said.  he said that there was not intent to
> > violate transfer encoding requirements that represent hard-won lessons with
> > MIME.  During the previous discussion on this point, someone suggested that
> > this was really just like Multipart or Message and the author chimed in
> > that that sounded fine and that the spec probably should stated that
> > multipart c-t-e rules apply.

> This requires the name of the type be changed to place it under the
> "message" top-level type.  If it is placed under any other top-level
> type (excepting "multipart", which is not applicable) then existing
> intermediaries will feel free to apply a base64 or quoted-printable
> c-t-e to it.

Unless of course they understand that this is a composite type. But the entire
point of this type is to avoid composite treatment, of course.

In any case, I agree that this type really needs to be moved under the message
primary type, making it message/mime, not application/mime. This has  the
effect of fixing the encoding problem right off the bat. I also see no downside
to this -- the type message/delivery-status has been widely deployed of late
with no observed interoperability problems being reported.

With this change in place I have no objection to this moving forward.  I
continue to believe that this isn't likely to solve as many problems as people
think it will, but I also continue to believe that done right there is little
if any downside to defining such a thing.

				Ned

Date: Mon, 06 Oct 1997 09:42:50 -0700
From: Karen Rosenthal <[email-masked]>
Organization: Premenos
To: "[email-masked]'" <[email-masked]>
CC: Blake Ramsdell <[email-masked]>
Subject: Re: What version of PKCS #7?
Sender: [email-masked]

As another biased developer of existing S/MIME product, the thought of
the 'big switch' to PKCS #7 v2.0 (after having a successful and
widespread implementation of v1.5), and having to deal with backwards
(in)compatibility (not to mention code maintenance), scares the hell out
of me too.  Seeing Paul Hoffman's description of the IETF Working Group,
basing the upcoming IETF effort on an enhanced v1.5 to include algorithm
independence, is a welcome relief!

But then, this decision to build upon v1.5 within the IETF process (with
which I COMPLETELY approve!), makes me question the parallel track of
v2.0.  The existing v1.5 is solid, widely implemented, and works!
Perhaps my lack of involvement in the v2.0 development process grossly
limits my perspective, but I question why v2.0 stands as an essential
rewrite, rather than building upon v1.5.  How do we justify the parallel
rewrite track, while standardizing v1.5, which will only further promote
its implementation?

Regards,
Karen

Blake Ramsdell wrote:

> There have been some interesting points that have been raised in other
>
> threads about moving forward with PKCS #7 v2.0 and vSomethingElse.
> Some
> background (please feel free to correct any inaccuracies -- this is
> from
> memory):
>
> At one point, it was decided to make as few modifications to PKCS #7
> v1.5 in order to fix some of the problems with PKCS #7 that were
> brought
> to light when it was being considered if MSP would fit into the
> current
> S/MIME framework.  These changes were along the lines of key
> management,
> key identifiers and some other things such as security labels and
> mailing list expansion histories.  I believe that this discussion took
>
> place around the IETF meeting in Memphis.
>
> During the PKCS #7 workshop that was put on by RSADSI, the question
> was
> raised "does anyone care if the MSP-friendly version of S/MIME uses
> PKCS
> #7 v2.0 or should we stick with 1.5?"  I have been told that at the
> time
> there was no objection, so the direction shifted to using PKCS #7
> v2.0.
> I was not present at the meeting, so if someone else has a different
> recollection feel free to correct me.
>
> During the S/MIME Developer Workshop that was held recently, I brought
>
> up the following point:  To the extent that backwards compatibility is
>
> desired with existing S/MIME clients, it would be best to extend PKCS
> #7
> v1.5 in such a way that IF the algorithm suites fit into the S/MIME v2
>
> profile AND keys could be identified using the current means of
> IssuerAndSerialNumber AND any new features that were used did not
> affect
> existing S/MIME clients (such as security labels), THEN we should use
> PKCS #7 v1.5.  It then became clear that having the ability to use
> PKCS
> #7 v2.0 wasn't useful, since implementors had to implement PKCS #7
> v1.5
> for compatibility with older S/MIME v2 products, so we might as well
> modify PKCS #7 v1.5 a little bit to accommodate the new features and
> dump the use of PKCS #7 v2.0.
>
> The bottom line is that however clean it would be to move to PKCS #7
> v2.0 (and I agree 100% that it will be cleaner), you break
> compatibility
> with the (growing!!) installed base.  This scares the hell out of me.
> I
> am in NO WAY saying that this direction shouldn't be explored.
>
> I am also in NO WAY saying that I represent everyone, and I completely
>
> qualified my statements at the time as being the opinion of a single
> vendor (and not necessarily the most prominent vendor, either.  Maybe
> the noisiest...).
>
> The point is that we need to come up with a migration strategy of some
>
> sort.  I'm not sure that Flipping the Big Switch to PKCS #7 v2.0 is
> the
> best way to go.
>
> There are certainly people that are more qualified than I am to
> discuss
> the issues of "backwards compatibility" vs. "progressing forward", and
> I
> invite those people to step forward now and speak their piece.  My
> bias
> as a developer of S/MIME products is along the lines of protecting my
> customer's investments in technology, so certainly my opinions are not
>
> necessarily objective in this area.
>
> This note really isn't meant to be inflammatory, and isn't directed at
>
> anyone in particular.  dpkemp's comments served as the catalyst, and I
>
> hope that some discussion happens about this, because it is an
> important
> issue.
>
> Blake

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

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: SMIMECapabilities Attribute
Date: Sun, 5 Oct 1997 21:57:40 -0700
Sender: [email-masked]

I agree that from a convenience point of view, an authenticatedAttribute
containing the key exchange certificate would be a useful thing.
However, it can be accomplished (however clumsily) by using the generic
"bag o' certs".

We are free to implement other authenticatedAttributes, and perhaps the
use of the "bag o' certs" should be deprecated in favor of specifying
two new authenticatedAttributes that can each contain a "bags o' certs"
-- one containing the chain of certificates for validating signed
messages for this sender, and one containing the chain of certificates
for enveloping messages for this sender.  Of course, we would specify
this as a SEQUENCE OF and not a SET OF.  Don't go there.

Placing this under SMIMECapabilities makes me feel a bit icky, but we
can do it that way if desired.  I like the general idea, however, of
placing these somewhere in the authenticatedAttributes.

Blake

>-----Original Message-----
>From:	Russ Housley [SMTP:[email-masked]]
>Sent:	Saturday, October 04, 1997 2:53 PM
>To:	[email-masked]
>Subject:	SMIMECapabilities Attribute
>
>The current definition of the SMIMECapabilities Attribute allows the user
>to state their preference for key management algorithm.  I think that it
>would be very useful for the user to OPTINALLY include their key management
>certificate with this preference.
>
>Today, there is not a ubiquitous Directory available, so people need to
>distribute their certificates by other means.  By including the key
>management certificate in the SMIMECapabilities Attribute, sending a signed
>message allows the recipient to respond with a signed and encrypted
>message.  This is a nice bootstrap mechanism that works will in a Directory
>impaired environment.
>
>What do ya think?
>
>Russ

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: What version of PKCS #7?
Date: Sun, 5 Oct 1997 21:24:40 -0700
Sender: [email-masked]

There have been some interesting points that have been raised in other
threads about moving forward with PKCS #7 v2.0 and vSomethingElse.  Some
background (please feel free to correct any inaccuracies -- this is from
memory):

At one point, it was decided to make as few modifications to PKCS #7
v1.5 in order to fix some of the problems with PKCS #7 that were brought
to light when it was being considered if MSP would fit into the current
S/MIME framework.  These changes were along the lines of key management,
key identifiers and some other things such as security labels and
mailing list expansion histories.  I believe that this discussion took
place around the IETF meeting in Memphis.

During the PKCS #7 workshop that was put on by RSADSI, the question was
raised "does anyone care if the MSP-friendly version of S/MIME uses PKCS
#7 v2.0 or should we stick with 1.5?"  I have been told that at the time
there was no objection, so the direction shifted to using PKCS #7 v2.0.
I was not present at the meeting, so if someone else has a different
recollection feel free to correct me.

During the S/MIME Developer Workshop that was held recently, I brought
up the following point:  To the extent that backwards compatibility is
desired with existing S/MIME clients, it would be best to extend PKCS #7
v1.5 in such a way that IF the algorithm suites fit into the S/MIME v2
profile AND keys could be identified using the current means of
IssuerAndSerialNumber AND any new features that were used did not affect
existing S/MIME clients (such as security labels), THEN we should use
PKCS #7 v1.5.  It then became clear that having the ability to use PKCS
#7 v2.0 wasn't useful, since implementors had to implement PKCS #7 v1.5
for compatibility with older S/MIME v2 products, so we might as well
modify PKCS #7 v1.5 a little bit to accommodate the new features and
dump the use of PKCS #7 v2.0.

The bottom line is that however clean it would be to move to PKCS #7
v2.0 (and I agree 100% that it will be cleaner), you break compatibility
with the (growing!!) installed base.  This scares the hell out of me.  I
am in NO WAY saying that this direction shouldn't be explored.

I am also in NO WAY saying that I represent everyone, and I completely
qualified my statements at the time as being the opinion of a single
vendor (and not necessarily the most prominent vendor, either.  Maybe
the noisiest...).

The point is that we need to come up with a migration strategy of some
sort.  I'm not sure that Flipping the Big Switch to PKCS #7 v2.0 is the
best way to go.

There are certainly people that are more qualified than I am to discuss
the issues of "backwards compatibility" vs. "progressing forward", and I
invite those people to step forward now and speak their piece.  My bias
as a developer of S/MIME products is along the lines of protecting my
customer's investments in technology, so certainly my opinions are not
necessarily objective in this area.

This note really isn't meant to be inflammatory, and isn't directed at
anyone in particular.  dpkemp's comments served as the catalyst, and I
hope that some discussion happens about this, because it is an important
issue.

Blake

Date: Tue, 30 Sep 1997 15:23:04 -0400
To: "Roger Fajman" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re:  Signing time format
CC: [email-masked]
Sender: [email-masked]

This is different because the the format to support dates beyond 2050 is
already defined.  The Y2K problem is a problem because a format to handle
the upcoming century was not agreed to by everyone well in advance.

Russ

At 07:44 PM 9/24/97 EDT, Roger Fajman wrote:
>> Don't you think that fifty years is enough time to upgrade all certificate
>> implenetations?
>
>Sure, but a lot of people thought that they didn't have to worry about
>the year 2000 because it was 25 years away.  Why set deadlines sooner than
>they really need to be?
>

Date: Tue, 30 Sep 1997 12:36:30 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Proposed charter for a S/MIME working group
Sender: [email-masked]

Greetings, all. As you saw last week, RSA has sent the ISOC material that
(hopefully) meets the IESG's requirements for what must happen before we
form an S/MIME working group. So, our next task is to agree on a charter
and submit it to Jeff Schiller, the area director for security. If Jeff
agrees, he'll take it to the IESG for their consideration.

Below is what I think a reasonable charter should look like. All comments
are welcome.

= = = = = = = = =

S/MIME Mail Security (smime)

Chair:
     Russ Housley <[email-masked]>

Security Area Director:
     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. 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, 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 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.

Goals and Milestones:

History:
     PKCS #7 version 1.5 specification submitted as Informational RFC.
     S/MIME v2 message specification submitted as Informational RFC.
     S/MIME v2 certificate specification submitted as Informational RFC.

October 97:
     First draft of message syntax specification.
     First draft of S/MIME v3 message specification.
     First draft of S/MIME v3 certificate specification.
     First draft of S/MIME optional security extensions.

December 97:
     Last call on message syntax specification.
     Last call on S/MIME v3 message specification.
     Last call on S/MIME v3 certificate specification.

January 98:
     Last call on S/MIME optional security extensions.
     Submit  message syntax specification as a Proposed Standard.
     Submit S/MIME v3 message specification as a Proposed Standard.
     Submit S/MIME v3 certificate specification as a Proposed Standard.

February 98:
     Submit S/MIME optional security extensions as a Proposed Standard.

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

Date: Sat, 04 Oct 1997 17:52:44 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: SMIMECapabilities Attribute
Sender: [email-masked]

The current definition of the SMIMECapabilities Attribute allows the user
to state their preference for key management algorithm.  I think that it
would be very useful for the user to OPTINALLY include their key management
certificate with this preference.

Today, there is not a ubiquitous Directory available, so people need to
distribute their certificates by other means.  By including the key
management certificate in the SMIMECapabilities Attribute, sending a signed
message allows the recipient to respond with a signed and encrypted
message.  This is a nice bootstrap mechanism that works will in a Directory
impaired environment.

What do ya think?

Russ

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Creation of new SMIME OID
Date: Fri, 3 Oct 1997 19:04:08 -0700
Sender: [email-masked]

Originally an OID was registered under the PKCS #9 tree for
SMIMECapabilities.  Going forward, we will be presented with other OIDs
that need to be created and managed that do not seem like they should be
placed under SMIMECapabilities.  Instead of cluttering up PKCS #9, I
propose that we create a new OID called SMIME under the PKCS #9 tree,
and all NEW S/MIME OIDs are created under that.  This is something that
has been discussed in the authors group, and I think this is a good way
to go.

SMIMECapabilities and any capabilities-related OIDs will stay under the
existing SMIMECapabilities OID.  Anything else will go under SMIME.

Any objections?  By leaving the SMIMECapabilities where it is, we don't
disrupt the existing vendors that are using it.

I don't think that this is anything to panic about, and it's a pretty
minor point, so silence indicates approval.

The new OID will be posted next week, assuming there aren't any major
objections.

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: Tim Matthews <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Proposed charter for a S/MIME working group
Date: Fri, 3 Oct 1997 16:40:58 -0700
Sender: [email-masked]

Looks promising.  Harmonization with PKIX is a good thing.

Tim

Tim Matthews
Product Manager
RSA Data Security, Inc.
p. 650/595-8782
f.  650/595-1873
e. [email-masked]

>----------
>From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
>Sent: 	Tuesday, September 30, 1997 12:36 PM
>To: 	[email-masked]
>Subject: 	Proposed charter for a S/MIME working group
>
>Greetings, all. As you saw last week, RSA has sent the ISOC material that
>(hopefully) meets the IESG's requirements for what must happen before we
>form an S/MIME working group. So, our next task is to agree on a charter
>and submit it to Jeff Schiller, the area director for security. If Jeff
>agrees, he'll take it to the IESG for their consideration.
>
>Below is what I think a reasonable charter should look like. All comments
>are welcome.
>
>= = = = = = = = =
>
>S/MIME Mail Security (smime)
>
>Chair:
>     Russ Housley <[email-masked]>
>
>Security Area Director:
>     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. 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, 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 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.
>
>
>Goals and Milestones:
>
>History:
>     PKCS #7 version 1.5 specification submitted as Informational RFC.
>     S/MIME v2 message specification submitted as Informational RFC.
>     S/MIME v2 certificate specification submitted as Informational RFC.
>
>October 97:
>     First draft of message syntax specification.
>     First draft of S/MIME v3 message specification.
>     First draft of S/MIME v3 certificate specification.
>     First draft of S/MIME optional security extensions.
>
>December 97:
>     Last call on message syntax specification.
>     Last call on S/MIME v3 message specification.
>     Last call on S/MIME v3 certificate specification.
>
>January 98:
>     Last call on S/MIME optional security extensions.
>     Submit  message syntax specification as a Proposed Standard.
>     Submit S/MIME v3 message specification as a Proposed Standard.
>     Submit S/MIME v3 certificate specification as a Proposed Standard.
>
>February 98:
>     Submit S/MIME optional security extensions as a Proposed Standard.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>

Date: Thu, 02 Oct 1997 16:59:39 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: Re: application/mime objections
Sender: [email-masked]

Dave Crocker / IMC wrote:
> At 02:36 PM 10/1/97 -0700, John Myers wrote:
> >1) The type is not registered and does not have a referencable
> >specification.
> 
>         That is because it is being submitted through the standards process.

Application/mime went to a Last Call as an individual submission quite
some number of months ago.  At that time, I sent in these comments as
objections.  There has been no action since.

I believe there is sufficient controversy over the technical aspects of
the type to warrant a forum (perhaps a Working Group) to resolve them. 
In any case, it should be understood that anything which references
application/mime will be held up until application/mime completes the
process.

> >2) The type violates the MIME specification, specifically section 2.2.1
> >of RFC 2048 and the restriction of transfer encodings on composite
> >objects in section 6.4 of RFC 2045.
> 
>         From the discussion which ensued when you raised this point, I did not see
> a consensus view which agreed with either your assessment that there is a
> violation or that the specification would need changing.

I certainly don't see a consensus view which disagrees with my
assessment.  For example, Ned Freed states in his message of July 28
12:11:52 that "The current application/mime proposal is in clear
violation of the MIME specification." [In the context of section 6.4 of
RFC 2045.]

> >3) The possibility of a reader encountering binary MIME objects
> >underneath a transfer encoding applied to the application/mime object is
> >not adequately documented.
> 
>         Correct.  This improvement to the document needs to be made.
> 
> >The author of the application/mime specification has stated that this
> >implication of the type was not considered or intended, and expressed a
> >desire to prohibit transfer encodings being applied to application/mime
> 
>         that was not what the author said.  he said that there was not intent to
> violate transfer encoding requirements that represent hard-won lessons with
> MIME.  During the previous discussion on this point, someone suggested that
> this was really just like Multipart or Message and the author chimed in
> that that sounded fine and that the spec probably should stated that
> multipart c-t-e rules apply.

This requires the name of the type be changed to place it under the
"message" top-level type.  If it is placed under any other top-level
type (excepting "multipart", which is not applicable) then existing
intermediaries will feel free to apply a base64 or quoted-printable
c-t-e to it.

> >I see three alternatives for replacing the use of application/mime in
> >the document:
> >
> >a) signedData
> >
> >This alternative requires the least specification and deployment work.
> 
>         This requires the least initial effort for s/mime.  it require more,
> long-term work to overcome the specialized nature of this trick, since
> there will then be two ways of doing a single s/mime function set.

There are at least two ways of doing a single s/mime function set
(signing) under any proposal.  With the application/mime proposal, there
is:

* multipart/signed
* multipart/signed under application/mime
* multipart/signed under application/mime under application/mime
and so on.

(Why anyone would ever intentionally do the third way, I don't
understand, but it is handled as a special case in the current
application/mime proposal.  The reason for special-case requirement in
the application/mime proposal I don't understand either.)

> It will
> also require more long-term work because there is no reason to believe that
> s/mime is the only activity with this requirement.

Clearly there is OpenPGP, which would be able to use proposal (b).

> Any activity which is
> in the realm of Multipart/Related must also solve this problem.
> 
>         gee, maybe we should try to solve it once, for everyone.

In the case of application/mime, it is my firm opinion that the solution
is worse than the problem.  It is so general, it is capable and
extremely likely to crop up in places which are entirely unexpected,
causing opacity problems for various pieces of software.

If they are to exist at all, it is important that these opacity hacks
have limited scope.  More on this later.

> >b) application/signed
> >
> >This is my proposal for a type which is exactly like multipart/signed,
> >except the contents are labeled "application/signed" instead of
> >"multipart/signed".  Since the proposed type is under application, it
> >may have a non-trivial transfer-encoding applied to it (implying that
> >readers must be able to handle binary data underneath such an encoding)
> >and it does not have the default-to-multipart/mixed semantics of
> >multipart/signed.
> 
>         this, of course, makes imap no longer work with the signed content.  one
> must first break open the application/signed type, knowing how to handle
> such a thing.

This is the same for any of the proposals, including application/mime. 
If you want IMAP or other signature-unaware MIME applications to work
with the signed content, you have to use multipart/signed.
 
>         one could say the same for application/mime, but then we go back to the
> "do this task once and only once and then you don't need to keep adding
> special types that do it for individual applications".  application/signed
> is in the latter category.

So your IMAP comment has no relevance to the relative worth of proposal
(b) versus application/mime, and your only substantive comment is the
"once and only once" comment.

Adding different types for different applications is part and parcel of
what MIME is about.  It is why we have a registry in the first place. 
One may re-use pre-existing methods, structure, and syntax (as proposal
(b) does), but having different media type labels for different
applications is fundamental to MIME and key to its success.

> >c) message/mime-entity
> >
> >This is "application/mime" moved underneath the "message" top-level
> >type, in order to get the transfer encoding restrictions of the
> >"message" top-level type.
> >
> >It is unclear to me whether or not such a type violates section 2.2.1 of
> >RFC 2048.  Such a type is incapable of carrying binary signed objects
> >over non-binary transports, a disservice to the voice mail community.  A
> >similar concern applies to 8-bit signed objects.
> 
>         I think that message/mime, or somesuch, would be fine except that my
> recollection is that message/* is closed for general enhancement, based on
> discussion one or 3 years ago.

Well, message/delivery-status was created about two years ago, I don't
know what would have changed since then.

Date: Thu, 02 Oct 1997 16:03:08 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Proposed charter for a S/MIME working group
Sender: [email-masked]

There have been many things that might have happened that got called S/MIME
3. After RSA released the name, all of those fell away, since what's
important is what happens in the working group that will hopefully be
formed. RSA played it a bit loose as to what S/MIME 3 would be, but we
don't have to any longer. :-)

>However, there are three separate processes at work here, and I don't
>understand the relationship between them:

There is one process here: the formation of the working group. The other
groups are no longer working on any variants of S/MIME 3.

>1. What is the "message syntax specification" listed above for October 97?
>    "Son of PKCS#7 v1.5", a.k.a. "PKCS#7 v1.7"?  "PKCS#7 v2"?
>     Something else?

"Son of PKCS#7 v1.5", a.k.a. "PKCS#7 v1.7". We'll start with PKCS #7 1.5
and make as few changes to it as are needed to have algorithm independence.
This will *not* be called PKCS#7 v1.7, but will in fact have a name that we
come up with ourselves. The PKCS#7 v2 work will continue to happen on the
PKCS-TNG mailing list and is not related to the work we're doing here.

>2. Will IETF-S/MIME v3 refer to PKCS#7 v2 before becoming a Proposed Standard
>    in Jan 98?

No. It will refer to our "Son of". The primary reason for this is that the
PKCS #7 v2 work is going to be completely incompatible with v1.5; "Son of"
will be a minor change and therefore much easier for S/MIME implementors to
use quickly. RSADSI estimates that PKCS#7 v2 won't be done until next summer.

>3. If not 2, will IETF-S/MIME ever be based on PKCS#7 v2?

That's up to the working group. We can't really commit to it until we see
it. I believe that we should put wording into the document that tells
implementors to look at the version number, so we won't prevent v2 when it
appears, but we can't decide until it's published.

>4. If not 3, what purpose is served by continuing to develop PKCS#7 to v2
>    and beyond, and encouraging it to use techniques compatible with the
>    MSP-S/MIME work?

There are non-IETF groups that want some of the changes in v2. PKCS is up
to RSA; S/MIME is up to what will hopefully be this IETF working group.

>5. Will PKCS#7 v2 be submitted to the IETF in any form (Informational
>    or Standards Track), in any forum (IETF-S/MIME or elsewhere)?

Only RSA can commit that. It seems likely that they'll at least submit it
as an informational RFC, as they did v1.5, but there's no commitment yet
(nor should there be, given how early the v2 work is).
--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 2 Oct 1997 16:59:11 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Proposed charter for a S/MIME working group
Sender: [email-masked]

> >Goals and Milestones:
> >
> >History:
> >     PKCS #7 version 1.5 specification submitted as Informational RFC.
> >     S/MIME v2 message specification submitted as Informational RFC.
> >     S/MIME v2 certificate specification submitted as Informational RFC.
> >
> >October 97:
> >     First draft of message syntax specification.
> >     First draft of S/MIME v3 message specification.
> >     First draft of S/MIME v3 certificate specification.
> >     First draft of S/MIME optional security extensions.

I also admit being confused with this charter, since it doesn't specify
what documents the First Drafts or the Proposed Standards will be based
on.

Background: the MSP-S/MIME working group designed what was called
"S/MIME v3" based on the drafts of PKCS#7 v2.0, which has been discussed
on the PKCS-TNG mail list, but not submitted to the IETF.

Later, the MSP-S/MIME group decided to base its merged protocol on
PKCS#7 v1.5, which has been submitted as an Informational RFC, in order
to minimize the changes from the existing S/MIME v2.  I'm disappointed
by this decision because PKCS#7 v2 is a much cleaner design than v1.5,
but I understand the desire for bit-for-bit message compatibility with
existing PKCS#7 v1.5 implementations (instead of the signature compatibility
provided by PKCS#7 v2).

However, there are three separate processes at work here, and I don't
understand the relationship between them:

 1) merge MSP functionality into S/MIME with absolute minimum changes to
    the existing S/MIME v2 specs,

 2) produce baseline documents for the IETF-S/MIME standarization work, and

 3) produce the next-generation PKCS#7 standard, based on drafts designated
    v2.0.

Questions:

1. What is the "message syntax specification" listed above for October 97?
    "Son of PKCS#7 v1.5", a.k.a. "PKCS#7 v1.7"?  "PKCS#7 v2"?
     Something else?

2. Will IETF-S/MIME v3 refer to PKCS#7 v2 before becoming a Proposed Standard
    in Jan 98?

3. If not 2, will IETF-S/MIME ever be based on PKCS#7 v2?

4. If not 3, what purpose is served by continuing to develop PKCS#7 to v2
    and beyond, and encouraging it to use techniques compatible with the
    MSP-S/MIME work?

5. Will PKCS#7 v2 be submitted to the IETF in any form (Informational
    or Standards Track), in any forum (IETF-S/MIME or elsewhere)?

Date: Wed, 01 Oct 1997 23:32:13 -0700
To: [email-masked] (John Myers)
From: Dave Crocker / IMC <[email-masked]>
Subject: Re: application/mime objections
Cc: [email-masked], [email-masked]
Sender: [email-masked]

John,

At 02:36 PM 10/1/97 -0700, John Myers wrote:
>1) The type is not registered and does not have a referencable
>specification.

	That is because it is being submitted through the standards process.

>2) The type violates the MIME specification, specifically section 2.2.1
>of RFC 2048 and the restriction of transfer encodings on composite
>objects in section 6.4 of RFC 2045.

	From the discussion which ensued when you raised this point, I did not see
a consensus view which agreed with either your assessment that there is a
violation or that the specification would need changing.

>3) The possibility of a reader encountering binary MIME objects
>underneath a transfer encoding applied to the application/mime object is
>not adequately documented.

	Correct.  This improvement to the document needs to be made.

>The author of the application/mime specification has stated that this
>implication of the type was not considered or intended, and expressed a
>desire to prohibit transfer encodings being applied to application/mime

	that was not what the author said.  he said that there was not intent to
violate transfer encoding requirements that represent hard-won lessons with
MIME.  During the previous discussion on this point, someone suggested that
this was really just like Multipart or Message and the author chimed in
that that sounded fine and that the spec probably should stated that
multipart c-t-e rules apply.

>objects.  The only technically effective way to prohibit transfer
>encodings on the type is to place it under the "message" top level type,
>as intermediaries routinely feel free to transfer-encode arbitrary
>subtypes of "application".
>
>I see three alternatives for replacing the use of application/mime in
>the document:
>
>a) signedData
>
>This alternative requires the least specification and deployment work. 

	This requires the least initial effort for s/mime.  it require more,
long-term work to overcome the specialized nature of this trick, since
there will then be two ways of doing a single s/mime function set.  It will
also require more long-term work because there is no reason to believe that
s/mime is the only activity with this requirement.  Any activity which is
in the realm of Multipart/Related must also solve this problem.

	gee, maybe we should try to solve it once, for everyone.

>b) application/signed
>
>This is my proposal for a type which is exactly like multipart/signed,
>except the contents are labeled "application/signed" instead of
>"multipart/signed".  Since the proposed type is under application, it
>may have a non-trivial transfer-encoding applied to it (implying that
>readers must be able to handle binary data underneath such an encoding)
>and it does not have the default-to-multipart/mixed semantics of
>multipart/signed.

	this, of course, makes imap no longer work with the signed content.  one
must first break open the application/signed type, knowing how to handle
such a thing.

	one could say the same for application/mime, but then we go back to the
"do this task once and only once and then you don't need to keep adding
special types that do it for individual applications".  application/signed
is in the latter category.

>c) message/mime-entity
>
>This is "application/mime" moved underneath the "message" top-level
>type, in order to get the transfer encoding restrictions of the
>"message" top-level type.
>
>It is unclear to me whether or not such a type violates section 2.2.1 of
>RFC 2048.  Such a type is incapable of carrying binary signed objects
>over non-binary transports, a disservice to the voice mail community.  A
>similar concern applies to 8-bit signed objects.

	I think that message/mime, or somesuch, would be fine except that my
recollection is that message/* is closed for general enhancement, based on
discussion one or 3 years ago.

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

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

Date: Wed, 01 Oct 1997 14:36:22 -0700
From: [email-masked] (John Myers)
To: [email-masked]
Subject: application/mime objections
Sender: [email-masked]

To recap, my objections to the document's use of application/mime are:

1) The type is not registered and does not have a referencable
specification.

2) The type violates the MIME specification, specifically section 2.2.1
of RFC 2048 and the restriction of transfer encodings on composite
objects in section 6.4 of RFC 2045.

This implies that in order to register the application/mime media type
it would be required to change to the base MIME spec, probably resetting
MIME to Proposed.

3) The possibility of a reader encountering binary MIME objects
underneath a transfer encoding applied to the application/mime object is
not adequately documented.

The author of the application/mime specification has stated that this
implication of the type was not considered or intended, and expressed a
desire to prohibit transfer encodings being applied to application/mime
objects.  The only technically effective way to prohibit transfer
encodings on the type is to place it under the "message" top level type,
as intermediaries routinely feel free to transfer-encode arbitrary
subtypes of "application".

I see three alternatives for replacing the use of application/mime in
the document:

a) signedData

This alternative requires the least specification and deployment work. 
It requires more work of gateways which want to convert between the
"tunneled" and "transparent" types.

b) application/signed

This is my proposal for a type which is exactly like multipart/signed,
except the contents are labeled "application/signed" instead of
"multipart/signed".  Since the proposed type is under application, it
may have a non-trivial transfer-encoding applied to it (implying that
readers must be able to handle binary data underneath such an encoding)
and it does not have the default-to-multipart/mixed semantics of
multipart/signed.

As application/signed would be restricted to carrying only signed data,
it would avoid the MIME violation problems in (2).

This alternative requires more work to specify.  Deployment work is
roughly equivalent to application/mime.  The work required of gateways
to convert between the "tunneled" and "transparent" types would be
trivial.

c) message/mime-entity

This is "application/mime" moved underneath the "message" top-level
type, in order to get the transfer encoding restrictions of the
"message" top-level type.

It is unclear to me whether or not such a type violates section 2.2.1 of
RFC 2048.  Such a type is incapable of carrying binary signed objects
over non-binary transports, a disservice to the voice mail community.  A
similar concern applies to 8-bit signed objects.

This alternative requires work to specify, probably equivalent to (b). 
Deployment work is equivalent to application/mime.  Work required of
gateways is probably between application/mime and signedData, as
gateways may have to deal with the case where a multipart/signed object
cannot be tunneled inside a message/mime-entity because of transport
encoding restrictions.

I personally consider this alternative to be inferior to (b).

Date: Wed, 01 Oct 1997 10:25:51 -0400
To: David Solo <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: comments on the smime-cert draft
Cc: [email-masked]
Sender: [email-masked]

At 05:04 PM 9/30/97 -0400, David Solo wrote:
>>>extensions which have the greatest value in the S/MIME environment.
>>>The basicConstraints, keyUsage, and certificatePolicies extensions are
>>>defined in [X.509].
>>>
>>>Sending and receiving agents MUST correctly handle the v3 Basic
>>>Constraints Certificate Extension, the Key Usage Certificate
>>>Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when
>>>they appear in end-user certificates. Some mechanism SHOULD exist to
>>>handle the defined v3 certificate extensions when they appear in
>>>intermediate or CA certificates.
>>>
>>>In the S/MIME environment, CAs which issue v3 certificates SHOULD
>>>include only the extensions listed here.
>>>For these extensions, the criticality flag SHOULD be set to False
>>>unless the proper handling of the corresponding extension is deemed
>>>critical to the correct interpretation of the associated certificate.
>>>Also, in an S/MIME environment, when additional v3 extensions are
>>>included in a certificate, the corresponding criticality flags SHOULD
>>>be set to False.
>>
>>Replace with:
>>Certificates issued for the S/MIME environment SHOULD not contain any
>critical extensions other than those listed here.  These extensions SHOULD
>be marked as non-critical unless the proper handling of the extension is
>deemed critical to the correct interpretation of the associated certificate.
>When other extensions are included, those extensions MUST be marked as
>non-critical.

Dave, This is fine.  Since this will be an IETF document, shouldn't we
reference the PKIX Certificate and CRL profile instead of X.509?

The PKIX Working Group last call on this document was issued this morning.

Russ

Date: Wed, 01 Oct 1997 09:18:18 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Proposed charter for a S/MIME working group
Sender: [email-masked]

This looks like a fine charter to me.

We need a better name for the "Son of PKCS#7 version 1.5 document," but we
can figure that out after ther working group charter is approved.

Russ

At 12:36 PM 9/30/97 -0700, you wrote:
>Greetings, all. As you saw last week, RSA has sent the ISOC material that
>(hopefully) meets the IESG's requirements for what must happen before we
>form an S/MIME working group. So, our next task is to agree on a charter
>and submit it to Jeff Schiller, the area director for security. If Jeff
>agrees, he'll take it to the IESG for their consideration.
>
>Below is what I think a reasonable charter should look like. All comments
>are welcome.
>
>= = = = = = = = =
>
>S/MIME Mail Security (smime)
>
>Chair:
>     Russ Housley <[email-masked]>
>
>Security Area Director:
>     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. 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, 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 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.
>
>
>Goals and Milestones:
>
>History:
>     PKCS #7 version 1.5 specification submitted as Informational RFC.
>     S/MIME v2 message specification submitted as Informational RFC.
>     S/MIME v2 certificate specification submitted as Informational RFC.
>
>October 97:
>     First draft of message syntax specification.
>     First draft of S/MIME v3 message specification.
>     First draft of S/MIME v3 certificate specification.
>     First draft of S/MIME optional security extensions.
>
>December 97:
>     Last call on message syntax specification.
>     Last call on S/MIME v3 message specification.
>     Last call on S/MIME v3 certificate specification.
>
>January 98:
>     Last call on S/MIME optional security extensions.
>     Submit  message syntax specification as a Proposed Standard.
>     Submit S/MIME v3 message specification as a Proposed Standard.
>     Submit S/MIME v3 certificate specification as a Proposed Standard.
>
>February 98:
>     Submit S/MIME optional security extensions as a Proposed Standard.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>

Date: Wed, 1 Oct 1997 08:59:32 -0400
To: Paul Hoffman / IMC <[email-masked]>, [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Proposed charter for a S/MIME working group
Sender: [email-masked]

Paul,

Thank you for drafting the charter.  J.G. Van Dyke & Associates concurs with
the charter.  We plan to actively participate in the IETF S/MIME WG.  We are
currently developing a reference implementation of a library of functions
that will build and process PKCS #7 v1.5 objects including the optional
security features mentioned in the charter.  We will provide source code for
the library as freeware to the Internet community.  Organizations will be
able to use the library as part of their S/MIME v3 implementations including
the optional security features.

==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              [email-masked]

At 12:36 PM 9/30/97 -0700, Paul Hoffman / IMC wrote:
>Greetings, all. As you saw last week, RSA has sent the ISOC material that
>(hopefully) meets the IESG's requirements for what must happen before we
>form an S/MIME working group. So, our next task is to agree on a charter
>and submit it to Jeff Schiller, the area director for security. If Jeff
>agrees, he'll take it to the IESG for their consideration.
>
>Below is what I think a reasonable charter should look like. All comments
>are welcome.
>
>= = = = = = = = =
>
>S/MIME Mail Security (smime)
>
>Chair:
>     Russ Housley <[email-masked]>
>
>Security Area Director:
>     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. 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, 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 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.
>
>
>Goals and Milestones:
>
>History:
>     PKCS #7 version 1.5 specification submitted as Informational RFC.
>     S/MIME v2 message specification submitted as Informational RFC.
>     S/MIME v2 certificate specification submitted as Informational RFC.
>
>October 97:
>     First draft of message syntax specification.
>     First draft of S/MIME v3 message specification.
>     First draft of S/MIME v3 certificate specification.
>     First draft of S/MIME optional security extensions.
>
>December 97:
>     Last call on message syntax specification.
>     Last call on S/MIME v3 message specification.
>     Last call on S/MIME v3 certificate specification.
>
>January 98:
>     Last call on S/MIME optional security extensions.
>     Submit  message syntax specification as a Proposed Standard.
>     Submit S/MIME v3 message specification as a Proposed Standard.
>     Submit S/MIME v3 certificate specification as a Proposed Standard.
>
>February 98:
>     Submit S/MIME optional security extensions as a Proposed Standard.
>
>--Paul E. Hoffman, Director
>--Internet Mail Consortium
>
>
>