Subject: Re: Countersignature within CMS
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked]
Date: Tue, 30 Jun 1998 08:35:23 -0700

At 09:41 AM 6/30/98 +0100, William Ottaway wrote:
>I could propose a paragraph but I would like to hold off for a while. We
>will be releasing an internet draft on domain security services using
>S/MIME within the next couple of weeks and I want to take on board the
>comments it will raise before addressing the Countersignature issue.

Well, I would rather not delay the S/MIME work, so I'll propose one. Anyone
should feel free to comment on this.

A countersignature can be created without the countersigner knowing the
original content. The recipient who is validating the countersignature has
no way of knowing if the signature that was countersigned is valid without
checking that signature as well. Thus, a recipient who can validate a
countersignature but cannot validate the original signature must not infer
that the content that was signed has not been modified, and must not infer
that the original signer actually had access to the content.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 30 Jun 1998 09:41:17 +0100
To: Russ Housley <[email-masked]>
From: William Ottaway <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

Russ

I could propose a paragraph but I would like to hold off for a while. We
will be releasing an internet draft on domain security services using
S/MIME within the next couple of weeks and I want to take on board the
comments it will raise before addressing the Countersignature issue.

Bill.

At 15:18 26/06/98 -0400, Russ Housley wrote:
>Bill:
>
>You are correct.  Can you propose a paragraph for he Security
>Considerations to address your concerns?
>
>Russ
>
>
>At 08:51 AM 6/24/98 +0100, William Ottaway wrote:
>>Russ
>>
>>If a signer verifies the signature it is countersigning then everything is
>>fine and dandy. However, when I receive a countersignature I have no way of
>>knowing if the signature being signed has been checked first. Infact I
>>would expect that the entity applying the countersignature is more likely
>>not to check the signature over the original content because it doesn't
>>need to and may not be able to.
>>
>>Excerpt from last paragraph of section 11.4 in draft-ietf-smime-cms-05.txt
>>
>>"The fact that a countersignature is computed on a signature value means
>>that the countersigning process need not know the original content input to
>>the signing process."
>>
>>If the original content is not available then the signature being
>>countersigned can not be validated.
>>
>>Bill.
>>
>>At 22:56 23/06/98 -0400, you wrote:
>>>Bill:
>>>
>>>I should think that a signer would not apply a countersignature without
>>>verifying the signature that it covers.  One important place that
>>>countersignature might be used is a workflow application where concurrance
>>>is needed.
>>>
>>>Russ
>>>
>>>At 02:36 PM 6/22/98 +0100, William Ottaway wrote:
>>>>Hi all,
>>>>
>>>>I would like to know whether anyone uses or intends to use the
>>>>Countersignature attribute type defined in section 11.4 in
>>>>draft-ietf-smime-cms-04.txt.
>>>>
>>>>I myself do not see a use for it as I can't trust it. It is not
>>>>authenticated and it provides one or more signatures on a signature value
>>>>which may not be valid.
>>>>
>>>>Bill.
>>>>_____________________________________________________________________
>>>>William Ottaway,             Tel: +44 (0)1684 894079
>>>>DERA Malvern,                Fax: +44 (0)1684 896113
>>>>St. Andrews Road,            email: [email-masked]
>>>>Malvern,
>>>>Worcs, WR14 3PS
>>>>UK
>>>> 
>>>
>>"The Information contained in this E-Mail and any subsequent
>>correspondence is private and is intended solely for the intended
>>recipient(s).  For those other than the intended recipient any
>>disclosure, copying, distribution, or any action taken or omitted to
>>be taken in reliance on such information is prohibited and may be
>>unlawful."
>>____________________________________________________________
>>William Ottaway,             Tel: (01684) 894079
>>DERA Malvern,                Fax: (01684) 896113
>>St. Andrews Road,            email: [email-masked]
>>Malvern,
>>Worcs,
>>
>>WR14 3PS
>>
>>All opinions are my own.
>> 
>

Date: Fri, 26 Jun 1998 15:18:49 -0400
To: William Ottaway <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

Bill:

You are correct.  Can you propose a paragraph for he Security
Considerations to address your concerns?

Russ

At 08:51 AM 6/24/98 +0100, William Ottaway wrote:
>Russ
>
>If a signer verifies the signature it is countersigning then everything is
>fine and dandy. However, when I receive a countersignature I have no way of
>knowing if the signature being signed has been checked first. Infact I
>would expect that the entity applying the countersignature is more likely
>not to check the signature over the original content because it doesn't
>need to and may not be able to.
>
>Excerpt from last paragraph of section 11.4 in draft-ietf-smime-cms-05.txt
>
>"The fact that a countersignature is computed on a signature value means
>that the countersigning process need not know the original content input to
>the signing process."
>
>If the original content is not available then the signature being
>countersigned can not be validated.
>
>Bill.
>
>At 22:56 23/06/98 -0400, you wrote:
>>Bill:
>>
>>I should think that a signer would not apply a countersignature without
>>verifying the signature that it covers.  One important place that
>>countersignature might be used is a workflow application where concurrance
>>is needed.
>>
>>Russ
>>
>>At 02:36 PM 6/22/98 +0100, William Ottaway wrote:
>>>Hi all,
>>>
>>>I would like to know whether anyone uses or intends to use the
>>>Countersignature attribute type defined in section 11.4 in
>>>draft-ietf-smime-cms-04.txt.
>>>
>>>I myself do not see a use for it as I can't trust it. It is not
>>>authenticated and it provides one or more signatures on a signature value
>>>which may not be valid.
>>>
>>>Bill.
>>>_____________________________________________________________________
>>>William Ottaway,             Tel: +44 (0)1684 894079
>>>DERA Malvern,                Fax: +44 (0)1684 896113
>>>St. Andrews Road,            email: [email-masked]
>>>Malvern,
>>>Worcs, WR14 3PS
>>>UK
>>> 
>>
>"The Information contained in this E-Mail and any subsequent
>correspondence is private and is intended solely for the intended
>recipient(s).  For those other than the intended recipient any
>disclosure, copying, distribution, or any action taken or omitted to
>be taken in reliance on such information is prohibited and may be
>unlawful."
>____________________________________________________________
>William Ottaway,             Tel: (01684) 894079
>DERA Malvern,                Fax: (01684) 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs,
>
>WR14 3PS
>
>All opinions are my own.
> 

Date: Fri, 26 Jun 1998 14:28:07 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: CMS: key wrapping standard.
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

Steve:

The structure of the PKCS#1 key block used to encrypt a content-encryption
key in a recipient public key offers some integrity protection.  Other
techniques have been defined that offer even more integrity.

The recipient of such a block has some assurance that the unwrapped key is
the one used by the originator.  Thus, it is unlikely that the recipient
will spend time decrypting the message content if an attacker altered the
wrapped content-encryption key.

I am trying to specify a mechanism that offers similar capailities with
Diffie-Hellman key management.

There are many, many denial of service attacks possible.  This mechanis is
not intended to address all of them.

Russ

At 12:31 PM 6/19/98 +0100, Dr Stephen Henson wrote:
>Russ Housley wrote:
>> 
>> Steve:
>> 
>> This technique does not offer any integrity.  I have a strong desire for a
>> mechnaism that allows a message recipient to detect problems with the key
>> before processing the entire message content is possibel.
>> 
>
>Indeed it does not provide any integrity but then again even a
>sophisticated scheme is not resistant to even simple attacks. The
>anonymous nature of most of the enveloped data forms (barring non anon
>DH which has a signing element anyway). I'll describe a few possible
>attacks with each mode to illustrate the point.
>
>Some of these could also occur due to message corruption.
>
>These first few work in all modes and attack all recipients at once.
>
>1. The simplest attack is just to substitute bogus content. This is
>possible because RecipientInfo structures can be built using just public
>information (public keys of recipients or a random anon-DH keypair).
>Since this is a perfectly valid message it decrypts fine.
>
>2. Just scramble the encrypted content. Since only the last block has
>any kind of integrity check if you leave it and the previous one alone
>(due to CBC mode) you can kill the whole content and it will still
>decrypt fine. This works in static DH modes.
>
>The next few can be aimed at several recipients or just one. In the case
>of single recipient attacks the other recipient can read the message
>fine.
>
>3. Delete the RecipientInfo structure(s). A bit primitive and easily
>detectable.
>
>4. Substitute the RecipientInfo structure or part of it from another
>message. This shouldn't be detected until the whole message is read.
>Even then it may not be detected. Again this can hit static DH.
>
>The next few rely on finding a specific "content decryption key". Since
>only the last couple of blocks of a message have any kind of integrity
>check it is possible to find a bogus content encryption key which will
>decrypt the message just fine but yield only garbage. This can be done
>by just trying random keys. On average this will work after around 128
>attempts.
>
>5. Substitute the RecipientInfo structure(s) with one for the bogus key.
>Key transport makes this very easy. Key agreement is similar, except you
>have to follow the integrity check rules (if any).
>
>6. In key agreement swap the first two blocks of the EncryptedKey. This
>I believe is the attack that an integrity check will prevent. You can't
>touch the last two blocks because that could break the padding: since in
>3DES this padding will be 8 8s this makes it unlikely that touching the
>last two blocks will work.
>
>7. (May not be possible: depends on final structure) fiddle with the IV
>for the EncryptedKey.
>
>... Lots more I can't think of at present.
>
>Given that only one of these is stopped by an integrity check and
>several of the others are undetectable (and number 4 is particularly
>easy and nasty) IMHO an integrity check does not offer much if any
>useful protection. What do other people think?
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.

>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
> 

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Syntax on RecipientInfo
Date: Fri, 26 Jun 1998 17:53:44 -0700
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 26, 1998 10:10 AM
> To: [email-masked]
> Subject: Re: Syntax on RecipientInfo
> 
> I agree with your recommendation.

Me too.

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

Date: Fri, 26 Jun 1998 19:45:23 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Sender: [email-masked]

Russ,

Thanks for your reply.

(...)

> >The major issue I see is to mandate the use of ISO Distinguished Name.
> >This is currently mandated for the issuer names. For leaf names the
> >situation is is little more complex as it will be explained later.
> 
> PKCS#7 version 1.5 and CMS refer to certificates by isser DName and serial
> number.  Thus, S/MIME certificates must have an issuer DName.  

CMS is still under discussion I guess. Is PKCS#7 version 1.5 a reference
for S/MIME 3 ?

> compatibility discussion with PKCS#7 v1.5 has been repeated many, many
> times, so I will not repeat it again.

I understood that we had some freedom for S/MIME 3 (but not for S/MIME
2). Did I misunderstood ? I still do not see why *only* DNames should be
supported.
 
> >2.3 CertificateSet
> >
> >(...)
> >
> >"Receiving agents MUST support chaining based on the distinguished name
> >fields. Other methods of building certificate chains may be supported
> >but are not currently recommended."
> 
> Since the DNames are needed for PKCS#7 v1.5 and CMS, this seems like a
> reasonable next step.  Note that end entities do not have to have DNames.
> They can use the more widely accepted RFC822 AltNames, or other names
> formats.  The issuer name in the end entity certificate must be a DName,
> this will match the subject DName in the CA certificate.  Chaining does not
> invlove the end entity name.

In that case I do not see how security can be checked. Let us take a
simple example. My company is using E-mail addresses ending with
"bull.net". Your company is using E-mail addresses ending with
"spyrus.com". I would like to exchange E-mails with you. All the
certificates from my company are coming from a CA named [email-masked]. All
the certificates from your company are issued by a CA named
[email-masked]. I may trust your CA to issue certificates for Spyrus
users, but for Spyrus users only. In the same way I would guess that you
are ready to trust certificates issued by the Bull CA for Bull users,
but for Bull users only. A simple way to make chaining is to make sure
that the Bull CA only issue certificates ending with the same
hierarchical structure as its own name. The same would be valid for
Spyrus. Note that in that simple example I am using two trust points (or
root CAs).

