Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent

From: [email-masked]
Date: Sat, 31 Oct 1998 14:38:33 -0600

Please open the following message in your web browser

    http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML
____________________________________________________________
International Shoe Manufacturing Corp Update: 
International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage
financing to begin full-scale production at its plants in India. The $4.75 million is being
used to purchase the final equipment needed to begin production at the company’s existing
plant in India. With equipment in place, the company projects net profits of over $25
million a year within two years.

The company stated that the financing will be followed up by a $9 million dollar IPO in
India, anticipated for March 1999. The IPO will be handled by underwriters in India, and
will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the
IPO will pay off the $4.75 million dollar financing. The balance will be used for the
acquisition of additional shoe manufacturing.    

ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe
companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in
Noida, just outside of New Delhi, India, where skilled labor is plentiful and very
inexpensive. The Indian government recently developed new economic policy to attract
foreign investment that is export-oriented, and could employ large numbers of people. 
ISM is the only athletic shoe manufacturer in India directed toward the international
market. It currently has contracts with Adidas and The Pentland Group. These two
companies have agreed to purchase all the shoes ISM can manufacture. 

The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe
companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design
and marketing organizations that spend hundreds of millions of dollars a year getting their
products sold. They then rely on others to manufacture to their specifications. Almost, if
not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of
millions of dollars spent on advertising by the name-brand companies. The result is an
open purchase order where such manufacturers  literally can sell every pair of shoes they
can produce. A business like this lends itself to being privately held due to the large cash
flow allowing for internal financing. International Shoe Manufacturing Corp. is the only
company known to exist that offers a public investor the opportunity to own a share of this
highly lucrative business in a pure  investment play.

For inquiries please contact the office of the director of investor relations toll free at: 
877-ISM-CORP  (877-476-2677)  or send your e-mail request to [email-masked] Your request will be handled immediately.  Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752

Please visit ISM’s web site at www.ismcorp.net
Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press
release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of
1995.  Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual
results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things,
product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations,
imprecision in estimating product reserves and the company’s ability to replace and expand its holdings.

____________________________________________________________

Unsubscribe or access your membership settings at: 
http://gs4.revnet.com/GMG/ctrlpanel/0/79

From: [email-masked]
To: [email-masked]
Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent
Date: Sat, 31 Oct 1998 14:38:33 -0600
Originator: [email-masked]
Sender: [email-masked]

Please open the following message in your web browser

    http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML
____________________________________________________________
International Shoe Manufacturing Corp Update: 
International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage
financing to begin full-scale production at its plants in India. The $4.75 million is being
used to purchase the final equipment needed to begin production at the company’s existing
plant in India. With equipment in place, the company projects net profits of over $25
million a year within two years.

The company stated that the financing will be followed up by a $9 million dollar IPO in
India, anticipated for March 1999. The IPO will be handled by underwriters in India, and
will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the
IPO will pay off the $4.75 million dollar financing. The balance will be used for the
acquisition of additional shoe manufacturing.    

ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe
companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in
Noida, just outside of New Delhi, India, where skilled labor is plentiful and very
inexpensive. The Indian government recently developed new economic policy to attract
foreign investment that is export-oriented, and could employ large numbers of people. 
ISM is the only athletic shoe manufacturer in India directed toward the international
market. It currently has contracts with Adidas and The Pentland Group. These two
companies have agreed to purchase all the shoes ISM can manufacture. 

The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe
companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design
and marketing organizations that spend hundreds of millions of dollars a year getting their
products sold. They then rely on others to manufacture to their specifications. Almost, if
not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of
millions of dollars spent on advertising by the name-brand companies. The result is an
open purchase order where such manufacturers  literally can sell every pair of shoes they
can produce. A business like this lends itself to being privately held due to the large cash
flow allowing for internal financing. International Shoe Manufacturing Corp. is the only
company known to exist that offers a public investor the opportunity to own a share of this
highly lucrative business in a pure  investment play.

For inquiries please contact the office of the director of investor relations toll free at: 
877-ISM-CORP  (877-476-2677)  or send your e-mail request to [email-masked] Your request will be handled immediately.  Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752

Please visit ISM’s web site at www.ismcorp.net
Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press
release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of
1995.  Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual
results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things,
product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations,
imprecision in estimating product reserves and the company’s ability to replace and expand its holdings.

____________________________________________________________

Unsubscribe or access your membership settings at: 
http://gs4.revnet.com/GMG/ctrlpanel/0/79

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Comments on draft-ietf-smime-x942-01
Date: Fri, 30 Oct 1998 17:58:47 -0800
Sender: [email-masked]

The following is mainly because we are in final call and these types of
issues should be addressed:

1.  There is a missing reference in section 2.1.5 (REFERENCE?)  
2.  In section 2.1.6, the example is not correctly formatted.  It is
difficult to make sure that the SEQUENCE immeadiately following the ZZ
comment is part or not part of the example.  You should probably also put
the ZZ value onto a new line rather than following the colon.
3.  The TODO section should not be in a last call document.
4.  Section 2. last sentence.  I think the following would flow better:
	That keying material is typically used as a key encryption key (KEK)
to encrypt (wrap) a message encrytion key (MEK) which is in turn used to
encrypt the message data.
5.  Section 2.1.2 - The paragraph which describes the parameter H, ZZ and
OtherInfo.  Please either put in some periods or some newlines so that this
is really distinct sentences.

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "Robert Klerer" <[email-masked]>
cc: <[email-masked]>, <[email-masked]>
Subject: RE: email oid
Date: Fri, 30 Oct 1998 15:04:51 -0800
Sender: [email-masked]

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, October 29, 1998 5:39 PM
> To: Robert Klerer
> Cc: [email-masked]; [email-masked]
> Subject: Re: email oid
> 
> It is my understanding that the PKCS#9 OID is widely used in S/MIME v2
> implementations.

I have never seen anything other than the PKCS#9 OID used in S/MIME v2.
For the S/MIME camp this is not ambiguous at all.

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

Date: Thu, 29 Oct 1998 20:39:10 -0500
To: "Robert Klerer" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: email oid
Cc: [email-masked], [email-masked]
Sender: [email-masked]

It is my understanding that the PKCS#9 OID is widely used in S/MIME v2
implementations.

Russ

At 08:18 AM 10/29/98 -0500, Robert Klerer wrote:
>The other day in trying to accommodate a legacy pki, I ran into a problem
>with an oid specified in draft-ietf-pkix-ipki-part1-11.  The ASN.1 specifies
>that the oid used for an email address in the distinguished name is
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address.  I and
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>as specified in RFC1274.
>
>Since I believe that the intention is for both of these oids are meant to
>represent attributes that hold the same information, this discrepancy may
>cause confusion and failures in the future.  My suggestion would be to
>change part1 to refer to the more commonly used OID.
>
>
>
>

Date: Thu, 29 Oct 1998 21:50:18 -0500
To: Dr Stephen Henson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-x942-01.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

The section numbering (cut-and-paste error) is fixed.

I will permit the ukm to be present.  I changed the text to say:

"ukm may be absent.  The ukm is used to ensure that a different key-encryption
key is generated if the ephemeral private key might be used for more than
once."

Russ

At 05:11 PM 10/29/98 +0000, Dr Stephen Henson wrote:
>Thanks to Eric for the excellent spec.
>
>Just one brief point. 
>
>This spec suggests that the ephemeral key may be the same for several
>messages and that under such circumstances a separate pubInfo MUST be
>used with each message (2.3). pubInfo coming from ukm in CMS.
>
>However in the CMS the two ES examples given (12.3.1.1 [err there are
>two section 12.3.1.1's: typo?]) state that ukm must be absent.
>
>Personally I'd prefer it if ukm was allowed with CMS rather than banning
>it from X942.
>
>Steve.
>-- 
>Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
>For info see homepage at http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
>

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>, "Paul Hoffman (E-mail)" <[email-masked]>
Subject: ESS-09 ASN.1 comments
Date: Thu, 29 Oct 1998 18:33:56 -0800
Sender: [email-masked]

Here are a set of comments and problems with the ASN module at the end of
the draft.

1.  PolicyInformation import is missing a trailing ')' character ----
iso(1)
2.  CertificateSerialNumber import should not have a trailing comma
3.  The size markers on UTF8String and Printable string are incorrect.  The
SIZE (1..MAX) should really be (SIZE (1..MAX)) for example in ESSPrivacyMark
it should be
ESSPrivacyMark ::= CHOICE {
	pString PrintableString (SIZE (1..ub-privacy-mark-length)),
	utf8String UTF8String (SIZE(1..MAX))
}

Jim

Date: Thu, 29 Oct 1998 12:27:15 -0500
To: Denis Pinkas <[email-masked]>
From: Francois Rousseau <[email-masked]>
Subject: Re: Signing Policy
Cc: [email-masked]
Sender: [email-masked]

Denis,

I totally support your proposal of a "Signing Policy" as a new signed
attribute under ESS, except for the few minor suggestions that I have
interspersed below. It can address both the purpose for my proposed
"counterSignatureScope" attribute and the issue I raised in a previous
message about indicating HOW a "private key" is used to digitally sign
things in particular instances versus what is indicated through its related
public-key certificate.

Francois Rousseau
AEPOS Technologies

>This is an answer to an E-mail from Francois Rousseau posted some time ago
>about countersignatures.
>As you will see the issue is more complex than it looks. A signing Policy is
>proposed to be an additional signed attribute. The full text for such an
>additional section is provided.
>
>> In a previous message I have suggested the addition of a
>> "counterSignatureScope" attribute in ESS to explicitly indicate
>> whether or not the countersigning process has validated the
>> original content. This new attribute could address concerns raised
>> by various people under this mailing list. Dr. Steve Henson has
>> even proposed some minor modifications/expansions to this
>> counterSignatureScope attribute to make it more precise.
>
>> Further to my original message and to address another non-repudiation
>> concern, I would also like to see if there is an interest in generalizing
>> such an attribute in order to also effectively define the scope of a
>> standard digital signature.
>
>> It is my understanding that under the German digital signature law,
>> before a private key can be used to digitally sign something, every
>> usage of the key requires a new card holder verification. To
>> accommodate this requirement there is currently a plan for extending
>> PKCS#11 with new functions and a new attribute. The intention is
>> that a PIN would be needed each time the private key is being used.
>> However, for reliable non-repudiation, there are no means to
>> indicate that such a verification of the PIN was performed under
>> the current signed data syntax of CMS.
>>
>> The counterSignatureScope attribute could be generalized/expanded in
>> a "signatureScope" attribute to also address this scenario and possibly
>> others.
>>
>> Any thoughts?
>
>The generalization I propose is different. See the proposal hereunder.
>
>>
>> Francois Rousseau
>> AEPOS Technologies
>>
>
>I would propose to generalize the concept so that a signer can mention the
>conditions under which he agrees to comply with when signing with his/her
>private key.
>
>I thus propose to consider a Signing Policy (defined hereafter in ASN.1) that
>would be just another signed attribute under ESS and that would be placed on
>either the inner or outer SignedData message.
>
>This would capture the notion you proposed with the CounterSignatureScope
>attribute. Here is some text proposal to be added:
>
>=================================================
>
>SigningPolicy
>
>The SigningPolicy identifies the conditions under which :
>
>   (a) the signer agrees to comply with when signing with his/her
>       private key and
>   (b) the signature should be relied upon.
>
>The signing policy is defined as follows:
>
>   SigningPolicy ::= SEQUENCE {
>     signPolicyIdentifier   SignPolicyId,
>     signPolicyQualifier    SignPolicyQualifier,
>     counterSignQualifier   counterSignQualifier    OPTIONAL,
>     signPolicyUri          SignPolicyUri           OPTIONAL,
>     signPolicyHash         SignPolicyHash          OPTIONAL
>}
>
>   SignPolicyId ::= OBJECT IDENTIFIER
>
>   SignPolicyQualifier ::= CHOICE {
>     policySignPolicyQualifier    ANY DEFINED BY signPolicyIdentifier,
>     internetSignPolicyQualifier  InternetSignPolicyQualifier }
>
>InternetSignPolicyQualifier ::= ENUMERATED {
>                proof_of_receipt    (1),
>                proof_of_delivery   (2),
>                proof_of_approval   (3),
>                proof_of_creation   (4),
>                proof_of_sender     (5),
>                proof_of_origin     (6)
>}
>
>CounterSignatureQualifier ::=  BIT STRING {
>     noValidationPerformed              (0),

Since CounterSignatureQualifier is a BIT STRING and that bit "0" indicates
that no validation at all has been performed, you will need to include some
instructions below that explain that when the "noValidationPerformed"
qualifier bit "0" is turn on, other qualifier "bits" can NOT be turn on.

>     signatureValueValid                (1),

As per Section 5.4 of CMS, the content signature value is computed over a
message digest, which includes the message digest of the original signed
content with any signed attributes if present. Although under CMS the
counter signer is NOT mandated to validate the original content, the
counter signer could still validate that the message digest of the original
signed content with any present signed attributes match with the original
signature. This is what the "signatureValueValid" qualifier as originally
proposed by Dr. Henson was supposed to be addressing.

However, the counter signer could also validate that the original content
matches with the message digest. This is what the "messageDigestValid"
qualifier as originally proposed by Dr. Henson was supposed to be
addressing. To address these two separate aspects, I suggest that you
insert the choice of a "messageDigestValid" bit between the
"signatureValueValid" bit "1" and the "signingTimesTrusted" bit "2" and
renumber accordingly.

If the counter signer validates both the original content and also
validates that the message digest of the original signed content with any
signed attributes match with the original signature, both the
"signatureValueValid" and the "messageDigestValid" bits would than be turn on.

>     signingTimesTrusted                (2),
>     signingTimesValid                  (3),
>     signerCertificatesNotRevoked       (4),
>     certificationPathsCorrect          (5),
>     certificationPathsValid            (6) }
>
>   signPolicyUri ::= IA5String
>
>SignPolicyHash ::= SEQUENCE {
>     digestAlgorithm          DigestAlgorithmIdentifier,
>     digest                   Digest }
>
>DigestAlgorithmIdentifier ::= AlgorithmIdentifier
>
>Digest ::= OCTET STRING    -- hash of inner content
>                           -- of the signed Policy
>
>The signPolicyIdentifier mandates the signing policy to be used in
>the relying party's signature and path validation and identifies a
>qualifier for the signature.
>
>The following list of qualifiers is supported for Internet signing
>policy qualifiers. This list is by no means exhaustive and currently
>corresponds to the values supported by [IDUP]. It is anticipated
>that it may be extended in future versions of this specification.
>
>    "Non-repudiation of Receipt" prevents a message recipient's
>    false denial of having received a message (whose content was
>    not necessarily looked at by the recipient).
>
>    "Non-repudiation of Delivery" prevents a message recipient's
>    false denial of having received and looked at the content of a
>    message.
>
>    "Non-repudiation of Approval" prevents a message recipient's
>    false denial of having approved the content of a received
>    message.
>
>    "Non-repudiation of Creation" prevents a message creator's
>    false denial of creating a message.
>
>    "Non-repudiation of Sender" prevents a message creator's
>    false denial of sending a message (that was not necessarily
>    created by the sender).
>
>    "Non-repudiation of Origin" prevents a message creator's
>    false denial of creating and sending a message.
>
>The CounterSignatureQualifier may be present if the signature is over an
>already CMS signed message. Such a message may be signed by multiple signers.
>In that case the CounterSignatureQualifier indicates the degree of validation
>performed by the countersigner over all the previous signatures. A range of
>validations can be performed starting from none. When different degrees of
>validation can be performed on the previous signatures, the least common
>denominator will be indicated.
>
>Each validation is made in accordance with the signing policy mentioned by
>each signer and is performed for the time the original signer placed its
>signature. Such validation may indicate:
>
>  1) whether no validation at all has been performed,

As suggested above, item 2 would than read:

2) whether the combination of the signedAttributes contained within the
original signed message and the message digest of the content, matches with
the signature appended by each original signer <new>. This does not imply
that access to the original content is available <end>,

>  2) whether the combination of the signedAttributes contained within
>     the original signed message and the message digest of the content,
>     matches with the signature appended by each original signer,

An new item would have to be inserted between items 2 and 3 to address the
"messageDigestValid" qualifier suggested above, which would read:

x) whether the messageDigest attribute matches that of the original content,