Now could you explain how you can apply the previous trust model when
chaining does not involve the end entity name ?

My own understanding is that nothing would prevent a Bull CA to certify
a user from Spyrus (and the reverse) and that would not be automatically
discovered through the chaining mechanism. CAs cannot be trusted for
everything.

> >"Attribute certificates -- keep 'em or pitch 'em?"
> >
> >The ISO document is not yet stable. I would prefer that we do not
> >include them for the time being but that we indicate that the support of
> >roles is to be considered.
> 
> I can support removing them from the CERT document, but I do not think that
> we should eliminate them from the CMS document.  

I will consider this when reviewing CMS.

> Support for attribute certificates should be completely optional.

Yes.

> Russ

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 26 Jun 1998 13:09:55 -0400
To: "[email-masked]" <[email-masked]>
From: [email-masked] (John Pawling)
Subject: Re: Syntax on RecipientInfo
Sender: [email-masked]

Steve,

I agree with your recommendation.

Thanx,
- John Pawling

At 05:17 PM 6/26/98 +0100, [email-masked] wrote:
>John Pawling wrote:
>> 
>> All,
>> 
>> Michelle is correct.  Recommend changing RecipientInfo to:
>> 
>> RecipientInfo ::= CHOICE {
>>   ktri [0] KeyTransRecipientInfo,
>>   kari [1] KeyAgreeRecipientInfo,
>>   mlri [2] MailListRecipientInfo  }
>> 
>
>You can tell which one from the Version INTEGER. However this was
>mentioned before. The suggestion then was:
>
>RecipientInfo ::= CHOICE {
>  ktri KeyTransRecipientInfo,
>  kari [1] KeyAgreeRecipientInfo,
>  mlri [2] MailListRecipientInfo  }
>
>
>I didn't mention it at the time but for the sake of minimalism I'd
>suggest:
>
>RecipientInfo ::= CHOICE {
>  ktri KeyTransRecipientInfo,
>  kari [0] KeyAgreeRecipientInfo,
>  mlri [1] MailListRecipientInfo  }
>
>The absence of tag on the KeyTransRecipientInfo is essential for
>backwards compatability.
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
>
>

Date: Fri, 26 Jun 1998 17:17:06 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: John Pawling <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Syntax on RecipientInfo
Sender: [email-masked]

John Pawling wrote:
> 
> All,
> 
> Michelle is correct.  Recommend changing RecipientInfo to:
> 
> RecipientInfo ::= CHOICE {
>   ktri [0] KeyTransRecipientInfo,
>   kari [1] KeyAgreeRecipientInfo,
>   mlri [2] MailListRecipientInfo  }
> 

You can tell which one from the Version INTEGER. However this was
mentioned before. The suggestion then was:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  mlri [2] MailListRecipientInfo  }

I didn't mention it at the time but for the sake of minimalism I'd
suggest:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [0] KeyAgreeRecipientInfo,
  mlri [1] MailListRecipientInfo  }

The absence of tag on the KeyTransRecipientInfo is essential for
backwards compatability.

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

Date: Fri, 26 Jun 1998 09:33:54 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Syntax on RecipientInfo
Sender: [email-masked]

All,

Michelle is correct.  Recommend changing RecipientInfo to:

RecipientInfo ::= CHOICE {
  ktri [0] KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  mlri [2] MailListRecipientInfo  }

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

At 10:48 AM 6/25/98 -0400, Michelle Casagni wrote:
>
>I believe the following ASN definition is in error:
>
>RecipientInfo ::= CHOICE {
>  ktri KeyTransRecipientInfo,
>  kari KeyAgreeRecipientInfo,
>  mlri MailListRecipientInfo
>}
>
>Each choice is a Sequence so shouldn't they be numbered so that it is known
>which one is actually chosen?
>
>Michelle Casagni
>GTE Internetworking
>

Date: Thu, 25 Jun 1998 10:48:45 -0400
To: [email-masked]
From: Michelle Casagni <[email-masked]>
Subject: Syntax on RecipientInfo
Sender: [email-masked]

I believe the following ASN definition is in error:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari KeyAgreeRecipientInfo,
  mlri MailListRecipientInfo
}

Each choice is a Sequence so shouldn't they be numbered so that it is known
which one is actually chosen?

Michelle Casagni
GTE Internetworking

Date: Thu, 25 Jun 1998 09:35:11 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

At 18:58 24/06/98 +0100, you wrote:
>William Ottaway wrote:
>> 
>> 
>> If a signer verifies the signature it is countersigning then everything is
>> fine and dandy. However, when I receive a countersignature I have no way of
>> knowing if the signature being signed has been checked first. Infact I
>> would expect that the entity applying the countersignature is more likely
>> not to check the signature over the original content because it doesn't
>> need to and may not be able to.
>> 
>
>This is correct but there are cases where this is unncecessary: an
>example is a time stamping authority. All a time stamping authority is
>saying is that "at this time I produced this signature".

Fair enough.

>
>There are several circumstances where this is important for example
>archived messages signed with revoked certificates or copyright
>disputes. I'll expand on this if it isn't clear.
>
>A receiving agent would presumably regard the countersignature as
>valueless is the original signature is either invalid or could not be
>validated.

Utopia is where there is a global PKI where all signatures can be
validated. However, this will be unlikely due to the huge amount of public
keys which would need to be stored and maintained. A more likely scenario
is where a global PKI stores keys for countersigners. The counter signers
have the ability to validate originators signatures which fall in their
area. For example you could have a PKI for the IETF. People outside of the
IETF may not be able to validate signatures from IETF originators because
they don't have access to the appropriate information. However, their is a
countersigner (release authority) for the IETF who can and does validate
the signatures of IETF members and then countersigns the data. The
receipient can validate the countersigners signature because the
countersigner is in the global PKI. Since the countersigner MUST validate
the originators signature before countersigning the recipient can accept
the validity of the data when there is a valid countersigner signature.

>> Excerpt from last paragraph of section 11.4 in draft-ietf-smime-cms-05.txt
>> 
>> "The fact that a countersignature is computed on a signature value means
>> that the countersigning process need not know the original content input to
>> the signing process."
>> 
>> If the original content is not available then the signature being
>> countersigned can not be validated.
>> 
>
>Not by the signer at least but as I said there are times when this
>doesn't matter.
>
>In this case the signature value being countersigned compactly
>represents: some signed content, the signed attributes of that content
>and the signers public key. Asking the relevant countersigning agent to
>validate possibly huge quanties of data and signatures would not be
>practicable in all circumstances.

True. But would have to if acting as a release authority.

>There could, of course, be circumstances where the countersigning agent
>would check the original content if it wanted to place some other value
>on the counter signature. As in the case with signed messages in general
>the value of the counter signature is dependent on the CA doing the
>signing.
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.

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

Date: Wed, 24 Jun 1998 18:58:53 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: William Ottaway <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Countersignature within CMS
Sender: [email-masked]

William Ottaway wrote:
> 
> 
> If a signer verifies the signature it is countersigning then everything is
> fine and dandy. However, when I receive a countersignature I have no way of
> knowing if the signature being signed has been checked first. Infact I
> would expect that the entity applying the countersignature is more likely
> not to check the signature over the original content because it doesn't
> need to and may not be able to.
> 

This is correct but there are cases where this is unncecessary: an
example is a time stamping authority. All a time stamping authority is
saying is that "at this time I produced this signature".

There are several circumstances where this is important for example
archived messages signed with revoked certificates or copyright
disputes. I'll expand on this if it isn't clear.

A receiving agent would presumably regard the countersignature as
valueless is the original signature is either invalid or could not be
validated.

> Excerpt from last paragraph of section 11.4 in draft-ietf-smime-cms-05.txt
> 
> "The fact that a countersignature is computed on a signature value means
> that the countersigning process need not know the original content input to
> the signing process."
> 
> If the original content is not available then the signature being
> countersigned can not be validated.
> 

Not by the signer at least but as I said there are times when this
doesn't matter.

In this case the signature value being countersigned compactly
represents: some signed content, the signed attributes of that content
and the signers public key. Asking the relevant countersigning agent to
validate possibly huge quanties of data and signatures would not be
practicable in all circumstances.

There could, of course, be circumstances where the countersigning agent
would check the original content if it wanted to place some other value
on the counter signature. As in the case with signed messages in general
the value of the counter signature is dependent on the CA doing the
signing.

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

Date: Wed, 24 Jun 1998 08:51:49 +0100
To: Russ Housley <[email-masked]>
From: William Ottaway <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

Russ

If a signer verifies the signature it is countersigning then everything is
fine and dandy. However, when I receive a countersignature I have no way of
knowing if the signature being signed has been checked first. Infact I
would expect that the entity applying the countersignature is more likely
not to check the signature over the original content because it doesn't
need to and may not be able to.

Excerpt from last paragraph of section 11.4 in draft-ietf-smime-cms-05.txt

"The fact that a countersignature is computed on a signature value means
that the countersigning process need not know the original content input to
the signing process."

If the original content is not available then the signature being
countersigned can not be validated.

Bill.

At 22:56 23/06/98 -0400, you wrote:
>Bill:
>
>I should think that a signer would not apply a countersignature without
>verifying the signature that it covers.  One important place that
>countersignature might be used is a workflow application where concurrance
>is needed.
>
>Russ
>
>At 02:36 PM 6/22/98 +0100, William Ottaway wrote:
>>Hi all,
>>
>>I would like to know whether anyone uses or intends to use the
>>Countersignature attribute type defined in section 11.4 in
>>draft-ietf-smime-cms-04.txt.
>>
>>I myself do not see a use for it as I can't trust it. It is not
>>authenticated and it provides one or more signatures on a signature value
>>which may not be valid.
>>
>>Bill.
>>_____________________________________________________________________
>>William Ottaway,             Tel: +44 (0)1684 894079
>>DERA Malvern,                Fax: +44 (0)1684 896113
>>St. Andrews Road,            email: [email-masked]
>>Malvern,
>>Worcs, WR14 3PS
>>UK
>> 
>
"The Information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  For those other than the intended recipient any
disclosure, copying, distribution, or any action taken or omitted to
be taken in reliance on such information is prohibited and may be
unlawful."
____________________________________________________________
William Ottaway,             Tel: (01684) 894079
DERA Malvern,                Fax: (01684) 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs,

WR14 3PS

All opinions are my own.

Date: Wed, 24 Jun 1998 00:44:42 -0400
To: [email-masked] (David P. Kemp)
From: Russ Housley <[email-masked]>
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Cc: [email-masked]
Sender: [email-masked]

Dave:

>* CMS draft -05 section 2 contains the paragraph:
>
>    An implementation that conforms to this specification must implement
>    the data, signed-data, and enveloped-data content types.  The other
>    content types may be implemented if desired.
>
>Since this is an S/MIME conformance requirement, it should be moved
>to the MSG draft section 2.4, and removed from CMS.  For editorial
>consistency, the real content type names (Data, SignedData, and
>EnvelopedData) should be used instead of nicknames with dashes.

Yes, these are the forms needed to implement S/MIME.  However, I do not think
that a CMS implemntation should be required to implment all of the content
types.

The "nicknames with dashes" come from PKCS#7 version 1.5.  It is not a big
dela
to remove these names, but we should consider the origin before we make this
decision.

>* CMS section 3 says:
>
>    The Cryptographic Message Syntax associates a protection content
>    type with a protection content.  The syntax shall have ASN.1 type
>    ContentInfo:
>
>In cases where no other means of identifying the protection content
>type is available (as is the case with S/MIME), ContentInfo is used to
>identify the type of outer content.  However, when CMS is used inside a
>layered protocol (such as X.411), the enclosing protocol will include a
>content type identifier as part of it's own syntax, and the
>encapsulated content would be a SignedData, EnvelopedData, ... item,
>not a ContentInfo item.

PKCS#7 v1.5 only exports one type ContentInfo.  CMS is doing the same.

>It is ambiguous whether CMS contains any IETF conformance requirements.
>It doesn't have any capitalized MUSTs, SHOULDs or MAYs, but the word
>"shall" might be construed as a conformance requirement.  The paragraph
>above should be replaced with the following to remove the ambiguity:
>
>    The Cryptographic Message Syntax defines the ASN.1 type ContentInfo,
>    which associates a protection content type with a protection
>    content.  ContentInfo may be used as the top-level CMS structure,
>    or it may be omitted if the encapsulating environment provides
>    a method of identifying the CMS content type.

Does adding this to section 2 help?
The Cryptographic Message Syntax (CMS) is general enough to support many
different content types.  This document defines one protection content,
ContentInfo.  ContentInfo encapsulates one or more protection content type. 
This document defines six content types: data, signed-data, enveloped-data,
digested-data, encrypted-data, and authenticated-data.  Additional content
types can be defined outside this document. 
>* CMS section 4 says:>
>    The data content type is intended to refer to arbitrary octet
>    strings, such as ASCII text files; the interpretation is left to
>    the application.  Such strings need not have any internal structure
>    (although they could have their own ASN.1 definition or other
>    structure).
>
>    The data content type is generally used in conjunction with the
>    signed-data, enveloped-data, digested-data, encrypted-data, and
>    authenticated-data protection content types.  The data content
>    type is encapsulated in one of these protection content types.
>
>S/MIME (MSG section 2.4.1) requires that id-data be used to identify
>the inner content.  However, other protocols which reference CMS may
>wish to use a more specific type identifier.  CMS should explicitly
>allow this possibility:
>
>    The data content type is intended to refer to arbitrary octet
>    strings of unspecified type; the interpretation is left to
>    the application.  Such strings could be ASCII text files with
>    no internal structure, or they could be MIME entities, ASN.1
>    types, or other structured objects.
>
>    The data content type is generally used in conjunction with the
>    signed-data, enveloped-data, digested-data, encrypted-data, and
>    authenticated-data protection content types.  The data content
>    type is encapsulated in one of these protection content types.
>    Object identifiers other than id-data may be used to identify
>    the specific type of encapsulated content, but such usage is
>    outside the scope of this specification.

Agree.

Russ 

Date: Tue, 23 Jun 1998 23:30:15 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Cc: [email-masked]
Sender: [email-masked]

Denis:

>I have a few problems with cert (draft-ietf-smime-cert). The document
>refers to X.509 certificates instead of PKIX certificates.

I agree.  CERT should reference PKIX Part 1.

>The major issue I see is to mandate the use of ISO Distinguished Name.
>This is currently mandated for the issuer names. For leaf names the
>situation is is little more complex as it will be explained later.

PKCS#7 version 1.5 and CMS refer to certificates by isser DName and serial
number.  Thus, S/MIME certificates must have an issuer DName.  The backward
compatibility discussion with PKCS#7 v1.5 has been repeated many, many
times, so I will not repeat it again.

>2.3 CertificateSet
>
>(...)
>
>"Receiving agents MUST support chaining based on the distinguished name
>fields. Other methods of building certificate chains may be supported
>but are not currently recommended."

Since the DNames are needed for PKCS#7 v1.5 and CMS, this seems like a
reasonable next step.  Note that end entities do not have to have DNames.
They can use the more widely accepted RFC822 AltNames, or other names
formats.  The issuer name in the end entity certificate must be a DName,
this will match the subject DName in the CA certificate.  Chaining does not
invlove the end entity name.

>"Attribute certificates -- keep 'em or pitch 'em?"
>
>The ISO document is not yet stable. I would prefer that we do not
>include them for the time being but that we indicate that the support of
>roles is to be considered.

I can support removing them from the CERT document, but I do not think that
we should eliminate them from the CMS document.  Support for attribute
certificates should be completely optional.

Russ

Date: Tue, 23 Jun 1998 22:56:35 -0400
To: William Ottaway <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

Bill:

I should think that a signer would not apply a countersignature without
verifying the signature that it covers.  One important place that
countersignature might be used is a workflow application where concurrance
is needed.

Russ

At 02:36 PM 6/22/98 +0100, William Ottaway wrote:
>Hi all,
>
>I would like to know whether anyone uses or intends to use the
>Countersignature attribute type defined in section 11.4 in
>draft-ietf-smime-cms-04.txt.
>
>I myself do not see a use for it as I can't trust it. It is not
>authenticated and it provides one or more signatures on a signature value
>which may not be valid.
>
>Bill.
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs, WR14 3PS
>UK
> 

Reply-To: <[email-masked]>
From: "Rich Ankney" <[email-masked]>
To: <[email-masked]>, "EKR" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-smime-x942-00.txt comments.
Date: Mon, 22 Jun 1998 15:18:04 -0400
Sender: [email-masked]

> > I suppose it could be commented that using an OCTET STRING for
"counter"
> > to represent a number is a bit naughty and an INTEGER would be more
> > appropriate: but that doesn't really matter (to me at least).
> Not my idea. That's the way it is in X9.42. Compatibility seems
> more important than taste, in this case.
>

The counter is an OCTET STRING because (in prior drafts) it was just a
4-byte counter.  When we moved to ASN.1 (for other reasons), we (or
at least some of us, I forget who) wanted to keep a full 4-byte counter, 
vs. an ASN.1 INTEGER which would typically be only a byte.

Regards,
Rich

To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: draft-ietf-smime-x942-00.txt comments.
From: EKR <[email-masked]>
Date: 22 Jun 1998 10:10:20 -0700
Lines: 66
Sender: [email-masked]

Dr Stephen Henson <[email-masked]> writes:
> I've been perusing the DH draft: great work! 
Thanks.

> I have a few comments.
> 
> > 2.1.4.  Keylengths for common algorithms
> > 
> >    Some common key encryption algorithms have KEKs of the following
> >    lengths.
> > 
> >            DES-ECB         64 bits
> >            3DES-EDE-ECB    192 bits
> >            RC2 (all)       256 bits
> > 
> 
> RC2-n in the content encryption cipher I take to mean a keylength of n/8
> bytes and an effective keylength of n bits. I can't give a reference but
> for me at least it's simply "what works" and established practice for
> existing S/MIME implementations for RC2-128, RC2-64 and RC2-40.
Hmmm...

The RC2-RFC implies that standard practice is otherwise:

   This memo describes a conventional (secret-key) block encryption
   algorithm, called RC2, which may be considered as a proposal for a
   DES replacement. The input and output block sizes are 64 bits each.
   The key size is variable, from one byte up to 128 bytes, although the
   current implementation uses eight bytes.

Can some of the implementors comment on what they do?

For my part, I'd prefer a standard key size with variable effective
key lengths.

> This need not be followed for the key wrapping algorithms of course but
> it might be preferable if e.g. "RC2-40" always refers to the same basic
> algorithm.
We're talking about OIDs here, so they really have to have
a standard meaning. 

> Also the standard has SHA-1 hard coded. Perhaps this should be
> selectable by the CMS with a default of SHA-1. This would allow for
> healthy paranoia in that SHA-1 might be broken some day. Otherwise
> changing it would be very painful if CMS had no provision for an
> alternative digest function.
I see your point, however that requires some way to specify the
digest algorithm which means you have to worry about the
consequences of it being changed on the wire. 

Considering that all the workable attacks on digest algorithms
seem to involve generating collisions, not reversing the
digest, and that collisions aren't a thread to this usage.
I think I prefer simplicity.

> I suppose it could be commented that using an OCTET STRING for "counter"
> to represent a number is a bit naughty and an INTEGER would be more
> appropriate: but that doesn't really matter (to me at least).
Not my idea. That's the way it is in X9.42. Compatibility seems
more important than taste, in this case.

-Ekr

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

From: Jeff Gilchrist <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: ESS Security Policies
Date: Mon, 22 Jun 1998 11:30:02 -0400
Sender: [email-masked]

I am looking at the ESS document draft-ietf-smime-ess-06.txt in section
3.3.1 (Security Policy Identifier).

I was wondering if anyone knows of any standards (corporate, government,
etc...) for security policies?

Any help would be appreciated.  Thanks.

Regards,

-- 
Jeff Gilchrist  <[email-masked]>
Entrust Technologies Ltd.
http://www.entrust.com

Date: Mon, 22 Jun 1998 14:36:56 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Countersignature within CMS
Sender: [email-masked]

Hi all,

I would like to know whether anyone uses or intends to use the
Countersignature attribute type defined in section 11.4 in
draft-ietf-smime-cms-04.txt.

I myself do not see a use for it as I can't trust it. It is not
authenticated and it provides one or more signatures on a signature value
which may not be valid.

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

Date: Sun, 21 Jun 1998 02:53:34 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: draft-ietf-smime-x942-00.txt comments.
Sender: [email-masked]

I've been perusing the DH draft: great work! 

I have a few comments.

> 2.1.4.  Keylengths for common algorithms
> 
>    Some common key encryption algorithms have KEKs of the following
>    lengths.
> 
>            DES-ECB         64 bits
>            3DES-EDE-ECB    192 bits
>            RC2 (all)       256 bits
> 

RC2-n in the content encryption cipher I take to mean a keylength of n/8
bytes and an effective keylength of n bits. I can't give a reference but
for me at least it's simply "what works" and established practice for
existing S/MIME implementations for RC2-128, RC2-64 and RC2-40.

This need not be followed for the key wrapping algorithms of course but
it might be preferable if e.g. "RC2-40" always refers to the same basic
algorithm.

IMHO the "standard" meaning should be kept for the content encryption
key whatever the wrapping meaning to allow mixed key transport and key
agreement messages to work.

Also the standard has SHA-1 hard coded. Perhaps this should be
selectable by the CMS with a default of SHA-1. This would allow for
healthy paranoia in that SHA-1 might be broken some day. Otherwise
changing it would be very painful if CMS had no provision for an
alternative digest function.

I suppose it could be commented that using an OCTET STRING for "counter"
to represent a number is a bit naughty and an INTEGER would be more
appropriate: but that doesn't really matter (to me at least).

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

Date: Fri, 19 Jun 1998 15:52:38 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Patents and draft-ietf-smime-x942-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

The Internet-Draft draft-ietf-smime-x942-00.txt specified on of the
variants fron the ANSI X9.42 Draft Standad. This vairant of Diffie-Hellman
seems to be clear of IBM's pending patent.

At this point, I waould like all S/MIME WG members to determine if there
are any other potential patents (pending or otherwise) that might impact
the use of the Diffie-Hellman variant specified in
draft-ietf-smime-x942-00.txt.  At this point I am unaware of any, and this
query is to avoid any rude surprises.

Please forward this note to anyone who might offer assistance in the quick
resolution of this matter.

Russ
S/MIME WG Chair 

Date: Fri, 19 Jun 1998 17:22:51 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Russ Housley <[email-masked]>
CC: [email-masked]
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Sender: [email-masked]

Russ Housley wrote:

> S/MIME WG Participants:
> 
> These three documents seem to be in very good shape.  I have previously
> announced last Call for ESS, and a new version has been released to
> incorporate the comments.  I am now announcing Last Call for MSG and CERT.
> 
> None of these documents will be progressed to the IESG until CMS has
> completed Last Call.  At that time, CMS, ESS, MSG, and CERT will be
> forwrded to the IESG together.
> 
> Russ
> S/MIME WG Chair

I have a few problems with cert (draft-ietf-smime-cert). The document
refers to X.509 certificates instead of PKIX certificates.

Basically PKIX is a super set of X.509. I would prefer that we only use
and refer to the PKIX documents i.e. [KEYM] "Internet Public Key
Infrastructure X.509 Certificate and CRL Profile", Internet-Draft
draft-ietf-pkix-ipki-part1 and take advantage of the new capabilities
that have been added in PKIX, basically the use of Alternate names.

The major issue I see is to mandate the use of ISO Distinguished Name.
This is currently mandated for the issuer names. For leaf names the
situation is is little more complex as it will be explained later.