>  3) whether the various signature times are considered as trustable
>     (the use of the signingTime attribute by each signer is required),
>  4) whether the times each signer placed its signature were all
>     within the validity period of each certificate,
>  5) whether all signer's public key certificates were not-revoked,
>     at the time each signer placed its signature,
>  6) whether all the certification paths leading to a root key were
>     valid for each signing policy, but no revocation checking has
>     been done.
>  7) whether all the certification paths leading to a root key
>     were valid for each signing policy and revocation checking
>     has been done for the time at which each signer placed its
>     signature.
>
>   Other countersignature qualifiers could be added if required
>   in the future.
>
>   The SignPolicyUri contains a pointer to a Signature Policy
>   Statement (SPS). Such statement must be signed by the Authority
>   providing the statement. The pointer is in the form of a URI.
>
>   The SignPolicyHash contains a hash of the inner content of the SPS.
>   The definition of AlgorithmIdentifier is imported from X.509.
>   Implementations supporting the SignPolicyHash must support SHA-1
>   for the AlgorithmIdentifier.

Date: Thu, 29 Oct 1998 17:11:25 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-x942-01.txt
Sender: [email-masked]

Thanks to Eric for the excellent spec.

Just one brief point. 

This spec suggests that the ephemeral key may be the same for several
messages and that under such circumstances a separate pubInfo MUST be
used with each message (2.3). pubInfo coming from ukm in CMS.

However in the CMS the two ES examples given (12.3.1.1 [err there are
two section 12.3.1.1's: typo?]) state that ukm must be absent.

Personally I'd prefer it if ukm was allowed with CMS rather than banning
it from X942.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x942-01.txt
Date: Thu, 29 Oct 1998 09:32:10 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-01.txt
	Pages		: 7
	Date		: 28-Oct-98
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
   group. An algorithm for converting the shared secret into an arbi-
   trary amount of keying material is provided.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 29 Oct 1998 01:42:49 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

Magnus Nyström wrote:
> 
> Stephen Henson's first approach is similar to the approach taken in the
> new version (2.0) of PKCS#5, where the same problem previously existed -
> pbe algorithms where (unnecessarily) tied to particular encryption
> algorithms (e.g pbeWithMD5AndDES-CBC). My personal opinion is that Stephen
> Hensons proposal is to be preferred, due to it's dynamic nature.
> 

It was because of what happened with PKCS#5 and its variants and
extensions (PFX, PKCS#12 and vendor specific hacks and horrors) that I
made the suggestion.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Thu, 29 Oct 1998 01:56:58 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: S-MIME / IETF <[email-masked]>
Subject: Re: Signing Policy
Sender: [email-masked]

Denis Pinkas wrote:
> 
> This is an answer to an E-mail from Francois Rousseau posted some time ago
> about countersignatures.
> As you will see the issue is more complex than it looks. 

Indeed it is. There is also the issue of trust. A trusted countersigner
is a different beast from a trusted signer and likewise a trusted
countersigning CA is different from a normal end user CA.

I might trust an end user to sign a message (via a chain to a trusted
root) but I certainly wouldn't trust them to countersign a message
purporting to contain trusted timestamps and verifying chains in the
original SignerInfo.

This might be handled by some certificate extensions in the
countersigning certificate and the issuer certificate. This could either
be done either in a simple way (e.g. "certificate key approved for
countersigning" and "CA certificate can sign countersigning
certificates") or in a more intricate fashion ("trusted to countersign
with a trusted timestamp" etc etc).

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Wed, 28 Oct 1998 15:57:27 -0800
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: S-MIME / IETF <[email-masked]>
Subject: Signing Policy
Sender: [email-masked]

This is an answer to an E-mail from Francois Rousseau posted some time ago
about countersignatures.
As you will see the issue is more complex than it looks. A signing Policy is
proposed to be an additional signed attribute. The full text for such an
additional section is provided.

> In a previous message I have suggested the addition of a
> "counterSignatureScope" attribute in ESS to explicitly indicate
> whether or not the countersigning process has validated the
> original content. This new attribute could address concerns raised
> by various people under this mailing list. Dr. Steve Henson has
> even proposed some minor modifications/expansions to this
> counterSignatureScope attribute to make it more precise.

> Further to my original message and to address another non-repudiation
> concern, I would also like to see if there is an interest in generalizing
> such an attribute in order to also effectively define the scope of a
> standard digital signature.

> It is my understanding that under the German digital signature law,
> before a private key can be used to digitally sign something, every
> usage of the key requires a new card holder verification. To
> accommodate this requirement there is currently a plan for extending
> PKCS#11 with new functions and a new attribute. The intention is
> that a PIN would be needed each time the private key is being used.
> However, for reliable non-repudiation, there are no means to
> indicate that such a verification of the PIN was performed under
> the current signed data syntax of CMS.
>
> The counterSignatureScope attribute could be generalized/expanded in
> a "signatureScope" attribute to also address this scenario and possibly
> others.
>
> Any thoughts?

The generalization I propose is different. See the proposal hereunder.

> Francois Rousseau
> AEPOS Technologies

I would propose to generalize the concept so that a signer can mention the
conditions under which he agrees to comply with when signing with his/her
private key.

I thus propose to consider a Signing Policy (defined hereafter in ASN.1) that
would be just another signed attribute under ESS and that would be placed on
either the inner or outer SignedData message.

This would capture the notion you proposed with the CounterSignatureScope
attribute. Here is some text proposal to be added:

=================================================

SigningPolicy

The SigningPolicy identifies the conditions under which :

   (a) the signer agrees to comply with when signing with his/her
       private key and
   (b) the signature should be relied upon.

The signing policy is defined as follows:

   SigningPolicy ::= SEQUENCE {
     signPolicyIdentifier   SignPolicyId,
     signPolicyQualifier    SignPolicyQualifier,
     counterSignQualifier   counterSignQualifier    OPTIONAL,
     signPolicyUri          SignPolicyUri           OPTIONAL,
     signPolicyHash         SignPolicyHash          OPTIONAL
}

   SignPolicyId ::= OBJECT IDENTIFIER

   SignPolicyQualifier ::= CHOICE {
     policySignPolicyQualifier    ANY DEFINED BY signPolicyIdentifier,
     internetSignPolicyQualifier  InternetSignPolicyQualifier }

InternetSignPolicyQualifier ::= ENUMERATED {
                proof_of_receipt    (1),
                proof_of_delivery   (2),
                proof_of_approval   (3),
                proof_of_creation   (4),
                proof_of_sender     (5),
                proof_of_origin     (6)
}

CounterSignatureQualifier ::=  BIT STRING {
     noValidationPerformed              (0),
     signatureValueValid                (1),
     signingTimesTrusted                (2),
     signingTimesValid                  (3),
     signerCertificatesNotRevoked       (4),
     certificationPathsCorrect          (5),
     certificationPathsValid            (6) }

   signPolicyUri ::= IA5String

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

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

Digest ::= OCTET STRING    -- hash of inner content
                           -- of the signed Policy

The signPolicyIdentifier mandates the signing policy to be used in
the relying party's signature and path validation and identifies a
qualifier for the signature.

The following list of qualifiers is supported for Internet signing
policy qualifiers. This list is by no means exhaustive and currently
corresponds to the values supported by [IDUP]. It is anticipated
that it may be extended in future versions of this specification.

    "Non-repudiation of Receipt" prevents a message recipient's
    false denial of having received a message (whose content was
    not necessarily looked at by the recipient).

    "Non-repudiation of Delivery" prevents a message recipient's
    false denial of having received and looked at the content of a
    message.

    "Non-repudiation of Approval" prevents a message recipient's
    false denial of having approved the content of a received
    message.

    "Non-repudiation of Creation" prevents a message creator's
    false denial of creating a message.

    "Non-repudiation of Sender" prevents a message creator's
    false denial of sending a message (that was not necessarily
    created by the sender).

    "Non-repudiation of Origin" prevents a message creator's
    false denial of creating and sending a message.

The CounterSignatureQualifier may be present if the signature is over an
already CMS signed message. Such a message may be signed by multiple signers.
In that case the CounterSignatureQualifier indicates the degree of validation
performed by the countersigner over all the previous signatures. A range of
validations can be performed starting from none. When different degrees of
validation can be performed on the previous signatures, the least common
denominator will be indicated.

Each validation is made in accordance with the signing policy mentioned by
each signer and is performed for the time the original signer placed its
signature. Such validation may indicate:

  1) whether no validation at all has been performed,
  2) whether the combination of the signedAttributes contained within
     the original signed message and the message digest of the content,
     matches with the signature appended by each original signer,
  3) whether the various signature times are considered as trustable
     (the use of the signingTime attribute by each signer is required),
  4) whether the times each signer placed its signature were all
     within the validity period of each certificate,
  5) whether all signer's public key certificates were not-revoked,
     at the time each signer placed its signature,
  6) whether all the certification paths leading to a root key were
     valid for each signing policy, but no revocation checking has
     been done.
  7) whether all the certification paths leading to a root key
     were valid for each signing policy and revocation checking
     has been done for the time at which each signer placed its
     signature.

   Other countersignature qualifiers could be added if required
   in the future.

   The SignPolicyUri contains a pointer to a Signature Policy
   Statement (SPS). Such statement must be signed by the Authority
   providing the statement. The pointer is in the form of a URI.

   The SignPolicyHash contains a hash of the inner content of the SPS.
   The definition of AlgorithmIdentifier is imported from X.509.
   Implementations supporting the SignPolicyHash must support SHA-1
   for the AlgorithmIdentifier.

Date: Wed, 28 Oct 1998 09:16:30 -0500 (Eastern Standard Time)
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <[email-masked]>
To: Russ Housley <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

Stephen Henson's first approach is similar to the approach taken in the
new version (2.0) of PKCS#5, where the same problem previously existed -
pbe algorithms where (unnecessarily) tied to particular encryption
algorithms (e.g pbeWithMD5AndDES-CBC). My personal opinion is that Stephen
Hensons proposal is to be preferred, due to it's dynamic nature.

/Magnus
------------------------------------------------------------
Magnus Nyström            Email: [email-masked]
RSA Laboratories          Phone: (781) 687-7000
20 Crosby Drive           Fax:   (781) 687-7213
Bedford, MA 01730  USA                                          

On Tue, 27 Oct 1998, Russ Housley wrote:

> I think I understand Steve's point.  What do others think about this topic?
> 
> Russ

Date: Tue, 27 Oct 1998 18:31:53 -0500
To: "[email-masked]" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

I think I understand Steve's point.  What do others think about this topic?

Russ

At 04:52 PM 10/27/98 +0000, Dr Stephen Henson wrote:
>Ooops I messed up my response and got key agreement and transport
>transposed sorry. Hopefully it should have read...
>
>Dr Stephen Henson wrote:
>> 
>> 
>> The key encryption key algorithm and key transport algorithm is
>> determined implicitly from the keyEncryptionAlgorithm (which is now a
>> "key transport algorithm and key encryption algorithm") and the IV is
>> 'A5' as mentioned in 12.6.2 (6).
>> 
>
>I meant key agreement algorithm... 
>
>> 
>>    KeyTransRecipientInfo ::= SEQUENCE {
>>      version CMSVersion,  -- always set to 0 or 2
>>      rid RecipientIdentifier,
>>      keyTransportAlgorithm KeyTransportAlgorithmIdentifier,
>>      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>>      encryptedKey EncryptedKey }
>> 
>
>Likewise this proposal should read:
>
>      KeyAgreeRecipientInfo ::= SEQUENCE {
>        version CMSVersion,  -- always set to 3
>        originator [0] EXPLICIT OriginatorIdentifierOrKey,
>        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
>	keyArgeeAlgorithmIdentifier KeyAgreeAlgorithmIdentifier,
>        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>        recipientEncryptedKeys RecipientEncryptedKeys }
>
>Steve.
>-- 
>Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
>For info see homepage at http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
>

Date: Tue, 27 Oct 1998 16:52:39 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
CC: Russ Housley <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

Ooops I messed up my response and got key agreement and transport
transposed sorry. Hopefully it should have read...

Dr Stephen Henson wrote:
> 
> 
> The key encryption key algorithm and key transport algorithm is
> determined implicitly from the keyEncryptionAlgorithm (which is now a
> "key transport algorithm and key encryption algorithm") and the IV is
> 'A5' as mentioned in 12.6.2 (6).
> 

I meant key agreement algorithm... 

> 
>    KeyTransRecipientInfo ::= SEQUENCE {
>      version CMSVersion,  -- always set to 0 or 2
>      rid RecipientIdentifier,
>      keyTransportAlgorithm KeyTransportAlgorithmIdentifier,
>      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>      encryptedKey EncryptedKey }
> 

Likewise this proposal should read:

      KeyAgreeRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 3
        originator [0] EXPLICIT OriginatorIdentifierOrKey,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
	keyArgeeAlgorithmIdentifier KeyAgreeAlgorithmIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        recipientEncryptedKeys RecipientEncryptedKeys }

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Tue, 27 Oct 1998 12:09:00 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

Russ Housley wrote:
> 
> Steve & Eric:
> 
> >>    The key-encryption key is generated by the key agreement algorithm or
> >>    distributed as a mail list key.  With key agreement, the minimum
> >>    number of bits needed to form the key-encryption key must be used.
> >>    As an example, only the first 40 bits of Diffie-Hellman generated
> >>    keying material are used for a RC2/40 key-encryption key.
> >
> >This appears to be the "RC2 key length X/8" option. This adds the
> >restriction that X/8 must always be used in mixed DH+RSA messages though
> >just RSA need not be restricted to X/8. Or am I misinterpreting this?
> 
> How about:
> 
> The key-encryption key is generated by the key agreement algorithm or
> distributed as a mail list key.  For key agrement of RC2 key-encryption keys,
> 128 bits must be generated as input to the key expansion process used to
> compute the RC2 effective key [RFC 2268].
> 

OK as far as it goes but a few more points need calrifying IMHO.

1. The message encryption key (MEK) length cannot be determined
unambiguously from the wrapping algorithm. Unless the wrapping algorithm
is suitably modified (e.g. use standard block padding) this means that
whenever RC2 is used to key aggreement the MEK key must also be 128 bits
in length. This must also apply to messages where at least one recipient
uses key agreement but need not apply to those where all use key
transport.

2. It is implied in the fixed key length that RC2 with >128 bits cannot
be used if at least one recipient uses key agreement.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Tue, 27 Oct 1998 12:46:34 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

Russ Housley wrote:
> 
> Steve:
> 
> >As I understand the ES DH description there are two separate OIDs:
> >id-alg-ESDHwithRC2 and id-alg-ESDHwith3DES. This specifies both the key
> >transport and the symmetric encryption algorithms. What if someone wants
> >to use a different symmetric algorithm? Do they need to register an
> >id-alg-ESDHwithXXX OID and does everyone need to change their code to
> >support it? If history is anything to go by this will result in lots of
> >incompatible id-alg-ESDHwithXXX OIDs used by different applications.
> 
> Yes, an new OID is needed for each ESDHwithXXX.  We could have assigned one
> OID with a parameter of the symmetric algorithm, but then the structure is
> not quite right since the symmetric algorithm OID might require IVs or some
> other parameter.
> 

OK let me see if I've got this right. The message encryption key and
parameters (e.g. IV) come from the ContentEncryptionAlgorithmIdentifier
field.

The key encryption key algorithm and key transport algorithm is
determined implicitly from the keyEncryptionAlgorithm (which is now a
"key transport algorithm and key encryption algorithm") and the IV is
'A5' as mentioned in 12.6.2 (6).

This implies that the content encryption algorithm can be anything but
the key encryption algorithm can only be RC2 or triple DES unless and
until more OIDs are registered. 

Although 3DES is mandatory for S/MIME I suspect someone is going to want
to use DES, Blowfish, Idea or maybe RC5 and would not want to implement
another symmetric algorithm just for the key wrap. Considering the
change in US crypto laws there may be good reasons why someone would
want to use DES for 56 bits to avoid possible patent problems with 56
bit RC2. IMHO we should at least provide some syntax where this can be
done without necessitating OID registration and the possible chaos of
multiple OIDs.

I agree that just using an AlgorithmIdentifier for the KEK algorithm is
not strictly speaking correct because the IV will be included but 'A5'
will be used for the IV. However this appears to be allowed for in
12.6.1:

>    Some key-encryption algorithm identifiers include an IV as part of
>    the parameters.  The IV must still be the constant above.

Adding support for arbitrary key wrapping algorithms could be done in
two ways. One as you mention is to include the KEK algorithm in the
KeyEncryptionAlgorithmIdentifier parameters. The other is to change
KeyTransRecipientInfo to read:

   KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyTransportAlgorithm KeyTransportAlgorithmIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

So that for example for triple DES KeyEncryptionAlgorithmIdentifier
would be id-alg-ESDH and KeyEncryptionAlgorithmIdentifier would be
des-ede3-cbc the IV present being ignored for the key wrap and 'A5' used
instead (or maybe even forcing the IV parameter to be 'A5' and returning
and error if it is not).

A similar thing could be done with the mailing list wrapping algorithms.

This would have the advantage that any wrapping algorithms could be
handled automatically (if the algorithm was supported) rather than
having to add algorithm specific code for each wrapping OID.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 26 Oct 1998 22:40:22 -0500
To: Dr Stephen Henson <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve & Eric:

>>    The key-encryption key is generated by the key agreement algorithm or
>>    distributed as a mail list key.  With key agreement, the minimum
>>    number of bits needed to form the key-encryption key must be used.
>>    As an example, only the first 40 bits of Diffie-Hellman generated
>>    keying material are used for a RC2/40 key-encryption key.
>
>This appears to be the "RC2 key length X/8" option. This adds the
>restriction that X/8 must always be used in mixed DH+RSA messages though
>just RSA need not be restricted to X/8. Or am I misinterpreting this?

How about:

The key-encryption key is generated by the key agreement algorithm or
distributed as a mail list key.  For key agrement of RC2 key-encryption keys,
128 bits must be generated as input to the key expansion process used to
compute the RC2 effective key [RFC 2268].

Russ 

Date: Mon, 26 Oct 1998 22:23:38 -0500
To: Dr Stephen Henson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve:

>As I understand the ES DH description there are two separate OIDs:
>id-alg-ESDHwithRC2 and id-alg-ESDHwith3DES. This specifies both the key
>transport and the symmetric encryption algorithms. What if someone wants
>to use a different symmetric algorithm? Do they need to register an
>id-alg-ESDHwithXXX OID and does everyone need to change their code to
>support it? If history is anything to go by this will result in lots of
>incompatible id-alg-ESDHwithXXX OIDs used by different applications.

Yes, an new OID is needed for each ESDHwithXXX.  We could have assigned one
OID with a parameter of the symmetric algorithm, but then the structure is
not quite right since the symmetric algorithm OID might require IVs or some
other parameter.

>Is there some specific reason why we can't do the same as with RSA? That
>is have an id-alg-ESDH OID and then a separate symmetric algorithm OID.
>That way if someone wants to support some other algorithm with a
>registered OID they can already do it in a compatible way.

With RSA, the symmetric algorithm OID is inside the encrypted structure.
With E-S D-H we would have to put the symmetric algorithm OID as a
parameter to the ESDH OID.

>In 12.6:
>
>>    The key-encryption key is generated by the key agreement algorithm or
>>    distributed as a mail list key.  With key agreement, the minimum
>>    number of bits needed to form the key-encryption key must be used.
>>    As an example, only the first 40 bits of Diffie-Hellman generated
>>    keying material are used for a RC2/40 key-encryption key.
>
>This appears to be the "RC2 key length X/8" option. This adds the
>restriction that X/8 must always be used in mixed DH+RSA messages though
>just RSA need not be restricted to X/8. Or am I misinterpreting this?

You're right about this. Based on Eric's message, I will change it to use
the Fixed-128 option.

Russ

To: Dr Stephen Henson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Russ Housley <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
From: EKR <[email-masked]>
Date: 26 Oct 1998 18:57:55 -0800
Lines: 20
Sender: [email-masked]

Dr Stephen Henson <[email-masked]> writes:
> In 12.6:
> 
> >    The key-encryption key is generated by the key agreement algorithm or
> >    distributed as a mail list key.  With key agreement, the minimum
> >    number of bits needed to form the key-encryption key must be used.
> >    As an example, only the first 40 bits of Diffie-Hellman generated
> >    keying material are used for a RC2/40 key-encryption key.
> 
> This appears to be the "RC2 key length X/8" option. This adds the
> restriction that X/8 must always be used in mixed DH+RSA messages though
> just RSA need not be restricted to X/8. Or am I misinterpreting this?
You're right about this. Russ, I thought the plan here was to
use the Fixed-128 option.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

Date: Tue, 27 Oct 1998 02:32:48 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
CC: Russ Housley <[email-masked]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Sender: [email-masked]

Russ,

A few comments.

As I understand the ES DH description there are two separate OIDs:
id-alg-ESDHwithRC2 and id-alg-ESDHwith3DES. This specifies both the key
transport and the symmetric encryption algorithms. What if someone wants
to use a different symmetric algorithm? Do they need to register an
id-alg-ESDHwithXXX OID and does everyone need to change their code to
support it? If history is anything to go by this will result in lots of
incompatible id-alg-ESDHwithXXX OIDs used by different applications.

Is there some specific reason why we can't do the same as with RSA? That
is have an id-alg-ESDH OID and then a separate symmetric algorithm OID.
That way if someone wants to support some other algorithm with a
registered OID they can already do it in a compatible way.

In 12.6:

>    The key-encryption key is generated by the key agreement algorithm or
>    distributed as a mail list key.  With key agreement, the minimum
>    number of bits needed to form the key-encryption key must be used.
>    As an example, only the first 40 bits of Diffie-Hellman generated
>    keying material are used for a RC2/40 key-encryption key.

This appears to be the "RC2 key length X/8" option. This adds the
restriction that X/8 must always be used in mixed DH+RSA messages though
just RSA need not be restricted to X/8. Or am I misinterpreting this?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 26 Oct 1998 17:06:03 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [email-masked]
Sender: [email-masked]

S/MIME WG Memebers:

CMS is now read for Working Group Last Call.  The X9.42 draft is not
complete, but it should be posted near the end of the week.  Last Call will
close two weeks after the X9.42 draft is posted.

Russ
S/MIME WG Chair

>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the 
>IETF.
>
>	Title		: Cryptographic Message Syntax
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-smime-cms-07.txt
>	Pages		: 52
>	Date		: 23-Oct-98
>	
>   This document describes the Cryptographic Message Syntax.  This
>   syntax is used to digitally sign, digest, authenticate, or encrypt
>   arbitrary messages.
> 
>   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
>   [RFC 2315].  Wherever possible, backward compatibility is preserved;
>   however, changes were necessary to accommodate attribute certificate
>   transfer and key agreement techniques for key management.
> 
>   This draft is being discussed on the 'ietf-smime' mailing list.  To
>   join the list, send a message to <[email-masked]> with
>   the single word 'subscribe' in the body of the message.  Also, there
>   is a Web site for the mailing list at <http://www.imc.org/ietf->   smime/>.
>
>Internet-Drafts are available by anonymous FTP.  Login with the username
>"anonymous" and a password of your e-mail address.  After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-smime-cms-07.txt".
>A URL for the Internet-Draft is:
>ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-07.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nis.garr.it
>			
>	Pacific Rim: munnari.oz.au
>	
>	US East Coast: ftp.ietf.org
>	
>	US West Coast: ftp.isi.edu
>
>Internet-Drafts are also available by mail.
>
>Send a message to:	[email-masked].  In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-cms-07.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-cms-07.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-07.txt>

Date: Mon, 26 Oct 1998 19:52:09 +0000
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: Francois Rousseau <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-ess-09.txt
Sender: [email-masked]

Francois Rousseau wrote:
> 
> I do not think that this issue, which I raised in my previous message on a
> "signatureScope" attribute, of how "private keys" are used, which I will
> call a "Secure Sign" issue, can be resolved with public-key certificates.
> 
> The "Key Usage" extension from PKIX-1 may indicate the purpose of the
> public key contained in the certificate. The selection of the
> "digitalSignature" bit does not indicate how the private key is used in a
> particular case, but only that it can be used to performed digital
> signatures. Similarly the "Extended Key Usage" extension from PKIX-1 may
> indicate one or more purposes for which the certified public key may be
> used, in addition to or in place of the basic purposes indicated in the key
> usage extension field. It still does not indicate how the private key is
> used in a particular case. Similarly the "Certificate Policies" extension
> from PKIX-1 may contain a sequence of one or more policy information terms,
> each of which consists of an object identifier (OID) and optional
> qualifiers. These policy information terms indicate the policy under which
> the certificate has been issued and the purposes for which the certificate
> may be used. It still does not indicate how the private key is used in a
> particular case. Although the "Signing Certificate" attribute from ESS
> allows to bind under the signature of the sequence of policy IDs from the
> "Certificate Policies" extension from PKIX-1, it still does not address how
> the private key is used in a particular case.
> 

I think the problem is that with current crypto hardware it is difficult
to find some reliable way to say how a private key was used in a
"particular case". 

My suggestion was meant to imply that the certificate could contain some
indication saying that the private key can *only* be used in this way.

This would mean in practice that a CA would include this flag in an end
user certificate if the certificate was part of some hardware that
always required the PIN to be entered for each signature. Either
extended key usage or policy could be used for this purpose.

Trying to handle both cases (PIN entered on each signing and PIN only
entered once initially) with the same private key and certificate
present considerable problems considering how simple most "smart card"
technology currently is. In practice it would be much more easily
handled just using separate keys and certificates.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 26 Oct 1998 12:51:52 -0500
To: Dr Stephen Henson <[email-masked]>
From: Francois Rousseau <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-09.txt
Cc: [email-masked]
Sender: [email-masked]

I do not think that this issue, which I raised in my previous message on a
"signatureScope" attribute, of how "private keys" are used, which I will
call a "Secure Sign" issue, can be resolved with public-key certificates.

The "Key Usage" extension from PKIX-1 may indicate the purpose of the
public key contained in the certificate. The selection of the
"digitalSignature" bit does not indicate how the private key is used in a
particular case, but only that it can be used to performed digital
signatures. Similarly the "Extended Key Usage" extension from PKIX-1 may
indicate one or more purposes for which the certified public key may be
used, in addition to or in place of the basic purposes indicated in the key
usage extension field. It still does not indicate how the private key is
used in a particular case. Similarly the "Certificate Policies" extension
from PKIX-1 may contain a sequence of one or more policy information terms,
each of which consists of an object identifier (OID) and optional
qualifiers. These policy information terms indicate the policy under which
the certificate has been issued and the purposes for which the certificate
may be used. It still does not indicate how the private key is used in a
particular case. Although the "Signing Certificate" attribute from ESS
allows to bind under the signature of the sequence of policy IDs from the
"Certificate Policies" extension from PKIX-1, it still does not address how
the private key is used in a particular case.

Indeed this is an issue with indicating HOW a "private key" is used to
digitally sign things in particular instances and not with its related
public-key certificate. This should only be reflected in each particular
digitally signed thing. However, there are currently no means under CMS
and/or ESS to indicate under what circumstances a "private key" was used to
perform a particular digital signature. Ultimately, unless the
cryptographic module performing such a "secure sign" function could append
this "signatureScope" attribute on its own, I agree with Dr. Henson that
there will always be a trust issue with the user/application including such
an attribute. 

Any more thoughts?

Francois Rousseau
AEPOS Technologies

Dr Stephen Henson wrote:
>
>I'm not sure if I follow this. If the "signatureScope" is meant to be
>a signed attribute and signed by the signer then it would not be
>trustable: any certificate (whether the verification was performed or
>not) could include any value they wanted.
>
>There are several possible alternatives. One is an indicator in the
>signer's certificate (or issuing CA): since this is signed by the CA it
>would be trustable, but that makes it a PKIX issue. This might add a
>complication to the S/MIME chain verification in some cases.
>
>Alternatively a countersigner could verify that the signing certificate
>was valid for this purpose and include a bit in the proposed
>counterSignatureScope signed attribute. This adds the complication that
>the client would need to trust the counter signing authority as a "proxy
>chain verifier". 
>
>Steve.
>
>Francois Rousseau wrote:
>> 
>> It is my understanding that under the German digital signature law, before
>> a private key can be used to digitally sign something, every usage of the
>> key requires a new card holder verification. To accommodate this
>> requirement there is currently a plan for extending PKCS#11 with new
>> functions and a new attribute. The intention is that a PIN would be needed
>> each time the private key is being used. However, for reliable
>> non-repudiation, there are no means to indicate that such a verification of
>> the PIN was performed under the current signed data syntax of CMS. The
>> counterSignatureScope attribute could be generalized/expanded in a
>> "signatureScope" attribute to also address this scenario and possibly
others.
>> Any thoughts?

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-07.txt
Date: Mon, 26 Oct 1998 10:22:18 -0500
Sender: [email-masked]

--NextPart

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

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

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Sat, 24 Oct 1998 17:56:11 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-09.txt
Sender: [email-masked]

Francois Rousseau wrote:
> 
> 
> It is my understanding that under the German digital signature law, before
> a private key can be used to digitally sign something, every usage of the
> key requires a new card holder verification. To accommodate this
> requirement there is currently a plan for extending PKCS#11 with new
> functions and a new attribute. The intention is that a PIN would be needed
> each time the private key is being used. However, for reliable
> non-repudiation, there are no means to indicate that such a verification of
> the PIN was performed under the current signed data syntax of CMS. The
> counterSignatureScope attribute could be generalized/expanded in a
> "signatureScope" attribute to also address this scenario and possibly others.
> 
> Any thoughts?
> 

I'm not sure I follow this. If the "signatureScope" is meant to be a
signed attribute and signed by the signer then it would not be
trustable: any certificate (whether the verification was performed or
not) could include any value they wanted.

There are several possible alternatives. One is an indicator in the
signer's certificate (or issuing CA): since this is signed by the CA it
would be trustable, but that makes it a PKIX issue. This might add a
complication to the S/MIME chain verification in some cases.

Alternatively a countersigner could verify that the siging certificate
was valid for this purpose and include a bit in the proposed
counterSignatureScope signed attribute. This adds the complication that
the client would need to trust the counter signing authority as a "proxy
chain verifier". 

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: Stefan_Salzmann/HAM/[email-masked]
To: [email-masked]
Date: Fri, 23 Oct 1998 11:12:01 +0200
Subject: Difference between ssl certificate and smime certificate?
Sender: [email-masked]

Hi all,

Does anybody know the difference between smime certificates and ssl
certificates?

Regards
Stefan

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Ambiguity for EnvelopedData and PKCS#7
Date: Wed, 21 Oct 1998 13:24:31 -0700
Sender: [email-masked]

At Microsoft we appear to have run into a problem with an ambiguity in the
PKCS#7 documents and how we implemented the wrapping of non id-data in an
EnvelopedData structure.

The text from PKCS #7 on the Content-encryption process is:

"The input to the content-encryption process is the "value" of the content
being enveloped. Specifically, the input is the contents octets of a
definite-length BER encoding of the content field of the ContentInfo value
to which the enveloping process is applied. Only the contents octets of the
BER encoding are encrypted, not the identifier octets or length octets;
those other octets are not represented at all.
When the content being enveloped has content type data, then just the value
of the data (e.g., the contents of a file) is encrypted. This has the
advantage that the length of the content being encrypted need not be known
in advance of the encryption process. This method is compatible with
Privacy-Enhanced Mail.
The identifier octets and the length octets are not encrypted. The length
octets may be protected implicitly by the encryption process, depending on
the encryption algorithm. The identifier octets are not protected at all,
although they can be recovered from the content type, assuming that the
content type uniquely determines the identifier octets. Explicit protection
of the identifier and length octets requires that the
signed-and-enveloped-data content type be employed, or that the
digested-data and enveloped-data content types be applied in succession."
The problem here is that one reading of the text appears to imply that, for
non id-data, the identifier and length octets of the item to be encoded
should be striped PRIOR to the encryption and result of the encryption
placed into the EncryptedContent.  Unfortionately, it appears that Microsoft
interperated this way and has shipped product like this.  It is not clear at
this point if this is being used by callers of our APIs, but the normal
method of doing Enveloped(Signed(id-data)) appears to imply that this is
what should be done (i.e. no id-data wrapping between the Enveloped and the
Signed).
In order to prevent (save?) ourselfs from this problem, I propose the
following change to CMS
    version is the syntax version number. If originatorInfo is present, then