There is no rational provided in the document to explain why this choice
has been made.

Let us now look at the details.

2.3 CertificateSet

(...)

"Receiving agents MUST support chaining based on the distinguished name
fields. Other methods of building certificate chains may be supported
but are not currently recommended."

This is where in the document chaining of issuer DNs is mandated. 
As it will be explained later chaining can be done through naming
constraints within certificates or through local naming constrains.
Since the first one is not mandated and the second one is not described,
it is unclear how agent CAN support it.

Allowing other forms of name for CAs would be adequate. The X.400 naming
scheme which is also X.521 based has not been a success and leads to
names that are difficult to read/write and communicate. I would rather
prefer S/MIME to be a success. :-)

3. Distinguished Names in Certificates

3.1 Using Distinguished Names for Internet Mail

(...)

" All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE) in S/MIME-compliant v3 X.509 Certificates, except that the
subject DN in a user's (i.e. end-entity) certificate MAY be an empty
SEQUENCE in which case the subjectAltName extension will include the
subject's identifier and MUST be marked as critical."

This is where the subject name is mandated to be a DN, and then not
mandated. :-)

What is the "subject's identifier" is the second case ? What is the
relationship with an Internet mail address ?

3.2 Required Name Attributes

"Receiving agents MUST support parsing of zero, one, or more instances
of each of the following set of name attributes within the
Distinguished Names in certificates."

Is there no attributes required for sending agents ?

(...)

4.2 Certificate Chain Validation

"In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user. Certificate, CRL, and chain
validation MUST be performed as per [KEYM] when validating a
correspondent's public key."

A better reference would be needed. The section is called : 6 
Certificate Path Validation.

4.4 X.509 Version 3 Certificate Extensions

Wouldn't it be more appropriate to refer to [KEYM] "Internet Public Key
Infrastructure X.509 Certificate and CRL Profile", Internet-Draft
draft-ietf-pkix-ipki-part1 instead of X.509 Version 3 ?

4.4.1 Basic Constraints Certificate Extension

(...)

"Certificates SHOULD contain a basicConstraints extension".

Since basicConstraints extensions are hard to handle, it is a reasonable
choice. 

However indications should be given to apply external naming constraints
otherwise implementors could end up with insecure implementations: if
you trust two (or more) CAs and have no naming constraints (either local
or embedded within the certificates) then any of the CAs could certify
any end user.  :-(

We need to give guidance since we should not mandate a single root
self-certificate in a client workstation.

To this respect I do not see why the use of DNs offers a major advantage
over RFC822 names.

The use of DNs presents some properties that can be seen as both an
advantage and a disadvantage:

1) when DNs are used and many attributes are used, from the certificate
you can make sure you correspond with the right individual. The drawback
is to loose privacy. Another drawback is the size of the certificate
(especially if you want to have it a smart card).

2) when DNs are not used, you would need another mechanism to make sure
you correspond with the right individual, i.e. make some kind of look up
in a server that you can trust. You may have more privacy, the size of
the certificate is reduced.

I would think that both models make sense, but more text to explain it
would be adequate.

C. Needed changes

"Attribute certificates -- keep 'em or pitch 'em?"

The ISO document is not yet stable. I would prefer that we do not
include them for the time being but that we indicate that the support of
roles is to be considered.

Note: I will be away most of next week and unable to follow this thread.
So don't be surprised if there is no response from me until next Friday.
:-(

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Fri, 19 Jun 1998 12:31:18 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: CMS: key wrapping standard.
Sender: [email-masked]

Russ Housley wrote:
> 
> Steve:
> 
> This technique does not offer any integrity.  I have a strong desire for a
> mechnaism that allows a message recipient to detect problems with the key
> before processing the entire message content is possibel.
> 

Indeed it does not provide any integrity but then again even a
sophisticated scheme is not resistant to even simple attacks. The
anonymous nature of most of the enveloped data forms (barring non anon
DH which has a signing element anyway). I'll describe a few possible
attacks with each mode to illustrate the point.

Some of these could also occur due to message corruption.

These first few work in all modes and attack all recipients at once.

1. The simplest attack is just to substitute bogus content. This is
possible because RecipientInfo structures can be built using just public
information (public keys of recipients or a random anon-DH keypair).
Since this is a perfectly valid message it decrypts fine.

2. Just scramble the encrypted content. Since only the last block has
any kind of integrity check if you leave it and the previous one alone
(due to CBC mode) you can kill the whole content and it will still
decrypt fine. This works in static DH modes.

The next few can be aimed at several recipients or just one. In the case
of single recipient attacks the other recipient can read the message
fine.

3. Delete the RecipientInfo structure(s). A bit primitive and easily
detectable.

4. Substitute the RecipientInfo structure or part of it from another
message. This shouldn't be detected until the whole message is read.
Even then it may not be detected. Again this can hit static DH.

The next few rely on finding a specific "content decryption key". Since
only the last couple of blocks of a message have any kind of integrity
check it is possible to find a bogus content encryption key which will
decrypt the message just fine but yield only garbage. This can be done
by just trying random keys. On average this will work after around 128
attempts.

5. Substitute the RecipientInfo structure(s) with one for the bogus key.
Key transport makes this very easy. Key agreement is similar, except you
have to follow the integrity check rules (if any).

6. In key agreement swap the first two blocks of the EncryptedKey. This
I believe is the attack that an integrity check will prevent. You can't
touch the last two blocks because that could break the padding: since in
3DES this padding will be 8 8s this makes it unlikely that touching the
last two blocks will work.

7. (May not be possible: depends on final structure) fiddle with the IV
for the EncryptedKey.

... Lots more I can't think of at present.

Given that only one of these is stopped by an integrity check and
several of the others are undetectable (and number 4 is particularly
easy and nasty) IMHO an integrity check does not offer much if any
useful protection. What do other people think?

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

Date: Thu, 18 Jun 1998 11:38:58 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: CMS: key wrapping standard.
Cc: [email-masked]
Sender: [email-masked]

Steve:

This technique does not offer any integrity.  I have a strong desire for a
mechnaism that allows a message recipient to detect problems with the key
before processing the entire message content is possibel.

Russ

At 07:14 PM 6/17/98 +0100, Dr Stephen Henson wrote:
>While perusing PKCS#11 I came across a couple of descriptions for
>wrapping one secret (symmetric) key inside another. It is in section
>11.18.2 and 11.18.4 or thereabouts.
>
>The most usable method is the "naive" method I'd mentioned before which
>involves the following.
>
>1. Take the content encryption key.
>2. Pad to a multiple of the wrapping cipher block length using PKCS
>padding (as mentioned in PKCS#7 and PKCS#5).
>3. Encrypt using the wrapping cipher.
>
>The fact that this can be done with a library that implements enough
>of PKCS#11 has the advantage that neither the wrapping key nor the
>content encryption key have to be revealed outside the library
>internals. Any other method would require at least one key being
>revealed in plain text in the implementation.
>
>An additional EncryptionAlgorithmIdentifier added to the CMS would allow
>separate IVs and separate encryption algorithms to be used for content
>encryption and key wrapping.
>
>Steve.
>-- 
>Dr Stephen N. Henson.
>UK based freelance Cryptographic Consultant. For info see homepage.
>Homepage: http://www.drh-consultancy.demon.co.uk/
>Email: [email-masked]
>PGP key: via homepage.
> 

Date: Wed, 17 Jun 1998 19:14:56 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: CMS: key wrapping standard.
Sender: [email-masked]

While perusing PKCS#11 I came across a couple of descriptions for
wrapping one secret (symmetric) key inside another. It is in section
11.18.2 and 11.18.4 or thereabouts.

The most usable method is the "naive" method I'd mentioned before which
involves the following.

1. Take the content encryption key.
2. Pad to a multiple of the wrapping cipher block length using PKCS
padding (as mentioned in PKCS#7 and PKCS#5).
3. Encrypt using the wrapping cipher.

The fact that this can be done with a library that implements enough
of PKCS#11 has the advantage that neither the wrapping key nor the
content encryption key have to be revealed outside the library
internals. Any other method would require at least one key being
revealed in plain text in the implementation.

An additional EncryptionAlgorithmIdentifier added to the CMS would allow
separate IVs and separate encryption algorithms to be used for content
encryption and key wrapping.

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

To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Do CMS implementations allows Parallel Signer Infos from more than one signer?
From: EKR <[email-masked]>
Date: 16 Jun 1998 10:03:44 -0700
Lines: 31
Sender: [email-masked]

Tim Dean <[email-masked]> writes:
> CMS allow multiple entities to sign content 'in parallel'  (sect 5.1). 
>  However, I have come across an implementation which only expects to find 
> one signature in the SET OF SignerInfos, and will reject the message if 
> more than one is found.  The rationale was that if there are multiple 
> signers, it causes confusion as to who originated the message.  I have 
> several questions about this:
> 1) Is this behaviour regarded as conformant with the standard (since there 
> is no explicit size limit on the set)?
I believe so.

> 2) Are there other implementations which insist on this limitation?
My implementation will verify multiple signatures, provided they
use the same digest algorithm. (This wasn't really a conscious
choice, it's just a restriction that made implementation easier.)

> 3) Are there any implementations that have the capability to generate 
> multiple (parallel) signatures?
Not mine.

> 4) For implementations which accept multiple signatures, how do they detect 
> which one originated the message?
I don't have any UI, so I don't make any attempt. I just report back
a structure listing the signatures.

-Ekr

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

From: Tim Dean <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Do CMS implementations allows Parallel Signer Infos from more than one signer?
Date: Tue, 16 Jun 1998 16:46:21 +0100
Organization: Defence Evaluation and Research Agency
Sender: [email-masked]

CMS allow multiple entities to sign content 'in parallel'  (sect 5.1). 
 However, I have come across an implementation which only expects to find 
one signature in the SET OF SignerInfos, and will reject the message if 
more than one is found.  The rationale was that if there are multiple 
signers, it causes confusion as to who originated the message.  I have 
several questions about this:
1) Is this behaviour regarded as conformant with the standard (since there 
is no explicit size limit on the set)?
2) Are there other implementations which insist on this limitation?
3) Are there any implementations that have the capability to generate 
multiple (parallel) signatures?
4) For implementations which accept multiple signatures, how do they detect 
which one originated the message?

Feel free to respond to me individually, and I will summarise responses to 
the list (without attributing their source, if requested).

Tim Dean

Date: Mon, 15 Jun 1998 11:11:22 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Sender: [email-masked]

> From: Paul Hoffman / IMC <[email-masked]>

> >  From: dpk
> >
> >In cases where no other means of identifying the protection content
> >type is available (as is the case with S/MIME), ContentInfo is used to
> >identify the type of outer content.  However, when CMS is used inside a
> >layered protocol (such as X.411), the enclosing protocol will include a
> >content type identifier as part of it's own syntax, and the
> >encapsulated content would be a SignedData, EnvelopedData, ... item,
> >not a ContentInfo item.
> 
> That could be true, but doing so would certainly hurt interchangability of
> data with S/MIME. If the WG wants to go with this change, I would still
> like to see a sentence or two in the CMS draft saying that S/MIME requires
> a ContentInfo and other specs that want to not use ContentInfo should think
> twice.

Actually, these changes were motivated by a specific messaging
environment which has a requirement for signature interoperability with
S/MIME, and the lack of an enclosing ContentInfo has no effect on
interoperability.

It is important to remember that if a message is not in S/MIME format,
then it must be passed through a translation step before being usable
by S/MIME software - there's no way around that.   The data in an X.411
(for example) message must be twiddled around in order to make it
compliant with the S/MIME MSG specification and usable by S/MIME
software.  That twiddling must of course include stuffing a protection
type such as SignedData into a ContentInfo structure as one small step
- other necessary steps include moving certificates into the proper
location, MIME C-T-E processing, etc.