version shall be 2. <new> If the contentType is not id-data, then version
shall be 2.<end> If any of the RecipientInfo structures included have a
version other than 0, then the version shall be 2.  If originatorInfo is
absent<new>, the contentType is id-data<end> and all of the RecipientInfo
structures are version 0, then version shall be 0.

Date: Wed, 21 Oct 1998 16:09:32 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-09.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

In a previous message I have suggested the addition of a
"counterSignatureScope" attribute in ESS to explicitly indicate whether or
not the countersigning process has validated the original content. This new
attribute could address concerns raised by various people under this
mailing list. Dr. Steve Henson has even proposed some minor
modifications/expansions to this counterSignatureScope attribute to make it
more precise.

Further to my original message and to address another non-repudiation
concern, I would also like to see if there is an interest in generalizing
such an attribute in order to also effectively define the scope of a
standard digital signature. 

It is my understanding that under the German digital signature law, before
a private key can be used to digitally sign something, every usage of the
key requires a new card holder verification. To accommodate this
requirement there is currently a plan for extending PKCS#11 with new
functions and a new attribute. The intention is that a PIN would be needed
each time the private key is being used. However, for reliable
non-repudiation, there are no means to indicate that such a verification of
the PIN was performed under the current signed data syntax of CMS. The
counterSignatureScope attribute could be generalized/expanded in a
"signatureScope" attribute to also address this scenario and possibly others.

Any thoughts?

Francois Rousseau
AEPOS Technologies

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-09.txt
Date: Wed, 21 Oct 1998 10:07:21 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-09.txt
	Pages		: 35
	Date		: 20-Oct-98
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
 - signed receipts
 - security labels
 - secure mailing lists
 
The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient.
 
The format of the messages are described in ASN.1:1988 [ASN1-1988].
 
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 21 Oct 1998 11:39:38 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: IETF-PXIX <[email-masked]>, S-MIME / IETF <[email-masked]>
Subject: Cert. identifiers in OCSP and ESS
Sender: [email-masked]

Certificate identifiers are used both the OCSP specification from the PKIX WG
and in the ESS specification from the S/MIME WG. This is the reason why this
mail is posted to both the S/MIME and PKIX WGs.

A recent proposal made by Jim Schaad has been to change the "CertID
"definition from the S/MIME WG to "ESSCertID" because we had two different
ASN1 definitions for the same name. :-(

I would prefer to call the later "SigningCert", since the Certificates are
signed attributes and thus remove the ESS co-notation. We would then have :

     SigningCertificates ::=  SEQUENCE {
          certs        SEQUENCE OF SigningCert,
          (stuff deleted)

This is (only) a naming issue. :-)

A much more important concern is how to use the CertID content from ESS and
the CertID from the OCSP protocol altogether.

The current definition of CertID in ESS-08 is as follows:

     SigningCertificate ::=  SEQUENCE {
          certs        SEQUENCE OF CertID,
          policies     SEQUENCE OF PolicyInformation OPTIONAL
     }

   CertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

   Hash ::= OCTET STRING -- SHA1 hash of entire certificate

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

The current definition of CertID in OCSP-07 is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuer's public key
       serialNumber        CertificateSerialNumber }

One of the problems is that the current definition places limitations when
using both specifications.

A receiver of a signed message will be able to extract directly the
issuerSerial from the received message either from the CertID field or from
the issuerAndSerialNumber field contained in SignerInfo. It would be nice if
he would then immediately be able to ask to an OCSP server whether the
certificate is revoked or not. However, it can't.

He needs to obtain first the right issuerKeyHash, i.e. the hash of the
issuer's public key. For this he needs to fetch the certificate BEFORE making
the OCSP request AND to get the issuer public key. This can take long.

The goal is to be able to perform the operations in parallel or in whatever
order.

For this, what should be changed ? In which specification ?

I could end up the mail here. However, I will attempt to make a proposal which
is certainly not the single way to solve this issue. So other proposals
reaching the same goal are welcomed.

The idea is to optimise the cases where there is no name collisions for the
DNs of the CAs, without sacrifying any security. In case of name collision,
i.e. the same OCSP server supports two CAs with the same DN - which will be
very scarce in practice - performance will be much lower.

Let us redefine CertID in OCSP-07 is as follows:

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING OPTIONAL,
                           -- Hash of Issuer's public key
       serialNumber        CertificateSerialNumber }

i.e. let us make the issuerKeyHash OPTIONAL in the OCSP request. This means
that the receiver can immediately construct its OCSP request and send it to
the OCSP server while fetching after or in parallel the certificate and the
issuer public key.

In order to make sure that the right issuer was indeed selected, the OCSP
server will have to include in its response the issuerKeyHash. Thus "after the
fact", i.e. after fetching the certificate and the issuer public key, the
receiver can check that he got the right response from the OCSP server. If
not, he will have to query again the OCSP server using the issuerKeyHash in
its request.

I would thus propose that we modify OCSP to make issuerKeyHash optional and
this we add some text to explain that issuerKeyHash is optional for the
request but mandatory for the response.

I would also propose that we use the term "SigningCert" in the ESS document.

Denis

Date: Tue, 20 Oct 1998 00:02:02 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: Francois Rousseau <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Countersignature Security Consideration and proposed new  counterSignatureScope attribute for ESS
Sender: [email-masked]

Francois Rousseau wrote:
> 
> In response to Russ request for the "Security Considerations" section of
> CMS, I agree with others that CMS should not force a counter signer to
> validate the original content mainly for backward compatibility reasons.
> 
> For discussion on this mailing list, the suggested addition to ESS about
> this new attribute could read as follow:
> 
> "6. Countersignature Scope Attribute
> 
> The counterSignature attribute from [CMS] includes a digital signature that
> is computed on the content signature value, thus the countersigning process
> need not know the original signed content.  This structure permits
> implementations efficiency advantages; however, this structure may also
> permit the countersigning of an inappropriate signature value.   Although
> implementations that perform countersignatures could validate the original
> signature value prior to countersigning it (this validation requires
> processing of the original content), there are currently no means to
> indicate that the original content was validated.   This shortcoming, which
> might be adequate in most circumstance, does not address scenarios where a
> counter signer would have to explicitly indicate whether or not the
> original content was validated.
> 
> To effectively define the scope of the countersignature, the
> counterSignatureScope attribute MUST be present, in addition to existing
> attributes that are currently allowed in a counterSignature (e.g.
> counterSignature, messageDigest, signingTime, and signingCertificate).
> 
> The counterSignatureScope attribute MUST be a signed attribute; it cannot
> be an unsigned attribute, an authenticated attribute, or an unauthenticated
> attribute.
> 
> The following object identifier identifies the counterSignatureScope
> content type:
> 
>         id-aa-counterSignatureScope OBJECT IDENTIFIER ::= { iso(1)
>                 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
>                 smime(16) id-aa(2) <TBD> }
> 
> The definition of CounterSignatureScope is:
> 
> CounterSignatureScope ::=  INTEGER {
>         content validated               (0),
>         -- the countersigning process has validated the content
>         content not validated   (1),
>         -- the countersigning process has NOT validated the content
> }
> 
> A counterSignatureScope attribute must have a single attribute value."
> 

I agree with the principle but I would suggest that a BIT STRING would
be more appropriate and have several bits with different meanings to
allow the term "validated the content" to be more precisely stated.
Exactly what bits are used is open to debate. I'll suggest a few
possibilities, some of these could be combined or further qualified.

CounterSignatureScope ::=  BIT STRING {
           signatureValueValid      (0),
           messageDigestValid       (1),
           chainValid               (2),
           signerNotRevoked         (3),
	   timeStampTrusted	    (4) }

signatureValueValid: the signatureValue of the signedAttributes is
valid. This need not imply that access to the original content is
available.

messageDigestValid: the messageDigest attribute matches that of the
original content.

chainValid: the signing certificate chain is valid but no revocation
checking has been done.

signerNotRevoked: the signing certificate has not been revoked.

timeStampTrusted: the timestamp on the message can be considered
reliable.

Another possible flag would be that the countersigner verified some kind
of proof of private key possession.

There are several security issues involved. For example for
signerNotRevoked to be useful the signingCertificate attribute must be
present in the original signedAttributes (to avoid a substitution
attack). signerNotRevoked and trustedTimeStamp should imply that the
signing certificate was valid at some time on or after the timestamp.

This allows the counterSignature attribute to cover a whole range of
possible uses from a simple trusted time stamp to reliable
nonrepudiation.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Mon, 19 Oct 1998 09:47:30 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Diffie-Hellman Choices
Sender: [email-masked]

S/MIME Working Group:

The Concensus is clear.  We will proceed with Ephemeral-Static Diffie-Hellman.

Russ 

Date: Fri, 16 Oct 1998 11:13:17 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: Countersignature Security Consideration and proposed new counterSignatureScope attribute for ESS
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

In response to Russ request for the "Security Considerations" section of
CMS, I agree with others that CMS should not force a counter signer to
validate the original content mainly for backward compatibility reasons.

However, because of an historical shortcoming in the counterSignature
attribute and as previously suggested by Dr. Steve Henson and Denis Pinkas
recently, I would like to propose a new attribute for ESS, which would have
to be present to explicitly indicate whether or not the countersigning
process has validated the original content. As noted above, this new
attribute would only be useful if CMS does not mandate a counter signer to
validate the original content.

For discussion on this mailing list, the suggested addition to ESS about
this new attribute could read as follow:

"6. Countersignature Scope Attribute

The counterSignature attribute from [CMS] includes a digital signature that
is computed on the content signature value, thus the countersigning process
need not know the original signed content.  This structure permits
implementations efficiency advantages; however, this structure may also
permit the countersigning of an inappropriate signature value.   Although
implementations that perform countersignatures could validate the original
signature value prior to countersigning it (this validation requires
processing of the original content), there are currently no means to
indicate that the original content was validated.   This shortcoming, which
might be adequate in most circumstance, does not address scenarios where a
counter signer would have to explicitly indicate whether or not the
original content was validated.

To effectively define the scope of the countersignature, the
counterSignatureScope attribute MUST be present, in addition to existing
attributes that are currently allowed in a counterSignature (e.g.
counterSignature, messageDigest, signingTime, and signingCertificate).

The counterSignatureScope attribute MUST be a signed attribute; it cannot
be an unsigned attribute, an authenticated attribute, or an unauthenticated
attribute.

The following object identifier identifies the counterSignatureScope
content type:
  
	id-aa-counterSignatureScope OBJECT IDENTIFIER ::= { iso(1)
		member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
		smime(16) id-aa(2) <TBD> }

The definition of CounterSignatureScope is:

CounterSignatureScope ::=  INTEGER {
	content validated		(0),
	-- the countersigning process has validated the content
	content not validated	(1),
	-- the countersigning process has NOT validated the content
}

A counterSignatureScope attribute must have a single attribute value."

Francois Rousseau
AEPOS Technologies

Date: Fri, 16 Oct 1998 16:01:40 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Countersignature Security Consideration
Sender: [email-masked]

Russ,

I followed the thread and I have had difficulties to find some time available to
give my opinion earlier.

> I am trying to write a simple, short paragraph for the "Security
> Considerations" section of CMS dealing with the countersignature issues
> discussed at great length on this list.  I do not want to rekindle that debate,
> but I do want to make sure that the paragraph captures the concerns raised.
>
> Does the enclosed paragraph cover the issues?

I am afraid to say no.  :-(

There has been arguments to say that the co-signer had verified the previous
signature and also its contrary. I believe that the solution should be flexible
enough to handle both cases. Having said that, this means that we should be a
solution that is able to support both cases.

I think that the current document is not "rich" enough to handle the case. When
someone signs a document (e.g. a contract) this is in accordance with the terms of
a policy (i.e. the terms of a contract). In any case the intention of the signer
(or co-signer) must be explicitly mentionned. The intention may be "approval with
verification of the previous signature" or "approval without verification of the
previous signature". Translating this in technical terms, this means that we should
have a non-repudiation policy indicator/pointer and a type of non-repudiation
event. These two attributes should be signed (or "authenticated").

Unless these two "useful" signed attributes are added, I fear that we will not be
able to cover the issues correctly.

Regards,

Denis

> If not, please post a
> replacement paragraph.
>
> Russ
>
> = = = = = = = = =
>
> The countersignature unauthenticated attribute includes a digital signature
> that is computed on the content signature value, thus the countersigning
> process need not know the original signed content.  This structure permits
> implementations efficiency advantages; however, this structure may also permit
> the countersigning of an inappropriate signature value.  Therefore,
> implementations that perform countersignatures should either validate the
> original signature value prior to countersigning it (this validation requires
> processing of the original content), or implementations should perform
> countersigning in a context that ensures that appropriate signature values are
> countersigned.

Date: Thu, 15 Oct 1998 14:27:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Countersignature Security Consideration
Sender: [email-masked]

I am trying to write a simple, short paragraph for the "Security
Considerations" section of CMS dealing with the countersignature issues
discussed at great length on this list.  I do not want to rekindle that debate,
but I do want to make sure that the paragraph captures the concerns raised.

Does the enclosed paragraph cover the issues?  If not, please post a
replacement paragraph.

Russ

= = = = = = = = =

The countersignature unauthenticated attribute includes a digital signature
that is computed on the content signature value, thus the countersigning
process need not know the original signed content.  This structure permits
implementations efficiency advantages; however, this structure may also permit
the countersigning of an inappropriate signature value.  Therefore,
implementations that perform countersignatures should either validate the
original signature value prior to countersigning it (this validation requires
processing of the original content), or implementations should perform
countersigning in a context that ensures that appropriate signature values are
countersigned.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certdist-02.txt
Date: Wed, 14 Oct 1998 10:21:32 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-02.txt
	Pages		: 7
	Date		: 13-Oct-98
	
  Current methods of publishing certificates in directory services are
  restricted to just certificates.  This document provides a method of
  publishing certificates with secondary support information such as the
  SMimeCapabilities attribute (containing bulk algorithm support) in a
  way that is both authenticated and bound to a given certificate.
 
  This draft is being discussed on the 'ietf-smime' mailing list.  To
  join the list, send a message to <[email-masked]> with the
  single word 'subscribe' in the body of the message.  Also, there is a
  Web site for the mailing list at <http://www.imc.org/ietf-smime>.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-certdist-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-certdist-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>, "Paul Hoffman (E-mail)" <[email-masked]>
Subject: ESS draft 8 modifications
Date: Mon, 12 Oct 1998 14:20:28 -0700
Sender: [email-masked]

Since I have now found three different occurences of an ASN structure called
CertID (CMP is the first), please change the CertID in the ESS document to
ESSCertId to make it unique.

Thanks

jim schaad

Date: Fri, 09 Oct 1998 17:28:28 -0400
To: [email-masked]
From: "David M. Balenson" <[email-masked]>
Subject: NDSS '99 Registration Now Taking Place!
Cc: [email-masked]
Sender: [email-masked]

R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 3-5, 1999
Catamaran Resort Hotel
San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Steve Kent, BBN Technologies
                 Gene Tsudik, USC/Information Sciences Institute

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss99
EARLY REGISTRATION DISCOUNT DEADLINE:  January 6, 1999

The 6th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems.  Co-author of
"Privacy on the Line: The Politics of Wiretapping and Encryption."

THIS YEAR'S TOPICS INCLUDE:
- Secure Password-Based Protocol for Downloading a Private Key
- A Real-World Analysis of Kerberos Password Security
- Secure Remote Access to an Internal Web Server
- Security and the User
- Experimenting with Shared Generation of RSA Keys
- Addressing the Problem of Undetected Signature Key Compromise
- Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
- New Approaches to BGP Security
- Distributed Policy Management for Java 1.2
- Distributed Execution with Remote Audit
- Trust-Based Authentication in Open Networks
- A Network Security Research Agenda
- PGRIP: PNNI Global Routing Infrastructure Protection
- A Cryptographic Countermeasure Against Connection Depletion Attacks
- IPSec: Friend or Foe?

EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Windows NT Security
- Cryptography
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)
- JAVA Security

FOR MORE INFORMATION contact the Internet Society:
  Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
  Phone: +1-703-648-9888
  Fax: +1-703-648-9887
  E-mail: [email-masked]
  URL: http://www.isoc.org/ndss99/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Carla Rosenfeld at the Internet Society
at +1-703-648-9888 or send e-mail to [email-masked].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

----------------------------------------------------------------------------
David M. Balenson, Cryptographic Technologies Group
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363

Date: Tue, 06 Oct 1998 16:46:09 -0700
From: [email-masked] (Bob Relyea)
To: [email-masked]
Subject: [Fwd: RC2 Keylength Strawpoll]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------53E8C3C11571F996C6DFCAF2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------53E8C3C11571F996C6DFCAF2
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Tue, 06 Oct 1998 14:50:05 -0700
From: Robert Relyea <[email-masked]>
X-Mailer: Mozilla 4.07 [en]C-NSCP  (WinNT; U)
MIME-Version: 1.0
To: Dr Stephen Henson <[email-masked]>
Subject: Re: RC2 Keylength Strawpoll
References: <Dr Stephen Henson's message of "Sat, 03 Oct 1998 14:35:24 +0100">
			 <[email-masked]>
			 <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dr Stephen Henson wrote:

> Russ Housley wrote:
> >
> > Eric & Steve
> >
> > I would like to keep the key wrap algorithm as simple as possible.  It is
> > getting too complex already.
> >
> > Perhaps the key agreement AlgorithmIdentifier should have two paramters,
> > both AlgorithmIdentifiers.  One alg id tells the key agreement technique
> > and the second tells the key wrap technique.  This should make it more
> > flexible for the future.
> >
>
> What I was personally suggesting would make almost no changes to the
> wrapping spec: more a modification than an additional complication. Two
> ideas sprang to mind:
>
> Currently we have in the spec:
>
> "5. Generate the number of pad octets necessary to make the
>     result a multiple of the key-encryption algorithm block
>     size, then append them to the result."
>
> If this is modified to:
>
> "5. Pad the result using standard block padding (as described in
>     CMS 6.3) to make the result a multiple of the key-encryption
>     algorithm block size, then append them to the result."

> with corresponding decoding the MEK length can be determined
> unambiguously. This would apply to all cases: it is needed for RC2 but
> it could perform an additional integrity check in other cases.

This would be my preference for how this should work. It will make RSA and
Diffie Hellman key exchanges more alike, and considerably simplify code that
has to deal with both.

bob

--------------53E8C3C11571F996C6DFCAF2--

Date: Tue, 06 Oct 1998 22:14:39 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: RC2 Keylength Strawpoll
Sender: [email-masked]

Russ Housley wrote:
> 
> Eric & Steve
> 
> I would like to keep the key wrap algorithm as simple as possible.  It is
> getting too complex already.
> 
> Perhaps the key agreement AlgorithmIdentifier should have two paramters,
> both AlgorithmIdentifiers.  One alg id tells the key agreement technique
> and the second tells the key wrap technique.  This should make it more
> flexible for the future.
> 

What I was personally suggesting would make almost no changes to the
wrapping spec: more a modification than an additional complication. Two
ideas sprang to mind:

Currently we have in the spec:

"5. Generate the number of pad octets necessary to make the
    result a multiple of the key-encryption algorithm block
    size, then append them to the result."

If this is modified to:

"5. Pad the result using standard block padding (as described in
    CMS 6.3) to make the result a multiple of the key-encryption        
    algorithm block size, then append them to the result."

with corresponding decoding the MEK length can be determined
unambiguously. This would apply to all cases: it is needed for RC2 but
it could perform an additional integrity check in other cases.

This might even simplify things because some crypto libraries have
separarate (for example) "XXX" and "XXX with padding" algorithms. Since
the content encryption involves the "XXX with padding" form this would
mean that only "XXX with padding" algorithms would be used throughout.

The other alternative would be to simply have an OPTIONAL MEKlength
INTEGER parameter in CMS which would only be present for variable key
length algorithms whose key length is not specified in the
AlgorithmIdentifier: this probably means just RC2.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Tue, 06 Oct 1998 11:55:14 -0400
To: Dr Stephen Henson <[email-masked]>, EKR <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: RC2 Keylength Strawpoll
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Eric & Steve

I would like to keep the key wrap algorithm as simple as possible.  It is
getting too complex already.

Perhaps the key agreement AlgorithmIdentifier should have two paramters,
both AlgorithmIdentifiers.  One alg id tells the key agreement technique
and the second tells the key wrap technique.  This should make it more
flexible for the future.

Russ

At 03:13 PM 10/4/98 -0700, EKR wrote:
>Dr Stephen Henson <[email-masked]> writes:
>> Eric Rescorla wrote:
>> > 
>> > Russ has requested that I summarize the results of the RC2 keylength
>> > strawpoll and close out this issue. Unfortunately, the strawpoll
>> > reached no clear consensus. (It's pretty much dead even).
>> > 
>> > Consequently, we're going to leave things more or less as-is. RC2
>> > keys MUST be 16 octets, both when used as KEKs (the output of DH
>> > computations) and MEKs. Implementations SHOULD accept other length
>> > MEKs when RSA encrypted, in the interest of backwards compatibility.
>> > 
>> > If you have an objection to this (admittedly flawed) decision
>> > procedure (I.e. I as document editor just decide), speak up now.
>> > This isn't the time for substantive technical argument, however.
>> > 
>> 
>> Fair enough. Just a few comments.
>> 
>> For the record what was the actual result?
>4-4.
>
>> IMHO CMS needs a specific comment re RC2. Currently it doesn't
>> specifically exclude RC2 with keylength > 128 in DH.
>Fair enough. Paul, Can  you add the appropriate ocmment?
>
>> Is this going to apply to the other two possibilities, E-S and S-S DH?
>That's what it's intended to apply to, yes. As you know, DH
>is the case that creates this problem in the first place.
>
>> There was never any mention of why the key wrapping standard or CMS
>> couldn't be changed to allow the MEK length to be determined explicitly
>> and thus enable current RSA implementations to be unchanged in mixed RSA
>> and DH environments.
>Correct. This could be done and it's a separate issue.
>I'd argue against it on consistency grounds, but I'm not
>violently opposed to it. Perhaps Russ would like to weigh in,
>since wrapping is really his document.
>
>-Ekr
>
>-- 
>[Eric Rescorla                                   [email-masked]]

Date: Tue, 06 Oct 1998 13:37:09 -0400
To: Paul Hoffman / IMC <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Reference in CMS to other attributes from ESS
Cc: [email-masked]
Sender: [email-masked]

This paragraph was added to section 11 in CMS.

Russ

At 05:11 PM 10/2/98 -0700, Paul Hoffman / IMC wrote:
>At 04:24 PM 10/2/98 -0400, Francois Rousseau wrote:
>>NEW: "This section defines attributes that may be used with signed-data or
>>authenticated-data.  Some of these attributes were originally defined in
>>PKCS #9 [PKCS #9], others are defined and specified here.  Additional
>>attributes are defined in the Enhanced Security Services for S/MIME [ESS],
>>which also include recommendations on their placement.  The following
>>attributes are not listed in any particular order."
>
>I belive that this would pass muster as a "non-normative" reference,
>meaning that CMS would not be held up by ESS; I like that. However, I think
>we should mention the MSG spec as well, since signingTime and
>smimeCapabilities are also important attributes. Thus, I would change the
>sendtence added to read:
>
>Additional attributes are defined in many places, notably the S/MIME
>Version 3 Message Specification [MSG] and the Enhanced Security Services
>for S/MIME [ESS], which also include recommendations on the placement of
>these attributes.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date: Tue, 06 Oct 1998 11:58:08 -0400
To: "Blake Ramsdell" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: RC2 Keylength Strawpoll
Cc: [email-masked]
Sender: [email-masked]

I agree with Blake.  It would be most helpful if the RC2 key coming out of
RSA and D-H were the same.  In this way, "glue" software can be avoided.

Russ

At 04:01 PM 10/4/98 -0700, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: Dr Stephen Henson [mailto:[email-masked]]
>> Sent: Saturday, October 03, 1998 6:35 AM
>> To: [email-masked]
>> Subject: Re: RC2 Keylength Strawpoll
>> 
>> There was never any mention of why the key wrapping standard or CMS
>> couldn't be changed to allow the MEK length to be determined 
>> explicitly
>> and thus enable current RSA implementations to be unchanged 
>> in mixed RSA
>> and DH environments. As I recall one parameter in CMS or the 
>> alteration
>> of key wrap to use standard block padding would allow this. 
>> Did you see
>> this discussion Russ?
>
>Yes, I would like some clarification on this also -- I was ignorant and
>did not understand that the protected MEK length could not be determined
>after removing the DH protection.  As Dr. H points out, it would
>certainly be nice to be able to recycle some code and to use whatever
>padding method is necessary to be able to accurately know the
>unprotected data length (provided that there are no cryptographic
>weaknesses introduced by doing so).
>
>This will also simplify the backwards compatibility, since there won't
>be any "oh, if you're using RSA you have to be prepared for x and y, but
>if you're using DH you have to be prepared for z after you unprotect the
>MEK for RC2".  To the extent that we can make DH behave like RSA (once
>again, as long as there are no cryptographic, patent, etc. problems), I
>think we should do it.  I suspect that this was discussed at some point
>in X9, but I don't have a card to get into that club...
>
>>From my understanding, the padding would be a sequential operation with
>the DH protection / unprotection, so I don't think this should affect
>other X9 implementations when they come to exist.  Then again, I might
>be wrong.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>

Date: Tue, 06 Oct 1998 11:49:57 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-ess-08.txt
Sender: [email-masked]

All:

I would not like to see CMS delayed waiting for a trusted signing time.
Trusted time stamps are an activity that PKIX is considering adding to
their charter.  If this gets sorted out, then we can apply their mechanism.

Russ

At 09:47 PM 10/3/98 -0700, Jim Schaad (Exchange) wrote:
>Denis,
>
>> 
>> >
>> > 1.  It was felt by all involved that keeping the 
>> description text on what
>> > was being solved and how it was being solved was desirable. 
>>  This would be
>> > counter to the way that attributes are currently described 
>> in the CMS draft.
>> 
>> Having a bigger "security consideration" section in CMS would 
>> solve the problem.
>> The current section is rather small and could certainly be 
>> enhanced. This is the
>> natural place for such a wording.
>
>This idea almost scares me.  If we fold this type of detail into the
>security considerations section of CMS, I can envision that the section is
>going to end up being 20 pages long.  It would need to detail every attack
>that can possibly be envisioned along with a response to the attack.  This
>is the type of thing which makes for a new draft not a  modification to the
>security considerations section.  Security considerations in my opinion
>should give enough information to make users aware of some of the most
>drastic problems that can occur, but not offering full solutions on steps
>they should be taking to solve the problems.
>
>I can support the type of change that was suggested by Francois Rousseau in
>making a reference to the ESS draft (although I think that since it has a
>reference name it may end up being held up in order to get the reference
>correct at a later date).   I don't think that CMS should be considered the
>final answer on all security problems by any group including ourselfs.
>
>> 
>> > 3.  There was discussion about the need to put this into 
>> CMS.  The attribute
>> > really goes with the idea of ESS giving ENHANCED security 
>> rather than this
>> > attribute being required for really having any security.
>> 
>> The Attribute specification addresses two separate items:
>> 
>> 1) the addition of a (single) user (identity) certificate,
>> 2) the inclusion of attribute certificates.
>> 
>> While it is true that attribute certificates are not mandated and give
>enhanced
>> capabilities, the inclusion of the signed (single) user (identity)
>certificate
>> is there precisely to address some security issues discussed at length in
>the
>> document. The addition of a (single) user (identity)certificate is
>REQUIRED
>> security for many (but not all) contexts. The inclusion of attribute
>> certificates in CMS is desirable: this is a "useful attribute".
>
>Yes, it is required from SOME contexts.  This is percisely what I meant when
>I said it is an ENHANCED service.  It is not required by everyone, just
>those that need the enhanced service.  I don't think that anybody can really
>make a statement that given today's technology the same could be said about
>signing time or counter signatures.  These items are included in CMS more
>for the fact that they were defined by PKCS#7 than for any other reason.
>These attributes could just as easily have been moved into the ESS draft
>except for the fact that a primary consideration of CMS was to make sure it
>could to everything that PKCS#7 did.
>
>jim

Reply-To: "Darren Harter" <[email-masked]>
From: "Darren Harter" <[email-masked]>
To: "William Ottaway" <[email-masked]>, "'Dr Stephen Henson'" <[email-masked]>, <[email-masked]>
Subject: Re: Countersignatures and verification of original content.
Date: Mon, 5 Oct 1998 21:14:18 -0000
Sender: [email-masked]

Bill,

I agree.

Darren

-----Original Message-----
From: William Ottaway <[email-masked]>
To: 'Dr Stephen Henson' <[email-masked]>;
[email-masked] <[email-masked]>
Date: Monday, October 05, 1998 05:17
Subject: RE: Countersignatures and verification of original content.

>A far better solution would be to have an authenticated attribute, within
>the SignerInfo, which must be present when that signer has verified the
>contents.
>

Date: Mon, 5 Oct 1998 15:27:12 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Another ESS-08 Comment
Sender: [email-masked]

Paul,

I have the following comment in addition to my previous comments to ESS-08: 

1) Appendix A:  Please add to the ESS ASN.1 module an import of
CertificateSerialNumber from the CertificateExtensions module.

======================================================
John Pawling                         [email-masked]

J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================

From: William Ottaway <[email-masked]>
To: "'Dr Stephen Henson'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Countersignatures and verification of original content.
Date: Mon, 5 Oct 1998 16:51:45 +0100
Sender: [email-masked]

I agree with Steve in that it should not be mandatory that a counter signer 
verifies the original content.

S/MIME needs to allow for a recipient to detect that the counter signer has 
verified the contents not force counter signers to check the contents, 
since in some cases the verification is unnecessary and possably 
impossible.

Tim Dean has proposed a solution to identifying counter signers which have 
verified the content by using the SignatureType attribute defined in 
draft-ietf-smime-domsec-00.txt. I agree that this is a valid solution but I 
don't believe it is the best solution for this problem. For a SignatureType 
attribute to be present the signer has to meet different requirements 
depending on what type to use. For example, if the type is 'domain' then 
the content must be verified. Other types may not have this requirement.

This could lead to types of 'TimestamperContentsVerified' and 
'TimestamperContentsNotVerified'. As more and more types are introduced the 
more messy this gets.

A far better solution would be to have an authenticated attribute, within 
the SignerInfo, which must be present when that signer has verified the 
contents.

Bill.

------------------------------------------------------
William Ottaway,
L323,                             Tel: +44 (0) 1684 894079
DERA Malvern,              Fax: +44 (0) 1684 896113
St. Andrews Road,        email: [email-masked]
Malvern,
Worcs,
WR14 3PS

-----Original Message-----
From:	Dr Stephen Henson [SMTP:[email-masked]]
Sent:	Friday, October 02, 1998 9:18 PM
To:	[email-masked]
Subject:	Countersignatures and verification of original content.

There has been some debate as to whether a countersigner should always
verify the original content of a message. IMHO there are compelling
reasons for not enforcing this which I'll mention below.

I'm not saying that a countersigner cannot verify the original content
just that it should not be forced to do so.

One form of countersigner is a trusted timestamping authority. Its
purpose is solely to demonstrate that a signature existed at a certain
time. As has been mentioned before, such a signature has an essential
puropose for nonrepudiation.

In addition it can be used to demonstrate the validity of a signature
after the certificates have expired: for example if CMS is used for code
signing. The alternative would be for software signatures to become
invalid after their certificate has expired (and they would typically
stop working) this is clearly unacceptable. The trusted timestamp could
cover several hundred Mb of data (for example an MPEG file).

Current systems of timestamping (for example the Verisign authority)
allow a request to be sent in plain text using HTTP. The request
includes just the SignatureValue portion of a SignerInfo structure. The
returned data is usable as a counterSignature attribute to establish the
signing time of the message.

In this case no attempt is made to verify the original content because
this is not necessary: no statement is being made by the timestamper
about the original content.

If the original content must be verified even for a timestamp then this
has several consequences.

1. Volume of data.

Potentially very large amounts of data would need to be passed to a
countersigner. This would make it impracticable to use over dial up
lines for example.

2. Security issues.