However, there is no more reason to require the X.411 message itself to
include a ContentInfo structure than there is to require the X.411
message to have a application/pkcs7-mime MIME header.  The requirement
doesn't make architectural sense.  The only real requirement applicable
to X.411 User Agents is for signatures to be computed in accordance with
CMS procedures, and placed in some location where they can be found by the
X.411-to-S/MIME translator.  CMS must mandate how data is signed
and enciphered, but it should not mandate that the results be encoded
in any specific format.

Date: Fri, 12 Jun 1998 13:44:42 -0700
To: [email-masked] (David P. Kemp), [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Sender: [email-masked]

>    An implementation that conforms to this specification must implement
>    the data, signed-data, and enveloped-data content types.  The other
>    content types may be implemented if desired.
>
>Since this is an S/MIME conformance requirement, it should be moved
>to the MSG draft section 2.4, and removed from CMS.

I can see the logic in this. Let CMS just define the objects (not just for
S/MIME), and MSG define which must be supported for S/MIME.

>    The Cryptographic Message Syntax associates a protection content
>    type with a protection content.  The syntax shall have ASN.1 type
>    ContentInfo:
>
>In cases where no other means of identifying the protection content
>type is available (as is the case with S/MIME), ContentInfo is used to
>identify the type of outer content.  However, when CMS is used inside a
>layered protocol (such as X.411), the enclosing protocol will include a
>content type identifier as part of it's own syntax, and the
>encapsulated content would be a SignedData, EnvelopedData, ... item,
>not a ContentInfo item.

That could be true, but doing so would certainly hurt interchangability of
data with S/MIME. If the WG wants to go with this change, I would still
like to see a sentence or two in the CMS draft saying that S/MIME requires
a ContentInfo and other specs that want to not use ContentInfo should think
twice.

>It is ambiguous whether CMS contains any IETF conformance requirements.
>It doesn't have any capitalized MUSTs, SHOULDs or MAYs, but the word
>"shall" might be construed as a conformance requirement.

Boy, you hit half a dozen things there. There is no such thing as an "IETF
conformance requirement". You can claim conformance to a particular RFC,
but that has nothing to do with the IETF. Because CMS doesn't reference RFC
2119, there is no definition of MUST/SHALL or SHOULD or MAY, and I think
that's fine. The "shalls" mean "need to do this for consistency" or "need
to do this for security".

>S/MIME (MSG section 2.4.1) requires that id-data be used to identify
>the inner content.  However, other protocols which reference CMS may
>wish to use a more specific type identifier.  CMS should explicitly
>allow this possibility:

I can buy this, again with the same caveat from above, that we say what
S/MIME is doing to help other implementors make their data more easily
interchange with S/MIME.

--Paul Hoffman, Director
--Internet Mail Consortium

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x942-00.txt
Date: Wed, 03 Jun 1998 10:24:52 -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		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-00.txt
	Pages		: 5
	Date		: 02-Jun-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. In addition, a standard
   group that meets the X9.42 requirements 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-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-x942-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: 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-00.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-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-06.txt
Date: Wed, 03 Jun 1998 10:23:37 -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-06.txt
	Pages		: 31
	Date		: 02-Jun-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-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-06.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-06.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-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 11 Jun 1998 15:01:19 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: WG LAST CALL for ESS, MSG and CERT
Sender: [email-masked]

The following comments relate to the use of CMS in non-S/MIME
environments:

* CMS draft -05 section 2 contains the paragraph:

    An implementation that conforms to this specification must implement
    the data, signed-data, and enveloped-data content types.  The other
    content types may be implemented if desired.

Since this is an S/MIME conformance requirement, it should be moved
to the MSG draft section 2.4, and removed from CMS.  For editorial
consistency, the real content type names (Data, SignedData, and
EnvelopedData) should be used instead of nicknames with dashes.

* CMS section 3 says:

    The Cryptographic Message Syntax associates a protection content
    type with a protection content.  The syntax shall have ASN.1 type
    ContentInfo:

In cases where no other means of identifying the protection content
type is available (as is the case with S/MIME), ContentInfo is used to
identify the type of outer content.  However, when CMS is used inside a
layered protocol (such as X.411), the enclosing protocol will include a
content type identifier as part of it's own syntax, and the
encapsulated content would be a SignedData, EnvelopedData, ... item,
not a ContentInfo item.

It is ambiguous whether CMS contains any IETF conformance requirements.
It doesn't have any capitalized MUSTs, SHOULDs or MAYs, but the word
"shall" might be construed as a conformance requirement.  The paragraph
above should be replaced with the following to remove the ambiguity:

    The Cryptographic Message Syntax defines the ASN.1 type ContentInfo,
    which associates a protection content type with a protection
    content.  ContentInfo may be used as the top-level CMS structure,
    or it may be omitted if the encapsulating environment provides
    a method of identifying the CMS content type.

* CMS section 4 says:

    The data content type is intended to refer to arbitrary octet
    strings, such as ASCII text files; the interpretation is left to
    the application.  Such strings need not have any internal structure
    (although they could have their own ASN.1 definition or other
    structure).

    The data content type is generally used in conjunction with the
    signed-data, enveloped-data, digested-data, encrypted-data, and
    authenticated-data protection content types.  The data content
    type is encapsulated in one of these protection content types.

S/MIME (MSG section 2.4.1) requires that id-data be used to identify
the inner content.  However, other protocols which reference CMS may
wish to use a more specific type identifier.  CMS should explicitly
allow this possibility:

    The data content type is intended to refer to arbitrary octet
    strings of unspecified type; the interpretation is left to
    the application.  Such strings could be ASCII text files with
    no internal structure, or they could be MIME entities, ASN.1
    types, or other structured objects.

    The data content type is generally used in conjunction with the
    signed-data, enveloped-data, digested-data, encrypted-data, and
    authenticated-data protection content types.  The data content
    type is encapsulated in one of these protection content types.
    Object identifiers other than id-data may be used to identify
    the specific type of encapsulated content, but such usage is
    outside the scope of this specification.

Date: Thu, 11 Jun 1998 16:51:40 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
CC: Blake Ramsdell <[email-masked]>
Subject: Re: Comment on Message spec.
Sender: [email-masked]

OK here is a suggested alternative wording which I think makes things a
little more explicit. I think the remaining cases (i.e. if all is valid
it SHOULD be accepted) are sufficiently obvious that no clarification is
needed.

- If the signature of the signed attributes is invalid or the value of
  the signing time lies far in the future (that is, a
greater             discrepancy than any reasonable clock skew) then the
list of            capabilities MUST NOT be accepted.
- If the timestamp and the signature of the signed attributes is
valid    but the messageDigest value is not valid then the receiving
agent       SHOULD accept the list of capabilities.
- If the receiving agent has not yet created a list of capabilities
  for the sender's public key, then, the receiving agent SHOULD 
  create a new list containing at least the signing time and the      
symmetric capabilities.
- If such a list already exists, the receiving agent SHOULD verify
  that the signing time in the incoming message is greater than
  the signing time stored in the list. If so, the receiving agent
  SHOULD update both the signing time and capabilities in the list. 

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

Date: Wed, 10 Jun 1998 19:51:38 -0700 (PDT)
From: 4n6n61 <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  44
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

Date: Wed, 10 Jun 1998 18:03:09 -0700 (PDT)
From: 3rstyhd <[email-masked]>
To: <[email-masked]>
Reply-To: [email-masked]
Sender: [email-masked]

Authenticated sender is <[email-masked]>
Subject:  3  g
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

EMAIL MARKETING WORKS!!

Bull's Eye Gold is the PREMIER email address collection tool.
This program allows you to develop TARGETED lists of email
addresses.  Doctors, florists, MLM, biz opp,...you can collect
anything...you are only limited by your imagination!  You can
even collect email addresses for specific states, cities, and
even countries!  All you need is your web browser and this program.
Our software utilizes the latest in search technology called
"spidering". By simply feeding the spider program a starting
website it will collect for hours. The spider will go from website
to targeted website providing you with thousands upon thousands of
fresh TARGETED email addresses. When you are done collecting,  the
spider removes duplicates and saves the email list in a ready to
send format. No longer is it necessary to send millions of ads to
get a handful of responses...SEND LESS...EARN MORE!!!

A terrific aspect of the Bull's Eye software is that there is
no difficult set up involved and no special technical mumbo-jumbo
to learn. All you need to know is how to search for your targeted
market in one of the many search engines and let the spider do the
rest! Not familiar with the search engines? No problem, we provide
you with a list of all the top search engines. Just surf to the
location of a search engine on your browser then search for the
market you wish to reach...it's that easy!

For instance if you were looking for email addresses of Doctors
in New York all you would do is:

1) Do a search using your favorite search engine by typing in
the words doctor(s) and New York
2) Copy the URL (one or more)...that's the stuff after the
http://...  for instance it might look like
http://www.yahoo.com/?doctor(s)/?New+York
3) Press the START button

THAT's IT!!!  The Bull's Eye spider will go to all the websites
that are linked, automatically extracting the email addresses
you want.

The spider is passive too! That means you can let it run all
day or all night while you are working on important things or
just having fun on your computer. There is no need to keep a
constant watch on it, just feed it your target market and give
it praise when it delivers thousands of email addresses at
the end of the day!

Features of the Bull's Eye Software:

* Does TARGETED searches of websites collecting the email
  addresses you want!
* Collects Email addresses by City, State, even specific
  Countries
* Runs Automatically...simply enter the Starting information,
  press The Start Button, and it does the rest
* Filters out duplicates
* Keeps track of URLs already visited
* Can run 24 hours per day, 7 days per week
* Fast and Easy List Management
* Also has built in filtering options...you can put in words
  that it "Must" have while searching,...you can even put in
  criteria that it  "Must NOT Have"...giving you added flexibility
* Also imports email addresses from any kind of files (text
  files, binary files, database files)
* List editor handles Multiple files to work on many lists
  simultaneously
* Has a Black-Book feature... avoid sending emails to people
  who do not want to receive it
* Built-in Mail program...send email directly on the internet
  with just a click of your mouse
* Personalized Emails...if the email address has the user's
  name when it is collected,..you can send Personalized emails!!!
* Sort by Location, Server, User Name, Contact Name
* Advanced Operations:
· Email address lists export in many different formats
  (HTML, Comma delimited, text file)
· Advanced editing...Transfer, Copy,  Addition, Delete, Crop,
  Move to Top/Bottom
· Operations between lists...Union, Subtraction, Comparison
* Program is Passive,...meaning you can run other programs at
  the same time

CALL FOR MORE INFORMATION   213-969-4930
CALL FOR MORE INFORMATION   213-969-4930

ORDERING INFORMATION

Customer Name
Company Name
Address
City
State                       Zip
Phone                                       Fax
Email Address

______ BULL'S EYE SOFTWARE   $259.00
Includes Software, Instructions, Technical Support

______ Shipping & Handling  (2-3 Day Fedex)  $10.00
                           (Fedex Overnite) $20.00

______  TOTAL
                 (CA Residents add applicable sales tax)

*All orders are for Win 95 and Win NT

                *****CREDIT CARDS ACCEPTED*****
                   MASTERCARD   VISA   AMEX

   PLEASE CALL 213-969-4930 to process your order
                        9am-5pm Pacific Time
                Checks or Money Orders send to:
                      WorldTouch Network Inc.
5670 Wilshire Blvd.  Suite 2170 Los Angeles, CA 90036
Please note:  Allow 5 business days for all checks to
clear before order is shipped.

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: Comment on Message spec.
Date: Tue, 9 Jun 1998 23:06:48 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[email-masked]]
> Sent: Tuesday, June 09, 1998 6:48 PM
> To: [email-masked]
> Subject: Comment on Message spec.
> 
> Re 2.6.1:
> 
> > - If the receiving agent has not yet created a list of capabilities
> >    for the sender's public key, then, after verifying the signature
> >    on the incoming message and checking the timestamp, the receiving
> >    agent SHOULD create a new list containing at least the signing
> >    time and the symmetric capabilities.
> >  - If such a list already exists, the receiving agent SHOULD verify
> >    that the signing time in the incoming message is greater than
> >    the signing time stored in the list and that the signature is
> >    valid. If so, the receiving agent SHOULD update both the signing
> >    time and capabilities in the list. Values of the signing 
> time that
> >    lie far in the future (that is, a greater discrepancy than any
> >    reasonable clock skew), or a capabilities list in messages whose
> >    signature could not be verified, MUST NOT be accepted.
> 
> Does the MUST NOT comment apply to both cases or just the last? It
> appears to just refer to the latter in which case the action 
> to be taken
> when no list of capabilities exists and bad timestamp or signature is
> not covered.