Currently only the digital signature is sent in plain text over http. If
the content needs to be verified as well, then potentially sensitive
data would need to be passed over insecure networks. This would
necessitate the use of some secure means of transferring the data such
as S/MIME envelopedData or SSL. Encryption laws in some countries would
mean that only inadequate weak encryption could be used for such
purposes. In some countries encryption would not be permitted at all.

3. Privacy issues.

If the content needs to be verified then the timestamper needs to be
sent a copy of the original content. The potential for abuse is
considerable. I for one would be very reluctant to send copies of all my
signed mail to a timestamping authority.

Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Blake Ramsdell" <[email-masked]>
To: "'Dr Stephen Henson'" <[email-masked]>, <[email-masked]>
Subject: RE: RC2 Keylength Strawpoll
Date: Sun, 4 Oct 1998 16:01:42 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[email-masked]]
> Sent: Saturday, October 03, 1998 6:35 AM
> To: [email-masked]
> Subject: Re: RC2 Keylength Strawpoll
> 
> There was never any mention of why the key wrapping standard or CMS
> couldn't be changed to allow the MEK length to be determined 
> explicitly
> and thus enable current RSA implementations to be unchanged 
> in mixed RSA
> and DH environments. As I recall one parameter in CMS or the 
> alteration
> of key wrap to use standard block padding would allow this. 
> Did you see
> this discussion Russ?

Yes, I would like some clarification on this also -- I was ignorant and
did not understand that the protected MEK length could not be determined
after removing the DH protection.  As Dr. H points out, it would
certainly be nice to be able to recycle some code and to use whatever
padding method is necessary to be able to accurately know the
unprotected data length (provided that there are no cryptographic
weaknesses introduced by doing so).

This will also simplify the backwards compatibility, since there won't
be any "oh, if you're using RSA you have to be prepared for x and y, but
if you're using DH you have to be prepared for z after you unprotect the
MEK for RC2".  To the extent that we can make DH behave like RSA (once
again, as long as there are no cryptographic, patent, etc. problems), I
think we should do it.  I suspect that this was discussed at some point
in X9, but I don't have a card to get into that club...

>From my understanding, the padding would be a sequential operation with
the DH protection / unprotection, so I don't think this should affect
other X9 implementations when they come to exist.  Then again, I might
be wrong.

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

To: Dr Stephen Henson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: RC2 Keylength Strawpoll
From: EKR <[email-masked]>
Date: 04 Oct 1998 15:13:48 -0700
Lines: 43
Sender: [email-masked]

Dr Stephen Henson <[email-masked]> writes:
> Eric Rescorla wrote:
> > 
> > Russ has requested that I summarize the results of the RC2 keylength
> > strawpoll and close out this issue. Unfortunately, the strawpoll
> > reached no clear consensus. (It's pretty much dead even).
> > 
> > Consequently, we're going to leave things more or less as-is. RC2
> > keys MUST be 16 octets, both when used as KEKs (the output of DH
> > computations) and MEKs. Implementations SHOULD accept other length
> > MEKs when RSA encrypted, in the interest of backwards compatibility.
> > 
> > If you have an objection to this (admittedly flawed) decision
> > procedure (I.e. I as document editor just decide), speak up now.
> > This isn't the time for substantive technical argument, however.
> > 
> 
> Fair enough. Just a few comments.
> 
> For the record what was the actual result?
4-4.

> IMHO CMS needs a specific comment re RC2. Currently it doesn't
> specifically exclude RC2 with keylength > 128 in DH.
Fair enough. Paul, Can  you add the appropriate ocmment?

> Is this going to apply to the other two possibilities, E-S and S-S DH?
That's what it's intended to apply to, yes. As you know, DH
is the case that creates this problem in the first place.

> There was never any mention of why the key wrapping standard or CMS
> couldn't be changed to allow the MEK length to be determined explicitly
> and thus enable current RSA implementations to be unchanged in mixed RSA
> and DH environments.
Correct. This could be done and it's a separate issue.
I'd argue against it on consistency grounds, but I'm not
violently opposed to it. Perhaps Russ would like to weigh in,
since wrapping is really his document.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, [email-masked]
Subject: RE: Diffie-Hellman Choices
Date: Sat, 3 Oct 1998 21:49:55 -0700 
Sender: [email-masked]

I strongly vote for the ES version of D-H.  The benefits of not having to
define fixed groups (especially the really small ones needed for dealing
with import/export restrictions of some governments) combined with the
anonymous behavior of ES is just overwhelming.
 
Jim Schaad

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Friday, October 02, 1998 5:28 AM
To: [email-masked]
Subject: Diffie-Hellman Choices

The S/MIME WG needs to select one mandatory to implement variant of
Diffie-Hellman.  This not presents the two alternatives that have been
proposed.  I would like the WG to discuss these alternatives and then select
the one that will be included in CMS.  Both alternatives were presented at
the face-to-face session in Chicago.

The criteria for selecting the most appropriate choice include security,
performance, and patents.

The two alternatives are both variants of X9.42, the ANSI Draft
Diffie-Hellman (D-H) standard.

Static-Static D-H is the first alternative.

Certicom has a pending patent that covers a check to avoid the small
subgroup attack.  Certicom has offered royalty-free lisence for CMS and PKIX
implemntations if this is chosen as the mandatory to implement algorithm.

Static-Static D-H requires one exponentiation per recipient when sending
encrypted messages.

Static-Static D-H provides data origin authuthentication.  This is due to
the originator public key being contained in a certificate.

Static-Static D-H would have a shorter certificate than the Ephemeral-Static
D-H alternative.

The originator certerficate is carried in message.  The public key in the
certificate is used by all recipients.

Static-Static D-H requires a common set of D-H parameters (p,q,g) for the
entire community.

Sample processing: 

 - Certificate contains Ya = ( g ** Xa ) mod p 

 - Originator certificate transferred in the header 

 - Originator generates random, R, that is transferred in plaintext in the
header 

 - Key = SHA1 [ ( g ** XaXb ) mod p || algorithm ID || counter || R ]

Ephemeral-Static D-H is the second alternative.

No patents known patents.  If there are any (including pending patents),
please make us aware of them now.

Ephemeral-Static D-H requires two exponentiations per recipient when sending
encrypted messages.

Ephemeral-Static D-H provides no authentication.  The originator uses an
ephemeral public/private key pair for each recipient, so there is not
originator certificate.

The recipient certificate must contain the D-H paramters (p,q,g), so the
certificate is longer than the Static-Static D-H alternative.  

Neither the originator nor the recipient certificate is carried in the
message.

When generating the ephemeral public/private key pair, the originator uses
the recipient's D-H parmaters (p,q,g) obtained from the recipient
certificate.  Thus, the community does not need to agree on a common set of
D-H paramters (p,q,g).

Sample processing: 

 - No originator certificate; Recipient certificate contains Yb = ( g ** Xb
) mod p 

 - Originator generates D-H key pair for each recipient, using the recipient
p,q,g values 

 - Originator Yr = ( g ** Xr ) mod p transferred in header for each
recipient 

 - Key = SHA1 [ ( g ** XrXb ) mod p || algorithm ID || counter ]

Which alternative do you prefer?  Why?

Russ 

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'Francois Rousseau'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-ess-08.txt
Date: Sat, 3 Oct 1998 21:47:19 -0700 
Sender: [email-masked]

Denis,

> 
> >
> > 1.  It was felt by all involved that keeping the 
> description text on what
> > was being solved and how it was being solved was desirable. 
>  This would be
> > counter to the way that attributes are currently described 
> in the CMS draft.
> 
> Having a bigger "security consideration" section in CMS would 
> solve the problem.
> The current section is rather small and could certainly be 
> enhanced. This is the
> natural place for such a wording.

This idea almost scares me.  If we fold this type of detail into the
security considerations section of CMS, I can envision that the section is
going to end up being 20 pages long.  It would need to detail every attack
that can possibly be envisioned along with a response to the attack.  This
is the type of thing which makes for a new draft not a  modification to the
security considerations section.  Security considerations in my opinion
should give enough information to make users aware of some of the most
drastic problems that can occur, but not offering full solutions on steps
they should be taking to solve the problems.

I can support the type of change that was suggested by Francois Rousseau in
making a reference to the ESS draft (although I think that since it has a
reference name it may end up being held up in order to get the reference
correct at a later date).   I don't think that CMS should be considered the
final answer on all security problems by any group including ourselfs.

> 
> > 3.  There was discussion about the need to put this into 
> CMS.  The attribute
> > really goes with the idea of ESS giving ENHANCED security 
> rather than this
> > attribute being required for really having any security.
> 
> The Attribute specification addresses two separate items:
> 
> 1) the addition of a (single) user (identity) certificate,
> 2) the inclusion of attribute certificates.
> 
> While it is true that attribute certificates are not mandated and give
enhanced
> capabilities, the inclusion of the signed (single) user (identity)
certificate
> is there precisely to address some security issues discussed at length in
the
> document. The addition of a (single) user (identity)certificate is
REQUIRED
> security for many (but not all) contexts. The inclusion of attribute
> certificates in CMS is desirable: this is a "useful attribute".

Yes, it is required from SOME contexts.  This is percisely what I meant when
I said it is an ENHANCED service.  It is not required by everyone, just
those that need the enhanced service.  I don't think that anybody can really
make a statement that given today's technology the same could be said about
signing time or counter signatures.  These items are included in CMS more
for the fact that they were defined by PKCS#7 than for any other reason.
These attributes could just as easily have been moved into the ESS draft
except for the fact that a primary consideration of CMS was to make sure it
could to everything that PKCS#7 did.

jim

Date: Sat, 03 Oct 1998 17:06:58 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Signing time (was Re: 8/26/98 S/MIME WG Minutes)
Sender: [email-masked]

I agree with Denis that some reference should be made about the
consequences of not having a trusted signingTime. The consequences of
this for nonrepudiation are very serious.

Since an attacker (or a malicious original signer) could set an
arbitrary signingTime with a compromised key this (in the absence of
suitable corroboration of a "signed before time" and revocation status
at or after that time) WOULD INVALIDATE THE SIGNATURE OF EVERY MESSAGE
EVER SIGNED BY THE COMPROMISED KEY.

Even real time applications are not totally immune. It all depends on
the granularity of the revocation process. There is still a CA dependent
"window" where an attack could take place. There is also the possibility
that a CA will permit a user to specify that their key was compromised
some time in the past.

In addition some applications need to demonstrate the validity of a
signature after the signing certificate chain has expired. A CA may not
make revocation information available (or even destroy it) a
considerable time after certificate expiry. As a result a CRL or
equivalent must be kept in such cases. To remove any possibility of
attack it must be able to demonstrate that the signer's certificate was
valid ON OR AFTER THE TIME OF THE TRUSTED TIMESTAMP.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Sat, 03 Oct 1998 14:35:24 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: RC2 Keylength Strawpoll
Sender: [email-masked]

Eric Rescorla wrote:
> 
> Russ has requested that I summarize the results of the RC2 keylength
> strawpoll and close out this issue. Unfortunately, the strawpoll
> reached no clear consensus. (It's pretty much dead even).
> 
> Consequently, we're going to leave things more or less as-is. RC2
> keys MUST be 16 octets, both when used as KEKs (the output of DH
> computations) and MEKs. Implementations SHOULD accept other length
> MEKs when RSA encrypted, in the interest of backwards compatibility.
> 
> If you have an objection to this (admittedly flawed) decision
> procedure (I.e. I as document editor just decide), speak up now.
> This isn't the time for substantive technical argument, however.
> 

Fair enough. Just a few comments.

For the record what was the actual result?

IMHO CMS needs a specific comment re RC2. Currently it doesn't
specifically exclude RC2 with keylength > 128 in DH.

Is this going to apply to the other two possibilities, E-S and S-S DH?

There was never any mention of why the key wrapping standard or CMS
couldn't be changed to allow the MEK length to be determined explicitly
and thus enable current RSA implementations to be unchanged in mixed RSA
and DH environments. As I recall one parameter in CMS or the alteration
of key wrap to use standard block padding would allow this. Did you see
this discussion Russ?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Fri, 02 Oct 1998 21:24:34 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Diffie-Hellman Choices
Sender: [email-masked]

At 08:51 PM 10/2/98 -0700, Blake Ramsdell wrote:
>The "unknown" nature of any patents regarding the ES variant is somewhat
>troubling, but will potentially iron itself out during this decision
>process.  Unfortunately, the penalty for not coming forward right now is
>minor (black-balled in the IETF), so just because no one comes forward
>right now doesn't mean that no one ever will.  The known nature of SS
>patents is more encouraging in this regard.

To be clear, we have one data point for SS and zero data points for ES, out
of an unknown number of data points. That is, we don't know diddly, and we
can't, because no one is forced to come forwards (Certicom was nice enough
to). On the other hand, if we choose ES, as the OpenPGP people have, we
have the slight advantage that someone watching should have seen the
OpenPGP people choosing this about nine months before S/MIME did. That
means they would have had to be purposely nasty for longer to withold notice.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Diffie-Hellman Choices
Date: Fri, 2 Oct 1998 20:51:45 -0700
Sender: [email-masked]

I think that we should not use the side effect of authentication in the
SS variant as a feature, and I as a vendor consider it to be annoying
(and potentially impossible) to mandate a keypair on the part of the
originator of an outbound encrypted message.

IMHO, I believe that there should be no evidence of the recipient other
than information identifying the certificate that contained the "keying
material" that was used to encrypt (IssuerAndSerialNumber or equivalent)
and no evidence at all of the sender.  This to me was the original
beauty(?!) of X.509 certificates -- the SubjectPublicKeyInfo contained
all of the information necessary to do an operation for the subject of
the certificate (in this case, symmetric key protection).  Plain and
simple.  Unless, of course I don't understand the religion yet.

The "unknown" nature of any patents regarding the ES variant is somewhat
troubling, but will potentially iron itself out during this decision
process.  Unfortunately, the penalty for not coming forward right now is
minor (black-balled in the IETF), so just because no one comes forward
right now doesn't mean that no one ever will.  The known nature of SS
patents is more encouraging in this regard.

The number of exponentiations and the size of the "keying material" are
not a factor, since I am a piggy desktop application and server
application vendor and I scoff at such limitations of processing power,
storage space and bandwidth.

In short if there are no major discoveries of patents regarding ES (that
make it worse than SS), then I would prefer it over SS.

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

To: [email-masked]
Subject: RC2 Keylength Strawpoll
Date: Fri, 02 Oct 1998 17:02:50 -0700
From: Eric Rescorla <[email-masked]>
Sender: [email-masked]

Russ has requested that I summarize the results of the RC2 keylength
strawpoll and close out this issue. Unfortunately, the strawpoll
reached no clear consensus. (It's pretty much dead even).

Consequently, we're going to leave things more or less as-is. RC2
keys MUST be 16 octets, both when used as KEKs (the output of DH
computations) and MEKs. Implementations SHOULD accept other length
MEKs when RSA encrypted, in the interest of backwards compatibility.

If you have an objection to this (admittedly flawed) decision
procedure (I.e. I as document editor just decide), speak up now.
This isn't the time for substantive technical argument, however.

Thanks,
-Ekr
[Eric Rescorla                                   [email-masked]]

Date: Fri, 02 Oct 1998 17:11:49 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Reference in CMS to other attributes from ESS
Sender: [email-masked]

At 04:24 PM 10/2/98 -0400, Francois Rousseau wrote:
>NEW: "This section defines attributes that may be used with signed-data or
>authenticated-data.  Some of these attributes were originally defined in
>PKCS #9 [PKCS #9], others are defined and specified here.  Additional
>attributes are defined in the Enhanced Security Services for S/MIME [ESS],
>which also include recommendations on their placement.  The following
>attributes are not listed in any particular order."

I belive that this would pass muster as a "non-normative" reference,
meaning that CMS would not be held up by ESS; I like that. However, I think
we should mention the MSG spec as well, since signingTime and
smimeCapabilities are also important attributes. Thus, I would change the
sendtence added to read:

Additional attributes are defined in many places, notably the S/MIME
Version 3 Message Specification [MSG] and the Enhanced Security Services
for S/MIME [ESS], which also include recommendations on the placement of
these attributes.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 02 Oct 1998 16:24:50 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Reference in CMS to other attributes from ESS
Sender: [email-masked]

Since I did not attend the last meeting in Chicago, I just wanted to
suggest that I though it would be more appropriate to add this new ESS
section 5 on "Signing Certificate Attribute" in CMS instead of ESS.
However, I do agree that CMS should not be held up because of this.

Instead, could a forward pointer be added in Section 11 of CMS to these
other useful attributes that are only defined in ESS?

This would result in the following changes to Section 11 of CMS:

OLD: "This section defines attributes that may used with signed-data or
authenticated-data.  Some of these attributes were originally defined in
PKCS #9 [PKCS #9], others are defined and specified here.  The attributes
are not listed in any particular order."

NEW: "This section defines attributes that may be used with signed-data or
authenticated-data.  Some of these attributes were originally defined in
PKCS #9 [PKCS #9], others are defined and specified here.  Additional
attributes are defined in the Enhanced Security Services for S/MIME [ESS],
which also include recommendations on their placement.  The following
attributes are not listed in any particular order."

[ESS] would also have to be defined in the "References" Section of CMS.

Francois Rousseau
AEPOS Technologies

>>> 2.  Since there was some discussions on the draft and changes were still
>>> being made, it was not felt desirable that the CMS draft be put at risk by
>>> this change occuring.
>>
>>During the last meeting in Chicago I raised the issue of some changes needed
>>into it  I recently sent a message on this topic.
>
>Exactly. This is a very good reason not to put these into CMS: we really,
>really don't want to hold it up.

Date: Fri, 02 Oct 1998 21:18:12 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Countersignatures and verification of original content.
Sender: [email-masked]

There has been some debate as to whether a countersigner should always
verify the original content of a message. IMHO there are compelling
reasons for not enforcing this which I'll mention below.

I'm not saying that a countersigner cannot verify the original content
just that it should not be forced to do so.

One form of countersigner is a trusted timestamping authority. Its
purpose is solely to demonstrate that a signature existed at a certain
time. As has been mentioned before, such a signature has an essential
puropose for nonrepudiation.

In addition it can be used to demonstrate the validity of a signature
after the certificates have expired: for example if CMS is used for code
signing. The alternative would be for software signatures to become
invalid after their certificate has expired (and they would typically
stop working) this is clearly unacceptable. The trusted timestamp could
cover several hundred Mb of data (for example an MPEG file).

Current systems of timestamping (for example the Verisign authority)
allow a request to be sent in plain text using HTTP. The request
includes just the SignatureValue portion of a SignerInfo structure. The
returned data is usable as a counterSignature attribute to establish the
signing time of the message.

In this case no attempt is made to verify the original content because
this is not necessary: no statement is being made by the timestamper
about the original content.

If the original content must be verified even for a timestamp then this
has several consequences.

1. Volume of data.

Potentially very large amounts of data would need to be passed to a
countersigner. This would make it impracticable to use over dial up
lines for example.

2. Security issues.

Currently only the digital signature is sent in plain text over http. If
the content needs to be verified as well, then potentially sensitive
data would need to be passed over insecure networks. This would
necessitate the use of some secure means of transferring the data such
as S/MIME envelopedData or SSL. Encryption laws in some countries would
mean that only inadequate weak encryption could be used for such
purposes. In some countries encryption would not be permitted at all.

3. Privacy issues.

If the content needs to be verified then the timestamper needs to be
sent a copy of the original content. The potential for abuse is
considerable. I for one would be very reluctant to send copies of all my
signed mail to a timestamping authority.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Reply-To: <[email-masked]>
From: "Greg Boverman" <[email-masked]>
To: <[email-masked]>
Subject: RE: Diffie-Hellman Choices
Date: Fri, 2 Oct 1998 14:14:22 -0400
Importance: Normal
Sender: [email-masked]

E-S key-establishment would allow anonymous messages to be sent, which might
be a requirement for certain uses. There also would not be a "shared secret"
that is vulnerable to being discovered. I think it is a good thing to keep
the encryption and signing operations separate, exactly as is the case for
RSA.

Greg Boverman

From: William Whyte <[email-masked]>
To: "'John Pawling'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Diffie-Hellman Choices
Date: Fri, 2 Oct 1998 18:28:42 +0100
Organization: Baltimore Technologies
Sender: [email-masked]

Hi all,

> 3) As Russ points out, the S-S D-H algorithm restricts an originator from
> forming a pairwise key with a user whose public key is formed using
> different p/q/g parameters.  The E-S D-H algorithm allows a user to form a
> pairwise key with any user's D-H public key regardless of the p/q/g values.
> I believe that this is a signifignat advantage of E-S D-H over S-S D-H.

To my mind, this is the killer argument.

William

Date: Fri, 2 Oct 1998 13:10:47 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Diffie-Hellman Choices
Sender: [email-masked]

All,

I believe that the group should choose the Ephemeral-Static D-H algorithm as
the "mandatory-to-implement" key management algorithm to be included in CMS
for the following reasons:

1) I believe that if a user requires the security service of data origin
authentication, then the user should digitally sign the data and encapsulate
the signed data within a signedData object.  I don't believe that the data
origin authentication service needs to be provided by the key management
algorithm.  Therefore, I do not object to the fact that the E-S D-H
algorithm does not provide the data origin authentication service.  

2) Many organizations levy a requirement that each X.509 certificate must be
validated before the public key contained within that certificate is used
for cryptographic processing.  In the case of the S-S D-H algorithm, the
originator's D-H public key is conveyed in an X.509 certificate contained in
the envelopedData heading.  Many organizations will require that the
originator's D-H X.509 certificate must be validated before the originator's
D-H public key is used to form the pairwise key required to decrypt the
message encryption key.  This implies that the originator's entire
certification path must be validated.  Therefore, I believe that the E-S D-H
algorithm's use of an ephemeral originator's public key is a significant
advantage because there is not an originator's D-H X.509 certificate to be
validated.  This will save a significant amount of time during the
decryption process.

3) As Russ points out, the S-S D-H algorithm restricts an originator from
forming a pairwise key with a user whose public key is formed using
different p/q/g parameters.  The E-S D-H algorithm allows a user to form a
pairwise key with any user's D-H public key regardless of the p/q/g values.
I believe that this is a signifignat advantage of E-S D-H over S-S D-H.

4) There are no known patents or pending patents that apply to the E-S D-H.
I believe that this is a significant advantage of the E-S D-H option over
the S-S D-H option.

5) At the present time, Certicom states that they will offer a royalty-free
license covering S-S D-H.  What happens if they change their mind and stop
issuing such licsences?  Has Certicom completed the royalty-free license
offer?  How long will it take for Certicom to do so?  In summary, I believe
that we should avoid the "license path" if at all possible.

======================================================
John Pawling                         [email-masked]

J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================

Date: Fri, 02 Oct 1998 10:02:14 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt
Sender: [email-masked]

At 10:25 AM 10/2/98 -0700, Denis Pinkas wrote:
>> 2.  Since there was some discussions on the draft and changes were still
>> being made, it was not felt desirable that the CMS draft be put at risk by
>> this change occuring.
>
>During the last meeting in Chicago I raised the issue of some changes needed
>into it  I recently sent a message on this topic.

Exactly. This is a very good reason not to put these into CMS: we really,
really don't want to hold it up.

>> I do no like the
>> idea that you seem to be suggesting that other groups look only at the CMS
>> draft for their work.  They should be looking at the range of work we are
>> doing.  The concepts in ESS are not restricted to S/MIME by any stretch of
>> the imagnination.
>
>The current title of ESS-08 is "Enhanced Security Services for S/MIME". It is
>not "Enhanced Security Services" and I think the current title is
appropriate.
>So ESS *is* restricted to S/MIME.

I believe you are being way too literal here. "for S/MIME" does *not* mean
"only for S/MIME". The IETF has a long history of protocol X using parts
(or all) of protocol Y, even when they are in very different areas of the
Internet. Anyone is free to use any part of the ESS draft for any purpose.
That's the way we do things in the IETF.

>On the other hand, many people are 
>considering
>using CMS outside the context of S/MIME. They are not going to look at a
>document like ESS (that is S/MIME specific).

Why not? If they want to only look at one document, fine, but that's their
problem, not ours. Good protocol designers will look to a variety of
sources for information.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Fri, 02 Oct 1998 17:19:27 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: Diffie-Hellman Choices
Sender: [email-masked]

My thanks to Russ for presenting the two alternatives.

I would want the Ephemeral-Static D-H to be included. I'll abbreviate
this as ES and the alternative as SS.

Let me outline my reasons.

1. ES does not force authentication. With SS there is an implied
signature which would make such messages traceable: effectively forcing
the originator to sign everything. Personally I don't want to be forced
to sign everything I send. 

There was a requirement to add anon DH to the current CMS for this
reason. Jim Schaad wrote in a message on 28 May:

> At the December working group meeting, this was expressed as a desire from
> the S/MIME side of CMS.  People working for groups like Amnesty
> International wanted to be able to send anonymous mail which could not be
> traced back to them without having decrypted the message.
> 

2. SS requires a fixed set of parameters. What happens if, in future,
some weakness is found in the chosen common parameter set? This could
prove painful to modify.

3. As I understand it SS has some additional security concerns. In
particular the originator's private key needs to be accessed: this can
cause considerable problems for automated systems (e.g. encrypted
mailing lists). Systems which need to be restartable without the
operator entering a password may be forced to either store the private
key unencrypted, rely on fixed "security by obscurity" keys or use some
additional hardware. 

In ES all that is needed is the recipient's public keys. A one time key
pair is generated in each case but it is discarded after use. This does
not require access to any sensitive information and it is much more
secure in automated environments.

In the SS case if an attacker obtains the private key while the process
is taking place then all future messages involving the originator can be
decrypted. In the ES case only the one message can be read.

4. The ES properties are very similar to those of the RSA equivalent for
key transport, which many are more familiar with.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

Date: Fri, 02 Oct 1998 08:28:20 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Diffie-Hellman Choices
Sender: [email-masked]

<html>
The S/MIME WG needs to select one mandatory to implement variant of
Diffie-Hellman.&nbsp; This not presents the two alternatives that have
been proposed.&nbsp; I would like the WG to discuss these alternatives
and then select the one that will be included in CMS.&nbsp; Both
alternatives were presented at the face-to-face session in Chicago.<br>
<br>
The criteria for selecting the most appropriate choice include security,
performance, and patents.<br>
<br>
The two alternatives are both variants of X9.42, the ANSI Draft
Diffie-Hellman (D-H) standard.<br>
<br>
Static-Static D-H is the first alternative.<br>

<dl>
<dd>Certicom has a pending patent that covers a check to avoid the small
subgroup attack.&nbsp; Certicom has offered royalty-free lisence for CMS
and PKIX implemntations if this is chosen as the mandatory to implement
algorithm.<br>
<br>

<dd>Static-Static D-H requires one exponentiation per recipient when
sending encrypted messages.<br>
<br>

<dd>Static-Static D-H provides data origin authuthentication.&nbsp; This
is due to the originator public key being contained in a
certificate.<br>
<br>

<dd>Static-Static D-H would have a shorter certificate than the
Ephemeral-Static D-H alternative.<br>
<br>

<dd>The originator certerficate is carried in message.&nbsp; The public
key in the certificate is used by all recipients.<br>
<br>

<dd>Static-Static D-H requires a common set of D-H parameters (p,q,g) for
the entire community.<br>
<br>

<dd>Sample processing:
<dd>&nbsp;- Certificate contains Ya = ( g ** Xa ) mod p
<dd>&nbsp;- Originator certificate transferred in the header
<dd>&nbsp;- Originator generates random, R, that is transferred in
plaintext in the header
<dd>&nbsp;- Key = SHA1 [ ( g ** XaXb ) mod p || algorithm ID || counter
|| R ]<br>
<br>

</dl>Ephemeral-Static D-H is the second alternative.<br>

<dl>
<dd>No patents known patents.&nbsp; If there are any (including pending
patents), please make us aware of them now.<br>
<br>

<dd>Ephemeral-Static D-H requires two exponentiations per recipient when
sending encrypted messages.<br>
<br>

<dd>Ephemeral-Static D-H provides no authentication.&nbsp; The originator
uses an ephemeral public/private key pair for each recipient, so there is
not originator certificate.<br>
<br>

<dd>The recipient certificate must contain the D-H paramters (p,q,g), so
the certificate is longer than the Static-Static D-H alternative.&nbsp;
<br>
<br>

<dd>Neither the originator nor the recipient certificate is carried in
the message.<br>
<br>

<dd>When generating the ephemeral public/private key pair, the originator
uses the recipient's D-H parmaters (p,q,g) obtained from the recipient
certificate.&nbsp; Thus, the community does not need to agree on a common
set of D-H paramters (p,q,g).<br>
<br>

<dd>Sample processing:
<dd>&nbsp;- No originator certificate; Recipient certificate contains Yb
= ( g ** Xb ) mod p
<dd>&nbsp;- Originator generates D-H key pair for each recipient, using
the recipient p,q,g values
<dd>&nbsp;- Originator Yr = ( g ** Xr ) mod p transferred in header for
each recipient
<dd>&nbsp;- Key = SHA1 [ ( g ** XrXb ) mod p || algorithm ID || counter
]<br>
<br>

</dl>Which alternative do you prefer?&nbsp; Why?<br>
<br>
Russ</html>

Date: Fri, 02 Oct 1998 10:25:34 -0700
From: Denis Pinkas <[email-masked]>
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "'Francois Rousseau'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt
Sender: [email-masked]

Jim,

I am supportive of the comment made by Francois about the inclusion of the new
section 5 in CMS. More explanations follow.

> Although it was originally planned that the signing certificate attribute
> would be folded back into the CMS draft, the decision of the various authors
> involved was that we would put the draft into ESS for a variaty of reasons:
>
> 1.  It was felt by all involved that keeping the description text on what
> was being solved and how it was being solved was desirable.  This would be
> counter to the way that attributes are currently described in the CMS draft.

Having a bigger "security consideration" section in CMS would solve the problem.
The current section is rather small and could certainly be enhanced. This is the
natural place for such a wording.

> 2.  Since there was some discussions on the draft and changes were still
> being made, it was not felt desirable that the CMS draft be put at risk by
> this change occuring.

During the last meeting in Chicago I raised the issue of some changes needed
into it  I recently sent a message on this topic.

> 3.  There was discussion about the need to put this into CMS.  The attribute
> really goes with the idea of ESS giving ENHANCED security rather than this
> attribute being required for really having any security.

The Attribute specification addresses two separate items:

1) the addition of a (single) user (identity) certificate,
2) the inclusion of attribute certificates.

While it is true that attribute certificates are not mandated and give enhanced
capabilities, the inclusion of the signed (single) user (identity) certificate
is there precisely to address some security issues discussed at length in the
document. The addition of a (single) user (identity)certificate is REQUIRED
security for many (but not all) contexts. The inclusion of attribute
certificates in CMS is desirable: this is a "useful attribute".

> I do no like the
> idea that you seem to be suggesting that other groups look only at the CMS
> draft for their work.  They should be looking at the range of work we are
> doing.  The concepts in ESS are not restricted to S/MIME by any stretch of
> the imagnination.

The current title of ESS-08 is "Enhanced Security Services for S/MIME". It is
not "Enhanced Security Services" and I think the current title is appropriate.
So ESS *is* restricted to S/MIME. On the other hand, many people are considering
using CMS outside the context of S/MIME. They are not going to look at a
document like ESS (that is S/MIME specific). CMS is seen as a
replacement/enhancement of PKCS#7 and will be used by many applications. It is
therefore important that people looking ONLY at this specification find all the
information needed including the security consideration issues that currently
come with the section about attributes certificates.

Regards,

Denis