I'm not sure that this case needs to be covered -- in the event that you
receive a message that has a bad timestamp or a bad signature and that
contains capabilities, you MUST NOT use those capabilities.  This is
irrespective of whether or not you currently have any capabilities for
the sender.

Did I understand your question correctly?

> Secondly the "signature". Does this (if signed attributes are present)
> refer to the whole message signature? That is, messageDigest matches
> digest of message and signature on signed attributes valid. The
> condition could be weakened to just signature of signed 
> attributes valid
> (messageDigest could differ due to message corruption). This would not
> involve loss of security since the attribute signature is still valid.

Ah -- interesting.  It is my opinion that if the signature is valid on
the authenticated attributes, regardless of whether or not the
messageDigest matches the digest of the actual contents, then the
capabilities should be considered valid (in other words, I agree with
you).  Other comments?  Worth clarifying?

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

Date: Wed, 10 Jun 1998 02:47:30 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Comment on Message spec.
Sender: [email-masked]

Re 2.6.1:

> - If the receiving agent has not yet created a list of capabilities
>    for the sender's public key, then, after verifying the signature
>    on the incoming message and checking the timestamp, the receiving
>    agent SHOULD create a new list containing at least the signing
>    time and the symmetric capabilities.
>  - If such a list already exists, the receiving agent SHOULD verify
>    that the signing time in the incoming message is greater than
>    the signing time stored in the list and that the signature is
>    valid. If so, the receiving agent SHOULD update both the signing
>    time and capabilities in the list. Values of the signing time that
>    lie far in the future (that is, a greater discrepancy than any
>    reasonable clock skew), or a capabilities list in messages whose
>    signature could not be verified, MUST NOT be accepted.

Does the MUST NOT comment apply to both cases or just the last? It
appears to just refer to the latter in which case the action to be taken
when no list of capabilities exists and bad timestamp or signature is
not covered.

Secondly the "signature". Does this (if signed attributes are present)
refer to the whole message signature? That is, messageDigest matches
digest of message and signature on signed attributes valid. The
condition could be weakened to just signature of signed attributes valid
(messageDigest could differ due to message corruption). This would not
involve loss of security since the attribute signature is still valid.

As an alternative I would suggest that the list of capabilites MUST NOT
be updated if either the timestamp or signed attribute signature is
invalid but if just the messageDigest is invalid the list MAY (or even
SHOULD) be updated.

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

Date: Wed, 10 Jun 1998 01:07:04 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Certificate Distribution Specification comments.
Sender: [email-masked]

Jim Schaad (Exchange) wrote:
> 
> Steve,
> 
> I put the wording in on the matching so that I could do something along the
> lines of I use this certificate for signing and it contains my email name.
> The certificate I want to use for encrytion does not have my email address.
> Since I had done a "match" and it was signed by the matching certificate
> then it seems to me that I should be able to accept the lack of match on the
> encryption certificate.
> 
> I can understand what you are saying about always wanting to check this,
> however I don't think this should be disallowed.  Do you really think this
> is a big problem?

What I meant was that the encryption certificate should be verified in
the sense of checking its signature chain to a trusted root. I don't see
any reason why the email address on the encryption certificate should
match the intended recipient.

My primary concern is avoiding a possible substitution attack because
SMimeEncryptionKeyPreference contains potentially forgeable information.
If the encryption certificate is not verified, a bogus version could be
substituted and a "man in the middle" attack performed.

If SMIMEEncryptionKeyPreference had a "hash of certificate" alternative
no verification would be needed at all. Indeed under those circumstances
the encryption certificate need not be from a trusted authority or
indeed any authority at all. Alas not possible at present...

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

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Certificate Distribution Specification comments.
Date: Tue, 9 Jun 1998 15:06:45 -0700 
Sender: [email-masked]

Steve,

I put the wording in on the matching so that I could do something along the
lines of I use this certificate for signing and it contains my email name.
The certificate I want to use for encrytion does not have my email address.
Since I had done a "match" and it was signed by the matching certificate
then it seems to me that I should be able to accept the lack of match on the
encryption certificate.

I can understand what you are saying about always wanting to check this,
however I don't think this should be disallowed.  Do you really think this
is a big problem?

jim

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[email-masked]]
> Sent: Friday, June 05, 1998 3:04 PM
> To: [email-masked]
> Subject: Certificate Distribution Specification comments.
> 
> 
> This spec seems to cover most of the points. Many thanks to Jim for
> producing it.
> 
> A few comments:
> 
> "3.4  Signing Certificate
> 
>   1.   Verify that the SMimeCertificatePublish object contains
>     a valid signature and the certificate used to sign the
>     message can be validated.
>   2.   Does the certificate used to sign the
>     SMimeCertificatePublish object "match" the intended
>     recipient of the encryption object.  If so proceed to step 6
>     else step 3.
> .....
>   6.   Locate the encryption certificate using the
>     SMimeEncryptionKeyPreference attribute in the signed
>     attributes of the SMimeCertificatePublish object."
> 
> It appears that if the "match" occurs in step 2. then the
> SMIMEEncryptionKeyPreference certificate is not validated. IMHO the
> encryption certificate must always be validated.
> 
> Re the issue of multiple SignerInfos. I'm personally in favour of this
> because there may be times when several certificates need to be
> published for the same recipient. They may have different policies or
> indeed different algorithms: a sending agent can then decide which (if
> any) to use. IMHO this is best handled with a single
> SMimeCertificatePublish object to allow flexibility if the object is
> being distributed over HTTP/FTP and there is no technique to 
> obtain the
> "next object" if the one retrieved is not acceptable.
> 
> Steve.
> -- 
> Dr Stephen N. Henson.
> UK based freelance Cryptographic Consultant. For info see homepage.
> Homepage: http://www.drh-consultancy.demon.co.uk/
> Email: [email-masked]
> PGP key: via homepage.
> 
> 

From: "Curtin, William" <[email-masked]>
To: [email-masked]
Subject: Comments on certificate handling draft
Date: Wed, 3 Jun 1998 12:24:00 -0400 
Sender: [email-masked]

          Below are comments to the cert handling draft. Most of them 
          are editorial in nature. I really haven't been following 
          this draft so I may have made some improper assumptions. Use 
          them for what they're worth.
          
                                bill
          
          - clause 3.1 seemed to be placing quite a bit under the 
          heading of DN for Internet mail. I've made the following 
          assumptions: the section is really Using Internet Mail for 
          DN; the section was addressing using an e-mail address in 
          place of the Extension.subject DN; the section was 
          addressing how receiving agents handle using e-mail as a DN. 
          Below is recommended text. In it the Issuer and Subject 
          names were moved out of section 3.1 to the more generic 
          section 3.0, and added a clause that when using the email as 
          DN the Extension.subject field should be empty, 

          3. Distinguished Names in Certificates
          
          Issuer names MUST be populated (i.e. not an empty SEQUENCE) 
          in S/MIME-compliant v3 X.509 Certificates.
          
          Subject names MUST be populated in S/MIME-compliant v3 X.509 
          Certificates, unless identity information is present only in 
          the subjectAltName extension (see 4.4.3) in which case the 
          subject may contain an empty SEQUENCE. In the latter case 
          the subjectAltName extension MUST be marked as critical. 
          
          3.1 Using Internet Mail for Distinguished Names 
          
          End-entity certificates MAY contain an Internet mail address 
          as described in [RFC-822]. The address MUST be an 
          "addr-spec" as defined in Section 6.1 of that specification. 
           The email address SHOULD be in the subjectAltName 
          extension.
          
          When used as a subject identifier, email addresses SHOULD 
          NOT be in the subject distinguished name. The subject 
          distinguished name SHOULD instead contain an empty SEQUENCE.
          
          Receiving agents MUST recognize email addresses in the 
          certificate subjectAltName extension. While using email 
          addresses in the certificate subject field is not 
          recommended by this document, receiving agents MUST be able 
          to recognize email addresses in the subject Distinguished 
          Name field.
          
          Sending agents SHOULD make the address in the From or Sender 
          header in a mail message match an Internet mail address in 
          the signer's certificate. Receiving agents MUST check that 
          the address in the From or Sender header of a mail message 
          matches an Internet mail address in the signer's 
          certificate, if mail addresses are present in the 
          certificate. A receiving agent SHOULD provide some explicit 
          alternate processing of the message if this comparison 
          fails, which may be to display a message that shows the 
          recipient the addresses in the certificate or other 
          certificate details.
          
          - I thought that section 4.4 was a little wordy and 
          redundant. Below is recommended text which express the 
          following: changed "X.509 v3 standard" (never saw it 
          expressed like that); and the draft called out a " minimum 
          required set" of extensions but doesn't say what it is (I 
          made the assumption that it was the 5 extensions that the 
          agents were required to handle) and that although "minimum 
          required" would suggest a MUST the later definition of the 
          extensions suggested that it was a SHOULD. 
          
          4.4 X.509 Version 3 Certificate Extensions
          
          The X.509 standard [X.509] describes an extensible framework 
          in which the basic certificate information can be extended 
          and how such extensions can be used to control the process 
          of issuing and validating certificates. The PKIX Working 
          Group has ongoing efforts to identify and create extensions 
          which have value in particular certification environments. 
          As such, there is still a fair amount of profiling work to 
          be done before there is widespread agreement on which v3 
          extensions will be used. Further, there are active efforts 
          underway to issue X.509 v3 certificates for business 
          purposes. 
          
          At a minimum, the basicConstraints, keyUsage, 
          authorityKeyID, subjectKeyID, and the subjectAltNames X.509 
          v3 certificate extensions, defined in [X.509], SHOULD be 
          supported. Other X.509 v3 certificate extensions MAY also be 
          supported. Unless the extension is deemed critical for 
          correct interpretation of the associated certificate or 
          otherwise noted in this document, all extensions SHOULD be 
          marked as non-critical.
          
          Sending and receiving agents MUST correctly handle the v3 
          Basic Constraints Certificate Extension, the Key Usage 
          Certificate Extension, authorityKeyID, subjectKeyID, and the 
          subjectAltNames when they appear in end-user certificates. 
          Some mechanism SHOULD exist to handle the defined v3 
          certificate extensions when they appear in intermediate or 
          CA certificates.
          
          Unless otherwise specified in this document, interpretation 
          and syntax for all extensions MUST follow [KEYM].
          
          - clause 4.4.1 - 4.4.3: address 3 of the 5 recommended 
          extensions in more detail (i.e. basicConstraints, keyUsage, 
          and subjectAltNames) were the other two (authorityKeyID and 
          subjectKeyID) omitted for a reason? Recommend giving the 
          criticality of all of the extensions defined in these 
          sections in the same manner as 4.4.2.
          
          - clause 4.4.1: doesn't indicate whether the extension is 
          critical and one would assume based on earlier guidance in 
          the document that is should be non-critical (by default). 
          Recommendations from both X.509 (1997) and the PKIX profile 
          would seem to suggest that this should be a critical 
          extension. 

          -clause 4.4.3: suggest restating guidance on criticality of 
          subjectAltName expressed in section 3.1 here.

Date: Mon, 08 Jun 1998 13:39:00 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Certificate transport encoding question
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter:

PKCS#7 version 1.5 does not constrain the ordering of the certificates, so
the recipient must be prepared for the worst possible haphazard ordering.
CMS has a backward comparability goal, so we get this feature too.