> With regards to the new attribute that you desire, I do not know of any
> draft authors currently taking this under consideration.  If you want to see
> this incorperated into a draft please specify what draft it should be in and
> give suggested text on how the attribute should be structured and treated.
> While there has been general discussion on the scope of counterSignatures I
> don't think the idea of a new attribute has ever really be under
> consideration.
>
> jim schaad
>
> -----Original Message-----
> From: Francois Rousseau [mailto:[email-masked]]
> Sent: Thursday, October 01, 1998 9:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt
>
> Paul,
>
> In this updated version 8 of ESS, I have noticed that the previous work of
> Jim Schaad on the "Signing Certificate Attribute Specification" has been
> integrated as part of a new Section 5 on the "Signing Certificate
> Attribute". The signingCertificate attribute is also listed as one of the
> permitted attribute in a counterSignature attribute in Section 1.3.4 of ESS.
>
> However, since countersignatures will be used more widely than just within
> S/MIME and the signingCertificate attribute could also be used with normal
> signatures, should not this new Section 5 of ESS have been integrated
> within CMS instead?
>
> In addition, is there anything done to create a new attribute that would
> also be allowed in a counterSignature attribute in order to effectively
> define its scope (e.g. content was or was not verified against the message
> digest before generating the countersignature)?
>
> Francois Rousseau
> AEPOS Technologies
> Tel: (819) 772-8522 Ext 314
> Fax: (819) 772-0449
> [email-masked]
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >This draft is a work item of the S/MIME Mail Security Working Group of the
> IETF.
> >
> >       Title           : Enhanced Security Services for S/MIME
> >       Author(s)       : P. Hoffman
> >       Filename        : draft-ietf-smime-ess-08.txt
> >       Pages           : 31
> >       Date            : 30-Sep-98
> >
> >This document describes three optional security service extensions for
> >S/MIME. These services provide functionality that is similar to the Message
> >Security Protocol [MSP4], but are useful in many other environments,
> >particularly business and finance. The services are:
> > - signed receipts
> > - security labels
> > - secure mailing lists
> >
> >The services described here are extensions to S/MIME version 3 [SMIME3],
> >and some of them can also be added to S/MIME version 2 [SMIME2]. The
> >extensions described here will not cause an S/MIME version 3 recipient to
> >be unable to read messages from an S/MIME version 2 sender. However, some
> >of the extensions will cause messages created by an S/MIME version 3 sender
> >to be unreadable by an S/MIME version 2 recipient.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Updated ASN.1 dump program uploaded
Reply-To: [email-masked]
Date: Fri, 2 Oct 1998 18:44:52 (NZST)
Sender: [email-masked]

I've just uploaded the latest update of my ASN.1 dump/diagnostic tool to 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c,cfg}.  The main changes are 
more OIDs in the config file, a kludge workaround for when it can't locate the 
config file if argv[0] is set wrong (you can also tell it manually where the 
file is with the -c option), and more options for picking apart ASN.1 
objects.  Run it with no args for a help screen.
 
Peter.

Date: Fri, 02 Oct 1998 02:08:45 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt
Sender: [email-masked]

Francois Rousseau wrote:
> 
> 
> In addition, is there anything done to create a new attribute that would
> also be allowed in a counterSignature attribute in order to effectively
> define its scope (e.g. content was or was not verified against the message
> digest before generating the countersignature)?
> 

I recall mentioning this as a possible way to make it easier for a
client to know if a countersigner has verified the original content.

There are various other ways of dealing with this which don't need an
additional attribute. One is to treat it in an analagous manner to other
signatures and judge the validity of the certificate based on the
signing authority: or more specifically its policy.

In the case of some timestamping servers the certificates have specific
V3 extensions: extendedKeyUsage. I can't comment on how universal this
is.

In a human readable environment the actual name of the countersigning
authority could help avoid confusion: for example a message saying
"countersigned by 'foobar timestamping authority' on HH:MM".

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Francois Rousseau'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-ess-08.txt
Date: Thu, 1 Oct 1998 16:56:35 -0700 
Sender: [email-masked]

Although it was originally planned that the signing certificate attribute
would be folded back into the CMS draft, the decision of the various authors
involved was that we would put the draft into ESS for a variaty of reasons:

1.  It was felt by all involved that keeping the description text on what
was being solved and how it was being solved was desirable.  This would be
counter to the way that attributes are currently described in the CMS draft.

2.  Since there was some discussions on the draft and changes were still
being made, it was not felt desirable that the CMS draft be put at risk by
this change occuring.

3.  There was discussion about the need to put this into CMS.  The attribute
really goes with the idea of ESS giving ENHANCED security rather than this
attribute being required for really having any security.  I do no like the
idea that you seem to be suggesting that other groups look only at the CMS
draft for their work.  They should be looking at the range of work we are
doing.  The concepts in ESS are not restricted to S/MIME by any stretch of
the imagnination.

With regards to the new attribute that you desire, I do not know of any
draft authors currently taking this under consideration.  If you want to see
this incorperated into a draft please specify what draft it should be in and
give suggested text on how the attribute should be structured and treated.
While there has been general discussion on the scope of counterSignatures I
don't think the idea of a new attribute has ever really be under
consideration.

jim schaad

-----Original Message-----
From: Francois Rousseau [mailto:[email-masked]]
Sent: Thursday, October 01, 1998 9:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt

Paul,

In this updated version 8 of ESS, I have noticed that the previous work of
Jim Schaad on the "Signing Certificate Attribute Specification" has been
integrated as part of a new Section 5 on the "Signing Certificate
Attribute". The signingCertificate attribute is also listed as one of the
permitted attribute in a counterSignature attribute in Section 1.3.4 of ESS.

However, since countersignatures will be used more widely than just within
S/MIME and the signingCertificate attribute could also be used with normal
signatures, should not this new Section 5 of ESS have been integrated
within CMS instead?

In addition, is there anything done to create a new attribute that would
also be allowed in a counterSignature attribute in order to effectively
define its scope (e.g. content was or was not verified against the message
digest before generating the countersignature)?

Francois Rousseau
AEPOS Technologies
Tel: (819) 772-8522 Ext 314
Fax: (819) 772-0449
[email-masked]

>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the
IETF.
>
>	Title		: Enhanced Security Services for S/MIME
>	Author(s)	: P. Hoffman
>	Filename	: draft-ietf-smime-ess-08.txt
>	Pages		: 31
>	Date		: 30-Sep-98
>	
>This document describes three optional security service extensions for
>S/MIME. These services provide functionality that is similar to the Message
>Security Protocol [MSP4], but are useful in many other environments,
>particularly business and finance. The services are:
> - signed receipts
> - security labels
> - secure mailing lists
> 
>The services described here are extensions to S/MIME version 3 [SMIME3],
>and some of them can also be added to S/MIME version 2 [SMIME2]. The
>extensions described here will not cause an S/MIME version 3 recipient to
>be unable to read messages from an S/MIME version 2 sender. However, some
>of the extensions will cause messages created by an S/MIME version 3 sender
>to be unreadable by an S/MIME version 2 recipient.

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: ESS-08 Comments
Date: Thu, 1 Oct 1998 16:43:09 -0700 
Sender: [email-masked]

I have no problem with any of these changes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 01, 1998 3:26 PM
To: [email-masked]
Subject: ESS-08 Comments

All,

Once again I believe that Paul has done a brilliant job of incorporating the
comments into ESS that have received the concurrence of the WG.  I have a
few minor comment regarding ESS-08:

1) Sec 5, 4th para: Please replace "policies" with "certificate policies" to
distinguish between security policies (discussed in ESS Section 3) and
certificate policies (discussed in Sec 5).  This results in the following
changes:

OLD: "Explicit policies can also be used as part of a signature verification
process. If a signer desires to state an explicit policy that should be used
validating the signature, that policy needs to be cryptographically bound
into the signing process. The methods described in this section allows for a
set of policy statements to be listed as part of the signing certificate
attribute."

NEW: "Explicit certificate policies can also be used as part of a signature
verification process. If a signer desires to state an explicit certificate
policy that should be used when validating the signature, that policy needs
to be cryptographically bound into the signing process. The methods
described in this section allows for a set of certificate policy statements
to be listed as part of the signing certificate attribute."

2) Sec 5.1.1, 1rst para, last sent:  Please change as follows: 

OLD: "This new certificate is used the signature verification process."

NEW: "This new certificate is used during the signature verification
process."

3) Sec 5.2.2, 2nd para: Please change as follows because there is already a
sequence of CertIDs in the attribute:

OLD: "Preventing the attack based on reissuing of CA certificates would
require a substantial change the attribute presented in section 5.4. It
would require that a sequence of certificate identifiers be included in the
attribute."

NEW: "Preventing the attack based on reissuing of CA certificates would
require a substantial change to the usage of the signingCertificate
attribute presented in section 5.4.  It would require that CertIDs would
need to be included in the attribute to represent the issuer certificates in
the signer's certification path."

4) Sec 5.4, Please change as follows:

OLD: "The following object identifier identifies the encrypted-data content
type:"

NEW: "The following object identifier identifies the signingCertificate
attribute:"

5) Sec 5.4, 3rd para, 2nd sent:  Please change as follows:

OLD: "The encoding of the CertID for this certificate SHOULD NOT include the
issuerAndSerialNumber because the issuerAndSerialNumber is already present
in the SignerInfo."

NEW: "The encoding of the CertID for this certificate SHOULD NOT include the
issuerSerial because the issuerAndSerialNumber is already present in the
SignerInfo."

6) Sec 5.4, 3rd para, last sent:  Please change as follows:

OLD:  "If the hash of the certificate does not match the certificate used to
decode the signature, the signature MUST be considered invalid."

NEW: "If the hash of the certificate does not match the certificate used to
verify the signature, the signature MUST be considered invalid."

7) Sec 5.4, 4th para, 2nd  sent:  Please change as follows:

OLD: "The issuerAndSerialNumber SHOULD be present in these certificates,
unless the client who is validating the signature is expected to have easy
access to all the certificates required for validation."

NEW: "The issuerSerial SHOULD be present in these certificates, unless the
client who is validating the signature is expected to have easy access to
all the certificates required for validation."

8) Sec 5.4,.1, 1rst para, last sent:  Please change as follows:

OLD: "A hash of the entire certificate serves the same function (allowing
the receiver to very the same certificate is being used), is smaller and
permits a detection of the simple substitution attacks."

NEW: "A hash of the entire certificate serves the same function (allowing
the receiver to verify that the same certificate is being used as when the
message was signed), is smaller and permits a detection of the simple
substitution attacks."

9) Appendix A: Please add the CertID and SigningCertificate attribute
syntaxes to the ASN.1 module.

10) Appendix A:  Please add an import of PolicyInformation from the PKIX
Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 1988 Syntax,
PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

======================================================
John Pawling                         [email-masked]

J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================

Date: Thu, 1 Oct 1998 18:25:30 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: ESS-08 Comments
Sender: [email-masked]

All,

Once again I believe that Paul has done a brilliant job of incorporating the
comments into ESS that have received the concurrence of the WG.  I have a
few minor comment regarding ESS-08:

1) Sec 5, 4th para: Please replace "policies" with "certificate policies" to
distinguish between security policies (discussed in ESS Section 3) and
certificate policies (discussed in Sec 5).  This results in the following
changes:

OLD: "Explicit policies can also be used as part of a signature verification
process. If a signer desires to state an explicit policy that should be used
validating the signature, that policy needs to be cryptographically bound
into the signing process. The methods described in this section allows for a
set of policy statements to be listed as part of the signing certificate
attribute."

NEW: "Explicit certificate policies can also be used as part of a signature
verification process. If a signer desires to state an explicit certificate
policy that should be used when validating the signature, that policy needs
to be cryptographically bound into the signing process. The methods
described in this section allows for a set of certificate policy statements
to be listed as part of the signing certificate attribute."

2) Sec 5.1.1, 1rst para, last sent:  Please change as follows: 

OLD: "This new certificate is used the signature verification process."

NEW: "This new certificate is used during the signature verification process."

3) Sec 5.2.2, 2nd para: Please change as follows because there is already a
sequence of CertIDs in the attribute:

OLD: "Preventing the attack based on reissuing of CA certificates would
require a substantial change the attribute presented in section 5.4. It
would require that a sequence of certificate identifiers be included in the
attribute."

NEW: "Preventing the attack based on reissuing of CA certificates would
require a substantial change to the usage of the signingCertificate
attribute presented in section 5.4.  It would require that CertIDs would
need to be included in the attribute to represent the issuer certificates in
the signer's certification path."

4) Sec 5.4, Please change as follows:

OLD: "The following object identifier identifies the encrypted-data content
type:"

NEW: "The following object identifier identifies the signingCertificate
attribute:"

5) Sec 5.4, 3rd para, 2nd sent:  Please change as follows:

OLD: "The encoding of the CertID for this certificate SHOULD NOT include the
issuerAndSerialNumber because the issuerAndSerialNumber is already present
in the SignerInfo."

NEW: "The encoding of the CertID for this certificate SHOULD NOT include the
issuerSerial because the issuerAndSerialNumber is already present in the
SignerInfo."

6) Sec 5.4, 3rd para, last sent:  Please change as follows:

OLD:  "If the hash of the certificate does not match the certificate used to
decode the signature, the signature MUST be considered invalid."

NEW: "If the hash of the certificate does not match the certificate used to
verify the signature, the signature MUST be considered invalid."

7) Sec 5.4, 4th para, 2nd  sent:  Please change as follows:

OLD: "The issuerAndSerialNumber SHOULD be present in these certificates,
unless the client who is validating the signature is expected to have easy
access to all the certificates required for validation."

NEW: "The issuerSerial SHOULD be present in these certificates, unless the
client who is validating the signature is expected to have easy access to
all the certificates required for validation."

8) Sec 5.4,.1, 1rst para, last sent:  Please change as follows:

OLD: "A hash of the entire certificate serves the same function (allowing
the receiver to very the same certificate is being used), is smaller and
permits a detection of the simple substitution attacks."

NEW: "A hash of the entire certificate serves the same function (allowing
the receiver to verify that the same certificate is being used as when the
message was signed), is smaller and permits a detection of the simple
substitution attacks."

9) Appendix A: Please add the CertID and SigningCertificate attribute
syntaxes to the ASN.1 module.

10) Appendix A:  Please add an import of PolicyInformation from the PKIX
Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 1988 Syntax,
PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

======================================================
John Pawling                         [email-masked]

J.G. Van Dyke & Associates, Inc.     www.jgvandyke.com       
======================================================

Date: Thu, 01 Oct 1998 12:03:45 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-ess-08.txt
Cc: [email-masked]
Sender: [email-masked]

Paul,

In this updated version 8 of ESS, I have noticed that the previous work of
Jim Schaad on the "Signing Certificate Attribute Specification" has been
integrated as part of a new Section 5 on the "Signing Certificate
Attribute". The signingCertificate attribute is also listed as one of the
permitted attribute in a counterSignature attribute in Section 1.3.4 of ESS.

However, since countersignatures will be used more widely than just within
S/MIME and the signingCertificate attribute could also be used with normal
signatures, should not this new Section 5 of ESS have been integrated
within CMS instead?

In addition, is there anything done to create a new attribute that would
also be allowed in a counterSignature attribute in order to effectively
define its scope (e.g. content was or was not verified against the message
digest before generating the countersignature)?

Francois Rousseau
AEPOS Technologies
Tel: (819) 772-8522 Ext 314
Fax: (819) 772-0449
[email-masked]

>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the
IETF.
>
>	Title		: Enhanced Security Services for S/MIME
>	Author(s)	: P. Hoffman
>	Filename	: draft-ietf-smime-ess-08.txt
>	Pages		: 31
>	Date		: 30-Sep-98
>	
>This document describes three optional security service extensions for
>S/MIME. These services provide functionality that is similar to the Message
>Security Protocol [MSP4], but are useful in many other environments,
>particularly business and finance. The services are:
> - signed receipts
> - security labels
> - secure mailing lists
> 
>The services described here are extensions to S/MIME version 3 [SMIME3],
>and some of them can also be added to S/MIME version 2 [SMIME2]. The
>extensions described here will not cause an S/MIME version 3 recipient to
>be unable to read messages from an S/MIME version 2 sender. However, some
>of the extensions will cause messages created by an S/MIME version 3 sender
>to be unreadable by an S/MIME version 2 recipient.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-08.txt
Date: Thu, 01 Oct 1998 10:22:43 -0400
Sender: [email-masked]

--NextPart

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

	Title		: Enhanced Security Services for S/MIME
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-smime-ess-08.txt
	Pages		: 31
	Date		: 30-Sep-98
	
This document describes three optional security service extensions for
S/MIME. These services provide functionality that is similar to the Message
Security Protocol [MSP4], but are useful in many other environments,
particularly business and finance. The services are:
 - signed receipts
 - security labels
 - secure mailing lists
 
The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient.
 
The format of the messages are described in ASN.1:1988 [ASN1-1988].
 
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     [email-masked]
with the single word
     subscribe
in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--