Russ

At 05:10 AM 6/6/98 +0000, Peter Gutmann wrote:
>I've got two questions about certificate encoding in transport formats, I've 
>sent them to both lists since they're a bit nonspecific.
> 
>The first one concerns the order of certs in a cert chain.  Looking at the
CMS 
>spec, it says that the SET OF Certificate should contain chains from the
root 
>down to each required subject, but doesn't give any explicit ordering.  An 
>ASN.1 SET is inherently unordered, but is there any recommended, consistent 
>way to encode a cert chain, or do you just add them in whatever order you
feel 
>like?  So far I've seen them ordered from subject to root, from root to 
>subject, and pseudorandomly (using the DER SET encoding rules)... all of
these 
>are equally valid, it just seems messy to have any number of possible 
>orderings present.
> 
>The second one concerns something which isn't explicitly addressed by any 
>standard but which it might be worth covering somewhere.  When a certificate 
>or cert-related object (cert request, CRL) is base64-encoded, there are
again 
>a large number of different interpretations on what delimiters to use around 
>the base64 data.  I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST, 
>BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something 
>else :-).  Alongside these are various creative mutations (extra blank
lines, 
>name:value pairs a la PGP, and other oddities).  It's probably a good idea
to 
>specify a set format for these as well and attach them to some existing 
>standard.  If there's a need for them I'll put together a paragraph or two 
>defining the exact format.
> 
>Peter.
> 

Date: Mon, 08 Jun 1998 10:05:10 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: WG LAST CALL for ESS, MSG and CERT
Cc: [email-masked]
Sender: [email-masked]

S/MIME WG Participants:

These three documents seem to be in very good shape.  I have previously
announced last Call for ESS, and a new version has been released to
incorporate the comments.  I am now announcing Last Call for MSG and CERT.

None of these documents will be progressed to the IESG until CMS has
completed Last Call.  At that time, CMS, ESS, MSG, and CERT will be
forwrded to the IESG together.

Russ
S/MIME WG Chair

Date: Sat, 06 Jun 1998 01:15:03 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Re: Certificate Distribution Specification comments.
Sender: [email-masked]

I've just had another thought:

"3.4  Signing Certificate

  The SMimeCertificatePublish object MUST be signed by a
  signing certificate associated with the end-entity, or a
  signing certificate of a CA in the validation path of the
  encryption certificate."

I believe one requirement is that if the keyUsage extension is present
in the signing certificate then the digitalSignature bit must be set.

In the case of a CA certificate this may well not be the case and indeed
several CAs currently do not set the digitalSignature bit. 

Perhaps the easiest solution is not to enforce this criteria for the
purpose of a CA signed SMIMECertificatePublish object.

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

Date: Fri, 05 Jun 1998 23:04:20 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: Certificate Distribution Specification comments.
Sender: [email-masked]

This spec seems to cover most of the points. Many thanks to Jim for
producing it.

A few comments:

"3.4  Signing Certificate

  1.   Verify that the SMimeCertificatePublish object contains
    a valid signature and the certificate used to sign the
    message can be validated.
  2.   Does the certificate used to sign the
    SMimeCertificatePublish object "match" the intended
    recipient of the encryption object.  If so proceed to step 6
    else step 3.
.....
  6.   Locate the encryption certificate using the
    SMimeEncryptionKeyPreference attribute in the signed
    attributes of the SMimeCertificatePublish object."

It appears that if the "match" occurs in step 2. then the
SMIMEEncryptionKeyPreference certificate is not validated. IMHO the
encryption certificate must always be validated.

Re the issue of multiple SignerInfos. I'm personally in favour of this
because there may be times when several certificates need to be
published for the same recipient. They may have different policies or
indeed different algorithms: a sending agent can then decide which (if
any) to use. IMHO this is best handled with a single
SMimeCertificatePublish object to allow flexibility if the object is
being distributed over HTTP/FTP and there is no technique to obtain the
"next object" if the one retrieved is not acceptable.

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

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Certificate transport encoding question
Reply-To: [email-masked]
Date: Sat, 6 Jun 1998 05:10:27 (NZST)
Sender: [email-masked]

I've got two questions about certificate encoding in transport formats, I've 
sent them to both lists since they're a bit nonspecific.
 
The first one concerns the order of certs in a cert chain.  Looking at the CMS 
spec, it says that the SET OF Certificate should contain chains from the root 
down to each required subject, but doesn't give any explicit ordering.  An 
ASN.1 SET is inherently unordered, but is there any recommended, consistent 
way to encode a cert chain, or do you just add them in whatever order you feel 
like?  So far I've seen them ordered from subject to root, from root to 
subject, and pseudorandomly (using the DER SET encoding rules)... all of these 
are equally valid, it just seems messy to have any number of possible 
orderings present.
 
The second one concerns something which isn't explicitly addressed by any 
standard but which it might be worth covering somewhere.  When a certificate 
or cert-related object (cert request, CRL) is base64-encoded, there are again 
a large number of different interpretations on what delimiters to use around 
the base64 data.  I've seen BEGIN CERTIFICATE, BEGIN CERTIFICATE REQUEST, 
BEGIN NEW CERTIFICATE REQUEST, BEGIN PGP MESS...no hang on, that's something 
else :-).  Alongside these are various creative mutations (extra blank lines, 
name:value pairs a la PGP, and other oddities).  It's probably a good idea to 
specify a set format for these as well and attach them to some existing 
standard.  If there's a need for them I'll put together a paragraph or two 
defining the exact format.
 
Peter.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-x942-00.txt
Date: Wed, 03 Jun 1998 10:24:52 -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		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-00.txt
	Pages		: 5
	Date		: 02-Jun-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. In addition, a standard
   group that meets the X9.42 requirements 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-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-x942-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: 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-00.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-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ess-06.txt
Date: Wed, 03 Jun 1998 10:23:37 -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-06.txt
	Pages		: 31
	Date		: 02-Jun-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-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-ess-06.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-06.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-06.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: X9.42 draft
Date: Tue, 02 Jun 1998 12:12:52 -0700
From: EKR <[email-masked]>
Sender: [email-masked]

I've submitted a draft of an X9.42-derived Key Agreement 
specification to Internet-Drafts. It should be out in a couple
of days. Here's a prerelease.

There are a couple of problems known with this draft:
It's missing both examples and the default group.
I'm not sure if the RC2 keylength is correctly dealt with.
RC2 is a variable effective keylength cipher with a variable
length key.  I.e. you can imagine calling RC2 like this:

RC2Init(char *key, int key_length, int effective_key_length)

So, we need to decide how long the keys are for RC2-40.
(We probably should use 16-byte long, 128 bit effective
for RC2-128).

Comments and questions welcomed,
-Ekr

                                                            E. Rescorla
INTERNET-DRAFT                                     Terisa Systems, Inc.
<draft-ietf-smime-x942-00.txt>         June 1998 (Expires December 1998)

                  Diffie-Hellman Key Agreement Method

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   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. In addition, a standard
   group that meets the X9.42 requirements is provided.

TODO

   Redo the examples to match the new algorithm for computing K.  Actu-
   ally generate the group.

1.  Introduction

   In [DH76] Diffie and Hellman describe a means for two parties to
   agree upon a shared secret in such a way that the secret will be una-
   vailable to eavesdroppers. This secret may then be converted into
   cryptographic keying material for other (symmetric) algorithms.  A
   large number of minor variants of this process exist. This document
   describes one such variant, based on the ANSI X9.42 specification.

Rescorla                                                         [Page 1]Internet-Draft    Diffie-Hellman Key Agreement Method     

1.1.  Discussion of this Draft

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

1.2.  Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [RFC2119].

2.  Overview Of Method

   Diffie-Hellman key agreement requires that both the sender and reci-
   pient of a message have key pairs. By combining one's private key and
   the other party's public key, both parties can compute the same
   shared secret number. This number can then be converted into crypto-
   graphic keying material. That keying material is typically used as a
   key encryption key (KEK) to encrypt (wrap) a key (a message encryp-
   tion key -- MEK) which is in turn used to encrypt the message data.

2.1.  Key Agreement

   The first stage of the key agreement process is to compute a shared
   secret number ZZ (which will be constant for any pair of Diffie-
   Hellman keys). ZZ is then converted into a shared symmetric key. Note
   that the symmetric key will be different for each key agreement, due
   to the introduction of public random components.

2.1.1.  Generation of ZZ

   X9.42 defines that the shared secret ZZ is generated as follows:

           ZZ = g ^ (xb * xa) (mod p)

   Note that the individual parties actually perform the computations:

           ZZ = yb ^ xa    (mod p) = ya ^ xb  (mod p)

   where ^ denotes exponentiation
         ya is party a's public key; ya = g ^ xa (mod p)
         yb is party b's public key; yb = g ^ xb (mod p)
         xa is party a's private key
         xb is party b's private key
         p is a large prime

Rescorla                                                         [Page 2]Internet-Draft    Diffie-Hellman Key Agreement Method     

         g is a generator for the integer group specified by p.
         (See Section 2.2 for criteria for keys and parameters)

   In CMS, the recipient's key is identified by the CMS RecipientIden-
   tifier, which points to the recipient's certificate.  The sender's
   key is identified using the OriginatorIdentifier field, either by
   reference to the sender's certificate or by inline inclusion of a
   key.

   Senders SHOULD verify the receiver's public key using the procedure
   of Section 2.1.5 before generating shared secrets. This check MAY be
   omitted if the CA which certified the key performs this check. Simi-
   larly, recipient's SHOULD verify the sender's public key before
   decrypting messages.

2.1.2.  Generation of Keying Material

   X9.42 provides an algorithm for generating an essentially arbitrary
   amount of keying material from ZZ. Our algorithm is derived from that
   algorithm by mandating some optional fields and omitting others.

           KM = H ( ZZ || OtherInfo)

   H is the message digest function SHA-1 [FIPS-180] ZZ is the shared
   key computed in Section 2.1.1 OtherInfo is the DER encoding of the
   following structure:

           OtherInfo ::= SEQUENCE {
             keyInfo KeySpecificInfo,
             pubInfo [2] OCTET STRING OPTIONAL,
           }

           KeySpecificInfo ::= SEQUENCE {
             algorithm OBJECT IDENTIFIER,
             counter OCTET STRING SIZE (4..4) }

   algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which
     this KEK will be used.
   counter is a 32 bit number, represented in network byte order.
   Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex)
   pubInfo is a random string provided by the sender. In CMS, it is provided
   as a parameter in the UserKeyingMaterial field (a 512 bit byte string).

   Note that the only source of secret entropy in this computation is
   ZZ, so the security of this data is limited to the size of ZZ, even
   if more data than ZZ is generated. However, since pubInfo is dif-
   ferent for each message, a different KEK will be generated for each

Rescorla                                                         [Page 3]Internet-Draft    Diffie-Hellman Key Agreement Method     

   message.

2.1.3.  KEK Computation

   Each key encryption algorithm requires a specific size key (n). The
   KEK is generated by mapping the left n-most bytes of KM onto the key.
   Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of
   keying material, the algorithm is only run once, with a counter value
   of 1.  The first 64 bits of the output are parity adjusted and con-
   verted into a DES key.  For 3DES, which requires 192 bits of keying
   material, the algorithm must be run twice, once with a counter value
   of 1 (to generate K1', K2', and the first 32 bits of K3') and once
   with a counter value of 2 (to generate the last 32 bits of K3).
   K1',K2' and K3' are then parity adjusted to generate the 3 DES keys
   K1,K2 and K3.

2.1.4.  Keylengths for common algorithms

   Some common key encryption algorithms have KEKs of the following
   lengths.

           DES-ECB         64 bits
           3DES-EDE-ECB    192 bits
           RC2 (all)       256 bits

2.1.5.  Public Key Validation

   The following algorithm may be used to validate received public keys.

           1. Verify that y lies within the interval [2,p-1]. If it does not,
           the key is invalid.
           2. Compute y^q (mod p). If the result == 1, the key is valid.
           Otherwise the key is invalid.

2.1.6.  Example

   TBD

2.2.  Key and Parameter Requirements

   X9.42 requires that the group parameters be of the form p=jq + 1
   where q is a large prime of length m and j>=2. An algorithm for gen-
   erating primes of this form can be found in FIPS PUB 186-1[DSS] and
   ANSI, X9.30-1 1996 [X930], as well as in [X942].

   X9.42 requires that the private key x be in the interval [2^(m-1) +

Rescorla                                                         [Page 4]Internet-Draft    Diffie-Hellman Key Agreement Method     

   1, (q - 2)]. x should be randomly generated in this interval. y is
   then computed by calculating g^x (mod p).  To comply with this draft,
   m MUST be >=128, (consequently, q and x MUST each be at least 128
   bits long). When symmetric ciphers stronger than DES are to be used,
   a larger m may be advisable.

2.2.1.  Common Group

   This standard specifies a common IETF DH group that satisfies the
   above parameters. Standards incorporating this key exchange method
   may choose to require support of this group.  TBD

Acknowledgements

   The Key Agreement method described in this document is based on work
   done by the ANSI X9F1 working group. The author wishes to extend his
   thanks for their assistance.

   The author also wishes to thank Russ Housley, Brian Korver, Mark
   Schertler, and Peter Yee for their expert advice and review.

References
   [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-05.txt.

   [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB)
        46-1, Data Encryption Standard, Reaffirmed 1988 January 22
        (supersedes FIPS PUB 46, 1977 January 15).

   [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB)
        81, DES Modes of Operation, 1980 December 2.

   [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB)
       180-1, "Secure Hash Standard", 1995 April 17.

   [X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms",
       ANSI draft, 1998.

Security Considerations

   All the security in this system is provided by the secrecy of the
   private keying material. If either sender or recipient private keys
   are disclosed, all messages sent or received using that key are
   compromised. Similarly, loss of the private key results in an inabil-
   ity to read messages sent using that key.

Author's Address

Rescorla                                                         [Page 5]Internet-Draft    Diffie-Hellman Key Agreement Method     

Eric Rescorla <[email-masked]>
Terisa Systems, Inc.
4984 El Camino Real
Los Altos, CA 94022
Phone: (650) 919-1753

Rescorla                                                         [Page 6]Internet-Draft    Diffie-Hellman Key Agreement Method     

                           Table of Contents

1. Introduction ...................................................    1

1.1. Discussion of this Draft .....................................    2

1.2. Requirements Terminology .....................................    2

2. Overview Of Method .............................................    2

2.1. Key Agreement ................................................    2

2.1.1. Generation of ZZ ...........................................    2

2.1.2. Generation of Keying Material ..............................    3

2.1.3. KEK Computation ............................................    4

2.1.4. Keylengths for common algorithms ...........................    4

2.1.5. Public Key Validation ......................................    4

2.1.6. Example ....................................................    4

2.2. Key and Parameter Requirements ...............................    4

2.2.1. Common Group ...............................................    5

2.2.1. Acknowledgements ...........................................    5

2.2.1. References .................................................    5

Security Considerations ...........................................    5

Author's Address ..................................................    5

Date: 1 Jun 1998 22:35:04 -0000
From: "Niels Brinch" <[email-masked]>
Subject: Cool page
To: [email-masked]
Sender: [email-masked]

Hi all, I just found this cool page. They call them self "Surfree". I do not believe this, it is some guy, who have gathered a lot of information from the whole web in one place, so that it is like a search engine where you don't have to search. That was also how I got to this place. When I was here, looking through some messages, I just thought I would pass you a note about that great web page. I know that the subject of the page is not exactly the same, but since it is a good page, and since I think I owe it to you, I thought it was ok. The address is: http://surfree.cjb.net

Bye, and sorry I took your time with this letter.

Date: Mon, 1 Jun 1998 18:08:08 -0400
To: <[email-masked]>
From: [email-masked] (John Pawling)
Subject: RE: ESS EquivalentLabel Proposal
Sender: [email-masked]

All,

I agree with the concept of Paul's text that he proposes to add to the
EquivalentLabels attribute proposal.  I have a few wordsmithing
recommendations included:

"Before processing an EquivalentLabels attribute, the receiving agent MUST
verify the signature of the SignerInfo which covers the EquivalentLabels
attribute. A receiving agent MUST NOT process an EquivalentLabels attribute
for which the signature has not been verified.  A receiving agent MUST NOT
act on an EquivalentLabels attribute which is not signed by an entity that
is trusted to specify equivalence mappings.  The process by which the
receiving agent determines if an entity is trusted to specify equivalence
mappings is a matter of local policy.  A receiving agent SHOULD process the
ESSSecurityLabel attribute before processing the EquivalentLabels attribute.
If the security policy in the ESSSecurityLabel attribute is understood by
the receiving agent, it SHOULD process that label and ignore the
equivalentLabels attribute."

- John Pawling

Paul's words:
>Sorry, I thought that was obvious. A recipient would have a list of trusted
>mappers. The new addition now reads:
>
>When processing an EquivalentLabels attribute, the receiving agent MUST
>validate the signature onthe EquivalentLabels to determine if there are
>additional security labels it wishes to use. A receiving agent MUST NOT act
>on EquivalentLabels for which the signature could not be validated or
>EquivalentLabels not signed by entities trusted to add or change access
>policies; determining who is allowed to specify equivalence mappings is a
>local policy. A receiving agent SHOULD process the ESSSecurityLabel before
>processing the EquivalentLabels. If the policy in the ESSSecurityLabel is
>understood by the receiving agent, it SHOULD process that label and ignore
>the EquivalentLabels.

Date: Mon, 01 Jun 1998 15:54:21 -0400
To: Francois Rousseau <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: CMS-05 Comments
Cc: [email-masked]
Sender: [email-masked]

Francois:

>1) Sec 6.2.3, "mlKeyId" was replaced by "mlid".
Fixed.

>2) Sec 9.1, the definition for the originatorInfo field indicates that it
>may contain user keying material (UKMs), as defined in Section 6.1.
>However, UKMs are not contained in the originatorInfo field, but instead
>are contained in the KeyAgreeRecipientInfo field defined in Sec 6.2.2.
Fixed.

>3) Sec 9.1, the last sentence indicates that useful attribute types are
>defined in Section 11. You should probably indicate that of the attributes
>defined in Section 11, none currently apply for unauthenticatedAttributes. 
Fixed.

Russ

From: "Don Johnson" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 1 Jun 1998 10:12:29 -0400
Subject: Re: CMS Key Wrapping
Sender: [email-masked]

--0__=gaBOUW2EfujCLBMOjDxPkj4P18CETxt9MLUwyK6Q2wKH8RfLBync5gUw
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline

Russ,

16 bits would be considered very weak for integrity even if it was the
output of a crypto one-way function, which is not what you propose.  If you
want strong integrity checking, you should consider going to at least 64
bits, whatever what believed to resist exhaustion attacks.  I suppose you
are also counting on the parity bits, parity bits are a very weak integrity
function.

For an example of an attack off the top of my heed, one could merely
replicate one of the encrypted TDES keys 3 times, break the 16 bit checksum
by exhaustion and then break the TDES single length key by exhaustion.
Done 3 times, this totally breaks the TDES key is work essentially
proportional to that of a single length DES key.  There might be some other
reason why this attack is not feasible in what you are doing, I cannot say.

You mention use of a 32 bit random salt.  This might imply you want the
same key going to different entities to not be able to be determined.  Is
this true?  Why the salt?  If you do not need a salt, then you could extend
the size of the integrity value.  If you do need a salt, then you need to
determine what the appropriate size is, for a 32 bit random salt one
expects a collision in 2**16 samples, so one should not use this method to
send to  64 thousand entities and expect a viewer to not be able to tell
that 2 entites were getting the same key.

Typo: hexadecimal.
Don J.

Russ Housley <[email-masked]> on 05/29/98 03:26:46 PM

To:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: Don Johnson/Certicom)
Subject:  CMS Key Wrapping

All:

S/MIME 3 requires a function to encrypt one Triple-DES key in another.
--0__=gaBOUW2EfujCLBMOjDxPkj4P18CETxt9MLUwyK6Q2wKH8RfLBync5gUw
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

=A0 I
posted a proposed method several weeks ago, and I got a fair amount of
feedback.=A0 The most common concern was the lack of flexibility.=A0 ma=
y people
prefered a technique that was algorithm independent.=A0 Below, I propos=
e an
algorithm independent function, and I am writing to request review of
that function.=A0 I propose a function that provides confidentiality an=
d
integrity.

As background, here is refresher about how S/MIME 3 will use the functi=
on.
S/MIME 3 locally generates a random content-encryption key.=A0 As the n=
ame
implies, this key will be used to encrypt the message content.=A0 Then,=

Diffie-Hellman will be used to generate a pairwise key-encryption key w=
ith
each
message recipient, and the content-encryption key will be encrypted und=
er
the
pairwise key-encryption key.

The blocksize of the key-encryption algorithm can be determined from th=
e
CMS
KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of=
 the
content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be=
 an
exception here; the same identifer is used for both 2-key and 3-key Tri=
ple
DES.  This is probably easily handled by always wrapping three keyes, e=
ven
if
the first and third keys match.

Please do not propose improvements that are covered by any issued or
pending
patents.

Thanks for your assistance,
=A0 Russ

- - - - - - - - - -

KEY CHECKSUM ALGORITHM:

1.=A0 Initialize two 16 bit integers, sum1 and sum2, to zero.
2.=A0 Loop through the octets of the content-encryption key, most
=A0=A0=A0 significant octet to least significant octet.
=A0=A0=A0 2a.=A0 Create a 16 bit integer, called temp, by concatenating=

=A0=A0=A0=A0=A0=A0=A0=A0 8 zero bits and the key octet.
=A0=A0=A0 2b.=A0 sum1 =3D sum1 + temp.
=A0=A0=A0 2c.=A0 sum2 =3D sum2 + sum1.
3.=A0 Use sum2 as the checksum value.

KEY WRAP ALGORITHM:

1.=A0 Adjust the parity bits on DES and Triple-DES keys.
2.=A0 Compute a 16-bit key checksum value on the content-encryption
=A0=A0=A0 key as described above.
3.=A0 Generate a 4-octet random salt value.
4.=A0 Concatenate the salt, content-encryption key, and key
=A0=A0=A0 checksum value.
5.=A0 Generate the number of pad octets necessary to make the
=A0=A0=A0 result a multiple of the key-encryption algorithm block
=A0=A0=A0 size, then append them to the result.
6.=A0 Encrypt the result with the key-encryption key.=A0 If the
=A0=A0=A0 algorithm requires an IV, use an IV with each octet equal
=A0=A0=A0 to 'A5' hexidecimal.

KEY UNWRAP ALGORITHM:

1.=A0 Decrypt the wrapped ciphertext using the key-encryption key.
=A0=A0=A0 If the algorithm requires an IV, use an IV with each octet
=A0=A0=A0 equal to 'A5' hexidecimal.
2.=A0 Check the parity of DES and Triple-DES keys.=A0 If any is
=A0=A0=A0 incorrect then there is an error.
3.=A0 Compute a 16-bit key checksum value on the content-encryption
=A0=A0=A0 key as described above.
4.=A0 If computed key checksum value does not match the decrypted
=A0=A0=A0 key checksum value, then there is an error.

=

--0__=gaBOUW2EfujCLBMOjDxPkj4P18CETxt9MLUwyK6Q2wKH8RfLBync5gUw--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certdist-00.txt
Date: Mon, 01 Jun 1998 09:11: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		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-00.txt
	Pages		: 6
	Date		: 29-May-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 <ietf-smime-
  [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-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-certdist-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: 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-00.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-00.txt

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

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

--OtherAccess--

--NextPart--