Re: I-D ACTION:draft-ietf-smime-ess-10.txt

[Andrew Farrell <[e-mail]>]

Wahey! I'm famous:)

I'm still not clear on how 4.2.3.2 matches 4.2, though. Is it the
intention that the "outermost SignedData layer" going into this process
be the "outer" signedData layer from 4.2? That is, should the search for
the outer layer already be done when we start this processing?

If it isn't, what the flowchart does to Example 5 _now_ is pass it
straight through 1->2->4 and produces S4(S3(S2(E1(S1(Original
Content)))))

What I was saying earlier was that if the outer layer is signed without
a mlExpansionHistory, then we must delve further in, but we must also
keep a copy of the original, because if we don't find an "outer" signed
layer, we have to sign the original. In a flowchart where the only
"state" is the current layer, I don't see how that's possible.

Andrew.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA02252 for ietf-smime-bks; Thu, 31 Dec 1998 21:33:41 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA02248 for <[e-mail]>; Thu, 31 Dec 1998 21:33:38 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id SAA25411; Fri, 1 Jan 1999 18:32:38 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91516875827663>; Fri, 1 Jan 1999 18:32:38 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
Cc: [e-mail]
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 1 Jan 1999 18:32:38 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I believe you've misunderstood the attack. It is indeed a problem for CMS 
>(though likely not for S/MIME). Let's deal with the RSA case for a second: 
>The purpose of the attack is to recover the MEK given a wrapped MEK in a 
>known public key. The attack depends on the attacker being able to 
>differentiate a message which when decrypted yields an badly formatted (in 
>the PKCS-1) sense message from a message which is correctly formatted but 
>(presumably) yields a bad message encryption key.
 
It also depended on an implementation bug in which some SSL implementations 
wouldn't check the PKCS #1 padding properly, stopping at the '00 02' and 
returning an error specific to this case (these implementations were 
identified in the CERT advisory and have now been fixed).
 
There are two ways to determine just how serious this is as a problem.  The 
first one is to look at how it affects existing implementations: Currently 
every S/MIME implementation, PGP, and countless other vendor-specific 
protocols use PKCS #1 padding.  Somehow, the entire planet has managed to get 
by in the presence of the "weakness", which would indicate that it's not much 
of a practical threat.
 
The second approach is to see just what it would take to implement this attack 
on CMS (not S/MIME, but anything involving CMS).  For this analysis I'll make 
several assumptions:
 
1. The implementor has managed to design a protocol which will accept 
   arbitrary numbers of chosen-ciphertext messages and reply to each one with 
   an exact indication of how the decrypt failed, leaking information about
   the decrypted message to an attacker.  This is a fairly remarkable feat, 
   but let's say, just for arguments sake, that someone did do this.
2. The implementor and any third-party reviewers have somehow missed the CERT 
   advisory, RSA labs bulletin, publicity about the attack, and whatever else 
   is around there which tells people about the problem and (very simple) fix.
3. The PKCS #1 implementation being used is correct (that is, it doesn't have 
   the implementation bug which was found and fixed in the SSL implementations).
4. A typical query+response takes half a second (this means opening a 
   connecting, generating a chosen-ciphertext message, transmitting it, having 
   the victim decode and try to decrypt it, generating a response, wrapping up 
   an exact indication of the decryption error it encountered, and sending it 
   back to the attacker).
 
OK, so we have a server which does all of the above sitting there ready for 
attack.  With a correct PKCS #1 implementation (that is, it checks the padding 
as per the PKCS #1 spec), the complexity is approximately 1 million attempts 
(for the 00 02 padding) x 20 (for the second 00 before the MEK) x 2 (for the 
minimum of 8 nonzero bytes), or 40 million attempts (the 1 million attempts 
requires the presence of the SSL implementation bug mentioned above).
 
This requires just under 8 months of CPU time to perform, after which you've 
recovered a single MEK.
 
I would suggest that anyone who doesn't notice that their server is under 
continuous attack for 8 solid months has more than simple crypto problems to 
worry about.
 
>Note that the attack does NOT necessarily require return receipt or even 
>accurate error reporting if it's being used in an interactive protocol. If 
>the message is long, you may be able to differentiate these two error tpes 
>through timing analysis. 
 
This will slow things down even further, because you need to wait seconds 
(minutes?) for each response.  In this case you'd need to continously attack a 
server for years to recover a single MEK.
 
>>As a security threat, I'd say this rates somewhere down with "Router hit by
>>meteorite", "Computer trampled by stampeding water buffalo", "Hard drive
>>kidnapped by space aliens", and similar FUD.
>
>I believe this estimate is unjustifiably optimistic.
 
Given the above analysis I'll let list members decide how realistic this is or 
not.  However, I'm also prepared to put my money where my mouth is: If you 
like, I'll set up a process on a server which runs some protocol which is 
specificaly custom-designed to provide this "weakness" for you, and you can 
try and recover a MEK with it.  If you can recover a single MEK before 
whatever Y2K-induced armageddon is supposed to swallow us all occurs, I'll 
admit I was wrong, and that it is a practical weakness.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27501 for ietf-smime-bks; Thu, 31 Dec 1998 08:18:37 -0800 (PST)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27497 for <[e-mail]>; Thu, 31 Dec 1998 08:18:35 -0800 (PST)
Received: from cougar.baltimore.ie ([e-mail] [194.125.215.12]) by puma.baltimore.ie (8.8.5/8.8.5) with ESMTP id QAA03944 for <[e-mail]>; Thu, 31 Dec 1998 16:18:49 GMT
Received: from cougar.baltimore.ie (afarrell@localhost [127.0.0.1]) by cougar.baltimore.ie (8.8.5/8.8.5) with ESMTP id QAA15207 for <[e-mail]>; Thu, 31 Dec 1998 16:18:48 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-ess-10.txt 
In-Reply-To: Your message of "Tue, 22 Dec 1998 16:08:52 EST." <[e-mail]> 
Date: Thu, 31 Dec 1998 16:18:48 +0000
From: Andrew Farrell <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wahey! I'm famous:)

I'm still not clear on how 4.2.3.2 matches 4.2, though. Is it the
intention that the "outermost SignedData layer" going into this process
be the "outer" signedData layer from 4.2? That is, should the search for
the outer layer already be done when we start this processing?

If it isn't, what the flowchart does to Example 5 _now_ is pass it
straight through 1->2->4 and produces S4(S3(S2(E1(S1(Original
Content)))))

What I was saying earlier was that if the outer layer is signed without
a mlExpansionHistory, then we must delve further in, but we must also
keep a copy of the original, because if we don't find an "outer" signed
layer, we have to sign the original. In a flowchart where the only
"state" is the current layer, I don't see how that's possible.

Andrew.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA18669 for ietf-smime-bks; Tue, 29 Dec 1998 23:27:19 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA18665 for <[e-mail]>; Tue, 29 Dec 1998 23:27:17 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id XAA19924; Tue, 29 Dec 1998 23:27:54 -0800 (PST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 29 Dec 1998 23:27:53 -0800
In-Reply-To: [e-mail]'s message of "Fri, 25 Dec 1998 21:32:54 (NZDT)"
Message-ID: <[e-mail]>
Lines: 109
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] (Peter Gutmann) writes:

> >I'm referring to the Bleichenbacher attack on RSA key transport, aka the 
> >"Million Message Attack." I don't believe it's known that this cannot be 
> >extended to ElGamal. I prefer not to take chances.
>  
> For those of you who have been sitting on the sidelines watching the messages 
> whooshing past overhead, it looks like we were talking about two different 
> "Bleichenbacher attacks" in the last few messages.  The one I was thinking 
> about was from 1996, applies only to Elgamal signatures (not encryption), and 
> even then only works if a badly chosen key is used.  This attack doesn't apply 
> to Elgamal key wrapping.
>  
> The one Eric was thinking of was from 1998.  In order to work for the Elgamal 
> key wrapping I've proposed for CMS, this attack requires that an attacker send 
> you around a million pieces of CMS encrypted email with attached receipt 
> requests, that you respond with a million receipts indicating to the attacker 
> the exact details of why the decrypt failed, that you reuse the same 
> per-message key for each of those million messages, and that you (rather than 
> the attacker) know this per-message key.
>  
> Now maybe I'm being a bit optimistic here, but I do think that claiming this 
> is a weakness is a pretty silly.  First of all you need to assume that an 
> attacker can somehow send you a million pieces of email without you noticing 
> and without it getting stopped by spam blockers.  Your own software then has 
> to try to decrypt each of the one million pieces of email, find that it can't, 
> and send out a receipt to the sender containing an indication of exactly how 
> the decryption failed (this isn't possible even if you wanted to do it, 
> although who knows what the Receipt Notification WG have been working on 
> recently).  Finally, the whole attack only works if you reuse cryptovariables 
> - it would work nicely if you use something like the ES-DH cached values which 
> Eric mentioned in a previous message, but not against Elgamal key wrapping.  
> This is why the CERT advisory on this problem specifically points out "This 
> vulnerability does not affect S/MIME or SET".
>
I believe you've misunderstood the attack. It is indeed a problem
for CMS (though likely not for S/MIME). Let's deal with the RSA case
for a second:
The purpose of the attack is to recover the MEK given a wrapped MEK
in a known public key.
The attack depends on the attacker being able to differentiate a 
message which when decrypted yields an badly formatted (in the PKCS-1)
sense message from a message which is correctly formatted but
(presumably) yields a bad message encryption key. 

Remember, PKCS-1 padding is 00 02 [random nonzero bytes] 00 MEK

So, if the attacker can determine whether a candidate message decryptes
to 00 02  <garbage> or XX XX <garbage> where XX XX is something other
than 00 02, he is able to mount this attack. When I say determine,
what I mean is that he can get the recipient to tell him.

So, the attacker takes message M with a wrapped MEK (W) off the wire and
generates a new message M' with a modified W (W') which s otherwise
the same. He sends it to the recipient and waits for the error response.
Now, the recipient's decryption algorithm usually looks like this:

RSA Unwrap
Check PKCS-1 padding. (Case 1) If bad return an error.
Decrypt the message. 
Check the message integrity (case 2) If bad return an error.

If the attacker can distinguish between case 1 and case 2, he can
mount an adaptive chosen ciphertext attack, generating successive 
W's and eventually recover the wrapped MEK. This takes a long time
like a million messages. However, it's quite feasible for SSL.

You raise several issues which need to be considered:
1. Does this apply to S/MIME? Probably not. As you indicate, it's hard
to believe that someone wouldn't notice getting a million probe
messages. However, as I said before, CMS does not apply only to
S/MIME, and it's important to get it right for automated applications
where this could be a problem.  

Incidentally, while it's true that this attack does not apply to SET,
that's BECAUSE SET uses OAEP. If SET used PKCS-1, it would be
vulnerable.

Note that the attack does NOT necessarily require return receipt or even 
accurate error reporting if it's being used in an interactive
protocol. If the message is long, you may be able to differentiate
these two error tpes through timing analysis. However, interactive
protocols might well use error reporting mechanisms which would
reveal this sort of difference.

2. Does this attack apply to ES/SS-DH. No. There's no block formatting
in X9.42. In fact, there's no public key wrapped key at all. Rather,
the KEK is implied by the DH pairs. And since there's a checksum
on MEK unwrapping that fails with a probability of 2^64/1 if the 
wrapped MEK has been tampered with, this attack is impractical.

3. Does this attack work on ElGamal? I don't know. The only cryptovaribale
it depends on being reused is the recipient's key pair, which
would be the case with both ES-DH and ElGamal, so it's not
inconceivable that it would work.

The broad outlines of such an attack would be the same, however. You'd
generate successive W's and examine the server's response. 

> As a security threat, I'd say this rates somewhere down with "Router hit by 
> meteorite", "Computer trampled by stampeding water buffalo", "Hard drive 
> kidnapped by space aliens", and similar FUD.
I believe this estimate is unjustifiably optimistic.

-Ekr


-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA27813 for ietf-smime-bks; Tue, 29 Dec 1998 18:05:32 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA27805; Tue, 29 Dec 1998 18:03:57 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 29 Dec 1998 18:03:13 -0800
To: gau <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: SFL(snacc) can compile the ASN.1 code of pkcs#7 ?
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The proper place to talk about problems with the SFL is on the
"[e-mail]" mailing list, not the "[e-mail]" mailing list.
I know the two addresses look alike, but I tried to disambiguate them as
much as I could.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27695 for ietf-smime-bks; Tue, 29 Dec 1998 17:46:23 -0800 (PST)
Received: from crab.ccl.itri.org.tw (crab.ccl.itri.org.tw [140.96.83.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27691 for <[e-mail]>; Tue, 29 Dec 1998 17:46:20 -0800 (PST)
Received: from pc083070.ccl.itri.org.tw (pc083070.ccl.itri.org.tw [140.96.83.70]) by crab.ccl.itri.org.tw (8.7.1/8.6.12) with SMTP id JAA04067 for <[e-mail]>; Wed, 30 Dec 1998 09:40:51 +0800 (CST)
Received: by pc083070.ccl.itri.org.tw with Microsoft Mail id <[e-mail]>; Wed, 30 Dec 1998 09:45:35 +0800
Message-ID: <[e-mail]>
From: gau <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: SFL(snacc) can compile the ASN.1 code of pkcs#7 ?
Date: Wed, 30 Dec 1998 09:45:34 +0800
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,
We are working with pkcs#7, and we need ASN.1 en/decode function.
We use SFL(snacc) to compile the ASN.1 code of pkcs#7, but it tell us
that it do not know CLASS  the key word.
Can you tell us how overcome the problem?
Many sincere thanks and kind regards,
MIN-JEA GAU
[e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24647 for ietf-smime-bks; Tue, 29 Dec 1998 10:49:41 -0800 (PST)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA24643 for <[e-mail]>; Tue, 29 Dec 1998 10:49:40 -0800 (PST)
Received: (qmail 28583 invoked from network); 29 Dec 1998 18:49:48 -0000
Received: from userp719.uk.uudial.com (HELO GK-Acer) (193.149.93.210) by smtp.dial.pipex.com with SMTP; 29 Dec 1998 18:49:48 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 29 Dec 1998 19:52:22 +0000
To: [e-mail]
From: Graham Klyne <[e-mail]>
Subject: Re: Some comments on the use of DH in S/MIME
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 21:32 25/12/98, Peter Gutmann wrote:

I am not going to comment on the cryptographic aspects here, but...

>Now maybe I'm being a bit optimistic here, but I do think that claiming this 
>is a weakness is a pretty silly.  First of all you need to assume that an 
>attacker can somehow send you a million pieces of email without you noticing 
>and without it getting stopped by spam blockers.

I think this *must* be a working assumption.  As soon as e-mail (or other
S/MIME-protected object transport) is used for automated transactions
(which I believe will happen) then this assumption becomes a real
probability, IMO.  I see this as another aspect of Internet protocol
scalability.

>...  Your own software then has 
>to try to decrypt each of the one million pieces of email, find that it
can't, 
>and send out a receipt to the sender containing an indication of exactly how 
>the decryption failed (this isn't possible even if you wanted to do it, 
>although who knows what the Receipt Notification WG have been working on 
>recently).

The fact that 'receipt' doesn't currently have a mechanism to carry this
information doesn't mean:
(a) that it never will, or
(b) that some other mechanism will be not used that does have this capability.

>...  Finally, the whole attack only works if you reuse cryptovariables 
>- it would work nicely if you use something like the ES-DH cached values
which 
>Eric mentioned in a previous message, but not against Elgamal key wrapping.  
>This is why the CERT advisory on this problem specifically points out "This 
>vulnerability does not affect S/MIME or SET".

I cannot comment on the truth of this assertion.  But it does seem to me
that this should be the basis of debate for the issue you raise, rather
than assumptions about message volumes, etc.

#g

------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA27733 for ietf-smime-bks; Mon, 28 Dec 1998 19:24:11 -0800 (PST)
Received: from saturn.infoserv.dk ([195.249.146.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA27724 for <[e-mail]>; Mon, 28 Dec 1998 19:24:09 -0800 (PST)
Received: from europa ([195.249.146.10] (may be forged)) by saturn.infoserv.dk (2.5 Build 2626 (Berkeley 8.8.6)/8.8.4) with SMTP id EAA16498 for <[e-mail]>; Tue, 29 Dec 1998 04:26:18 +0100
Message-Id: <[e-mail]>
Date: Tue, 29 Dec 1998 04:30:32 +0100
From: [e-mail]
Subject: New Martial Arts Organisation
To: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This e-mail is to inform you, that we have started a non-profit
friendship association called Friends of the Fighting Spirit.
 
Through the years, we have established many contacts in
different countries. Now, together with all other interested
people worldwide, it 's possible through Dai Ki Haku to become
member of the non-profit friendship association Friends of
the Fighting Spirit
 
Our intention is to provide all forms of martial arts and combatants
with the opportunity of to derive knowledge from each other in various
ways, respective of different individual levels, religions and culture.
 
If you are accepted as a member, you will never have to pay anything
for you membership. Both individuals and clubs can become
members. 
By visiting the below web-site, you will be able to read some material
about Friends of the Fighting spirit.
 
http://ffs.daikihaku.dk/
 
The material includes information and replies to questions about why Friends
of the Fighting Spirit is quite special within Martial Art.
 
Please take the time to read the entire material so that we may have some
well-considered applications for membership.
 
On behalf of
Shihan Oerum
 
---
(Please note that this is not a commercial e-mail, this is a non-profit organisation.
Your have received this e-mail because of your interest in Martial Art, and you
will not receive any more e-mail's if you decide not to join the organisation.)
---



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA01134 for ietf-smime-bks; Mon, 28 Dec 1998 09:29:43 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA01128; Mon, 28 Dec 1998 09:29:39 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 28 Dec 1998 09:36:24 -0800
To: Peter Sylvester <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Signing Certificate Attribute Definition
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 06:26 PM 12/28/98 +0100, Peter Sylvester wrote:
>In particular chapter 5 is not introduced in the introduction:

Whoops, my mistake. I'll add that.


--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA00858 for ietf-smime-bks; Mon, 28 Dec 1998 09:19:39 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [193.51.12.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA00854 for <[e-mail]>; Mon, 28 Dec 1998 09:19:37 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA24385 for <[e-mail]>; Mon, 28 Dec 1998 18:26:41 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.1); Mon, 28 Dec 1998 18:26:41 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.6.10/8.6.6) with ESMTP id SAA11155 for <[e-mail]>; Mon, 28 Dec 1998 18:26:40 +0100
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.6.10/8.6.6) id SAA12769 for [e-mail]; Mon, 28 Dec 1998 18:26:40 +0100
Date: Mon, 28 Dec 1998 18:26:40 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Signing Certificate Attribute Definition
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hello,

somewhere I read that Denis Pinkas had proposed to move the 
Signing Certificate Attribute description from ess to cms. 

I wonder whether the whole chapter 5 should go there. 

In particular chapter 5 is not introduced in the introduction:

  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

Or, at least, there should be one phrase about chapter 5 in the introduction
such that a reader who continues and reads

  This document describes both the procedures and the attributes needed for
  the three services. Note that some of the attributes described in this
  document are quite useful in other contexts and should be considered when
  extending S/MIME or other CMS applications.

would really read the document.

Peter Sylvester



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28563 for ietf-smime-bks; Mon, 28 Dec 1998 07:18:26 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28559 for <[e-mail]>; Mon, 28 Dec 1998 07:18:24 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20397; Mon, 28 Dec 1998 10:25:04 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-msg-06.txt
Date: Mon, 28 Dec 1998 10:25:03 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-msg-06.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-msg-06.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-msg-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA01353 for ietf-smime-bks; Sat, 26 Dec 1998 18:47:12 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA01349 for <[e-mail]>; Sat, 26 Dec 1998 18:47:10 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA32311; Sun, 27 Dec 1998 15:54:07 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91472724614715>; Sun, 27 Dec 1998 15:54:06 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: key preferences, usages, and S/MIME recipients
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 27 Dec 1998 15:54:06 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>What's a conformant recipient to do, however, if a message is generated for 
>it using a encryption key which not only doesn't match its encryption key 
>preference but whose referenced certificate doesn't permit key management 
>usage?  I'm not sure how comprehensively an S/MIME recipient is expected to 
>process and validate *its own* certificates, when encountered as references 
>identifying the key(s) used to encrypt messages sent to it. In a spirit of 
>conditionally liberal acceptance despite erroneously non-conservative 
>generation, I'd propose that local policy and configuration should control 
>whether a recipient system is allowed to decrypt such a message, and whether 
>the associated user is to be warned or consulted for confirmation before 
>proceeding.  Does anyone's interpretation disagree, and would this case be 
>worth noting in MSG and/or CERT?
 
I think this is a Bad Thing, for three reasons: Firstly, if a key is marked 
as (for example) authentication only, then a number of profiles say that you 
can't use it for other purposes (of course you're free to choose a profile 
which says the field is advisory only, even if marked critical).  Secondly, 
confidentiality keys may be issued under a completely different policy to 
authentication keys, so you could quite easily be violating the cert policy by 
doing this.  Finally, it looks like governments are going to (at least try to) 
regulate confidentiality keys under very different terms from authentication 
keys.  By making every key a potential confidentiality key, you really mess up 
the legal framework surrounding the keys.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA25218 for ietf-smime-bks; Fri, 25 Dec 1998 00:26:19 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA25214 for <[e-mail]>; Fri, 25 Dec 1998 00:26:16 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id VAA24928; Fri, 25 Dec 1998 21:32:54 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91457477430018>; Fri, 25 Dec 1998 21:32:54 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 25 Dec 1998 21:32:54 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>I'm referring to the Bleichenbacher attack on RSA key transport, aka the 
>"Million Message Attack." I don't believe it's known that this cannot be 
>extended to ElGamal. I prefer not to take chances.
 
For those of you who have been sitting on the sidelines watching the messages 
whooshing past overhead, it looks like we were talking about two different 
"Bleichenbacher attacks" in the last few messages.  The one I was thinking 
about was from 1996, applies only to Elgamal signatures (not encryption), and 
even then only works if a badly chosen key is used.  This attack doesn't apply 
to Elgamal key wrapping.
 
The one Eric was thinking of was from 1998.  In order to work for the Elgamal 
key wrapping I've proposed for CMS, this attack requires that an attacker send 
you around a million pieces of CMS encrypted email with attached receipt 
requests, that you respond with a million receipts indicating to the attacker 
the exact details of why the decrypt failed, that you reuse the same 
per-message key for each of those million messages, and that you (rather than 
the attacker) know this per-message key.
 
Now maybe I'm being a bit optimistic here, but I do think that claiming this 
is a weakness is a pretty silly.  First of all you need to assume that an 
attacker can somehow send you a million pieces of email without you noticing 
and without it getting stopped by spam blockers.  Your own software then has 
to try to decrypt each of the one million pieces of email, find that it can't, 
and send out a receipt to the sender containing an indication of exactly how 
the decryption failed (this isn't possible even if you wanted to do it, 
although who knows what the Receipt Notification WG have been working on 
recently).  Finally, the whole attack only works if you reuse cryptovariables 
- it would work nicely if you use something like the ES-DH cached values which 
Eric mentioned in a previous message, but not against Elgamal key wrapping.  
This is why the CERT advisory on this problem specifically points out "This 
vulnerability does not affect S/MIME or SET".
 
As a security threat, I'd say this rates somewhere down with "Router hit by 
meteorite", "Computer trampled by stampeding water buffalo", "Hard drive 
kidnapped by space aliens", and similar FUD.
 
#include <previous stuff about DH as Elgamal being better than DH as ES-DH>
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA01077 for ietf-smime-bks; Thu, 24 Dec 1998 14:22:53 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA01073 for <[e-mail]>; Thu, 24 Dec 1998 14:22:51 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id OAA03355; Thu, 24 Dec 1998 14:30:26 -0800 (PST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 24 Dec 1998 14:30:25 -0800
In-Reply-To: [e-mail]'s message of "Thu, 24 Dec 1998 20:43:55 (NZDT)"
Message-ID: <[e-mail]>
Lines: 65
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] (Peter Gutmann) writes:

> >The same sorts of issues that have been raised with respect to PKCS-1 in RSA
> >are worth worrying about with ElGamal. In particular see the Bleichenbacher
> >attack. I don't know that these attacks are feasible for ElGamal, but I'd
> >rather not take chances.
>  
> I don't have Bleichenbachers paper in front of me right now but as I recall it
> applied only to Elgamal *signatures* (the title is a sure giveaway, it was
> something like "How to generate Elgamal signatures without knowing the key").
I'm referring to the Bleichenbacher attack on RSA key transport,
aka the "Million Message Attack." I don't believe it's known that this cannot
be extended to ElGamal. I prefer not to take chances.

> I agree with you 100%.  If you use OAEP then they're probably of roughly
> similar complexity.
>  
> Since there's no need to use OAEP, it's also obvious that DH as Elgamal is
> vastly simpler than DH as ES-DH.  QED.
I'm not convinced that there's no need to use OAEP. As Mihir Bellare
is fond of pointing out, when you're designing new protocols, it's good
to protect against attacks you don't know about as well as attacks
you do. Hence a provably secure padding algorithm seems like a good
choice.

> I was referring to Static-Static, cached (ie reused) cryptovariables, etc etc:
>  
>   As noted above, it can be run in a Static-Static mode which requires half as
>   many modular exponentiations as either ElGamal or ES, and also provides Data
>   Origin Authentication. If you cache ZZ, the number of exponentiations per
>   message drops to zero (a la SKIP).
Fair enough. However, there are caching optimizations available when you
use ES-DH as well that do not have the problems of SS. Moreover, as
I originally indicated, SS can be used safely, you just have to choose
a larger group.

> >I think you're overstating the amount of implementation complexity. I estimate
> >it as being no more than a day or two's work.
>  
> Have you actually tried it?
Not yet. It's my estimate based on triangulating between the effort
to do DH in SSL and the original effort to do PKCS-7 with RSA. 

>  It's a lot more than a day or two's work, and as
> I've mentioned before once you've got it all going there's no guarantee,
> because of the complexity, that your version will interoperate with anyone
> elses version.
Yes, but we expect to publish examples, so I'm not really that concerned
about this issue. 

> Just as a data point, in the implementation I have the use of Elgamal for key
> transport actually required zero time, it's a heavily object-oriented design so
> throwing an Elgamal object at key transport works just as well as throwing an
> RSA object at it.  At the moment I've actually had to put in special code to
> disable Elgamal for key transport, so I guess you could say it'd take a
> negative amount of code to implement because I'd have to delete the code which
> disables it.  That's got to be fairly conclusive proof that the implementation
> overhead is minimal.
I didn't say the ElGamal overhead wasn't minimal. I said that I didn't
consider the DH overhead prohibitive. Implementation complexity is
always a concern, but it's not the only concern.

-Ekr
-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28781 for ietf-smime-bks; Thu, 24 Dec 1998 07:31:57 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28777 for <[e-mail]>; Thu, 24 Dec 1998 07:31:56 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA00586; Thu, 24 Dec 1998 10:38:16 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x942-04.txt
Date: Thu, 24 Dec 1998 10:38:15 -0500
Sender: [e-mail]
Precedence: bulk

--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-04.txt
	Pages		: 10
	Date		: 22-Dec-98
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-04.txt

Internet-Drafts are also 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-04.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-04.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA22790 for ietf-smime-bks; Wed, 23 Dec 1998 23:37:31 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA22786 for <[e-mail]>; Wed, 23 Dec 1998 23:37:29 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id UAA19661; Thu, 24 Dec 1998 20:43:56 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91448543522662>; Thu, 24 Dec 1998 20:43:55 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 24 Dec 1998 20:43:55 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>The same sorts of issues that have been raised with respect to PKCS-1 in RSA
>are worth worrying about with ElGamal. In particular see the Bleichenbacher
>attack. I don't know that these attacks are feasible for ElGamal, but I'd
>rather not take chances.
 
I don't have Bleichenbachers paper in front of me right now but as I recall it
applied only to Elgamal *signatures* (the title is a sure giveaway, it was
something like "How to generate Elgamal signatures without knowing the key").
Since we're talking about key transport, the attack isn't even relevant.  In
any case it's trivial to protect against, all you need to do is make sure that
g != 2 (or any other small, smooth divisor of p-1).  I don't know of anything
which does use Elgamal signatures except in their DSA variant (as Anderson and
Vaudenay put it in their analysis of DSA, "DSA is Elgamal with the bugs
fixed").  Given that fact, and that there's a well-established standard for
DSA, I can't see any incentive to use Elgamal signatures.  In any case, we were
debating key transport/agreement, not signatures.
 
>As I said previously, I agree that there is additional implementation
>complexity in parsing te new ASN.1 structs, but the CRYPTO implementation cost
>is fairly similar. In particular, OAEP and the X9.42 expansion/wrapping
>transforms are of comparable cost. I stand by this statement.
 
I agree with you 100%.  If you use OAEP then they're probably of roughly
similar complexity.
 
Since there's no need to use OAEP, it's also obvious that DH as Elgamal is
vastly simpler than DH as ES-DH.  QED.
 
>2. I don't believe you are correct about the security problems. What precisely
>do you believe the problem is with reusing the sender's key with ES-DH
>provided that you use a new pubInfo for each message? I agree that there is a
>security issue wrt to a shared group for SS mode, and that's why it's
>optional.
 
I was referring to Static-Static, cached (ie reused) cryptovariables, etc etc:
 
  As noted above, it can be run in a Static-Static mode which requires half as
  many modular exponentiations as either ElGamal or ES, and also provides Data
  Origin Authentication. If you cache ZZ, the number of exponentiations per
  message drops to zero (a la SKIP).
 
>I think you're overstating the amount of implementation complexity. I estimate
>it as being no more than a day or two's work.
 
Have you actually tried it?  It's a lot more than a day or two's work, and as
I've mentioned before once you've got it all going there's no guarantee,
because of the complexity, that your version will interoperate with anyone
elses version.
 
Just as a data point, in the implementation I have the use of Elgamal for key
transport actually required zero time, it's a heavily object-oriented design so
throwing an Elgamal object at key transport works just as well as throwing an
RSA object at it.  At the moment I've actually had to put in special code to
disable Elgamal for key transport, so I guess you could say it'd take a
negative amount of code to implement because I'd have to delete the code which
disables it.  That's got to be fairly conclusive proof that the implementation
overhead is minimal.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA03239 for ietf-smime-bks; Wed, 23 Dec 1998 18:57:33 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA03230 for <[e-mail]>; Wed, 23 Dec 1998 18:57:30 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 23 Dec 1998 19:04:04 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Security considerations section for ESS
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

A few of you noticed that I had a stub for the security considerations
in the ESS draft. Below is what I think we might want to put in.
Additions, deletions, and rewording is welcome.

-=-=-=-=-=-=

All security considerations from [CMS] and [SMIME3] apply to applications
that use procedures described in this document.

As stated in Section 2.3, a recipient of a receipt request must not send
back a reply if it cannot validate the signature. Similarly, if there
conflicting receipt requests in a message, the recipient must not send back
receipts, since an attacker may have inserted the conflicting request.
Sending a signed receipt to an unvalidated sender can expose information
about the recipient that it may not want to expose to unknown senders.

Senders of receipts should consider encrypting the receipts to prevent a
passive attacker from gleaning information in the receipts.

Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that adding a
security label to a message will prevent recipients from viewing messages
the sender doesn't want them to view. It is expected that there will be
many S/MIME clients that will not understand security labels but will still
display a labelled message to a recipient.

A receiving agent that processes security labels must handle the content of
the messages carefully. If the agent decides not to show the message to the
intended recipient after processing the security label, the agent must take
care that the recipient does not accidentally see the content at a later
time. For example, if an error response sent to the originator contains the
content that was hidden from the recipient, and that error response bounces
back to the sender due to addressing errors, the original recipient can
possibly see the content since it is unlikely that the bounce message will
have the proper security labels.

A man-in-the-middle attack can cause a recipient to send receipts to an
attacker if that attacker has a signature that can be validated by the
recipient. The attack consists of intercepting the original message and
adding a mLData attribute that says that a receipt should be sent to the
attacker in addition to whoever else was going to get the receipt.

Mailing lists that encrypt their content may be targets for
denial-of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is quite
easy to subscribe one encrypted mailing list to another, thereby setting up
an infinite loop.

Mailing List Agents need to be aware that they can be used as oracles for
the the adaptive chosen ciphertext attack described in [CMS].  MLAs should
notify an administrator if a large number of undecryptable messages are
received.

When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates previously
known to be valid, or certificates that have come from a signed
SigningCertificate attribute. Otherwise, the attacks described in Section 5
can cause the receiver to possibly think a signature is valid when it is
not.



--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02491 for ietf-smime-bks; Wed, 23 Dec 1998 18:34:32 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02487 for <[e-mail]>; Wed, 23 Dec 1998 18:34:30 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id SAA05141; Wed, 23 Dec 1998 18:41:57 -0800 (PST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 23 Dec 1998 18:41:56 -0800
In-Reply-To: [e-mail]'s message of "Thu, 24 Dec 1998 15:25:31 (NZDT)"
Message-ID: <[e-mail]>
Lines: 66
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] (Peter Gutmann) writes:

> >No more so than in the ElGamal case. The ElGamal bignum primitves are indeed
> >simple, as are the DH ones. The implementation trickiness is in the symmetric
> >wrapping stages. To correctly use ElGamal, you should use OAEP, which is not
> >widely implemented.
>  
> Why would you want to do this (apart from adding unnecessary complexity)?
> What's wrong with PKCS #1 wrapping? 
The same sorts of issues that have been raised with respect to 
PKCS-1 in RSA are worth worrying about with ElGamal. In particular
see the Bleichenbacher attack. I don't know that these attacks are
feasible for ElGamal, but I'd rather not take chances.

> >Similarly, X9.42 requires the expansion and key wrapping transforms. I
> >consider these of approximately similar complexity, as I indicated in my
> >previous message.
>  
> In terms of complexity the two aren't even in the same league!  Elgamal
> requires one or two extra lines of code in an existing implementation while
> X9.42 requires an entirely new RecipientInfo type, key wrapping, processing,
> and whatnot, with accompanying interoperability problems.
Peter, I understand that you feel strongly about this, but please read
more carefully. What I wrote was:

  No more so than in the ElGamal case. The ElGamal bignum primitves
  are indeed simple, as are the DH ones. The implementation trickiness
  is in the symmetric wrapping stages. To correctly use ElGamal, you
  should use OAEP, which is not widely implemented. Similarly, X9.42
  requires the expansion and key wrapping transforms. I consider these
  of approximately similar complexity, as I indicated in my 
  previous message.

As I said previously, I agree that there is additional implementation
complexity in parsing te new ASN.1 structs, but the CRYPTO implementation
cost is fairly similar. In particular, OAEP and the X9.42 expansion/
wrapping transforms are of comparable cost. I stand by this statement.

> >Asked and answered. It's better, for technical reasons which I laid out in my
> >previous message.
>  
> The only reasons were that in some special cases (that is, by re-using existing
> cryptovariables, with its accompanying security problems)
1. Those weren't the only reasons. As I indicated, the SS case
gives you data origin authentication.
2. I don't believe you are correct about the security problems.
What precisely do you believe the problem is with reusing 
the sender's key with ES-DH provided that you use a new pubInfo
for each message? I agree that there is a security issue
wrt to a shared group for SS mode, and that's why it's optional.

> it was possible for
> users to get their mail a few milliseconds faster than if Elgamal was used.
> ES-DH, in return for a vast amount of unnecessary implementation complexity,
I think you're overstating the amount of implementation complexity.
I estimate it as being no more than a day or two's work.

> offers in return a minor speed tradeoff which noone will ever notice in
> practice.
You're missing the big picture: CMS is not just for email. For
interactive applications, this cost can become significant.
(Especially on the server side.) 

-Ekr
--
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02416 for ietf-smime-bks; Wed, 23 Dec 1998 18:19:01 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02412 for <[e-mail]>; Wed, 23 Dec 1998 18:18:59 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA18383; Thu, 24 Dec 1998 15:25:31 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91446633119980>; Thu, 24 Dec 1998 15:25:31 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 24 Dec 1998 15:25:31 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>No more so than in the ElGamal case. The ElGamal bignum primitves are indeed
>simple, as are the DH ones. The implementation trickiness is in the symmetric
>wrapping stages. To correctly use ElGamal, you should use OAEP, which is not
>widely implemented.
 
Why would you want to do this (apart from adding unnecessary complexity)?
What's wrong with PKCS #1 wrapping?  The Elgamal X.509 profile draft has been
around for about a year and was also discussed in sci.crypt without anyone
claiming you needed OAEP (in fact strictly speaking you don't even need the
PKCS #1 block type 02 random padding since Elgamal is randomised anyway, but I
used it for consistency with the RSA usage).
 
>Similarly, X9.42 requires the expansion and key wrapping transforms. I
>consider these of approximately similar complexity, as I indicated in my
>previous message.
 
In terms of complexity the two aren't even in the same league!  Elgamal
requires one or two extra lines of code in an existing implementation while
X9.42 requires an entirely new RecipientInfo type, key wrapping, processing,
and whatnot, with accompanying interoperability problems.
 
>>KeyTransRecipientInfo is vastly less complex than adding a whole new
>>RecipientInfo type, and when they're providing exactly the same service I
>>really don't see why ES-DH should be the way to go (thus the "pushing a pea
>>up a mountain with your nose" quote in the previous message).
 
>Asked and answered. It's better, for technical reasons which I laid out in my
>previous message.
 
The only reasons were that in some special cases (that is, by re-using existing
cryptovariables, with its accompanying security problems) it was possible for
users to get their mail a few milliseconds faster than if Elgamal was used.
ES-DH, in return for a vast amount of unnecessary implementation complexity,
offers in return a minor speed tradeoff which noone will ever notice in
practice.  I just don't see the point of going to all this effort for no
obvious (to the user) return.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00409 for ietf-smime-bks; Wed, 23 Dec 1998 13:42:43 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00403 for <[e-mail]>; Wed, 23 Dec 1998 13:42:37 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id QAA16450; Wed, 23 Dec 1998 16:49:23 -0500
Message-Id: <4.1.19981223164613.0098fe20@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 1 (Highest)
Date: Wed, 23 Dec 1998 16:48:12 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Ready For Last Call:draft-ietf-smime-x942-04.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jeff:

This document is ready for IETF-wide Last Call.

I recommend a four week last call.  Since this document specifies a
Diffie-Hellman variant, it should get reviewed by as many cryptographers as
possible.

Other documents from the S/MIME Working Group will be ready for IETF-wide
Last Call within the next two weeks.

Russ


At 02:24 PM 12/23/98 -0500, [e-mail] wrote:
>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-04.txt
>	Pages		: 10
>	Date		: 22-Dec-98
>	
>   This document standardizes one particular Diffie-Hellman variant,
>   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
>   group. Diffie-Hellman is a key agreement algorithm used by two par-
>   ties to agree on a shared secret. An algorithm for converting the
>   shared secret into an arbitrary amount of keying material is pro-
>   vided. The resulting keying material is used as a symmetric encryp-
>   tion key.  The D-H variant described requires the recipient to have a
>   certificate, but the originator may have a static key pair (with the
>   public key placed in a certificate) or an ephemeral key pair.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-04.txt
>
>Internet-Drafts are also 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-04.txt".
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nic.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:	[e-mail].  In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-x942-04.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-x942-04.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-x942-04.txt>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00256 for ietf-smime-bks; Wed, 23 Dec 1998 13:32:51 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00265 for <[e-mail]>; Wed, 23 Dec 1998 13:25:29 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id QAA15969; Wed, 23 Dec 1998 16:32:02 -0500
Message-Id: <4.1.19981223151845.0098e2b0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 1 (Highest)
Date: Wed, 23 Dec 1998 15:23:03 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Ready For Last Call: draft-ietf-smime-cms-10.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jeff:

This document is ready for IETF-wide Last Call.

I recommend a four week last call.  Since this document includes a key wrap
algorithm, it should get by as many cryptographers as possible.

Other documents from the S/MIME Working Group will be ready for IETF-wide
Last Call witin the next two weeks.

Russ


>To: IETF-Announce: ;
>Cc: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-ietf-smime-cms-10.txt
>Date: Tue, 22 Dec 1998 16:08:48 -0500
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the S/MIME Mail Security Working Group of the 
>IETF.
>
>	Title		: Cryptographic Message Syntax
>	Author(s)	: R. Housley
>	Filename	: draft-ietf-smime-cms-10.txt
>	Pages		: 54
>	Date		: 15-Dec-98
>	
>   This document describes the Cryptographic Message Syntax.  This
>   syntax is used to digitally sign, digest, authenticate, or encrypt
>   arbitrary messages.
> 
>   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
>   as specified in RFC 2315 [PKCS#7].  Wherever possible, backward
>   compatibility is preserved; however, changes were necessary to
>   accommodate attribute certificate transfer and key agreement
>   techniques for key management.
> 
>   This draft is being discussed on the 'ietf-smime' mailing list.  To
>   join the list, send a message to <[e-mail]> 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/>.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-ietf-smime-cms-10.txt".
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nic.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:	[e-mail].  In the body type:
>	"FILE /internet-drafts/draft-ietf-smime-cms-10.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-cms-10.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15836 for ietf-smime-bks; Wed, 23 Dec 1998 11:18:31 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15832 for <[e-mail]>; Wed, 23 Dec 1998 11:18:30 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA04809; Wed, 23 Dec 1998 14:24:47 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x942-04.txt
Date: Wed, 23 Dec 1998 14:24:46 -0500
Sender: [e-mail]
Precedence: bulk

--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-04.txt
	Pages		: 10
	Date		: 22-Dec-98
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
   group. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-x942-04.txt

Internet-Drafts are also 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-04.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-04.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA15414 for ietf-smime-bks; Wed, 23 Dec 1998 10:13:04 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA15410 for <[e-mail]>; Wed, 23 Dec 1998 10:13:02 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id KAA01565; Wed, 23 Dec 1998 10:20:16 -0800 (PST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 23 Dec 1998 10:20:15 -0800
In-Reply-To: [e-mail]'s message of "Wed, 23 Dec 1998 23:54:16 (NZDT)"
Message-ID: <[e-mail]>
Lines: 54
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] (Peter Gutmann) writes:

> >>Now let's look at the way it's applied here.  A rough outline of what's
> >>contained in KeyAgreeRecipientInfo is:
>  
> >>  originatorDH  -- Originators DH values p, g, y = g^x mod p
> >>  recipientDH   -- Recipients fixed DH values p, g, y' = g^x' mod p
> >>  nonce         -- Extra material to mix in to ensure different keys are
> >>                   produced
>  
> >This is incorrect. Here's the ASN.1 for reference:
>  
> I'd abstracted it down to what was actually being processed for
> KeyAgreeRecipientInfo, for the ASN.1 I assumed most people on the list would
> already have a copy of the S/MIME spec so I didn't copy it all out.
Peter, my complaint is that you DIDN'T abstract it down. Your 
text implies that p,q,g, are carried in the message. They are not. 
Neither is y'. The text that you snipped makes this clear. I supplied
the ASN.1 merely as background for my comments.

> This obscures a great amount of detail in the ES-DH case.  To really compare 
> the level of complexity, let's assume that you have an underlying 
> implementation which does (or can do) either DH or Elgamal as a primitive 
> operation (it's a dozen or so lines of code using any common bignum library).  
No more so than in the ElGamal case. The ElGamal bignum primitves
are indeed simple, as are the DH ones. The implementation trickiness
is in the symmetric wrapping stages. To correctly use ElGamal, you
should use OAEP, which is not widely implemented. Similarly, X9.42
requires the expansion and key wrapping transforms. I consider these
of approximately similar complexity, as I indicated in my 
previous message.

> In contrast to implement key transport (agreement) using a DH key as ES-DH 
> key, you need to implement a completely new RecipientInfo type with associated 
> processing, and large amounts of X9.42 with the associated increase in 
> complexity and virtually guaranteed interoperability problems between 
> implementations.
I agree that there is some additional implementation complexity in
managing the new ASN.1 types. I don't consider it that substantial.
Moreover, once we've taken this one-time hit, we are able to use a 
broader class of algorithms than before. (A number of elliptic curve
algorithms come to mind.)

> KeyTransRecipientInfo is vastly less complex than adding a whole new 
> RecipientInfo type, and when they're providing exactly the same service I 
> really don't see why ES-DH should be the way to go (thus the "pushing a pea up 
> a mountain with your nose" quote in the previous message).
Asked and answered. It's better, for technical reasons which I laid out
in my previous message. 

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA14189 for ietf-smime-bks; Wed, 23 Dec 1998 07:13:17 -0800 (PST)
Received: from stax05.cubis.de (wks1.cubis.de [194.112.101.50]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA14185 for <[e-mail]>; Wed, 23 Dec 1998 07:13:15 -0800 (PST)
Received: from ex-mail.cubis.de (ex-mail.cubis.de [10.16.4.44]) by stax05.cubis.de (8.7.5/8.7.3) with ESMTP id QAA04074 for <[e-mail]>; Wed, 23 Dec 1998 16:19:33 +0100 (MET)
Received: by ex-mail.cubis.de with Internet Mail Service (5.5.1960.3) id <Y9C0677A>; Wed, 23 Dec 1998 16:17:51 +0100
Message-ID: <[e-mail]>
From: "Gawlick, Thomas" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: First call for papers
Date: Wed, 23 Dec 1998 16:20:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA14186
Sender: [e-mail]
Precedence: bulk

Hi everyone !

Please find the attached first call for papers for a new international
forum for information security. We apologize if you have multiple
receipts of  this message.

We wish you all a joyous Holiday Season and a Happy New Year!

	secunet                             	
	Security Networks GmbH 
	CQRE - Team 




                          First CALL FOR PAPERS
                          --------------------------------------
             CQRE [Secure] Exhibition & Congress
             --------------------------------------------------------
         Nov. 30 - Dec. 2, 1999, Duesseldorf, Germany


CQRE [Secure] Exhibition & Congress provides a new international
forum giving a close-up view on information security in the context
of rapidly evolving economic processes. The unprecedented reliance
on computer technology has transformed the previous technical
side-issue "information security" to a management problem requiring
decisions of strategic importance. Hence, the targeted audience
represents decision makers from government, industry, commercial,
and academic communities.

If you are concerned with solutions relating to the protection of
your country´s information infrastructure or a commercial
enterprise, consider submitting a paper to the CQRE [Secure]
Exhibition & Congress.


We are looking for papers and panel discussions covering:

* ELECTRONIC COMMERCE            * CORPORATE SECURITY
---------------------------------------------
--------------------------------------------------
- new business processes                 - access control
- secure business transactions          - secure teleworking
- online merchandising                      - enterprise key management
- electronic payment / banking           - IT-audit
- innovative applications                     - risk / disaster
management
* NETWORK SECURITY                   - security awareness and training
---------------------------------------------          - implementation,
accreditation,
- virtual private networks                       and operation of secure
systems
- security aspects in internet                in a government, business,
or
  utilization                                         industry
environment
- security aspects in multi-               * SECURITY TECHNOLOGY
  media-applications
--------------------------------------------------
- intrusion detection systems            - cryptography
* LEGAL ASPECTS                         - public key infrastructures
------------------------------                        - chip card
technology
- digital signature acts                      - biometrics
- privacy and anonymity                   * TRUST MANAGEMENT
- crypto regulation
--------------------------------------------------
- liability                                         - evaluation of
products and systems
		                                         - international
harmonization of
              			        security evaluation criteria
                                                     * STANDARDIZATION
                                                     * FUTURE
PERSPECTIVES

Any other contribution addressing the involving of IT security in
economic processes will also be welcome. Authors are invited to
submit an extended abstract of their contribution to the program
chair. The submissions should be original research results, survey
articles or "high quality" case studies and position papers.
Product advertisements are welcome for presentation, but will not
be considered for the proceedings. Manuscripts must be in English,
and not more than 2.000 words. The extended abstracts should be in
a form suitable for anonymous review, without author's names,
affiliations, acknowledgements or obvious references. Contributions
must not be submitted in parallel to any conference or workshop
that has proceedings. Separately, an abstract of the paper with no
more than 200 words and with title, name and addresses (incl. an
E-mail address) of the authors may be submitted. In case of
multiple authors the contacting author must be clearly identified.
We strongly encourage electronic submission in Postscript format.
The submissions must be in 11pt format, use standard fonts or
include the necessary fonts. Proposals for panel discussions should
also be sent to the program chair. Panels of interest include those
that present alternative/controversial viewpoints or those that
encourage lively discussions of relevant issues. Panels that are
collections of unrefereed papers will not be considered. Panel
proposals should be a minimum of one page describing the subject
matter, the appropriateness of the panel for this conference and
should identify participants and their respective viewpoints.

MAILING LIST:
--------------------------------------
If you want to receive emails with subsequent Call for Papers and
registration information, please send a brief mail to [e-mail].

WEB SITE:
--------------------------------------
Up to date information about CQRE [Secure] Exhibition & Congress
will be available at http://www.secunet.de/Forum/cqre.html

IMPORTANT DATES:
--------------------------------------
- Deadline for submission of extended abstracts	               May 14,
1999
- Deadline for submission of panel proposals                      June
1,  1999
- Notification of acceptance
June 25, 1999
- Deadline for submission of complete papers                    July 30,
1999

PROGRAM COMMITTEE:
--------------------------------------
Johannes Buchmann                 (TU Darmstadt) 
Dirk Fox                                   (Secorvo) 
Walter Fumy                             (Siemens) 
Rüdiger Grimm                          (GMD) 
Helena Handschuh                    (ENST/Gemplus)
Thomas Hoeren                         (Uni Muenster) 
Pil Joong Lee                            (POSTECH) 
Alfred Menezes                         (U.of Waterloo / Certicom) 
David Naccache                        (Gemplus) 
Clifford Neumann                       (USC) 
Mike Reiter                               (Bell Labs) 
Matt Robshaw                           (RSA) 
Richard Schlechter                    (EU-comm.)
Bruce Schneier                         (Counterpane) 
Tsuyoshi Takagi                        (NTT) 
Yiannis Tsiounis                        (GTE Labs) 
Michael Waidner                       (IBM) 
Moti Yung                                (CERTCO) 
Robert Zuccherato 		(Entrust)

PROGRAM CHAIR: 
--------------------------------------
Rainer Baumgart 
secunet Security Networks GmbH
Weidenauer Str. 223 - 225 
57076 Siegen Germany 
Tel.: [phone] 
Fax: [phone] 
[e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA10846 for ietf-smime-bks; Wed, 23 Dec 1998 02:48:05 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA10840 for <[e-mail]>; Wed, 23 Dec 1998 02:48:00 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA13554; Wed, 23 Dec 1998 23:54:17 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91441045617212>; Wed, 23 Dec 1998 23:54:16 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 23 Dec 1998 23:54:16 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>>Now let's look at the way it's applied here.  A rough outline of what's
>>contained in KeyAgreeRecipientInfo is:
 
>>  originatorDH  -- Originators DH values p, g, y = g^x mod p
>>  recipientDH   -- Recipients fixed DH values p, g, y' = g^x' mod p
>>  nonce         -- Extra material to mix in to ensure different keys are
>>                   produced
 
>This is incorrect. Here's the ASN.1 for reference:
 
I'd abstracted it down to what was actually being processed for
KeyAgreeRecipientInfo, for the ASN.1 I assumed most people on the list would
already have a copy of the S/MIME spec so I didn't copy it all out.
 
>Perhaps it would be a useful exercise to review ES-DH (the required mode) and 
>ElGamal side by side, from the Originator's perspective: Assume that the 
>receiver's key is Yr and the group is g,q,p.
>
>ES-DH                                  ElGamal
>1. Generate random Xo.                 1. Generate random Xo.
>2. Y=g^Xo mod p.                       2. Compute Y=g^Xo mod p.
>3. ZZ=Yr^Xo mod p.                     3. ZZ=Yr^Xo mod p
>4. KEK=H(ZZ,...)                       4. PM=Pad M to fit in p.
>5. Wrapped Key=3DES(KEK,MEK || H(MEK)) 5. Wrapped key = PM * ZZ
>6. Send Y,Wrapped Key                  6. Send Y,wrapped Key
 
This obscures a great amount of detail in the ES-DH case.  To really compare 
the level of complexity, let's assume that you have an underlying 
implementation which does (or can do) either DH or Elgamal as a primitive 
operation (it's a dozen or so lines of code using any common bignum library).  
Let's assume in addition that you have at least S/MIME v2 implemented (so you 
have code to wrap and unwrap data, handle the older types like 
KeyTransRecipientInfo, etc etc).  I assume this is valid for pretty much 
anyone on the list who has an implementation.
 
In order to implement key transport using a DH key as Elgamal, the overall 
change to the code is:
 
  switch( algorithmType )
      ...
      case Elgamal:
         elgamalEncrypt( ... );
 
alongside the existing case of RSA in the code which handles 
KeyTransRecipientInfo (it's somewhat implementation-dependent, for example in 
mine there's no overhead at all because Elgamal is automatically available for 
use where appropriate).
 
In contrast to implement key transport (agreement) using a DH key as ES-DH 
key, you need to implement a completely new RecipientInfo type with associated 
processing, and large amounts of X9.42 with the associated increase in 
complexity and virtually guaranteed interoperability problems between 
implementations.
 
>So, exactly what features of the current X9.42 draft are you complaining 
>about? Your message implies that the problem is implementation complexity, 
>but I don't see where that complexity is supposed to lie.
 
See above.  For DH as Elgamal you typically need to add one more case 
statement to your KeyTransRecipientInfo code, while for DH as DH-ES you need 
to implement and somehow make interoperable an entirely new RecipientInfo type 
with associated complexity from X9.42.  Adding a single new algorithm type to 
KeyTransRecipientInfo is vastly less complex than adding a whole new 
RecipientInfo type, and when they're providing exactly the same service I 
really don't see why ES-DH should be the way to go (thus the "pushing a pea up 
a mountain with your nose" quote in the previous message).
 
>On the other hand, if your problem is a matter of taste, de gustibus non est
>disputandum.
 
Yeah?  Well mater tua caligas gerit!  (That's more in tone with a rant :-).
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15008 for ietf-smime-bks; Tue, 22 Dec 1998 13:23:21 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA15004 for <[e-mail]>; Tue, 22 Dec 1998 13:23:20 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08449; Tue, 22 Dec 1998 16:29:29 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cert-06.txt
Date: Tue, 22 Dec 1998 16:29:29 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: S/MIME Version 3 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-cert-06.txt
	Pages		: 8
	Date		: 16-Dec-98
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM].  S/MIME agents MUST meet the S/MIME-specific
requirements documented in this I-D in addition to those stated in
[KEYM].
 
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cert-06.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cert-06.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cert-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14854 for ietf-smime-bks; Tue, 22 Dec 1998 13:02:44 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14850 for <[e-mail]>; Tue, 22 Dec 1998 13:02:43 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA07452; Tue, 22 Dec 1998 16:08:53 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-ess-10.txt
Date: Tue, 22 Dec 1998 16:08:52 -0500
Sender: [e-mail]
Precedence: bulk

--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-10.txt
	Pages		: 36
	Date		: 15-Dec-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 ([MSG] and
[CERT]), 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.
 
This document describes both the procedures and the attributes needed for
the three services. Note that some of the attributes described in this
document are quite useful in other contexts and should be considered when
extending S/MIME or other CMS applications.

The format of the messages are described in ASN.1:1988 [ASN1-1988].
 
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED',  'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [MUSTSHOULD].
 
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     [e-mail]
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/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ess-10.txt

Internet-Drafts are also 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-10.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ess-10.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA14849 for ietf-smime-bks; Tue, 22 Dec 1998 13:02:40 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA14845 for <[e-mail]>; Tue, 22 Dec 1998 13:02:39 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA07439; Tue, 22 Dec 1998 16:08:49 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-10.txt
Date: Tue, 22 Dec 1998 16:08:48 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-10.txt
	Pages		: 54
	Date		: 15-Dec-98
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
   as specified in RFC 2315 [PKCS#7].  Wherever possible, backward
   compatibility is preserved; however, changes were necessary to
   accommodate attribute certificate transfer and key agreement
   techniques for key management.
 
   This draft is being discussed on the 'ietf-smime' mailing list.  To
   join the list, send a message to <[e-mail]> 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/>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-10.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-10.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA05749 for ietf-smime-bks; Tue, 22 Dec 1998 03:17:50 -0800 (PST)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA05741 for <[e-mail]>; Tue, 22 Dec 1998 03:17:48 -0800 (PST)
Received: from cougar.baltimore.ie ([e-mail] [194.125.215.12]) by puma.baltimore.ie (8.8.5/8.8.5) with ESMTP id LAA28424; Tue, 22 Dec 1998 11:24:23 GMT
Received: from cougar.baltimore.ie (afarrell@localhost [127.0.0.1]) by cougar.baltimore.ie (8.8.5/8.8.5) with ESMTP id LAA06455; Tue, 22 Dec 1998 11:24:22 GMT
Message-Id: <[e-mail]>
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on drafts. 
In-Reply-To: Your message of "Mon, 21 Dec 1998 17:01:23 EST." <4.1.19981221165945.00976630@209.172.119.123> 
Date: Tue, 22 Dec 1998 11:24:22 +0000
From: Andrew Farrell <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <4.1.19981221165945.00976630@209.172.119.123>you write:
>Andrew:

>>cms-09.txt:

>>1: Reference to MUSTSHOULD?

>Why?  The document does not capitalize those words.

Hurm. I went back and checked this when I was composing the mail, and
meant to leave it out. Apologies.

Andrew.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA14022 for ietf-smime-bks; Mon, 21 Dec 1998 21:56:11 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA14017 for <[e-mail]>; Mon, 21 Dec 1998 21:56:09 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPL4Z866>; Mon, 21 Dec 1998 21:59:19 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B87@localhost>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: RE: December WG Minutes
Date: Mon, 21 Dec 1998 21:59:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I received only one comment so here are the final minutes

All,

This message includes the minutes of the IETF S/MIME Working Group (WG) 
meeting held on 9 December 1998 in Orlando, FL. These minutes have been
coordinated with the briefing presenters. All briefing slides are stored
at: ftp://ftp.ietf.org/ietf/smime/.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley

Russ reviewed the agenda. Nobody objected the agenda.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS Draft Discussion - Russ Housley

Russ presented the current status on the CMS draft. The document is
currently in Working Group last call and will remain there until the X9.42
draft has finished its last call. The majority of the comments since the
last meeting have focused on Section 12. (This is the section on algorithms 
and key wrapping support.) The comments received to date have been 
incorporated in draft 10 which should be distributed soon.

Key Wrapping Algorithm: Several changes have been made to the key 
algorithm and some comments on it have been received since the last WG 
meeting. The algorithm has been found to be unsecure with stream cipher 
algorithms and block ciphers in OFB mode. A statement to this effect will
be placed in the document.

Russ stated that several people have asked for a modification to the check
sum algorithm be made. People are worried about the arithmetic nature of 
the algorithm. Additionally, there was a question on moving from 16 to 32 
bits in size. Russ reviewed the key wrap and unwrap algorithms as part of 
this discussion.

Several people indicated that they felt better using the left-most bits of 
a SHA-1 hash rather than the current Fletcher checksum. However, if the 
change was made, the checksum size should be increased to 32 bits. Jim 
Schaad raised a potential problem in that moving to 32 bits changed the 
block alignment. (32 bits of salt and 32 bits of checksum make a full 8
octet Triple-DES or RC2 block, thus a full block of pad will be needed.) 
After a fair amount of discussion, the WG decided to change the checksum
algorithm to the left-most 64 bits of the SHA-1 hash of the key material.
This takes advantage of the one-way nature of SHA-1 and provides a longer
integrity check value without increasing the size of the wrapped key.

Russ stated that several people has requested that once the CMS drafts are 
finished a four week rather than the normal two week IETF last call be 
requested. This request was based on the fact that the algorithms really 
need to have a wider review before being placed in proposed standard form.
The WG concurred.

Russ then asked for any other unresolved issued on CMS. 

Jim Schaad brought up the question of placing Subject Key Identifier (SKI)
into the SignerInfo structure. Jim proposed that the SKI be added to CMS,
however a statement be added to MSG that only the issuer and serial number
choice may be used in S/MIME version 3. A discussion followed where two
possible uses of SKI would be of use. The first would be to allow for PGP
keys to be referenced in a CMS object. The second related to the
Certificate Management over CMS (CMC) internet-draft in the PKIX working
group. After some discussion the proposal was adopted by the working group.

Denis Pinkas raised an issue that he thought section 5.6 (signature
verification process) was confusing and he had posted a message to this
effect. Russ requested that he repost the message to the list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X9.42 Draft Discussion - Eric Rescorla

Eric next presented the changes and plans for the X9.42 draft. Text has
been included in the draft to provide a standard way to produce the group
parameters for q >= 160. A statement that q must be at least 160 is being
included into the draft. With this set of changes the draft should be ready
for WG last call.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERT Draft Discussion - Paul Hoffman (for Blake Ramsdell)

Paul presented this and the CERT draft discussion on behalf of Blake who was
unable to make the meeting. Paul stated that only minor changes have been
made to the drafts since the last meeting. The most significant of these
dealt with making some terms about entities clearer and more consistent.
Paul stated that no new draft has been posted since the last working group
meeting but one should be expected soon.

An issue was raised that the last paragraph in section 3.1 is now redundant
as the NULL Subject DN on end-entity certificates is no longer permitted by
the PKIX documents.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

MSG Draft Discussion - Paul Hoffman (for Blake Ramsdell)

Paul stated that no significant changes have been made to the MSG draft
since the last meeting. The most significant editorial changes have been 
clarification about attribute counts in section 2.5, text clarification on
section 2.5.3 and a change to the Triple-DES reference. An updated draft
should be posted soon.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ESS Draft Discussion - Paul Hoffman

Paul stated that no significant changes have been made to the ESS draft
since the last meeting beyond the inclusion of the SigAttr section. Paul
stated that he would do some rewrites on the introduction to make it easier
to find the assorted attributes which have been added to the draft.

Issues raised from the floor on the ESS draft were:

1) Denis Pinkas requested that the Signature Cert attribute be moved from 
the ESS draft to the CMS draft. He stated that this attribute is needed in
order to be able to make a clear statement on signature verification. After
some discussion a straw poll was taken on the placement of the attribute 
with a majority preferring to keep the attribute in the ESS draft.

2) Andrew Farrell stated that section 4.2.2 was missing from the numbering.

3) Andrew Farrell stated that there appeared to be a large amount of 
redundancy between the processing of secure receipts in the subsections of
4.2.3. Paul explained that his opinion was that the text would be harder to
read if the three different cases were collapsed into a single section.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim stated that no significant changes have been made since the last WG
meeting. Following the successful progression of the other drafts and final
edits to the Security Considerations section the document will move to WG
Last Call.

Two issues were raised from the floor:

1. Andrew Farrell raied two content issues: Need an OID for the LDAP schema
and section 4.4 has an error in the flow chart.

2. Andrew Farrell requested that an example to be added as a new appendix.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Bill stated that changes to the draft included the inclusion of multiple
signature types were added to the draft and clarification of the text on
parallel and encapsulated signatures were added.

Several issues were raised from the floor:

Eric Rescorla made a statement about a problem with parallel signatures 
where an entity could remove the originator signature and substitute their
own. Bill said he would take this comment under advisement.

Bill then asked for guidance if the draft should go to informational or
standard track. Paul Hoffman suggested that the appropriate place may be
experimental unless others are going to implement. A straw poll of the 
group favored moving the draft to experimental. The WG agreed that if a
significant number of implementors emerge, then it can be moved to the
standards track.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Request: CEK Key Mgmt - Frank Siebenlist

Frank made a presentation about a request to modify CMS to allow for the
use of a shared content-encryption key (CEK) without the overhead of
wrapping with a key-encryption key (KEK). This would allow session based
protocols (such as TLS) to use CMS as a building block. As part of this
presentation a set of suggested ASN.1 changes to accomplish this were
presented.

Eric Rescorla raised immediate concerns that it is not good practice to
re-use an CEK especially in a persistent storage format. Many others
agreed this was a problem. Frank responded that the change was only for
session-based protocols and session-based protocols all suffered from this
re-use "problem".

Jim Schaad presented an alternate method of doing what was desired by the
creation of a new KEK algorithm which performed an identity transform from
the KEK to the CEK and would require no changes to existing CMS draft. The
proposal could then stand on its own merits. A straw poll showed the group
favored this approach to the problem.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Open PGP Compatibility - Jon Callas

Jon made an argument that there were some changes that could be made to the
CMS, MSG and CERT drafts which would allow for easy use of PGP keys to be
used for wrapping CEKs. Specifically, if the MUST on usage of 
IssuerAndSerialNumber in MSG is relaxed to a SHOULD then the SKI option 
could reference PGP keys.

Eric Rescorla stated that while this would give a potential way of dealing
with PGP keys, the message differences would still not be addressed and 
questioned if this should not be done all at once.

Paul Hoffman stated that allowing this would lead to backwards compatibility
problems with existing S/MIME implementations as they could not correctly
verify such signatures.

After some discussion the suggestion was made that a document should be
presented to the group which identified all of the incompatibly issues and
presented possible solutions that could be used to fix a sufficient set for
interoperability. The WG concurred with this approach.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

New Samples Document - Paul Hoffman

Paul made a presentation for the creation of a new document providing CMS
examples. The overview of the document would be a short introduction, a 
basic example of each content type and advanced examples of different types.
Consistent data on keys would be used through out the entire set of
examples. The timing of this document is such that it would not be started
until the CMS draft has moved to the RFC editors.

It was suggested that the document include some incorrect examples that flag
common implementation errors. Paul agreed to add a section for these.

Paul is only going to coordinate putting this document together. If 
individuals would like to volunteer to do examples they should contact Paul
at [e-mail].

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ACTION ITEMS:
1. Change the Checksum algorithm in CMS (Russ Housley)
2. Add SKI to SignerInfo (Russ Housley)
3. Add SKI restriction to the MSG draft (Blake Ramsdell)
4. Require IssuerAndSerialNumber in SigAttr (Paul Hoffman)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00794 for ietf-smime-bks; Mon, 21 Dec 1998 14:05:13 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00790 for <[e-mail]>; Mon, 21 Dec 1998 14:05:12 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA14599; Mon, 21 Dec 1998 17:11:46 -0500
Message-Id: <4.1.19981221170604.009756d0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 21 Dec 1998 17:07:35 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Extensibility discussion
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

As noted in a posting after the face-to-face WG eeting, ths CMS ASN.1 was
changed to accompdate signatures with SKI references.  However, the issuer
and serial number will be required for S/MIME v3 (see MSG spec).

I think this issue is closed.  Agree?

Russ

At 10:08 AM 12/9/98 +0000, Peter Gutmann wrote:
>Russ Housley <[e-mail]> wrote:
>
>>Support for PGP requires a bit more than this.  You also need to carry
>>non-X.509 PGP certificates.  CMS does not permit this.  
>
>The need to lug armfuls of certs around with you wherever you go is an 
>artifact of X.509, not something required by PGP.  All that PGP (and
>SPKI) require is a way to identify the key used to sign or encrypt data
>(the PGP native format doesn't even provide a way to communicate certs
>a la CMS's CertificateSet, so it's really not an issue).
>
>(To put it another way, given support for PGP and SPKI key ID's in the
> xxxInfo's, I can have a fully compatible implementation running in an 
> afternoon).
>
>Peter.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA00785 for ietf-smime-bks; Mon, 21 Dec 1998 14:05:08 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA00781 for <[e-mail]>; Mon, 21 Dec 1998 14:05:07 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA14602; Mon, 21 Dec 1998 17:11:46 -0500
Message-Id: <4.1.19981221170928.0097c9c0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 21 Dec 1998 17:10:19 -0500
To: Graham Klyne <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Key Wrap Algoritm
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

That is why I posted the decision to the list.  This posting allows anyone
who was unable to attend the meeting to raise an objection.

Russ
S/MIME WG Chair


At 03:30 PM 12/14/98 +0000, Graham Klyne wrote:
>At 23:11 09/12/98 -0500, Russ Housley wrote:
>>All:
>>
>>In today's face-to-face working group meeting, we decided to replace the
>>Fletcher Checksum with the first 64 bits of a SHA-1 hash.
>
>This is the second of two messages I've seen where the face-to-face meeting
>decided to change something in S/MIME.
>
>I thought that IETF procedure required that all decisions for substantive
>change were made on the mailing list.
>
>I don't oppose the changes, just raising a flag.  Having done so, I'll
>leave this to the WG chair to resolve.
>
>#g
>
>------------
>Graham Klyne
>([e-mail])
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00701 for ietf-smime-bks; Mon, 21 Dec 1998 13:54:47 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00697 for <[e-mail]>; Mon, 21 Dec 1998 13:54:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA14212; Mon, 21 Dec 1998 17:01:12 -0500
Message-Id: <4.1.19981221151125.009735d0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 2 (High)
Date: Mon, 21 Dec 1998 15:13:15 -0500
To: "Darren Harter" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SignerInfo Change
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Darren:

I understand your desire; however at this late stage, I a relucatnt to make
any further changes unless there is significant demand from the entire
working group.

All:

If you agree with Darren's suggestion, speak NOW!

Russ
Chair, S/MIME WG


At 10:57 AM 12/18/98 +0000, Darren Harter wrote:
>Russ,
>
>Thanks for the clarification on the reason why it was added.  I believe we 
>still have scope for extending this to a more useable form and bundling the 
>changes together.
>
>My developers complained like hell when they first encountered 
>IssuerAndSerialNumber as it's a complete nightmare when working with 
>subjectName based repositories.  Using SubjectAndKeyIdentifier would allow 
>very easy location of certs whether they were in the received SignedData or 
>not.
>
>Regards,
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail]
>Home: [e-mail]
>
>>>> Russ Housley <[e-mail]> 12/16/98 06:50pm >>>
>Darren:
>
>The reasonf or the chane is CMC support.  In this case, the signer does not
>have a certificate yet.  The point of the message is a certificate request.
> So, the signer does not have a issuer/serial number pair.  This change
>lets CMC use the SignerInfo.
>
>The reason for the MSG document change is to mangate the use of a
>issuer/serial number pair with S/MIME v3.
>
>Russ
>
>
>At 04:35 PM 12/10/98 +0000, Darren Harter wrote:
>>Russ,
>>
>>Sorry if this is a no brainer.  I couldn't make the meeting this time, so 
>>what I'm about to ask may have come up in discussion in the WG session.  As 
>>we've taken this opportunity to modify SignerInfo, would it not be a good 
>>time to add a field that may  simplify the identification of the signer's 
>>certificate even more.
>>
>>First of all let me confirm that I think it is good that the 
>>subjectKeyIdentifier has been added.  My concern is that I'm going to have 
>>to do a lot of work to find such a certificate in a simple repository that 
>>doesn't have good matching rule support.
>>
>>I propose that we instead have the following structure:
>>
>>SignerIdentifier ::= CHOICE {
>>   issuerAndSerialNumber IssuerAndSerialNumber,
>>   subjectKeyIdentifier [0] SubjectKeyIdentifier,
>>   subjectAndKeyIdentifier [1] SubjectAndKeyIdentifier }
>>
>>where,
>>
>>SubjectAndKeyIdentifer ::= SEQUENCE {
>>   subjectName Name,
>>   subjectKeyIdentifier [0] SubjectKeyIdentifier OPTIONAL }
>>
>>This will allow simple subject name look-up should an application wish to do 
>>that.  Your proposed words for the MSG spec would still stand unaltered.
>>
>>Regards,
>>
>>Darren
>>
>>-------------------------------------------------------------
>>Darren Harter BSc Hons MBCS CEng
>>CASM Technical Architect
>>CASM Programme Office
>>CESG
>>Work: [e-mail] 
>>Home: [e-mail] 
>>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00695 for ietf-smime-bks; Mon, 21 Dec 1998 13:54:40 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00690; Mon, 21 Dec 1998 13:54:38 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA14207; Mon, 21 Dec 1998 17:01:11 -0500
Message-Id: <4.1.19981221150901.0099a100@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 21 Dec 1998 15:10:12 -0500
To: "Darren Harter" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Signed Receipts
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Darren:

The recipient of a reciept must be the originator or a recipient of the
original message.  I think we should add this guidance to the document.

Russ


At 01:36 PM 12/18/98 +0000, Darren Harter wrote:
>Paul/Russ,
>
>I've been looking through the Signed Receipts section of ESS again, and I 
>believe I may have found an ommision.
>
>Let me set the scene...
>
>In order to validate a receipt, you need to have the original message (or at 
>least a digest of it).  Clearly if you are the "Sender" you would have this.
>
>The receipt request structure contains a ReceiptsTo element, where the 
>originator must specify their own address if they wish to receive the 
>receipt messages.
>
>What if you're not the originator but are named on the ReceiptsTo list.  How 
>do you validate the receipt message without having access to the original 
>message (or digest of it) - clearly you can't.
>
>If the original message is copied to the entities on the ReceiptsTo list 
>this would be avoided.  There is the potential problem of a receipt message 
>being received before the message that it corresponds to but this can be 
>dealt with quite easily.
>
>I suggest that we add new paragraphs somewhere to ESS along the following 
>lines:
>
>"In order to allow the returned receipt message to be validated by all 
>entities named in the receiptsTo field of the receipt request attribute, the 
>Sender SHOULD ensure that the original message is copied to all such entities.
>
>It is possible that a receipt message may be received before the original 
>message that it corresponds to.  When such a receipt message is received, 
>the recipient SHOULD store the receipt message for later validation.
>
>When a recipient of a message is named on the ReceiptTo list in a 
>receiptRequest attribute, they SHOULD ensure that sufficient information is 
>retained from the message to allow validation of any associated receipt 
>messages that are subsequently received.  The recipient SHOULD immediately 
>validate any receipt messages that were received prior to message reception."
>
>I've used SHOULDs here to allow for the situation where an entity on the 
>ReceiptsTo list is being used as a non-validating receipt sink.
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail]
>Home: [e-mail]
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00689 for ietf-smime-bks; Mon, 21 Dec 1998 13:54:38 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00685 for <[e-mail]>; Mon, 21 Dec 1998 13:54:37 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA14226; Mon, 21 Dec 1998 17:01:15 -0500
Message-Id: <4.1.19981221165945.00976630@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 21 Dec 1998 17:01:23 -0500
To: "Andrew Farrell" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on drafts.
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Andrew:

>cms-09.txt:
>
>1: Reference to MUSTSHOULD?

Why?  The document does not capitalize those words.

>1: The first sentence is the same as the first sentence from the Abstract, 
>but missing authentication or digesting.
>
>5.1: Last two paragraphs belong in 5.2
>
>11: The attributes defined can also presumably be used in enveloped-data. I 
>can't actually see how or why, but there's a pointer from 6.1 to here.

None of these are a big deal.  I will add them if a version 11 is needed.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29089 for ietf-smime-bks; Mon, 21 Dec 1998 10:41:46 -0800 (PST)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA29085 for <[e-mail]>; Mon, 21 Dec 1998 10:41:45 -0800 (PST)
Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 21 Dec 1998 18:45:56 UT
Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id NAA15287 for <[e-mail]>; Mon, 21 Dec 1998 13:55:53 -0500 (EST)
Received: by exna01.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <YY4RG6PR>; Mon, 21 Dec 1998 13:48:18 -0500
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'IETF SMIME list'" <[e-mail]>
Subject: key preferences, usages, and S/MIME recipients
Date: Mon, 21 Dec 1998 13:51:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In reading sections 2.5.3 and 2.5.3.1 of msg-05, I'm wondering about the
possibilities where an S/MIME recipient may receive a message encrypted with
a key which doesn't match its encryption key preference, and about what that
recipient can and should do under such circumstances.  

In the last sentence of 2.5.3, I'm presuming that the statement, "... the
receiving agent may use any certificate in replying to the sender that is
valid" implies that the certificate's key usage extension (if present)
should be checked to verify that it allows key management operations.  It's
clear that a recipient must be able to accommodate suitable certificates
diverging from its intended preference. What's a conformant recipient to do,
however, if a message is generated for it using a encryption key which not
only doesn't match its encryption key preference but whose referenced
certificate doesn't permit key management usage?  I'm not sure how
comprehensively an S/MIME recipient is expected to process and validate *its
own* certificates, when encountered as references identifying the key(s)
used to encrypt messages sent to it. In a spirit of conditionally liberal
acceptance despite erroneously non-conservative generation, I'd propose that
local policy and configuration should control whether a recipient system is
allowed to decrypt such a message, and whether the associated user is to be
warned or consulted for confirmation before proceeding.  Does anyone's
interpretation disagree, and would this case be worth noting in MSG and/or
CERT?

Regards, ...

--jl


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28270 for ietf-smime-bks; Mon, 21 Dec 1998 08:56:30 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28266 for <[e-mail]>; Mon, 21 Dec 1998 08:56:30 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id JAA10295; Mon, 21 Dec 1998 09:03:49 -0800 (PST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
References: <[e-mail]> <[e-mail]>
From: EKR <[e-mail]>
Date: 21 Dec 1998 09:03:48 -0800
In-Reply-To: EKR's message of "21 Dec 1998 07:17:05 -0800"
Message-ID: <[e-mail]>
Lines: 19
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

EKR <[e-mail]> writes:
> I don't agree with your characterization that a DH static key is
> 'insecure due to reuse'. While it's true that a common group makes
> common group, because fewer computations are required to actually send
> a message, the group can be substantially larger while still retaining
> good performance.
Ooops. This should read:

I don't agree with your characterization that a DH static key is
'insecure due to reuse'.  While it's true that a common group makes an
attractive target, because fewer computations are required to actually
send a message, the group can be substantially larger while still
retaining good performance.

-Ekr


-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27566 for ietf-smime-bks; Mon, 21 Dec 1998 07:10:04 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27562 for <[e-mail]>; Mon, 21 Dec 1998 07:10:02 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id HAA09442; Mon, 21 Dec 1998 07:17:06 -0800 (PST)
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on the use of DH in S/MIME
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 21 Dec 1998 07:17:05 -0800
In-Reply-To: [e-mail]'s message of "Mon, 21 Dec 1998 19:51:31 (NZDT)"
Message-ID: <[e-mail]>
Lines: 141
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

[e-mail] (Peter Gutmann) writes:
> Well OK, a bit of a rant rather than just comments...
Peter, I'm having a lot of trouble understanding what you're
actually complaining about here. I've done a lot of trimming
to separate out the actual comments from the ranting, but
if I've overtrimmed, feel free to restore the relevant
material.

>Now let's look at the way it's applied here.  A rough outline of what's 
>contained in KeyAgreeRecipientInfo is:
 
>  originatorDH  -- Originators DH values p, g, y = g^x mod p
>  recipientDH   -- Recipients fixed DH values p, g, y' = g^x' mod p
>  nonce         -- Extra material to mix in to ensure different keys are 
>                   produced
This is incorrect. Here's the ASN.1 for reference:

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

      RecipientEncryptedKey ::= SEQUENCE {
        rid KeyAgreeRecipientIdentifier,
        encryptedKey EncryptedKey }

      KeyAgreeRecipientIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        rKeyId [0] IMPLICIT RecipientKeyIdentifier }

The originator's information consists of the originator's public
key (y) only.
The recipient's information is a pointer to the recipient's certificate
indicated by issuerserial or by keyid. At no time is the recipient's
keying material explicitly in the message. In point of fact, this
same ASN.1 type RecipientIdentifier, is pointed to by 
KeyTransRecipientInfo.

The ukm is indeed a nonce intended to differentiate keys generated
by the same DH originator-recipient pairs.

> As a result you either end 
> up with a solution which is of questionable security due to use and re-use of 
> widely-shared public values, or which is extremely expensive and practically 
> impossible to manage because you need to have a certified DH public key 
> corresponding to each recipients DH key (CMS tries to kludge around this by 
> requiring the use of originatorKey, an uncertified, unauthenticated DH public 
> value).
This is the expected mode of operation. Whether it's a kludge or not
is a matter of opinion, I suppose.

> Anyway, moving past this, you either have a DH static key (inexpensive but 
> insecure due to reuse), a DH ephemeral key (expensive since you need a new 
> cert issued for each key),
> or the abovementioned unauthenticated DH public 
> value 
It was never intended that you would have a certified public key for
each recipient's DH key if a large number of groups were in use. The
only two reasonable options are Static-Static with a few (1?) groups
(presumably in a closed community) and Ephemeral-Static.  

I don't agree with your characterization that a DH static key is
'insecure due to reuse'. While it's true that a common group makes
common group, because fewer computations are required to actually send
a message, the group can be substantially larger while still retaining
good performance. However, it's not reuse that's the problem here.
Provided that you use pubInfo (and you MUST if you reuse keys),
it's fine to have a static key.

>(again, CMS explicitly requires the use of a static key for the 
> recipient). 
Of course it does; it's in his certificate. This would be a requirement
with ElGamal as well. The point here is that you have 1 static key
which you use to receive messsages and that you generate a new
ephemeral key for each group every time you send a message,
just as you would with ElGamal. [0]

Perhaps it would be a useful exercise to review ES-DH (the required
mode) and ElGamal side by side, from the Originator's perspective:
Assume that the receiver's key is Yr and the group is g,q,p.
ES-DH                                  ElGamal
1. Generate random Xo.                 1. Generate random Xo.
2. Y=g^Xo mod p.                       2. Compute Y=g^Xo mod p.
3. ZZ=Yr^Xo mod p.                     3. ZZ=Yr^Xo mod p
4. KEK=H(ZZ,...)                       4. PM=Pad M to fit in p.
5. Wrapped Key=3DES(KEK,MEK || H(MEK)) 5. Wrapped key = PM * ZZ
6. Send Y,Wrapped Key                  6. Send Y,wrapped Key

So, in point of fact, the only difference between ElGamal and and
ES-DH is how you wrap the DH key (steps 4,5), and I don't think that
this particularly favors ElGamal, either in terms of security of
implementation complexity. I don't specify step 4 of ElGamal above,
but it SHOULD be OAEP, in which case it's certainly not any simpler
than the X9.42 key expansion transform. The CMS wrapping algorithm
(step 5) is a little tricky, but not overly so.


So, you might ask, given that these schemes are so similar, why favor
X9.42?

Basically, it's more flexible. In particular, its best case behavior
is much faster.

As noted above, it can be run in a Static-Static mode which requires
half as many modular exponentiations as either ElGamal or ES, and also
provides Data Origin Authentication. If you cache ZZ, the number of
exponentiations per message drops to zero (a la SKIP). Also, of
course, in a closed community, you can arrange to hardwire the group
and thus reduce the certificate size substantially.

Moreover, because of the pubInfo input to the key expansion, even the
ES mode can optimized by caching the generated ephemeral keys, with
the consequence that repeated transactions with the same party can be
very fast. [1]

I don't know of any balancing technical advantages to ElGamal.
        
So, exactly what features of the current X9.42 draft are you
complaining about? Your message implies that the problem is
implementation complexity, but I don't see where that complexity is
supposed to lie.

On the other hand, if your problem is a matter of taste, de gustibus
non est disputandum.

-Ekr

[0] I suppose you could have an ephemeral recipient key as well, but
you wouldn't explicitly place it in the message, you'd merely refer to
it by KeyId (or not at all, if it was somehow externally specified.)
In any case, the syntax allows this case, if somewhat implicitly. It
may be banned in the document text somewhere.

[1] It's possible that you could perform this optimization with
ElGamal, provided that your padding function was sufficiently
strong. Anyone know?

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA22377 for ietf-smime-bks; Sun, 20 Dec 1998 22:45:19 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA22372 for <[e-mail]>; Sun, 20 Dec 1998 22:45:17 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id TAA26178 for <[e-mail]>; Mon, 21 Dec 1998 19:51:32 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91422309103645>; Mon, 21 Dec 1998 19:51:31 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Some comments on the use of DH in S/MIME
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 21 Dec 1998 19:51:31 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Well OK, a bit of a rant rather than just comments...
 
I've had a go at implementing this, and after stuffing around with it for 
awhile I've come to the conclusion that this option must have been designed by 
RSADSI to make the alternative of getting a patent license to use 
KeyTransRecipientInfo look good[0].  What a mess!  Consider the most obvious 
use for DH keying material, which is to use it in Elgamal as per the existing 
KeyTransRecipientInfo and RFC TBA, the X.509 profile for Elgamal.  All it 
takes is a few lines of code to use it with existing mechanisms.
 
Now let's look at the way it's applied here.  A rough outline of what's 
contained in KeyAgreeRecipientInfo is:
 
  originatorDH  -- Originators DH values p, g, y = g^x mod p
  recipientDH   -- Recipients fixed DH values p, g, y' = g^x' mod p
  nonce         -- Extra material to mix in to ensure different keys are 
                   produced
 
First of all, both sender and recipient need to somehow agree on using the 
same p and g values, which means either everyone shares the same values 
(presumably these will be ones for which the NSA et al have performed the 
necessary precomputations to make solving the DLP easier), or alternatively 
you need to get a new certificate for each users values (OK, looks like 
Verisign were in on designing this thing as well).  As a result you either end 
up with a solution which is of questionable security due to use and re-use of 
widely-shared public values, or which is extremely expensive and practically 
impossible to manage because you need to have a certified DH public key 
corresponding to each recipients DH key (CMS tries to kludge around this by 
requiring the use of originatorKey, an uncertified, unauthenticated DH public 
value).
 
Anyway, moving past this, you either have a DH static key (inexpensive but 
insecure due to reuse), a DH ephemeral key (expensive since you need a new 
cert issued for each key), or the abovementioned unauthenticated DH public 
value (again, CMS explicitly requires the use of a static key for the 
recipient).  Since the DH exchange with fixed parameters always produces the 
same output, you also need to mix in extra keying material in a further kludge 
to try and shoehorn straight DH into functioning as a form of key transport 
mechanism.
                "To walk right past the correct solution and come up with this 
                 takes some beating" 
                        - Comment from someone who reviewed this rant
 
I realise there's probably some sort of motivation to try and do something 
with X9.42, but do we really have to jump off a cliff just because X9.42 does 
as well?  
                "Just because it's possible to push a pea up a mountain with 
                 your nose doesn't mean that this is a good way of getting it 
                 there"
                        - Chris Strachey
 
Why not just change the requirements to:
 
  "Implementations MUST support key transport using Elgamal.  Implementations 
   MAYM[1] include key agreement using X9.42 Ephemeral-Static Diffie Hellman".
 
This provides a straightforward nonpatented alternative to RSA which uses DH 
keys just as KeyTransRecipientInfo does (so it's possible to claim compliance 
to X9.42 or reference it in the spec or include it in the product advertising 
or whatever the rationale for working with it is) while still having something 
which is practical and simple to implement.
 
Peter (and I made it right through that without including the "looks like the 
       winning candidate from a 'Worst way to apply DH to a key management 
       problem' competition" comment :-).
 
[0] This is satire folks, not intended as a slight on RSADSI.
[1] "MAY if the implementors are Masochists".  An alternative is MAYEURKW, 
    "MAY if they Enjoy Unnecessary Root Canal Work".



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA11972 for ietf-smime-bks; Fri, 18 Dec 1998 05:35:11 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA11965; Fri, 18 Dec 1998 05:35:03 -0800 (PST)
Received: by access.itsec.gov.uk; id AA02462; Fri, 18 Dec 98 13:29:35 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma002455; Fri, 18 Dec 98 13:29:11 GMT
Received: by ingress.itsec.dmz; id AA25160; Fri, 18 Dec 98 13:30:28 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma025150; Fri, 18 Dec 98 13:30:14 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Fri, 18 Dec 1998 13:28:48 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Fri, 18 Dec 1998 13:36:58 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Signed Receipts
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA11968
Sender: [e-mail]
Precedence: bulk

Paul/Russ,

I've been looking through the Signed Receipts section of ESS again, and I believe I may have found an ommision.

Let me set the scene...

In order to validate a receipt, you need to have the original message (or at least a digest of it).  Clearly if you are the "Sender" you would have this.

The receipt request structure contains a ReceiptsTo element, where the originator must specify their own address if they wish to receive the receipt messages.

What if you're not the originator but are named on the ReceiptsTo list.  How do you validate the receipt message without having access to the original message (or digest of it) - clearly you can't.

If the original message is copied to the entities on the ReceiptsTo list this would be avoided.  There is the potential problem of a receipt message being received before the message that it corresponds to but this can be dealt with quite easily.

I suggest that we add new paragraphs somewhere to ESS along the following lines:

"In order to allow the returned receipt message to be validated by all entities named in the receiptsTo field of the receipt request attribute, the Sender SHOULD ensure that the original message is copied to all such entities.

It is possible that a receipt message may be received before the original message that it corresponds to.  When such a receipt message is received, the recipient SHOULD store the receipt message for later validation.

When a recipient of a message is named on the ReceiptTo list in a receiptRequest attribute, they SHOULD ensure that sufficient information is retained from the message to allow validation of any associated receipt messages that are subsequently received.  The recipient SHOULD immediately validate any receipt messages that were received prior to message reception."

I've used SHOULDs here to allow for the situation where an entity on the ReceiptsTo list is being used as a non-validating receipt sink.

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA09543 for ietf-smime-bks; Fri, 18 Dec 1998 03:04:34 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA09532 for <[e-mail]>; Fri, 18 Dec 1998 03:04:29 -0800 (PST)
Received: by access.itsec.gov.uk; id AA01736; Fri, 18 Dec 98 10:58:58 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma001723; Fri, 18 Dec 98 10:58:30 GMT
Received: by ingress.itsec.dmz; id AA24289; Fri, 18 Dec 98 10:59:48 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma024282; Fri, 18 Dec 98 10:59:43 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Fri, 18 Dec 1998 10:58:16 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Fri, 18 Dec 1998 10:57:47 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: SignerInfo Change
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA09538
Sender: [e-mail]
Precedence: bulk

Russ,

Thanks for the clarification on the reason why it was added.  I believe we still have scope for extending this to a more useable form and bundling the changes together.

My developers complained like hell when they first encountered IssuerAndSerialNumber as it's a complete nightmare when working with subjectName based repositories.  Using SubjectAndKeyIdentifier would allow very easy location of certs whether they were in the received SignedData or not.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]

>>> Russ Housley <[e-mail]> 12/16/98 06:50pm >>>
Darren:

The reasonf or the chane is CMC support.  In this case, the signer does not
have a certificate yet.  The point of the message is a certificate request.
 So, the signer does not have a issuer/serial number pair.  This change
lets CMC use the SignerInfo.

The reason for the MSG document change is to mangate the use of a
issuer/serial number pair with S/MIME v3.

Russ


At 04:35 PM 12/10/98 +0000, Darren Harter wrote:
>Russ,
>
>Sorry if this is a no brainer.  I couldn't make the meeting this time, so 
>what I'm about to ask may have come up in discussion in the WG session.  As 
>we've taken this opportunity to modify SignerInfo, would it not be a good 
>time to add a field that may  simplify the identification of the signer's 
>certificate even more.
>
>First of all let me confirm that I think it is good that the 
>subjectKeyIdentifier has been added.  My concern is that I'm going to have 
>to do a lot of work to find such a certificate in a simple repository that 
>doesn't have good matching rule support.
>
>I propose that we instead have the following structure:
>
>SignerIdentifier ::= CHOICE {
>   issuerAndSerialNumber IssuerAndSerialNumber,
>   subjectKeyIdentifier [0] SubjectKeyIdentifier,
>   subjectAndKeyIdentifier [1] SubjectAndKeyIdentifier }
>
>where,
>
>SubjectAndKeyIdentifer ::= SEQUENCE {
>   subjectName Name,
>   subjectKeyIdentifier [0] SubjectKeyIdentifier OPTIONAL }
>
>This will allow simple subject name look-up should an application wish to do 
>that.  Your proposed words for the MSG spec would still stand unaltered.
>
>Regards,
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail] 
>Home: [e-mail] 
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA12076 for ietf-smime-bks; Thu, 17 Dec 1998 10:08:30 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA12072 for <[e-mail]>; Thu, 17 Dec 1998 10:08:29 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id NAA21895; Thu, 17 Dec 1998 13:13:14 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 17 Dec 1998 13:09:56 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Comment on CERTDIST-02
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim,

I understand that the S/MIME working group had to create the
SMimeEncryptionCerts attribute because the X.509 "supported algorithms"
attribute is not an authenticated attribute and it is not bound to a given
certificate. The SMimeEncryptionCerts attribute 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.

However, could not similar results be achieved if the SMimeCapabilities
attribute was instead stored as an attribute of an X.509 Attribute
Certificate that is bound to a user's X.509 public key certificate?

Francois Rousseau
AEPOS Technologies


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA11894 for ietf-smime-bks; Thu, 17 Dec 1998 09:49:33 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11890 for <[e-mail]>; Thu, 17 Dec 1998 09:49:31 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <Y3K80STX>; Thu, 17 Dec 1998 09:52:48 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B64@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: December WG Minutes
Date: Thu, 17 Dec 1998 09:52:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE29E6.0E507B88"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BE29E6.0E507B88
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here are the proposed minutes.=A0 Comment if you feel it is necessary.
jim
All,
This message includes the minutes of the IETF S/MIME Working Group (WG) =

meeting held on 9 December 1998 in Orlando, FL. These minutes have been
coordinated with the briefing presenters. All briefing slides are =
stored
at: ftp://ftp.ietf.org/ietf/smime/ <ftp://ftp.ietf.org/ietf/smime/> .
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Introductions - Russ Housley
Russ reviewed the agenda. Nobody objected the agenda.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CMS Draft Discussion - Russ Housley
Russ presented the current status on the CMS draft. The document is
currently in Working Group last call and will remain there until the =
X9.42
draft has finished its last call. The majority of the comments since =
the
last meeting have focused on Section 12. (This is the section on =
algorithms=20
and key wrapping support.) The comments received to date have been=20
incorporated in draft 10 which should be distributed soon.
Key Wrapping Algorithm: Several changes have been made to the key=20
algorithm and some comments on it have been received since the last WG=20
meeting. The algorithm has been found to be unsecure with stream cipher =

algorithms and block ciphers in OFB mode. A statement to this effect =
will
be placed in the document.
Russ stated that several people have asked for a modification to the =
check
sum algorithm be made. People are worried about the arithmetic nature =
of=20
the algorithm. Additionally, there was a question on moving from 16 to =
32=20
bits in size. Russ reviewed the key wrap and unwrap algorithms as part =
of=20
this discussion.
Several people indicated that they felt better using the left-most bits =
of=20
a SHA-1 hash rather than the current Fletcher checksum. However, if the =

change was made, the checksum size should be increased to 32 bits. Jim=20
Schaad raised a potential problem in that moving to 32 bits changed the =

block alignment. (32 bits of salt and 32 bits of checksum make a full 8
octet Triple-DES or RC2 block, thus a full block of pad will be =
needed.)=20
After a fair amount of discussion, the WG decided to change the =
checksum
algorithm to the left-most 64 bits of the SHA-1 hash of the key =
material.
This takes advantage of the one-way nature of SHA-1 and provides a =
longer
integrity check value without increasing the size of the wrapped key.
Russ stated that several people has requested that once the CMS drafts =
are=20
finished a four week rather than the normal two week IETF last call be=20
requested. This request was based on the fact that the algorithms =
really=20
need to have a wider review before being placed in proposed standard =
form.
The WG concurred.
Russ then asked for any other unresolved issued on CMS.=20
Jim Schaad brought up the question of placing Subject Key Identifier =
(SKI)
into the SignerInfo structure. Jim proposed that the SKI be added to =
CMS,
however a statement be added to MSG that only the issuer and serial =
number
choice may be used in S/MIME version 3. A discussion followed where two
possible uses of SKI would be of use. The first would be to allow for =
PGP
keys to be referenced in a CMS object. The second related to the
Certificate Management over CMS (CMC) internet-draft in the PKIX =
working
group. After some discussion the proposal was adopted by the working =
group.
Denis Pinkas raised an issue that he thought section 5.6 (signature
verification process) was confusing and he had posted a message to this
effect. Russ requested that he repost the message to the list.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
X9.42 Draft Discussion - Eric Rescorla
Eric next presented the changes and plans for the X9.42 draft. Text has
been included in the draft to provide a standard way to produce the =
group
parameters for q >=3D 160. A statement that q must be at least 160 is =
being
included into the draft. With this set of changes the draft should be =
ready
for WG last call.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CERT Draft Discussion - Paul Hoffman (for Blake Ramsdell)
Paul presented this and the CERT draft discussion on behalf of Blake =
who was
unable to make the meeting. Paul stated that only minor changes have =
been
made to the drafts since the last meeting. The most significant of =
these
dealt with making some terms about entities clearer and more =
consistent.
Paul stated that no new draft has been posted since the last working =
group
meeting but one should be expected soon.
An issue was raised that the last paragraph in section 3.1 is now =
redundant
as the NULL Subject DN on end-entity certificates is no longer =
permitted by
the PKIX documents.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
MSG Draft Discussion - Paul Hoffman (for Blake Ramsdell)
Paul stated that no significant changes have been made to the MSG draft
since the last meeting. The most significant editorial changes have =
been=20
clarification about attribute counts in section 2.5, text clarification =
on
section 2.5.3 and a change to the Triple-DES reference. An updated =
draft
should be posted soon.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ESS Draft Discussion - Paul Hoffman
Paul stated that no significant changes have been made to the ESS draft
since the last meeting beyond the inclusion of the SigAttr section. =
Paul
stated that he would do some rewrites on the introduction to make it =
easier
to find the assorted attributes which have been added to the draft.
Issues raised from the floor on the ESS draft were:
1) Denis Pinkas requested that the Signature Cert attribute be moved =
from=20
the ESS draft to the CMS draft. He stated that this attribute is needed =
in
order to be able to make a clear statement on signature verification. =
After
some discussion a straw poll was taken on the placement of the =
attribute=20
with a majority preferring to keep the attribute in the ESS draft.
2) Andrew Farrell stated that section 4.2.2 was missing from the =
numbering.
3) Andrew Farrell stated that there appeared to be a large amount of=20
redundancy between the processing of secure receipts in the subsections =
of
4.2.3. Paul explained that his opinion was that the text would be =
harder to
read if the three different cases were collapsed into a single section.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CERTDIST Draft Discussion - Jim Schaad
Jim stated that no significant changes have been made since the last WG
meeting. Following the successful progression of the other drafts and =
final
edits to the Security Considerations section the document will move to =
WG
Last Call.
Two issues were raised from the floor:
1. Andrew Farrell raied two content issues: Need an OID for the LDAP =
schema
and section 4.4 has an error in the flow chart.
2. Andrew Farrell requested that an example to be added as a new =
appendix.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DOMSEC Draft Discussion - Bill Ottaway
Bill stated that changes to the draft included the inclusion of =
multiple
signature types were added to the draft and clarification of the text =
on
parallel and encapsulated signatures were added.
Several issues were raised from the floor:
Eric Rescorla made a statement about a problem with parallel signatures =

where an entity could remove the originator signature and substitute =
their
own. Bill said he would take this comment under advisement.
Bill then asked for guidance if the draft should go to informational or
standard track. Paul Hoffman suggested that the appropriate place may =
be
experimental unless others are going to implement. A straw poll of the=20
group favored moving the draft to experimental. The WG agreed that if a
significant number of implementors emerge, then it can be moved to the
standards track.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Request: CEK Key Mgmt - Frank Siebenlist
Frank made a presentation about a request to modify CMS to allow for =
the
use of a shared content-encryption key (CEK) without the overhead of
wrapping with a key-encryption key (KEK). This would allow session =
based
protocols (such as TLS) to use CMS as a building block. As part of this
presentation a set of suggested ASN.1 changes to accomplish this were
presented.
Eric Rescorla raised immediate concerns that it is not good practice to
re-use an CEK especially in a persistent storage format. Many others
agreed this was a problem. Frank responded that the change was only for
session-based protocols and session-based protocols all suffered from =
this
re-use "problem".
Jim Schaad presented an alternate method of doing what was desired by =
the
creation of a new KEK algorithm which performed an identity transform =
from
the KEK to the CEK and would require no changes to existing CMS draft. =
The
proposal could then stand on its own merits. A straw poll showed the =
group
favored this approach to the problem.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Open PGP Compatibility - Jon Callas
Jon made an argument that there were some changes that could be made to =
the
CMS, MSG and CERT drafts which would allow for easy use of PGP keys to =
be
used for wrapping CEKs. Specifically, if the MUST on usage of=20
IssuerAndSerialNumber in MSG is relaxed to a SHOULD then the SKI option =

could reference PGP keys.
Eric Rescorla stated that while this would give a potential way of =
dealing
with PGP keys, the message differences would still not be addressed and =

questioned if this should not be done all at once.
Paul Hoffman stated that allowing this would lead to backwards =
compatibility
problems with existing S/MIME implementations as they could not =
correctly
verify such signatures.
After some discussion the suggestion was made that a document should be
presented to the group which identified all of the incompatibly issues =
and
presented possible solutions that could be used to fix a sufficient set =
for
interoperability. The WG concurred with this approach. Jon agreed to =
post
an internet-draft.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
New Samples Document - Paul Hoffman
Paul made a presentation for the creation of a new document providing =
CMS
examples. The overview of the document would be a short introduction, a =

basic example of each content type and advanced examples of different =
types.
Consistent data on keys would be used through out the entire set of
examples. The timing of this document is such that it would not be =
started
until the CMS draft has moved to the RFC editors.
It was suggested that the document include some incorrect examples that =
flag
common implementation errors. Paul agreed to add a section for these.
Paul is only going to coordinate putting this document together. If=20
individuals would like to volunteer to do examples they should contact =
Paul
at [e-mail] <mailto:[e-mail]> .
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ACTION ITEMS:
1. Change the Checksum algorithm in CMS (Russ Housley)
2. Add SKI to SignerInfo (Russ Housley)
3. Add SKI restriction to the MSG draft (Blake Ramsdell)
4. Require IssuerAndSerialNumber in SigAttr (Paul Hoffman)
5. Post PGP Compatability Internet-Draft (Jon Callas)


------_=_NextPart_001_01BE29E6.0E507B88
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.1012.1004" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Here are the 
proposed minutes.&nbsp; Comment if you feel it is necessary.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998></SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>jim</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998></SPAN></FONT></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>All,</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>This message 
includes the minutes of the IETF S/MIME Working Group (WG) <BR>meeting held on 9 
December 1998 in Orlando, FL.  These minutes have been<BR>coordinated with the 
briefing presenters.  All briefing slides are stored<BR>at: <A 
href="ftp://ftp.ietf.org/ietf/smime/">ftp://ftp.ietf.org/ietf/smime/</A>.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Introductions - Russ 
Housley</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Russ reviewed the 
agenda.  Nobody objected the agenda.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>CMS Draft Discussion 
- Russ Housley</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Russ presented the 
current status on the CMS draft.  The document is<BR>currently in Working Group 
last call and will remain there until the X9.42<BR>draft has finished its last 
call.  The majority of the comments since the<BR>last meeting have focused on 
Section 12. (This is the section on algorithms <BR>and key wrapping support.)  
The comments received to date have been <BR>incorporated in draft 10 which 
should be distributed soon.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Key Wrapping 
Algorithm:  Several changes have been made to the key <BR>algorithm and some 
comments on it have been received since the last WG <BR>meeting.  The algorithm 
has been found to be unsecure with stream cipher <BR>algorithms and block 
ciphers in OFB mode.  A statement to this effect will<BR>be placed in the 
document.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Russ stated that 
several people have asked for a modification to the check<BR>sum algorithm be 
made.  People are worried about the arithmetic nature of <BR>the algorithm.  
Additionally, there was a question on moving from 16 to 32 <BR>bits in size.  
Russ reviewed the key wrap and unwrap algorithms as part of <BR>this 
discussion.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Several people 
indicated that they felt better using the left-most bits of <BR>a SHA-1 hash 
rather than the current Fletcher checksum.  However, if the <BR>change was made, 
the checksum size should be increased to 32 bits.  Jim <BR>Schaad raised a 
potential problem in that moving to 32 bits changed the <BR>block alignment.  
(32 bits of salt and 32 bits of checksum make a full 8<BR>octet Triple-DES or 
RC2 block, thus a full block of pad will be needed.)  </SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>After a fair amount 
of discussion, the WG decided to change the checksum<BR>algorithm to the 
left-most 64 bits of the SHA-1 hash of the key material.<BR>This takes advantage 
of the one-way nature of SHA-1 and provides a longer<BR>integrity check value 
without increasing the size of the wrapped key.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Russ stated that 
several people has requested that once the CMS drafts are <BR>finished a four 
week rather than the normal two week IETF last call be <BR>requested.  This 
request was based on the fact that the algorithms really <BR>need to have a 
wider review before being placed in proposed standard form.<BR>The WG 
concurred.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Russ then asked for 
any other unresolved issued on CMS.  </SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Jim Schaad brought 
up the question of placing Subject Key Identifier (SKI)<BR>into the SignerInfo 
structure.  Jim proposed that the SKI be added to CMS,<BR>however a statement be 
added to MSG that only the issuer and serial number<BR>choice may be used in 
S/MIME version 3.  A discussion followed where two<BR>possible uses of SKI would 
be of use.  The first would be to allow for PGP<BR>keys to be referenced in a 
CMS object.  The second related to the<BR>Certificate Management over CMS (CMC) 
internet-draft in the PKIX working<BR>group.  After some discussion the proposal 
was adopted by the working group.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Denis Pinkas raised 
an issue that he thought section 5.6 (signature<BR>verification process) was 
confusing and he had posted a message to this<BR>effect.  Russ requested that he 
repost the message to the list.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>X9.42 Draft 
Discussion - Eric Rescorla</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Eric next presented 
the changes and plans for the X9.42 draft.  Text has<BR>been included in the 
draft to provide a standard way to produce the group<BR>parameters for q &gt;= 
160.  A statement that q must be at least 160 is being<BR>included into the 
draft.  With this set of changes the draft should be ready<BR>for WG last 
call.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>CERT Draft 
Discussion - Paul Hoffman (for Blake Ramsdell)</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Paul presented this 
and the CERT draft discussion on behalf of Blake who was<BR>unable to make the 
meeting.  Paul stated that only minor changes have been<BR>made to the drafts 
since the last meeting.  The most significant of these<BR>dealt with making some 
terms about entities clearer and more consistent.<BR>Paul stated that no new 
draft has been posted since the last working group<BR>meeting but one should be 
expected soon.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>An issue was raised 
that the last paragraph in section 3.1 is now redundant<BR>as the NULL Subject 
DN on end-entity certificates is no longer permitted by<BR>the PKIX 
documents.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>MSG Draft Discussion 
- Paul Hoffman (for Blake Ramsdell)</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Paul stated that no 
significant changes have been made to the MSG draft<BR>since the last meeting.  
The most significant editorial changes have been <BR>clarification about 
attribute counts in section 2.5, text clarification on<BR>section 2.5.3 and a 
change to the Triple-DES reference.  An updated draft<BR>should be posted 
soon.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>ESS Draft Discussion 
- Paul Hoffman</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Paul stated that no 
significant changes have been made to the ESS draft<BR>since the last meeting 
beyond the inclusion of the SigAttr section.  Paul<BR>stated that he would do 
some rewrites on the introduction to make it easier<BR>to find the assorted 
attributes which have been added to the draft.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Issues raised from 
the floor on the ESS draft were:</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>1) Denis Pinkas 
requested that the Signature Cert attribute be moved from <BR>the ESS draft to 
the CMS draft.  He stated that this attribute is needed in<BR>order to be able 
to make a clear statement on signature verification.  After<BR>some discussion a 
straw poll was taken on the placement of the attribute <BR>with a majority 
preferring to keep the attribute in the ESS draft.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>2) Andrew Farrell 
stated that section 4.2.2 was missing from the numbering.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>3) Andrew Farrell 
stated that there appeared to be a large amount of <BR>redundancy between the 
processing of secure receipts in the subsections of<BR>4.2.3.  Paul explained 
that his opinion was that the text would be harder to<BR>read if the three 
different cases were collapsed into a single section.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>CERTDIST Draft 
Discussion - Jim Schaad</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Jim stated that no 
significant changes have been made since the last WG<BR>meeting.  Following the 
successful progression of the other drafts and final<BR>edits to the Security 
Considerations section the document will move to WG<BR>Last 
Call.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Two issues were 
raised from the floor:</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>1. Andrew Farrell 
raied two content issues: Need an OID for the LDAP schema<BR>and section 4.4 has 
an error in the flow chart.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>2. Andrew Farrell 
requested that an example to be added as a new appendix.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>DOMSEC Draft 
Discussion - Bill Ottaway</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Bill stated that 
changes to the draft included the inclusion of multiple<BR>signature types were 
added to the draft and clarification of the text on<BR>parallel and encapsulated 
signatures were added.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Several issues were 
raised from the floor:</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Eric Rescorla made a 
statement about a problem with parallel signatures <BR>where an entity could 
remove the originator signature and substitute their<BR>own.  Bill said he would 
take this comment under advisement.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Bill then asked for 
guidance if the draft should go to informational or<BR>standard track.  Paul 
Hoffman suggested that the appropriate place may be<BR>experimental unless 
others are going to implement.  A straw poll of the <BR>group favored moving the 
draft to experimental.  The WG agreed that if a<BR>significant number of 
implementors emerge, then it can be moved to the<BR>standards 
track.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Request: CEK Key 
Mgmt - Frank Siebenlist</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Frank made a 
presentation about a request to modify CMS to allow for the<BR>use of a shared 
content-encryption key (CEK) without the overhead of<BR>wrapping with a 
key-encryption key (KEK).  This would allow session based<BR>protocols (such as 
TLS) to use CMS as a building block. As part of this<BR>presentation a set of 
suggested ASN.1 changes to accomplish this 
were<BR>presented.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Eric Rescorla raised 
immediate concerns that it is not good practice to<BR>re-use an CEK especially 
in a persistent storage format.  Many others<BR>agreed this was a problem.  
Frank responded that the change was only for<BR>session-based protocols and 
session-based protocols all suffered from this<BR>re-use 
"problem".</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Jim Schaad presented 
an alternate method of doing what was desired by the<BR>creation of a new KEK 
algorithm which performed an identity transform from<BR>the KEK to the CEK and 
would require no changes to existing CMS draft.  The<BR>proposal could then 
stand on its own merits.  A straw poll showed the group<BR>favored this approach 
to the problem.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Open PGP 
Compatibility - Jon Callas</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Jon made an argument 
that there were some changes that could be made to the<BR>CMS, MSG and CERT 
drafts which would allow for easy use of PGP keys to be<BR>used for wrapping 
CEKs.  Specifically, if the MUST on usage of <BR>IssuerAndSerialNumber in MSG is 
relaxed to a SHOULD then the SKI option <BR>could reference PGP 
keys.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Eric Rescorla stated 
that while this would give a potential way of dealing<BR>with PGP keys, the 
message differences would still not be addressed and <BR>questioned if this 
should not be done all at once.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Paul Hoffman stated 
that allowing this would lead to backwards compatibility<BR>problems with 
existing S/MIME implementations as they could not correctly<BR>verify such 
signatures.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>After some 
discussion the suggestion was made that a document should be<BR>presented to the 
group which identified all of the incompatibly issues and<BR>presented possible 
solutions that could be used to fix a sufficient set for<BR>interoperability.  
The WG concurred with this approach.  Jon agreed to post<BR>an 
internet-draft.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>New Samples Document 
- Paul Hoffman</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Paul made a 
presentation for the creation of a new document providing CMS<BR>examples.  The 
overview of the document would be a short introduction, a <BR>basic example of 
each content type and advanced examples of different types.<BR>Consistent data 
on keys would be used through out the entire set of<BR>examples.  The timing of 
this document is such that it would not be started<BR>until the CMS draft has 
moved to the RFC editors.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>It was suggested 
that the document include some incorrect examples that flag<BR>common 
implementation errors.  Paul agreed to add a section for 
these.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>Paul is only going 
to coordinate putting this document together.  If <BR>individuals would like to 
volunteer to do examples they should contact Paul<BR>at <A 
href="mailto:[e-mail]">[e-mail]</A>.</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=087235817-17121998>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV></DIV>
<DIV><FONT face=Arial size=2><SPAN class=087235817-17121998>ACTION ITEMS:<BR>1.  
Change the Checksum algorithm in CMS (Russ Housley)<BR>2.  Add SKI to SignerInfo 
(Russ Housley)<BR>3.  Add SKI restriction to the MSG draft (Blake 
Ramsdell)<BR>4.  Require IssuerAndSerialNumber in SigAttr (Paul Hoffman)<BR>5.  
Post PGP Compatability Internet-Draft (Jon 
Callas)<BR></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01BE29E6.0E507B88--


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10148 for ietf-smime-bks; Thu, 17 Dec 1998 06:52:11 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10144 for <[e-mail]>; Thu, 17 Dec 1998 06:52:10 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA15923; Thu, 17 Dec 1998 09:56:53 -0500
Message-Id: <4.1.19981216134701.0097e300@209.172.119.123>
Message-Id: <4.1.19981216134701.0097e300@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 16 Dec 1998 13:50:05 -0500
To: "Darren Harter" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: SignerInfo Change
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Darren:

The reasonf or the chane is CMC support.  In this case, the signer does not
have a certificate yet.  The point of the message is a certificate request.
 So, the signer does not have a issuer/serial number pair.  This change
lets CMC use the SignerInfo.

The reason for the MSG document change is to mangate the use of a
issuer/serial number pair with S/MIME v3.

Russ


At 04:35 PM 12/10/98 +0000, Darren Harter wrote:
>Russ,
>
>Sorry if this is a no brainer.  I couldn't make the meeting this time, so 
>what I'm about to ask may have come up in discussion in the WG session.  As 
>we've taken this opportunity to modify SignerInfo, would it not be a good 
>time to add a field that may  simplify the identification of the signer's 
>certificate even more.
>
>First of all let me confirm that I think it is good that the 
>subjectKeyIdentifier has been added.  My concern is that I'm going to have 
>to do a lot of work to find such a certificate in a simple repository that 
>doesn't have good matching rule support.
>
>I propose that we instead have the following structure:
>
>SignerIdentifier ::= CHOICE {
>   issuerAndSerialNumber IssuerAndSerialNumber,
>   subjectKeyIdentifier [0] SubjectKeyIdentifier,
>   subjectAndKeyIdentifier [1] SubjectAndKeyIdentifier }
>
>where,
>
>SubjectAndKeyIdentifer ::= SEQUENCE {
>   subjectName Name,
>   subjectKeyIdentifier [0] SubjectKeyIdentifier OPTIONAL }
>
>This will allow simple subject name look-up should an application wish to do 
>that.  Your proposed words for the MSG spec would still stand unaltered.
>
>Regards,
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail]
>Home: [e-mail]
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA10122 for ietf-smime-bks; Thu, 17 Dec 1998 06:51:09 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA10118 for <[e-mail]>; Thu, 17 Dec 1998 06:51:07 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA15992; Thu, 17 Dec 1998 09:57:19 -0500
Message-Id: <4.1.19981216155453.0095d550@209.172.119.123>
Message-Id: <4.1.19981216155453.0095d550@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 16 Dec 1998 15:55:59 -0500
To: "Darren Harter" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments of CMS-09 - section 6.3
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Darren:

I understand.  If a Draft 11 is needed, I will change it to "lth".

Russ


At 10:58 AM 12/14/98 +0000, Darren Harter wrote:
>Russ,
>
>I would like to suggest a minor editorial change to this section. Currently 
>this section uses k-(l mod k) as a formulae for content padding.  This 
>unfortunately looks like k-(1 mod k) on my printer, and almost had me 
>sending a correction email until I reread the section.
>
>I believe changing the formulae to k-(n mod k) or even k-(length mod k) 
>would be useful in preventing implementation errors.
>
>Regards,
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail]
>Home: [e-mail]
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA05136 for ietf-smime-bks; Mon, 14 Dec 1998 17:32:00 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA05132 for <[e-mail]>; Mon, 14 Dec 1998 17:31:59 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Mon, 14 Dec 98 17:37:35 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XTQB923B>; Mon, 14 Dec 1998 17:37:35 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: DSS reference
Date: Mon, 14 Dec 1998 17:37:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A6B62D5351-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

The current reference in -msg for DSS is ANSI X9.57.  Should this be FIPS
186?

ANSI X9.57 is consistent with the current preference for ANSI standards in
the references section for -msg, but inconsistent with PKIX part I (which
refers to FIPS 186).

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04229 for ietf-smime-bks; Mon, 14 Dec 1998 16:42:38 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA04225 for <[e-mail]>; Mon, 14 Dec 1998 16:42:37 -0800 (PST)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Mon, 14 Dec 98 16:48:13 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XTQB92MY>; Mon, 14 Dec 1998 16:48:13 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Andrew Farrell'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on drafts.
Date: Mon, 14 Dec 1998 16:48:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A6B6E4757-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Andrew -- comments inline.  Thanks for the time...

> -----Original Message-----
> From: Andrew Farrell [mailto:[e-mail]]
> Sent: Thursday, December 10, 1998 4:11 PM
> To: [e-mail]
> Subject: Comments on drafts.
> 
> msg-09.txt:
> 
> 2.2: "The algorithm parameters for DSA MUST be absent."

The current sentences read:

Sending and receiving agents MUST support id-dsa defined in [DSS].  The
algorithm parameters MUST be absent (not encoded as NULL).

Would you like to see the second sentence reworded as you have suggested?

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29261 for ietf-smime-bks; Mon, 14 Dec 1998 11:47:59 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29257 for <[e-mail]>; Mon, 14 Dec 1998 11:47:58 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPL4ZHWP>; Mon, 14 Dec 1998 11:51:01 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B4D@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Francois Rousseau'" <[e-mail]>, [e-mail]
Subject: RE: Comment on ESS-09
Date: Mon, 14 Dec 1998 11:50:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

There are currently a large number of items which are assuming that SHA1
will not ever be effectively broken.  This is just another of those items.
If SHA1 ever does get broken then the algorithm here can be updated by
creating a new OID to define a new version of ESSCertID.  The problem with
making it flexible is that you then need to start stating which algorithms
can and cannot be used leading to the same problem of a new draft when SHA1
is broken anyway.

jim


> -----Original Message-----
> From: Francois Rousseau [mailto:[e-mail]]
> Sent: Thursday, December 10, 1998 9:32 AM
> To: [e-mail]
> Cc: Jim Schaad (Exchange)
> Subject: Comment on ESS-09
> 
> 
> I am not sure if there is any plan to change this for version 
> 10 of ESS or
> it was/will be discussed in Orlando, but I just though that the
> identification of certificates in Section 5.4.1 for the 
> Signing Certificate
> Attribute Definition should be more flexible and not 
> necessarily be bound
> for ever to SHA1. I however agree that SHA1 should be the 
> default digest
> algorithm at this point. Instead I suggest that it could read 
> as follows:
> 
> ESSCertID ::=  SEQUENCE {
>      certHash                 CertHash,
>      issuerSerial             IssuerSerial OPTIONAL
> }
> 
> CertHash ::=  SEQUENCE {
>      digestAlgorithm          DigestAlgorithmIdentifier,
>      digest                   Digest
> }
> 
> Digest ::= OCTET STRING -- hash of entire certificate
> 
> Francois Rousseau
> AEPOS Technologies
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29224 for ietf-smime-bks; Mon, 14 Dec 1998 11:45:55 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29220 for <[e-mail]>; Mon, 14 Dec 1998 11:45:54 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPL4ZHWD>; Mon, 14 Dec 1998 11:48:56 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B4C@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Francois Rousseau'" <[e-mail]>
Cc: [e-mail]
Subject: RE: ESS changes from the WG Meeting
Date: Mon, 14 Dec 1998 11:48:37 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

You are correct, my typo.

jim


> -----Original Message-----
> From: Francois Rousseau [mailto:[e-mail]]
> Sent: Monday, December 14, 1998 11:45 AM
> To: Jim Schaad (Exchange)
> Cc: [e-mail]
> Subject: Re: ESS changes from the WG Meeting
> 
> 
> Jim,
> 
> I agree that it should read differently, however see minor 
> change below:
> 
> >Given the addition of SKI to SignerInfo, the following 
> change should be made
> >in section 5.4 of ESS.
> >
> >First pargraph after ASN is:
> >
> >The first certificate identified in the sequence of 
> certificate identifiers
> >MUST be the certificate used to verify the signature. The 
> encoding of the
> >ESSCertID for this certificate SHOULD NOT include the 
> issuerSerial because
> >the issuerAndSerialNumber is already present in the SignerInfo. The
> >certificate identified is used during the signature 
> verification process. If
> >the hash of the certificate does not match the certificate 
> used to verify
> >the signature, the signature MUST be considered invalid.
> >
> >Paragraph should be:
> >
> >The first certificate identified in the sequence of 
> certificate identifiers
> >MUST be the certificate used to verify the signature.  The 
> encoding of the
> >ESSCertID for this certificate SHOULD include the 
> issuerSerial field.  If
> >other constraints ensure that issuerAndSerialNumber will be 
> present in the
> >SignerInfo, ESSCertID MAY be omitted. The certificate 
> identified is used
> >during the signature verification process. If the hash of 
> the certificate
> >does not match the certificate used to verify the signature, 
> the signature
> >MUST be considered invalid.
> >
> Should it not read as follow instead:
> 
> The first certificate identified in the sequence of 
> certificate identifiers
> MUST be the certificate used to verify the signature.  The 
> encoding of the
> ESSCertID for this certificate SHOULD include the 
> issuerSerial field.  If
> other constraints ensure that issuerAndSerialNumber will be 
> present in the
> SignerInfo, the issuerSerial field MAY be omitted. The certificate
> identified is used during the signature verification process. 
> If the hash
> of the certificate does not match the certificate used to verify the
> signature, the signature MUST be considered invalid.
> 
> Francois Rousseau
> AEPOS Technologies
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29204 for ietf-smime-bks; Mon, 14 Dec 1998 11:44:07 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29200 for <[e-mail]>; Mon, 14 Dec 1998 11:44:04 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id OAA19601; Mon, 14 Dec 1998 14:48:28 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 14 Dec 1998 14:45:00 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: ESS changes from the WG Meeting
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010FA56E35@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim,

I agree that it should read differently, however see minor change below:

>Given the addition of SKI to SignerInfo, the following change should be made
>in section 5.4 of ESS.
>
>First pargraph after ASN is:
>
>The first certificate identified in the sequence of certificate identifiers
>MUST be the certificate used to verify the signature. The encoding of the
>ESSCertID for this certificate SHOULD NOT include the issuerSerial because
>the issuerAndSerialNumber is already present in the SignerInfo. The
>certificate identified is used during the signature verification process. If
>the hash of the certificate does not match the certificate used to verify
>the signature, the signature MUST be considered invalid.
>
>Paragraph should be:
>
>The first certificate identified in the sequence of certificate identifiers
>MUST be the certificate used to verify the signature.  The encoding of the
>ESSCertID for this certificate SHOULD include the issuerSerial field.  If
>other constraints ensure that issuerAndSerialNumber will be present in the
>SignerInfo, ESSCertID MAY be omitted. The certificate identified is used
>during the signature verification process. If the hash of the certificate
>does not match the certificate used to verify the signature, the signature
>MUST be considered invalid.
>
Should it not read as follow instead:

The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature.  The encoding of the
ESSCertID for this certificate SHOULD include the issuerSerial field.  If
other constraints ensure that issuerAndSerialNumber will be present in the
SignerInfo, the issuerSerial field MAY be omitted. The certificate
identified is used during the signature verification process. If the hash
of the certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid.

Francois Rousseau
AEPOS Technologies


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27404 for ietf-smime-bks; Mon, 14 Dec 1998 08:57:09 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27399; Mon, 14 Dec 1998 08:57:09 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <Y3K89DZ6>; Mon, 14 Dec 1998 08:59:54 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010FA56E35@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Paul Hoffman (E-mail)" <[e-mail]>, "Ietf-Smime (E-mail)" <[e-mail]>
Subject: ESS changes from the WG Meeting
Date: Mon, 14 Dec 1998 08:59:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Given the addition of SKI to SignerInfo, the following change should be made
in section 5.4 of ESS.

First pargraph after ASN is:

The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature. The encoding of the
ESSCertID for this certificate SHOULD NOT include the issuerSerial because
the issuerAndSerialNumber is already present in the SignerInfo. The
certificate identified is used during the signature verification process. If
the hash of the certificate does not match the certificate used to verify
the signature, the signature MUST be considered invalid.

Paragraph should be:

The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature.  The encoding of the
ESSCertID for this certificate SHOULD include the issuerSerial field.  If
other constraints ensure that issuerAndSerialNumber will be present in the
SignerInfo, ESSCertID MAY be omitted. The certificate identified is used
during the signature verification process. If the hash of the certificate
does not match the certificate used to verify the signature, the signature
MUST be considered invalid.



jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA26772 for ietf-smime-bks; Mon, 14 Dec 1998 07:27:16 -0800 (PST)
Received: from monsoon.dial.pipex.net (monsoon.dial.pipex.net [158.43.128.69]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA26767 for <[e-mail]>; Mon, 14 Dec 1998 07:27:14 -0800 (PST)
Received: (qmail 27133 invoked from network); 14 Dec 1998 15:31:29 -0000
Received: from userc140.uk.uudial.com (HELO GK-Acer) (193.149.95.106) by smtp.dial.pipex.com with SMTP; 14 Dec 1998 15:31:29 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 14 Dec 1998 15:30:38 +0000
To: Russ Housley <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: Re: Key Wrap Algoritm
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 23:11 09/12/98 -0500, Russ Housley wrote:
>All:
>
>In today's face-to-face working group meeting, we decided to replace the
>Fletcher Checksum with the first 64 bits of a SHA-1 hash.

This is the second of two messages I've seen where the face-to-face meeting
decided to change something in S/MIME.

I thought that IETF procedure required that all decisions for substantive
change were made on the mailing list.

I don't oppose the changes, just raising a flag.  Having done so, I'll
leave this to the WG chair to resolve.

#g

------------
Graham Klyne
([e-mail])



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26416 for ietf-smime-bks; Mon, 14 Dec 1998 06:41:33 -0800 (PST)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26411; Mon, 14 Dec 1998 06:41:31 -0800 (PST)
Received: from cougar.baltimore.ie ([e-mail] [194.125.215.12]) by puma.baltimore.ie (8.8.5/8.8.5) with ESMTP id OAA07057; Mon, 14 Dec 1998 14:47:34 GMT
Received: from cougar.baltimore.ie (afarrell@localhost [127.0.0.1]) by cougar.baltimore.ie (8.8.5/8.8.5) with ESMTP id OAA08981; Mon, 14 Dec 1998 14:47:33 GMT
Message-Id: <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments on drafts. 
In-Reply-To: Your message of "Sun, 13 Dec 1998 05:11:46 EST." <[e-mail]> 
Date: Mon, 14 Dec 1998 14:47:32 +0000
From: Andrew Farrell <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ross wrote:

>>ess-09.txt:

>>2.3, second paragraph: I'm unhappy with the two consecutive sentences which 
>>say that if two verified signatures conflict, a signature must not be 
>>generated, but a signature should be generated if any signature verifies (or 
>>'validates') and another doesn't because you don't recognize the algorithm. 

>That's not what they say, I believe. They say if two *receiptRequest*
>attributes in a SignedData conflict, don't send back a receipt. If you
>can't validate a signature due to not knowing a particular algorithm, keep
>going.

First, the paragraph (in ess-09):


Before processing a receiptRequest signedAttribute, the receiving agent
MUST verify the signature of the SignerInfo which covers the
receiptRequest attribute. A recipient MUST NOT process a receiptRequest
attribute that has not been verified. Because all receiptRequest
attributes in a SignedData object must be identical, the receiving
application fully processes (as described in the following paragraphs)
the first receiptRequest attribute that it encounters in a SignerInfo
that it verifies, and it then ensures that all other receiptRequest
attributes in signerInfos that it verifies are identical to the first
one encountered. If there are verified ReceiptRequest attributes which
conflict, then the processing software MUST NOT return any signed
receipt. A signed receipt SHOULD be returned if any signerInfo
containing a receiptRequest attribute can be validated, even if other
signerInfos containing the same receiptRequest attribute cannot be
validated because they are signed using an algorithm not supported by
the receiving agent.


First, I'd like to propose 'recipient' for the list of terms whose use
should be regulated:) The problem is that what the final sentence means,
is that a signed receipt should be returned if any receiptRequest
verifies, under the restriction of the preceding sentence. In other
words, the final sentence doesn't stand on its own. And it doesn't say
anything different than the second sentence of the paragraph, it just
gives a reason why not processing a receiptRequest may not be an
'"error" error'.

>>4.2.3.2: I'm not sure this flowchart-like process will work. 

To shorten the path, what I mean by this is that the words in 4.2 say
that we determine the outer signed data by recursing through the nested
signatures until we find something we like, and that if we don't find
one, we treat the _original_ message as the outer signed data. This
isn't the sort of algorithm that I think can be represented in
flowcharts, without some sort of explicit variable storage, if you see
what I mean.

Andrew.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA23323 for ietf-smime-bks; Mon, 14 Dec 1998 02:56:00 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id CAA23319 for <[e-mail]>; Mon, 14 Dec 1998 02:55:54 -0800 (PST)
Received: by access.itsec.gov.uk; id AA02942; Mon, 14 Dec 98 10:50:10 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma002935; Mon, 14 Dec 98 10:49:42 GMT
Received: by ingress.itsec.dmz; id AA06985; Mon, 14 Dec 98 10:51:00 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma006980; Mon, 14 Dec 98 10:50:51 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Mon, 14 Dec 1998 10:49:29 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Mon, 14 Dec 1998 10:58:18 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Comments of CMS-09 - section 6.3
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA23320
Sender: [e-mail]
Precedence: bulk

Russ,

I would like to suggest a minor editorial change to this section. Currently this section uses k-(l mod k) as a formulae for content padding.  This unfortunately looks like k-(1 mod k) on my printer, and almost had me sending a correction email until I reread the section.

I believe changing the formulae to k-(n mod k) or even k-(length mod k) would be useful in preventing implementation errors.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA09959 for ietf-smime-bks; Sat, 12 Dec 1998 17:06:22 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA09955 for <[e-mail]>; Sat, 12 Dec 1998 17:06:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 13 Dec 1998 05:11:46 -0500
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Comments on drafts.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Andrew makes many good points that should be considered by other S/MIME
authors. As for ESS:

>ess-09.txt:
>
>1: reference to MUSTSHOULD?

Er, yes. Added.

>2.3, second paragraph: I'm unhappy with the two consecutive sentences which 
>say that if two verified signatures conflict, a signature must not be 
>generated, but a signature should be generated if any signature verifies (or 
>'validates') and another doesn't because you don't recognize the algorithm. 

That's not what they say, I believe. They say if two *receiptRequest*
attributes in a SignedData conflict, don't send back a receipt. If you
can't validate a signature due to not knowing a particular algorithm, keep
going.

>2.3, flowchart item 3.1: 'should' should be capitalised.

Yup.

>4.2.3.2: I'm not sure this flowchart-like process will work. Unless I'm 
>mistaken, it gives different results on, for example, 4.2.1 example 5, where 
>I see it returning S4(S2(E1(S1(Original Content)))).

I don't see this. I think that step 3.2.1 strips off S2, yes?

> Or example 2, where I 
>see it returning S4(S2(S1(Original Content))).

Yes, I agree; good catch! I have changed step 2 of 4.2.3.2 to:

2. If the outermost SignedData layer includes an signed mlExpansionHistory
attribute, the MLA checks for an expansion loop as described in the
"Detecting Mail List Expansion Loops" section, then go to step 3. If the
outermost SignedData layer does not include an signed mlExpansionHistory
attribute, go directly to step 4.
 
...and changed the flowchart to:

2. Does outermost SignedData layer contain mlExpansionHistory?
       YES -> Check it, then -> 3.
       NO  -> 4.

> If the text between 4.2 and 
>4.2.1 is what the group wants, I'm not convinced that the stuff between the 
>end of 4.2.1 and 4.3 does any good, apart from mentioning replacing 
>originatorInfo.

I think that it gives additional valuable examples of how to do processing.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA03663 for ietf-smime-bks; Fri, 11 Dec 1998 07:34:13 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA03658 for <[e-mail]>; Fri, 11 Dec 1998 07:34:10 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id KAA13213; Fri, 11 Dec 1998 10:38:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 11 Dec 1998 10:35:00 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-certdist-02.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim,

I am not sure if you have any plan to change this for version 3 of CERTDIST
or if it was discussed in Orlando, but I just thought that the syntax for
the SMimeEncryptionCerts attribute in Section 3 should be more flexible and
not necessarily be bound for ever to SHA1. I however agree that SHA-1
should be the default digest algorithm at this point. Instead I suggest
that it could read as follows:

       SMimeEncryptionCerts ::= SEQUENCE OF SMimeEncryptionCert

       SMimeEncryptionCert ::= SEQUENCE {
            certHash         CertHash,
            capabilities     SMIMECapabilities
       }

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

       DigestAlgorithmIdentifier ::= AlgorithmIdentifier

       Digest ::= OCTET STRING -- hash of the entire certificate

Francois Rousseau
AEPOS Technologies



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA04439 for ietf-smime-bks; Thu, 10 Dec 1998 17:44:28 -0800 (PST)
Received: from mcfs.whowhere.com (mcfs.whowhere.com [209.1.236.44]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA04435 for <[e-mail]>; Thu, 10 Dec 1998 17:44:27 -0800 (PST)
Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Thu Dec 10 17:10:30 1998
To: [e-mail]
Date: Thu, 10 Dec 1998 17:10:30 -0700
From: "Andrew Farrell" <[e-mail]>
Message-ID: <[e-mail]>
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
Subject: Comments on drafts.
X-Sender-Ip: 198.67.176.35
Organization: QUALCOMM Eudora Web-Mail  (http://www.eudoramail.com:80) 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

AFAIK, none of these have been brought up before. Apologies if any of them have (particularly the really small stuff). Also, the stuff I brought up about certdist won't be repeated here: It may be in the minutes, and I'm sure it'll be in the next draft.

cert-05.txt:

3.1: The last paragraph has nothing to do with email addresses in certificates, and looks more like it belongs is section 3.2. Now that (Paul said) 3.2 has disappeared, this should perhaps become section 3.2.
OR, specify that the SubjectAlternateName in this paragraph be resticted to rfc822address, if that's what we mean.

certdist-02.txt:

4: Third paragraph should read :

The ASN.1 definition of a SMimeCertificatePublish object is the same as that of a CMS signed object.

Also, throughout the document, shouldn't ASN be ASN.1?

cms-09.txt:

1: Reference to MUSTSHOULD?

1: The first sentence is the same as the first sentence from the Abstract, but missing authentication or digesting.

5.1: Last two paragraphs belong in 5.2

11: The attributes defined can also presumably be used in enveloped-data. I can't actually see how or why, but there's a pointer from 6.1 to here.

ess-09.txt:

1: reference to MUSTSHOULD?

2.3, second paragraph: I'm unhappy with the two consecutive sentences which say that if two verified signatures conflict, a signature must not be generated, but a signature should be generated if any signature verifies (or 'validates') and another doesn't because you don't recognize the algorithm. I suggest moving the second half of the second sentence up near the start of the paragraph, as the third sentence:

Note that it is possible that the receiving agent cannot verify a receiptRequest because the containing signerInfo is signed using an algorithm not supported by the receiving agent.

And replacing the last sentence in the paragraph with:

Failing this, the reciving agent SHOULD return a signed receipt.

2.3, flowchart item 3.1: 'should' should be capitalised.

4.2.3.2: I'm not sure this flowchart-like process will work. Unless I'm mistaken, it gives different results on, for example, 4.2.1 example 5, where I see it returning S4(S2(E1(S1(Original Content)))). Or example 2, where I see it returning S4(S2(S1(Original Content))). If the text between 4.2 and 4.2.1 is what the group wants, I'm not convinced that the stuff between the end of 4.2.1 and 4.3 does any good, apart from mentioning replacing originatorInfo.

msg-09.txt:

2.2: "The algorithm parameters for DSA MUST be absent."

x942-04.txt:

2.1.1: j and q are more or less out of nowhere. I'd suggest (for clarity) 

p is a large prime such that
j is a large integer, q is a large prime and p=qj + 1

or swapping the order of q and j so that j existence is a property of q, rather than vice versa:

q is a large prime such that
j a large integer and p=qj + 1.

That's all, folks.

Andrew (great to meet you all)
---
Insecure travelling address. [e-mail] is no less secure, but more likely to be read.


Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA00968 for ietf-smime-bks; Thu, 10 Dec 1998 11:55:35 -0800 (PST)
Received: from aum (ietf-177-74.mtg.ietf.org [198.67.177.74]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA00963 for <[e-mail]>; Thu, 10 Dec 1998 11:55:33 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 10 Dec 1998 13:59:05 -0500
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Fwd: I-D ACTION:draft-iab-secmech-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

People on this list might find this draft very useful. Steve Bellovin is
open to suggestions on the document.

>To: IETF-Announce: ;
>Cc: [e-mail]
>From: [e-mail]
>Reply-to: [e-mail]
>Subject: I-D ACTION:draft-iab-secmech-00.txt
>Date: Wed, 25 Nov 1998 10:37:38 -0500
>Sender: [e-mail]
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the Internet Architecture Board.
>
>	Title		: Security Mechanisms for the Internet
>	Author(s)	: S. Bellovin
>	Filename	: draft-iab-secmech-00.txt
>	Pages		: 8
>	Date		: 20-Nov-98
>	
>   Many different mechanisms can be used to provide security for
>   protocols.  The precise one that is appropriate in any given
>   situation can vary.  We review a number of different choices,
>   explaining the properties of each.
>
>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-iab-secmech-00.txt".
>A URL for the Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-iab-secmech-00.txt
>
>Internet-Drafts directories are located at:
>
>	Africa:	ftp.is.co.za
>	
>	Europe: ftp.nordu.net
>		ftp.nic.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:	[e-mail].  In the body type:
>	"FILE /internet-drafts/draft-iab-secmech-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.
>Content-Type: text/plain
>Content-ID:	<[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-iab-secmech-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-iab-secmech-00.txt>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29754 for ietf-smime-bks; Thu, 10 Dec 1998 09:30:57 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29750 for <[e-mail]>; Thu, 10 Dec 1998 09:30:53 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id MAA06594; Thu, 10 Dec 1998 12:34:59 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Thu, 10 Dec 1998 12:31:38 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Comment on ESS-09
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I am not sure if there is any plan to change this for version 10 of ESS or
it was/will be discussed in Orlando, but I just though that the
identification of certificates in Section 5.4.1 for the Signing Certificate
Attribute Definition should be more flexible and not necessarily be bound
for ever to SHA1. I however agree that SHA1 should be the default digest
algorithm at this point. Instead I suggest that it could read as follows:

ESSCertID ::=  SEQUENCE {
     certHash                 CertHash,
     issuerSerial             IssuerSerial OPTIONAL
}

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

Digest ::= OCTET STRING -- hash of entire certificate

Francois Rousseau
AEPOS Technologies


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29339 for ietf-smime-bks; Thu, 10 Dec 1998 08:33:28 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA29335 for <[e-mail]>; Thu, 10 Dec 1998 08:33:26 -0800 (PST)
Received: by access.itsec.gov.uk; id AA02595; Thu, 10 Dec 98 16:27:32 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma002578; Thu, 10 Dec 98 16:27:04 GMT
Received: by ingress.itsec.dmz; id AA14251; Thu, 10 Dec 98 16:28:22 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma014239; Thu, 10 Dec 98 16:28:13 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Thu, 10 Dec 1998 16:26:54 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Thu, 10 Dec 1998 16:35:41 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: SignerInfo Change
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA29336
Sender: [e-mail]
Precedence: bulk

Russ,

Sorry if this is a no brainer.  I couldn't make the meeting this time, so what I'm about to ask may have come up in discussion in the WG session.  As we've taken this opportunity to modify SignerInfo, would it not be a good time to add a field that may  simplify the identification of the signer's certificate even more.

First of all let me confirm that I think it is good that the subjectKeyIdentifier has been added.  My concern is that I'm going to have to do a lot of work to find such a certificate in a simple repository that doesn't have good matching rule support.

I propose that we instead have the following structure:

SignerIdentifier ::= CHOICE {
   issuerAndSerialNumber IssuerAndSerialNumber,
   subjectKeyIdentifier [0] SubjectKeyIdentifier,
   subjectAndKeyIdentifier [1] SubjectAndKeyIdentifier }

where,

SubjectAndKeyIdentifer ::= SEQUENCE {
   subjectName Name,
   subjectKeyIdentifier [0] SubjectKeyIdentifier OPTIONAL }

This will allow simple subject name look-up should an application wish to do that.  Your proposed words for the MSG spec would still stand unaltered.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA29159 for ietf-smime-bks; Thu, 10 Dec 1998 08:17:12 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA29155 for <[e-mail]>; Thu, 10 Dec 1998 08:17:10 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id IAA21539; Thu, 10 Dec 1998 08:23:24 -0800 (PST)
To: "Jim Schaad (Exchange)" <[e-mail]>
Cc: [e-mail]
Subject: Re: New X9.42 draft
References: <2FBF98FC7852CF11912A0000000000010FA56A52@DINO>
From: EKR <[e-mail]>
Date: 10 Dec 1998 08:23:23 -0800
In-Reply-To: "Jim Schaad's message of "Thu, 10 Dec 1998 05:59:06 -0800"
Message-ID: <[e-mail]>
Lines: 53
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Jim Schaad (Exchange)" <[e-mail]> writes:
> 1. Section 2.1.7 missing a return on the pubInfo Paragraph.
I can't see this. Can you post the offending line?

> 2. ASN formatting issue.  Should be another return and indentation for a2 42
> <CR> 04 40
Done.

> 3. General statment:  I don't like formulas of the format "ZZ = a ^ b (mod
> p)".  This does not make sense to me from my old days in math class.  Should
> this be written as "ZZ = (a ^ x) mod p" which corresponds to what my math
> teacher said? (I never got into the high level math courses in college.)
I think the conventions are mixed, but if noone else objects I'll
change this.

> 4. Section 2.1.1 - reverse the definitions of j and q so that j has a
> definition on the same line.
Done.

> 5.  Section 2.1.2 - new text on counter issue.
> counter is a 32 bit number, represented in network byte order. Its
>      initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01
> (hex),
>      and it is incremented by one every time the above key generation
>      function is run for a given KEK.
Done.

> 6.  Section 2.1.7 remove the phase "first invocation" in reference to SHA
> hashing, there is no second invocation for RC2.
Done.

> 7. Section 2.2.2 - bullet #2 - What is the "seed 'seed'"  string for.  I
> don't follow why the word is there twice.
Because it refers to a field in the validationParms structure.

> 8.  Security Considerations --  I have a problem with the concept of placing
> SHOULD and MAY in this section.  This is suppose to be an advisary section
> and I am not sure we want to try and get two implementations that actually
> deal with the suggested text.
Hmm... I think these requirements should go somewhere. I'm open to
moving them somewhere else

> 9.  Section 2.2.1.1 - I would recommend changing '160] 2^' to '160] * 2^'
Done.

> 10.  Section 2.2.1.1 - In step 10 the string starting with "Note" is in
> twice.  One should be removed.
Done.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28766 for ietf-smime-bks; Thu, 10 Dec 1998 07:29:21 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28762 for <[e-mail]>; Thu, 10 Dec 1998 07:29:20 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.124]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA18658; Thu, 10 Dec 1998 07:33:44 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 09 Dec 1998 23:11:38 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Key Wrap Algoritm
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

All:

In today's face-to-face working group meeting, we decided to replace the
Fletcher Checksum with the first 64 bits of a SHA-1 hash.

Russ


>
> Date: Tue, 08 Dec 1998 10:36:11 -0500
> To: [e-mail]
> From: Russ Housley <[e-mail]>
> Subject: Re: Key Wrap Algoritm
>
>
> Jim:
>
> I did not accept al of your changes.  I had to filter them with discussion
> going on with other threads.  So, attached is the Key Wrap Algorithm as
> presently defined.  Note that this algorithm is limited to Triple-DES and
> RC2.
>
> In addition, the following is added to the security considerations section:
> Section 12.6 specifies a key wrap algorithm used to encrypt a Triple-DES
> [3DES] or RC2 [RC2] content-encryption key with a Triple-DES or RC2
> key-encryption key using CBC mode [MODES].  This key wrap algorithm has been
> reviewed for use with Triple-DES in CBC mode and RC2 in CBC mode; it has not
> been reviewed for use with other algorithms or other modes.  Analysis has
> discovered concerns with using this key wrap algorithm with stream ciphers or
> block ciphers in OFB mode [MODES].  Therefore, if a CMS implementation wises
> to support ciphers in addition to Triple-DES in CBC mode or RC2 in CBC mode,
> then additional key wrap algorithms may need to be defined to support the
> additional ciphers.
>
>
> Russ
>
> = = = = = = = = = = 
>
> 12.6  Triple-DES and RC2 Key Wrap Algorithm
>
> CMS implementations must include encryption of a Triple-DES
> content-encryption key with a Triple-DES key-encryption key using the
> algorithm specified in this section.  CMS implementations should include
> encryption of a RC2 content-encryption key with a RC2 key-encryption key. 
> Triple-DES and RC2 content-encryption keys are encrypted in Cipher Block
> Chaining (CBC) mode [MODES].
>
> Key Transport algorithms allow for the content-encryption key to be directly
> encrypted; however, key agreement and symmetric key-encryption key algorithms
> encrypt the content-encryption key with a second symmetric encryption
> algorithm.  This section describes how the Triple-DES or RC2
> content-encryption key is formatted and encrypted.
>
> Key agreement algorithms generate a pairwise key-encryption key, and a key
> wrap algorithm is used to encrypt the content-encryption key with the
> pairwise key-encryption key.  Similarly, a key wrap algorithm is used to
> encrypt the content-encryption key in a previously distributed key-encryption
> key.
>
> The key-encryption key is generated by the key agreement algorithm or
> distributed out of band.  For key agreement of RC2 key-encryption keys, 128
> bits must be generated as input to the key expansion process used to compute
> the RC2 effective key [RC2].
>
> The block size of the key-encryption algorithm must be implicitly determined
> from the KeyEncryptionAlgorithmIdentifier field; however, both Triple-DES and
> RC2 have a block size of eight octets.
>
> The same algorithm identifier is used for both 2-key and 3-key Triple-DES. 
> When the length of the wrapped content-encryption key is 16 octets, 2-key
> Triple-DES is used for the content-encryption algorithm.  Similarly, when the
> length of the wrapped content-encryption key is 24 octets, 3-key Triple-DES
> is used for the content-encryption algorithm.
>
> 12.6.1  Key Checksum
>
> The Fletcher checksum [SUM] algorithm is used to provide an integrity check
> value.  The algorithm is:
>
> 1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
> 2.  Loop through the octets of the content-encryption key, most
>     significant (first) octet to least significant (last) octet.
>     2a.  Create a 16 bit integer, called temp, by concatenating 
>          eight zero bits and the key octet.
>     2b.  sum1 = sum1 + temp.
>     2c.  sum2 = sum2 + sum1.
> 3.  Use sum2 as the checksum value.
>
> 12.6.2  Key Wrap
>
> 1.  Modify the content-encryption key to meet any restrictions on the key.
>     For example, adjust the parity bits for each DES key comprising a 
>     Triple-DES key.
> 2.  Compute a 16-bit key checksum value on the content-encryption key as
>     described Section 12.6.1 above.
> 3.  Generate a 32-bit random salt value.
> 4.  Concatenate the salt, content-encryption key, and key checksum value.
> 5.  Pad the result, using the technique specified in Section 6.3, so 
>     that the padded result is a multiple of eight (the Triple-DES and
>     RC2 block size).  Append the pad to the result.
> 6.  Encrypt in CBC mode the padded result using the key-encryption key.
>     Use an IV with each octet equal to 'A5' hexadecimal.
>
> 12.6.3  Key Unwrap
>
> The key unwrap algorithm is:
>
> 1.  Decrypt in CBC mode the ciphertext using the key-encryption key.  Use
>     an IV with each octet equal to 'A5' hexadecimal.
> 2.  Decompose the result into the content-encryption key and key checksum
>     values.  The salt and pad values are discarded.
> 3.  Compute a 16-bit key checksum value on the content-encryption key
>     as described in Section 12.6.1 above.
> 4.  If the computed key checksum value does not match the decrypted key
>     checksum value, then there is an error.
> 5.  If there are restrictions on keys, then check if the content-
>     encryption key meets these restrictions.  For example, check for odd
>     parity of each octet in each DES key that makes up a Triple-DES key.
>     If any restriction is incorrect, then there is an error.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA28753 for ietf-smime-bks; Thu, 10 Dec 1998 07:28:36 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA28749 for <[e-mail]>; Thu, 10 Dec 1998 07:28:35 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.124]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA18660; Thu, 10 Dec 1998 07:33:47 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 10 Dec 1998 10:08:20 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: SignerInfo Change
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<html>
<font face="Courier New, Courier">Blake:<br>
<br>
At the face-to-face S/MIME working group session, the group decided to
make a chane to SignerInfo.&nbsp; Since you were not at the meeting, I am
sending it to you to make a corresponging change in the MSG
document.<br>
<br>
Below is the updates section 5.3.&nbsp; The old issuerAndSerialNumber is
replaced with sid.&nbsp; The MSG document must be updated to say:&nbsp;
S/MIME v3 requires the use of SignerInfo version 1, that is the
issuerAndSerialNumber CHOICE must be used for SignerIdentifier.<br>
<br>
Please post the updated MSG document ASAP.&nbsp; I would like to progress
to IETF Last Call before Christmas.<br>
<br>
Russ<br>
<br>
= = = = = = = = = = <br>
<br>
5.3&nbsp; SignerInfo Type<br>
<br>
Per-signer information is represented in the type SignerInfo:<br>
&nbsp;
<dl>
<dd>SignerInfo ::= SEQUENCE {
<dd>&nbsp; version CMSVersion,
<dd>&nbsp; sid SignerIdentifier,
<dd>&nbsp; digestAlgorithm DigestAlgorithmIdentifier,
<dd>&nbsp; signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
<dd>&nbsp; signatureAlgorithm SignatureAlgorithmIdentifier,
<dd>&nbsp; signature SignatureValue,
<dd>&nbsp; unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }<br>
<br>

<dd>SignerIdentifier ::= CHOICE {
<dd>&nbsp; issuerAndSerialNumber IssuerAndSerialNumber,
<dd>&nbsp; subjectKeyIdentifier [0] SubjectKeyIdentifier }<br>
<br>

<dd>SignedAttributes ::= SET SIZE (1..MAX) OF Attribute<br>
<br>

<dd>UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute<br>
<br>

<dd>Attribute ::= SEQUENCE {
<dd>&nbsp; attrType OBJECT IDENTIFIER,
<dd>&nbsp; attrValues SET OF AttributeValue }<br>
<br>

<dd>AttributeValue ::= ANY<br>
<br>

<dd>SignatureValue ::= OCTET STRING
</dl>&nbsp;<br>
The fields of type SignerInfo have the following meanings:<br>
&nbsp;
<dl>
<dd>version is the syntax version number.&nbsp; If the SignerIdentifier
is the CHOICE issuerAndSerialNumber, then the version shall be 1.&nbsp;
If the SignerIdentifier is subjectKeyIdentifier, then the version shall
be 3.<br>
<br>

<dd>sid specifies the signer's certificate (and thereby the signer's
public key).&nbsp; The signer's public key is needed by the recipient to
validate the signature.&nbsp; SignerIdentifier provides two alternatives
for specifying the signer's public key.&nbsp; The issuerAndSerialNumber
alternative identifies the signer's certificate by the issuer's
distinguished name and the certificate serial number; the
subjectKeyIdentifier identifies the signer's certificate by the X.509
subjectKeyIdentifier extension value.<br>
<br>

<dd>digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer.&nbsp; The message digest is
computed on either the content being signed or the content together with
the signed attributes using the process described in section 5.4.&nbsp;
The message digest algorithm should be among those listed in the
digestAlgorithms field of the associated SignerData.<br>
<br>

<dd>signedAttributes is a collection of attributes that are signed.&nbsp;
The field is optional, but it must be present if the content type of the
EncapsulatedContentInfo value being signed is not id-data. Each
SignedAttribute in the SET must be DER encoded.&nbsp; Useful attribute
types, such as signing time, are defined in Section 11.&nbsp; If the
field is present, it must contain, at a minimum, the following two
attributes:
<dd>&nbsp;
<dl>
<dd>A content-type attribute having as its value the content type of the
EncapsulatedContentInfo value being signed.&nbsp; Section 11.1 defines
the content-type attribute.&nbsp; The content-type attribute is not
required when used as part of a countersignature unsigned attribute as
defined in section 11.4.<br>
<br>

<dd>A message-digest attribute, having as its value the message digest of
the content.&nbsp; Section 11.2 defines the message-digest
attribute.<br>
<br>

</dl>
<dd>signatureAlgorithm identifies the signature algorithm, and any
associated parameters, used by the signer to generate the digital
signature.<br>
<br>

<dd>signature is the result of digital signature generation, using the
message digest and the signer's private key.<br>
<br>

<dd>unsignedAttributes is a collection of attributes that are not
signed.&nbsp; The field is optional.&nbsp; Useful attribute types, such
as countersignatures, are defined in Section 11.<br>
<br>

</dl>The fields of type SignedAttribute and UnsignedAttribute have the
following meanings:<br>

<dl>
<dd>attrType indicates the type of attribute.&nbsp; It is an object
identifier.<br>
<br>

<dd>attrValues is a set of values that comprise the attribute.&nbsp; The
type of each value in the set can be determined uniquely by
attrType.</font>
</dl></html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27906 for ietf-smime-bks; Thu, 10 Dec 1998 05:55:56 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27902 for <[e-mail]>; Thu, 10 Dec 1998 05:55:55 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <Y3K8772S>; Thu, 10 Dec 1998 05:59:08 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010FA56A52@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: Eric Rescorla <[e-mail]>, [e-mail]
Subject: RE: New X9.42 draft
Date: Thu, 10 Dec 1998 05:59:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="windows-1252"
Sender: [e-mail]
Precedence: bulk

Changes:

1. Section 2.1.7 missing a return on the pubInfo Paragraph.

2. ASN formatting issue.  Should be another return and indentation for a2 42
<CR> 04 40

3. General statment:  I don't like formulas of the format "ZZ = a ^ b (mod
p)".  This does not make sense to me from my old days in math class.  Should
this be written as "ZZ = (a ^ x) mod p" which corresponds to what my math
teacher said? (I never got into the high level math courses in college.)

4. Section 2.1.1 - reverse the definitions of j and q so that j has a
definition on the same line.

5.  Section 2.1.2 - new text on counter issue.
counter is a 32 bit number, represented in network byte order. Its
     initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01
(hex),
     and it is incremented by one every time the above key generation
     function is run for a given KEK.

6.  Section 2.1.7 remove the phase "first invocation" in reference to SHA
hashing, there is no second invocation for RC2.

7. Section 2.2.2 - bullet #2 - What is the "seed 'seed'"  string for.  I
don't follow why the word is there twice.

8.  Security Considerations --  I have a problem with the concept of placing
SHOULD and MAY in this section.  This is suppose to be an advisary section
and I am not sure we want to try and get two implementations that actually
deal with the suggested text.

9.  Section 2.2.1.1 - I would recommend changing '160] 2^' to '160] * 2^'

10.  Section 2.2.1.1 - In step 10 the string starting with "Note" is in
twice.  One should be removed.

jim,


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA28921 for ietf-smime-bks; Wed, 9 Dec 1998 11:11:48 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA28916 for <[e-mail]>; Wed, 9 Dec 1998 11:11:45 -0800 (PST)
Received: from localhost (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) with SMTP id LAA12426 for <[e-mail]>; Wed, 9 Dec 1998 11:18:00 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Fixed version of X9.42 draft
Date: Wed, 09 Dec 1998 11:17:59 -0800
From: Eric Rescorla <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Well, in all the excitement, I kind of screwed up a bunch of the
cut and pasting into this document. This version fixes a bunch
of those errors, found by Jim Schaad.

-Ekr






                                                            E. Rescorla
INTERNET-DRAFT                                                RTFM Inc.
<draft-ietf-smime-x942-04.txt>         December 1998 (Expires June 1999)

                  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. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.


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 <[e-mail]> 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 content-encryption key
   (CEK) 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, called ZZ.  When the same originator and recipient
   public/private key pairs are used, the same ZZ value will result.
   The ZZ value is then converted into a shared symmetric cryptographic
   key. When the originator employs a static private/public key pair,
   the introduction of public random values are used to ensure that the
   resulting symmetric key will be different for each key agreement.

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



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


         xb is party b's private key
         p is a large prime
         g = h(p-1)/q mod p, where
         h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
           (g has order q mod p)
         j a large integer such that
         q is a large prime and p=qj + 1
         (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 OriginatorIdentifierOrKey field, either
   by reference to the sender's certificate or by inline inclusion of a
   key.

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. Note that this is NOT an AlgorithmIdentifier,
     but simply the OBJECT IDENTIFIER. No paramters are used.
   counter is a 32 bit number, represented in network byte order. Its
     initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01 (hex),
     and it is incremented by one every time the above key generation
     function is run with a given ZZ.
   pubInfo is a random string provided by the sender. In CMS, it is provided as
     a parameter in the UserKeyingMaterial field (encoded as an OCTET STRING). If
     provided this pubInfo MUST contain 512 bits.

   Note that the only source of secret entropy in this computation is



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


   ZZ, so the security of this data is limited to the size of ZZ, even
   if more data than ZZ is generated. However, if pubInfo is different
   for each message, a different KEK will be generated for each message.
   Note that pubInfo MUST be used in Static-Static mode, but MAY appear
   in Ephemeral-Static mode.

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.
   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.  For RC2, which
   requires 128 bits of keying material, the algorithm is run once, with
   a counter value of 1, and the left-most 128 bits are directly con-
   verted to an RC2 key.

2.1.4.  Keylengths for common algorithms

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

           3DES-EDE-ECB    192 bits
           RC2 (all)       128 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.


   The primary purpose of public key validation is to prevent a small
   subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static
   mode is used, this check may not be necessary.

   Note that this procedure may be subject to pending patents.

2.1.6.  Example 1


   ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f



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


   The key encryption algorithm is 3DES-EDE.

   No pubInfo is used

   Consequently, the input to the first invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f       ; ZZ
   30 12
      30 10
         06 08 2a 86 48 86 f7 0d 03 07                   ; 3DES-EDE OID
         04 04 00 00 00 01                               ; Counter

   And the output is the 20 bytes:

   20 be 23 e3 3b 72 ef 16 8e e3 ae 18 5a 00 93 b0 d6 49 56 22

   The input to the second invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f       ; ZZ
   30 12
      30 10
         06 08 2a 86 48 86 f7 0d 03 07                   ; 3DES-EDE OID
         04 04 00 00 00 02                               ; Counter

   And the output is the 20 bytes:

   3b 4e fd d4 6e ff 6b 6d 35 a9 cd e3 e3 e7 05 39 e0 31 53 de

   Consequently,
   K1'=20 be 23 e3 3b 72 ef 16
   K2'=8e e3 ae 18 5a 00 93 b0
   K3'=d6 49 56 22 3b 4e fd d4

   Note: These keys are not parity adjusted

2.1.7.  Example 2

   ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f

   The key encryption algorithm is RC2

   The pubInfo used is the 64 bytes 01 23 45 67 89 ab cd ef 01 23 45 67
   89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45
   67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23
   45 67 89 ab cd ef

   Consequently, the input to the first invocation of SHA-1 is:




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


   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f       ; ZZ
   30 56
      30 10
         06 08 2a 86 48 86 f7 0d 03 02                   ; RC2 OID
         04 04 00 00 00 01                               ; Counter
      a2 42 04 40
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef ; PubInfo
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef

   And the output is the 20 bytes:

   c7 4e c5 80 68 7d 70 aa 06 38 d3 e3 c7 2a da 5a 67 4e cf 06

   Consequently,
   K=c7 4e c5 80 68 7d 70 aa 06 38 d3 e3 c7 2a da 5a

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 (derived from the algorithms in FIPS PUB
   186-1[DSS], and [X942]can be found in appendix A.

   X9.42 requires that the private key x be in the interval [2, (q -
   2)]. x should be randomly generated in this interval. y is then com-
   puted by calculating g^x (mod p).  To comply with this draft, m MUST
   be >=160, (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.  Group Parameter Generation

   Agents SHOULD generate domain parameters (g,p,q) using the following
   algorithm, derived from [FIPS-186] and [X942]. When this algorithm is
   used, the correctness of the generation procedure can be verified by
   a third party by the algorithm of 2.2.2.

2.2.1.1.  Generation of p, q

   This algorithm generates a p, q pair where q is of length m and
   p is of length L.

   Let L - 1 = n*m + b where both b and n are integers and
   0 <= b < 160.




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


   1. Choose an arbitrary sequence of at least m bits and call it SEED.
   Let g be the length of SEED in bits.

   2. Set U = 0

   3. Set m' = m / 160, where / represents integer division,
      consequently, if m = 200, m' = 1.

   4. for i = 0 to m' - 1

           U = U + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2^160] 2^(160 * i)

   Note that for m=160, this reduces to the algorithm of [FIPS186]

           U = SHA[SEED] XOR SHA[(SEED+1) mod 2^160 ].

   5.  Form q from U by setting the most significant bit (the 2^(m-1) bit)
   and the least significant bit to 1. In terms of boolean operations,
   q = U OR 2^(m-1) OR 1. Note that 2^(m-1) < q < 2^m

   6. Use a robust primality algorithm to test whether q is prime.

   7. If q is not prime then go to 1.

   8. Let counter = 0 and offset = 2

   9. For k = 0 to n let

           Vk = SHA[(SEED + offset + k) mod 2^160 ].

   10. Let W be the integer

           W = V0 + V1*2^160 + ... + Vn-1*2(n-1)*160 + (Vn mod 2^b)
            * 2n*160
   and let
           X = W + 2^(L-1)

   Note that 0 <= W < 2^(L-1) and hence 2^(L-1)

           Note that 0 <= W < 2^(L-1) and hence 2^(L-1) <= X < 2^L

   11. Let c = X mod (2 * q) and set p = X - (c-1). Note that p is congruent
   to 1 mod (2 * q).

   12. If p < 2^(L -1) then go to step 15.

   13. Perform a robust primality test on p.




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


   14. If p passes the test performed in step 13 go to step 17.

   15. Let counter = counter + 1 and offset = offset + n + 1.

   16. If counter >=  4096 go to step 1. Otherwise go to step 9.

   17. Save the value of SEED and the value of counter for use
   in certifying the proper generation of p and q.

   Note: A robust primality test is one where the probability of
   a non-prime number passing the test is at most 2^-80.

2.2.1.2.  Generation of g

   This section gives an algorithm (derived from [FIPS186]) for generat-
   ing g.
   1. Let j = (p - 1)/q.

   2. Set h = any integer, where 1 < h < p - 1 and h differs
   from any value previously tried.

   3. Set g = h^j mod p

   4. If g = 1 go to step 2

2.2.2.  Group Parameter Validation

   The ASN.1 for DH keys in [PKIX] includes elements j and validation-
   Parms which MAY be used by recipients of a key to verify that the
   group parameters were correctly generated. Two checks are possible:

        1. Verify that p=qj + 1. This demonstrates that the parameters meet
        the X9.42 parameter criteria.
        2. Verify that when the p,q generation procedure of [FIPS-186]
        Appendix 2 is followed with seed 'seed', that p is found when
        This demonstrates that the parameters were randomly chosen and
        do not have a special form.


   Whether agents provide validation information in their certificates
   is a local matter between the agents and their CA.

2.3.  Ephemeral-Static Mode

   In Ephemeral-Static mode, the recipient has a static (and certified)
   key pair, but the sender generates a new key pair for each message
   and sends it using the originatorKey production. If the sender's key
   is freshly generated for each message, the shared secret ZZ will be



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


   similarly different for each message and pubInfo MAY be omitted,
   since it serves merely to decouple multiple KEKs generated by the
   same set of pairwise keys. If, however, the same ephemeral sender key
   is used for multiple messages (e.g. it is cached as a performance
   optimization) then a separate pubInfo MUST be used for each message.
   All implementations of this standard MUST implement Ephemeral-Static
   mode.

2.4.  Static-Static Mode

   In Static-Static mode, both the sender and the recipient have a
   static (and certified) key pair. Since the sender's and recipient's
   keys are therefore the same for each message, ZZ will be the same for
   each message. Thus, pubInfo MUST be used (and different for each mes-
   sage) in order to ensure that different messages use different KEKs.
   Implementations MAY implement Static-Static mode.

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 Paul Hoffman, Stephen Henson, Russ
   Housley, Brian Korver, Jim Schaad, Mark Schertler, and Peter Yee for
   their expert advice and review.

References
   [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-07.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.

   [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB)
       186, "Digital Signature Standard", 1994 May 19.

   [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public
       Key Infrastructure Certificate and CRL Profile", RFC-XXXX.

   [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
       "An efficient protocol for authenticated key agreement",



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


       Technical report CORR 98-05, University of Waterloo, 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels." RFC 2119. March 1997.

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

   Static Diffie-Hellman keys are vulnerable to a small subgroup attack
   [LAW98]. In practice, this issue arises for both sides in Static-
   Static mode and for the receiver during Ephemeral-Static mode.  In
   Static-Static mode, both originator and recipient SHOULD either per-
   form the validation step described in S 2.1.5 or verify that the CA
   has properly verified the validity of the key.  In Ephemeral-Static
   mode, the recipient SHOULD perform the check described in 2.1.5. If
   the sender cannot determine success or failure of decryption, the
   recipient MAY choose to omit this check.

   In order to securely generate a symmetric key of length l, m (the
   length in bits of q, and hence x) should be at least 2l. m MUST
   always be >= 160. Consequently, for RC2, m should be >=256 and for
   3DES, >=336 (the effective length of 3DES keys is 168 bits).

Author's Address

Eric Rescorla <[e-mail]>
RTFM Inc.
30 Newell Road, #16
East Palo Alto, CA 94303













Rescorla                                                        [Page 10]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 1 ..................................................    4

2.1.7. Example 2 ..................................................    5

2.2. Key and Parameter Requirements ...............................    6

2.2.1. Group Parameter Generation .................................    6

2.2.1.1. Generation of p, q .......................................    6

2.2.1.2. Generation of g ..........................................    8

2.2.2. Group Parameter Validation .................................    8

2.3. Ephemeral-Static Mode ........................................    8

2.4. Static-Static Mode ...........................................    9

2.4. Acknowledgements .............................................    9




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


2.4. References ...................................................    9

Security Considerations ...........................................   10

Author's Address ..................................................   10
















































Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA28000 for ietf-smime-bks; Tue, 8 Dec 1998 14:56:54 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27996 for <[e-mail]>; Tue, 8 Dec 1998 14:56:51 -0800 (PST)
Received: from localhost (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) with SMTP id PAA03523 for <[e-mail]>; Tue, 8 Dec 1998 15:02:53 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: New X9.42 draft
Date: Tue, 08 Dec 1998 15:02:52 -0800
From: Eric Rescorla <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Here's a preview copy of the new X9.42 draft. It should accomodate all
the comments posted so far. Major new changes include an algorithm
for generating p,g,q, a section on Static-Static, and a private keylength
section in Security Considerations.

-Ekr






                                                            E. Rescorla
INTERNET-DRAFT                                                RTFM Inc.
<draft-ietf-smime-x942-04.txt>         December 1998 (Expires June 1999)

                  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. Diffie-Hellman is a key agreement algorithm used by two par-
   ties to agree on a shared secret. An algorithm for converting the
   shared secret into an arbitrary amount of keying material is pro-
   vided. The resulting keying material is used as a symmetric encryp-
   tion key.  The D-H variant described requires the recipient to have a
   certificate, but the originator may have a static key pair (with the
   public key placed in a certificate) or an ephemeral key pair.


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 <[e-mail]> 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 content-encryption key
   (CEK) 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, called ZZ.  When the same originator and recipient
   public/private key pairs are used, the same ZZ value will result.
   The ZZ value is then converted into a shared symmetric cryptographic
   key. When the originator employs a static private/public key pair,
   the introduction of public random values are used to ensure that the
   resulting symmetric key will be different for each key agreement.

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



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


         xb is party b's private key
         p is a large prime
         g = h(p-1)/q mod p, where
         h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
           (g has order q mod p)
         j a large integer such that
         q is a large prime and p=qj + 1
         (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 OriginatorIdentifierOrKey field, either
   by reference to the sender's certificate or by inline inclusion of a
   key.

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. Note that this is NOT an AlgorithmIdentifier,
     but simply the OBJECT IDENTIFIER. No paramters are used.
   counter is a 32 bit number, represented in network byte order. Its
     initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01 (hex),
     and it is incremented by one every time the above key generation
     function is run with a given ZZ.
   pubInfo is a random string provided by the sender. In CMS, it is provided as
     a parameter in the UserKeyingMaterial field (encoded as an OCTET STRING). If
     provided this pubInfo MUST contain 512 bits.

   Note that the only source of secret entropy in this computation is



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


   ZZ, so the security of this data is limited to the size of ZZ, even
   if more data than ZZ is generated. However, if pubInfo is different
   for each message, a different KEK will be generated for each message.
   Note that pubInfo MUST be used in Static-Static mode, but MAY appear
   in Ephemeral-Static mode.

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.
   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.  For RC2, which
   requires 128 bits of keying material, the algorithm is run once, with
   a counter value of 1, and the left-most 128 bits are directly con-
   verted to an RC2 key.

2.1.4.  Keylengths for common algorithms

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

           3DES-EDE-ECB    192 bits
           RC2 (all)       128 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.


   The primary purpose of public key validation is to prevent a small
   subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static
   mode is used, this check may not be necessary.

   Note that this procedure may be subject to pending patents.

2.1.6.  Example 1


   ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f



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


   The key encryption algorithm is 3DES-EDE.

   No pubInfo is used

   Consequently, the input to the first invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f       ; ZZ
   30 12
      30 10
         06 08 2a 86 48 86 f7 0d 03 07                   ; 3DES-EDE OID
         04 04 00 00 00 01                               ; Counter

   And the output is the 20 bytes:

   20 be 23 e3 3b 72 ef 16 8e e3 ae 18 5a 00 93 b0 d6 49 56 22

   The input to the second invocation of SHA-1 is:

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f       ; ZZ
   30 12
      30 10
         06 08 2a 86 48 86 f7 0d 03 07                   ; 3DES-EDE OID
         04 04 00 00 00 02                               ; Counter

   And the output is the 20 bytes:

   3b 4e fd d4 6e ff 6b 6d 35 a9 cd e3 e3 e7 05 39 e0 31 53 de

   Consequently,
   K1'=20 be 23 e3 3b 72 ef 16
   K2'=8e e3 ae 18 5a 00 93 b0
   K3'=d6 49 56 22 3b 4e fd d4

   Note: These keys are not parity adjusted

2.1.7.  Example 2

   ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f

   The key encryption algorithm is RC2

   The pubInfo used is the 64 bytes 01 23 45 67 89 ab cd ef 01 23 45 67
   89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45
   67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 01 23
   45 67 89 ab cd ef

   Consequently, the input to the first invocation of SHA-1 is:




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


   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f       ; ZZ
   30 56
      30 10
         06 08 2a 86 48 86 f7 0d 03 02                   ; RC2 OID
         04 04 00 00 00 01                               ; Counter
      a2 42 04 40
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef ; PubInfo
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef
         01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef

   And the output is the 20 bytes:

   c7 4e c5 80 68 7d 70 aa 06 38 d3 e3 c7 2a da 5a 67 4e cf 06

   Consequently,
   K=c7 4e c5 80 68 7d 70 aa 06 38 d3 e3 c7 2a da 5a

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 (derived from the algorithms in FIPS PUB
   186-1[DSS], and [X942]can be found in appendix A.

   X9.42 requires that the private key x be in the interval [2, (q -
   2)]. x should be randomly generated in this interval. y is then com-
   puted by calculating g^x (mod p).  To comply with this draft, m MUST
   be >=160, (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.  Group Parameter Generation

   Agents SHOULD generate domain parameters (g,p,q) using the following
   algorithm, derived from [FIPS-186] and [X942]. When this algorithm is
   used, the correctness of the generation procedure can be verified by
   a third party by the algorithm of 2.2.2.

2.2.1.1.  Generation of p, q

   Let L - 1 = n*m + b where both b and n are integers and
   0 <= b < 160.

   1. Choose an arbitrary sequence of at least m bits and call it SEED.
   Let g be the length of SEED in bits.




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


   2. Set U = 0

   3. Set m' = m / 160, where / represents integer division,
      consequently, if m = 200, l = 1.

   4. for i = 0 to m' - 1

           U = SU + SHA[SEED + i] XOR SHA[(SEED + m' + i) mod 2g] 2^(160 * i)

   Note that for m=160, this reduces to the algorithm of [FIPS186]

           U = SHA[SEED] XOR SHA[(SEED+1) mod 2g ].

   5.  Form q from U by setting the most significant bit (the 2^(m-1) bit)
   and the least significant bit to 1. In terms of boolean operations,
   q = U OR 2^(m-1) OR 1. Note that 2^(m-1) < q < 2^m

   6. Use a robust primality algorithm to test whether q is prime.

   7. If q is not prime then go to 1.

   8. Let counter = and offset = 2

   9. For k = 0,..., n let

           Vk = SHA[(SEED + offset + k) mod 2g ].

   10. Let W be the integer

           W = V0 + V1*2160 + ... + Vn-1*2(n-1)*160 + (Vn mod 2b)
            * 2n*160
   and let
           X = W + 2L-1.

   Note that 0 <= W < 2(L-1) and hence 2^(L-1)

           Note that 0 <= W < 2^(L-1) and hence 2^(L-1) <= X < 2^L

   11. Let c = X mod 2q and set p = X - (c-1). Note that p is congruent
   to 1 mod 2q.

   12. If p < 2^(L -1) then go to step 15.

   13. Perform a robust primality test on p.

   14. If p passes the test performed in step 13 go to step 17.

   15. Let counter = counter + 1 and offset = offset + n + 1.



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


   16. If counter >=  4096 go to step 1. Otherwise go to step 7.

   17. Save the value of SEED and the value of counter for use
   in certifying the proper generation of p and q.

2.2.1.2.  Generation of g

   This section gives an algorithm (derived from [FIPS186]) for generat-
   ing g.
   1. Let e = (p - 1)/q.

   2. Set h = any integer, where 1 < h < p - 1 and h differs
   from any value previously tried.

   3. Set g = he (mod p)

   4. If g = 1 go to step 2

2.2.2.  Group Parameter Validation

   The ASN.1 for DH keys in [PKIX] includes elements j and validation-
   Parms which MAY be used by recipients of a key to verify that the
   group parameters were correctly generated. Two checks are possible:

        1. Verify that p=qj + 1. This demonstrates that the parameters meet
        the X9.42 parameter criteria.
        2. Verify that when the p,q generation procedure of [FIPS-186]
        Appendix 2 is followed with seed 'seed', that p is found when
        This demonstrates that the parameters were randomly chosen and
        do not have a special form.


   Whether agents provide validation information in their certificates
   is a local matter between the agents and their CA.

2.3.  Ephemeral-Static Mode

   In Ephemeral-Static mode, the recipient has a static (and certified)
   key pair, but the sender generates a new key pair for each message
   and sends it using the originatorKey production. If the sender's key
   is freshly generated for each message, the shared secret ZZ will be
   similarly different for each message and pubInfo MAY be omitted,
   since it serves merely to decouple multiple KEKs generated by the
   same set of pairwise keys. If, however, the same ephemeral sender key
   is used for multiple messages (e.g. it is cached as a performance
   optimization) then a separate pubInfo MUST be used for each message.
   All implementations of this standard MUST implement Ephemeral-Static
   mode.



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


2.4.  Static-Static Mode 2.4. Static-Static Mode 8

   In Static-Static mode, both the sender and the recipient have a
   static (and certified) key pair. Since the sender's and recipient's
   keys are therefore the same for each message, ZZ will be the same for
   each message. Thus, pubInfo MUST be used (and different for each mes-
   sage) in order to ensure that different messages use different KEKs.
   Implementations MAY implement Static-Static mode.

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 Paul Hoffman, Stephen Henson, 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-07.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.

   [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB)
       186, "Digital Signature Standard", 1994 May 19.

   [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public
       Key Infrastructure Certificate and CRL Profile", RFC-XXXX.

   [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
       "An efficient protocol for authenticated key agreement",
       Technical report CORR 98-05, University of Waterloo, 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels." RFC 2119. March 1997.

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




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


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.

   Static Diffie-Hellman keys are vulnerable to a small subgroup attack
   [LAW98]. In practice, this issue arises for both sides in Static-
   Static mode and for the receiver during Ephemeral-Static mode.  In
   Static-Static mode, both originator and recipient SHOULD either per-
   form the validation step described in S 2.1.5 or verify that the CA
   has properly verified the validity of the key.  In Ephemeral-Static
   mode, the recipient SHOULD perform the check described in 2.1.5. If
   the sender cannot determine success or failure of decryption, the
   recipient MAY choose to omit this check.

   In order to securely generate a symmetric key of length l, m (the
   length in bits of q, and hence x) should be at least 2l. m MUST
   always be >= 160. Consequently, for RC2, m should be >=256 and for
   3DES, >=336 (the effective length of 3DES keys is 168 bits).

Author's Address

Eric Rescorla <[e-mail]>
RTFM Inc.
30 Newell Road, #16
East Palo Alto, CA 94303






















Rescorla                                                        [Page 10]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 1 ..................................................    4

2.1.7. Example 2 ..................................................    5

2.2. Key and Parameter Requirements ...............................    6

2.2.1. Group Parameter Generation .................................    6

2.2.1.1. Generation of p, q .......................................    6

2.2.1.2. Generation of g ..........................................    8

2.2.2. Group Parameter Validation .................................    8

2.3. Ephemeral-Static Mode ........................................    8

2.4. Acknowledgements .............................................    9

2.4. References ...................................................    9




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


Security Considerations ...........................................   10

Author's Address ..................................................   10


















































Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA27032 for ietf-smime-bks; Tue, 8 Dec 1998 13:02:49 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27028 for <[e-mail]>; Tue, 8 Dec 1998 13:02:48 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id KAA27123; Wed, 9 Dec 1998 10:08:19 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91315129908461>; Wed, 9 Dec 1998 10:08:19 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Extensibility discussion
Cc: [e-mail]
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Wed, 9 Dec 1998 10:08:19 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Russ Housley <[e-mail]> wrote:

>Support for PGP requires a bit more than this.  You also need to carry
>non-X.509 PGP certificates.  CMS does not permit this.  

The need to lug armfuls of certs around with you wherever you go is an 
artifact of X.509, not something required by PGP.  All that PGP (and
SPKI) require is a way to identify the key used to sign or encrypt data
(the PGP native format doesn't even provide a way to communicate certs
a la CMS's CertificateSet, so it's really not an issue).

(To put it another way, given support for PGP and SPKI key ID's in the
 xxxInfo's, I can have a fully compatible implementation running in an 
 afternoon).

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23678 for ietf-smime-bks; Tue, 8 Dec 1998 08:03:42 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23671 for <[e-mail]>; Tue, 8 Dec 1998 08:03:40 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.122]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id IAA14327; Tue, 8 Dec 1998 08:08:23 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Dec 1998 11:08:32 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Extensibility discussion
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

Support for PGP requires a bit more than this.  You also need to carry
non-X.509 PGP certificates.  CMS does not permit this.  And, our charter
aligns the protocol with PKIX....

Russ


At 11:23 PM 12/8/98 +0000, Peter Gutmann wrote:
>"John Ross" <[e-mail]> writes:
> 
>>but what about extending the choice, are you also opposed to that?
>                                             
>This is easy to handle in theory (just add a '...' to the ASN.1) but a bit 
>more difficult to handle in practice since you need some way to coordinate
the 
>extensions of the choice (everyone can't just add their own '[n] FooInfo').  
> 
>It may be possible to maintain a register of extensions, one thing I'm 
>(gradually) working on, if no support is added to CMS itself, is
extensions to 
>Recipient/SignerInfo to allow it to be used with the other IETF-standardised 
>(or about-to-be-standardised) certificate/key formats (which I mentioned in a 
>previous message).  At the moment this lives under the name More Enhanced 
>Security Services (MESS) for S/MIME, I've had a fair bit of comment on this 
>from other groups (eg OpenPGP members) who would like to see CMS less tied to 
>X.509 certs for everything it does.
> 
>What MESS does is add a few trivial extensions to the current CMS stuff to 
>support these additional formats, it's just the additional key identifiers I 
>mentioned in a previous message plus a few other bits and pieces.  If people 
>wanted either new key identifiers or recipient info types, and provided there 
>was a reasonable justification for them (for example "x zillion PGP users
need 
>to have this" is a good one), it could be added to the MESS.
> 
>Peter.
> 
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23670 for ietf-smime-bks; Tue, 8 Dec 1998 08:03:36 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23666 for <[e-mail]>; Tue, 8 Dec 1998 08:03:35 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.122]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id IAA14329; Tue, 8 Dec 1998 08:08:26 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Dec 1998 11:09:11 -0500
To: "John Ross" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Extensibility discussion
Cc: <[e-mail]>, <[e-mail]>
In-Reply-To: <004201be22ee$86be93b0$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

You are correct.  CMS uses 1988 ASN.1.

Russ


At 01:05 PM 12/8/98 -0800, John Ross wrote:
>I believe CMS does not use the latest ASN.1 so that is one reason why I did
>not propose "add a '...' to the ASN.1".
>
>But I would be happy with that option in the CMS document, if that was
>considered more acceptable.
>
>I agree with you that additions to the choice need not be defined in CMS
>itself, MESS could be used.
>
>Regards
>
>JR
>-----Original Message-----
>From: Peter Gutmann <[e-mail]>
>To: [e-mail] <[e-mail]>
>Cc: [e-mail] <[e-mail]>
>Date: Tuesday, December 08, 1998 2:24 AM
>Subject: Re: Extensibility discussion
>
>
>>"John Ross" <[e-mail]> writes:
>>
>>>but what about extending the choice, are you also opposed to that?
>>
>>This is easy to handle in theory (just add a '...' to the ASN.1) but a bit
>>more difficult to handle in practice since you need some way to coordinate
>the
>>extensions of the choice (everyone can't just add their own '[n] FooInfo').
>>
>>It may be possible to maintain a register of extensions, one thing I'm
>>(gradually) working on, if no support is added to CMS itself, is extensions
>to
>>Recipient/SignerInfo to allow it to be used with the other
>IETF-standardised
>>(or about-to-be-standardised) certificate/key formats (which I mentioned in
>a
>>previous message).  At the moment this lives under the name More Enhanced
>>Security Services (MESS) for S/MIME, I've had a fair bit of comment on this
>>from other groups (eg OpenPGP members) who would like to see CMS less tied
>to
>>X.509 certs for everything it does.
>>
>>What MESS does is add a few trivial extensions to the current CMS stuff to
>>support these additional formats, it's just the additional key identifiers
>I
>>mentioned in a previous message plus a few other bits and pieces.  If
>people
>>wanted either new key identifiers or recipient info types, and provided
>there
>>was a reasonable justification for them (for example "x zillion PGP users
>need
>>to have this" is a good one), it could be added to the MESS.
>>
>>Peter.
>>
>>
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23665 for ietf-smime-bks; Tue, 8 Dec 1998 08:03:29 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA23661 for <[e-mail]>; Tue, 8 Dec 1998 08:03:27 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.122]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id IAA14325; Tue, 8 Dec 1998 08:08:21 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Dec 1998 11:06:27 -0500
To: "John Ross" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Extensibility discussion
Cc: <[e-mail]>
In-Reply-To: <000a01be22cc$414890a0$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<html>
John:<br>
<br>
If you read the document carefully, you will see that each *RecipientInfo
structure has a different version number in it.&nbsp; I would not like to
see an OID followed by an ANY structure here.&nbsp; It will simply
increase the liklihood on non-interoperability.&nbsp; In fact, the MSG
spec would have to profile out its use.<br>
<br>
What key management technique is not supported by the alternative
provided?<br>
<br>
Russ<br>
<br>
<br>
At 09:00 AM 12/8/98 -0800, John Ross wrote: <br>
<font size=2><blockquote type=cite cite>Russ</font><br>
&nbsp;<br>
<font size=2>OK, </font><br>
but what about extending the choice, are you also opposed to that?<br>
&nbsp;<br>
<font size=2>Regards</font><br>
&nbsp;<br>
<font size=2>JR</font><br>
<font face="arial" size=2><b><blockquote type=cite cite>-----Original
Message-----</b><br>
From: </b>Russ Housley
&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;<br>
<b>To: </b>John Ross
&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;<br>
<b>Cc: </b><a href="mailto:[e-mail]">[e-mail]</a>
&lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;<br>
<b>Date: </b>Monday, December 07, 1998 8:36 PM<br>
<b>Subject: </b>Re: Extensibility discussion<br>
<br>
</font>John:<br>
<br>
One bucket for unprotected attributes in the EnvelopedData structure is more than enough.&nbsp; If we put two such buckets (by adding a second one to <font size=2>keyAgreeRecipientInfo), then the processing gets complex.<br>
<br>
I am strongly opposed.<br>
<br>
Russ<br>
<br>
<br>
</font>At 03:12 PM 12/3/98 -0800, John Ross wrote: <br>
--Cut--<br>
<blockquote type=cite cite><br>
<font size=2>&nbsp;The following is an example ASN.1:</font><br>
<br>
&nbsp;RecipientInfo ::= CHOICE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ktri KeyTransRecipientInfo,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kari [1] KeyAgreeRecipientInfo,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kekri [2] KEKRecipientInfo<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kext [3] ExternalyDefinedKeyAgreement --for future or private key management schemes }<br>
<br>
<br>
<font size=2>ExternalyDefinedKeyAgreement :: = OCTET STRING</font><br>
<br>
<br>
Alternatively,&nbsp; the syntax of the externally defined key management use the OID extension mechanism: <br>
<br>
ExternalyDefinedKeyAgreement :: = SEQUENCE {<br>
&nbsp;&nbsp; ExternalID&nbsp; OBJECT IDENTIFIER {<br>
&nbsp;&nbsp; ExternalValue ANY DEFINED BY&nbsp; ExternalID&nbsp; <br>
}<br>
<br>
<br>
<font size=2>I slightly favor the OID extension but if there is objection to that extension mechanism, the OCTET STRING approach would be adequate.</font><br>
<br>
<br>
John Ross</blockquote></blockquote></blockquote><br>
</html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23518 for ietf-smime-bks; Tue, 8 Dec 1998 07:52:26 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23514 for <[e-mail]>; Tue, 8 Dec 1998 07:52:25 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.122]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA14001; Tue, 8 Dec 1998 07:51:08 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 08 Dec 1998 10:36:11 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Key Wrap Algoritm
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010F52B5DE@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

I did not accept al of your changes.  I had to filter them with discussion
going on with other threads.  So, attached is the Key Wrap Algorithm as
presently defined.  Note that this algorithm is limited to Triple-DES and RC2.

In addition, the following is added to the security considerations section:
Section 12.6 specifies a key wrap algorithm used to encrypt a Triple-DES [3DES]
or RC2 [RC2] content-encryption key with a Triple-DES or RC2 key-encryption key
using CBC mode [MODES].  This key wrap algorithm has been reviewed for use with
Triple-DES in CBC mode and RC2 in CBC mode; it has not been reviewed for use
with other algorithms or other modes.  Analysis has discovered concerns with
using this key wrap algorithm with stream ciphers or block ciphers in OFB mode
[MODES].  Therefore, if a CMS implementation wises to support ciphers in
addition to Triple-DES in CBC mode or RC2 in CBC mode, then additional key wrap
algorithms may need to be defined to support the additional ciphers.


Russ

= = = = = = = = = = 

12.6  Triple-DES and RC2 Key Wrap Algorithm

CMS implementations must include encryption of a Triple-DES content-encryption
key with a Triple-DES key-encryption key using the algorithm specified in this
section.  CMS implementations should include encryption of a RC2
content-encryption key with a RC2 key-encryption key.  Triple-DES and RC2
content-encryption keys are encrypted in Cipher Block Chaining (CBC) mode
[MODES].

Key Transport algorithms allow for the content-encryption key to be directly
encrypted; however, key agreement and symmetric key-encryption key algorithms
encrypt the content-encryption key with a second symmetric encryption
algorithm.  This section describes how the Triple-DES or RC2 content-encryption
key is formatted and encrypted.

Key agreement algorithms generate a pairwise key-encryption key, and a key wrap
algorithm is used to encrypt the content-encryption key with the pairwise
key-encryption key.  Similarly, a key wrap algorithm is used to encrypt the
content-encryption key in a previously distributed key-encryption key.

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

The block size of the key-encryption algorithm must be implicitly determined
from the KeyEncryptionAlgorithmIdentifier field; however, both Triple-DES and
RC2 have a block size of eight octets.

The same algorithm identifier is used for both 2-key and 3-key Triple-DES. 
When the length of the wrapped content-encryption key is 16 octets, 2-key
Triple-DES is used for the content-encryption algorithm.  Similarly, when the
length of the wrapped content-encryption key is 24 octets, 3-key Triple-DES is
used for the content-encryption algorithm.

12.6.1  Key Checksum

The Fletcher checksum [SUM] algorithm is used to provide an integrity check
value.  The algorithm is:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Loop through the octets of the content-encryption key, most
    significant (first) octet to least significant (last) octet.
    2a.  Create a 16 bit integer, called temp, by concatenating 
         eight zero bits and the key octet.
    2b.  sum1 = sum1 + temp.
    2c.  sum2 = sum2 + sum1.
3.  Use sum2 as the checksum value.

12.6.2  Key Wrap

1.  Modify the content-encryption key to meet any restrictions on the key.
    For example, adjust the parity bits for each DES key comprising a 
    Triple-DES key.
2.  Compute a 16-bit key checksum value on the content-encryption key as
    described Section 12.6.1 above.
3.  Generate a 32-bit random salt value.
4.  Concatenate the salt, content-encryption key, and key checksum value.
5.  Pad the result, using the technique specified in Section 6.3, so 
    that the padded result is a multiple of eight (the Triple-DES and
    RC2 block size).  Append the pad to the result.
6.  Encrypt in CBC mode the padded result using the key-encryption key.
    Use an IV with each octet equal to 'A5' hexadecimal.

12.6.3  Key Unwrap

The key unwrap algorithm is:

1.  Decrypt in CBC mode the ciphertext using the key-encryption key.  Use
    an IV with each octet equal to 'A5' hexadecimal.
2.  Decompose the result into the content-encryption key and key checksum
    values.  The salt and pad values are discarded.
3.  Compute a 16-bit key checksum value on the content-encryption key
    as described in Section 12.6.1 above.
4.  If the computed key checksum value does not match the decrypted key
    checksum value, then there is an error.
5.  If there are restrictions on keys, then check if the content-
    encryption key meets these restrictions.  For example, check for odd
    parity of each octet in each DES key that makes up a Triple-DES key.
    If any restriction is incorrect, then there is an error.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA21794 for ietf-smime-bks; Tue, 8 Dec 1998 05:02:20 -0800 (PST)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA21790 for <[e-mail]>; Tue, 8 Dec 1998 05:02:19 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.054 #1) id 0znMrn-0003ed-00; Tue, 8 Dec 1998 13:07:51 +0000
Message-ID: <004201be22ee$86be93b0$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Extensibility discussion
Date: Tue, 8 Dec 1998 13:05:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

I believe CMS does not use the latest ASN.1 so that is one reason why I did
not propose "add a '...' to the ASN.1".

But I would be happy with that option in the CMS document, if that was
considered more acceptable.

I agree with you that additions to the choice need not be defined in CMS
itself, MESS could be used.

Regards

JR
-----Original Message-----
From: Peter Gutmann <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: Tuesday, December 08, 1998 2:24 AM
Subject: Re: Extensibility discussion


>"John Ross" <[e-mail]> writes:
>
>>but what about extending the choice, are you also opposed to that?
>
>This is easy to handle in theory (just add a '...' to the ASN.1) but a bit
>more difficult to handle in practice since you need some way to coordinate
the
>extensions of the choice (everyone can't just add their own '[n] FooInfo').
>
>It may be possible to maintain a register of extensions, one thing I'm
>(gradually) working on, if no support is added to CMS itself, is extensions
to
>Recipient/SignerInfo to allow it to be used with the other
IETF-standardised
>(or about-to-be-standardised) certificate/key formats (which I mentioned in
a
>previous message).  At the moment this lives under the name More Enhanced
>Security Services (MESS) for S/MIME, I've had a fair bit of comment on this
>from other groups (eg OpenPGP members) who would like to see CMS less tied
to
>X.509 certs for everything it does.
>
>What MESS does is add a few trivial extensions to the current CMS stuff to
>support these additional formats, it's just the additional key identifiers
I
>mentioned in a previous message plus a few other bits and pieces.  If
people
>wanted either new key identifiers or recipient info types, and provided
there
>was a reasonable justification for them (for example "x zillion PGP users
need
>to have this" is a good one), it could be added to the MESS.
>
>Peter.
>
>





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA18968 for ietf-smime-bks; Tue, 8 Dec 1998 02:18:12 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA18964 for <[e-mail]>; Tue, 8 Dec 1998 02:18:11 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA22559; Tue, 8 Dec 1998 23:23:34 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91311261306739>; Tue, 8 Dec 1998 23:23:33 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Extensibility discussion
Cc: [e-mail]
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 8 Dec 1998 23:23:33 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

"John Ross" <[e-mail]> writes:
 
>but what about extending the choice, are you also opposed to that?
                                             
This is easy to handle in theory (just add a '...' to the ASN.1) but a bit 
more difficult to handle in practice since you need some way to coordinate the 
extensions of the choice (everyone can't just add their own '[n] FooInfo').  
 
It may be possible to maintain a register of extensions, one thing I'm 
(gradually) working on, if no support is added to CMS itself, is extensions to 
Recipient/SignerInfo to allow it to be used with the other IETF-standardised 
(or about-to-be-standardised) certificate/key formats (which I mentioned in a 
previous message).  At the moment this lives under the name More Enhanced 
Security Services (MESS) for S/MIME, I've had a fair bit of comment on this 
from other groups (eg OpenPGP members) who would like to see CMS less tied to 
X.509 certs for everything it does.
 
What MESS does is add a few trivial extensions to the current CMS stuff to 
support these additional formats, it's just the additional key identifiers I 
mentioned in a previous message plus a few other bits and pieces.  If people 
wanted either new key identifiers or recipient info types, and provided there 
was a reasonable justification for them (for example "x zillion PGP users need 
to have this" is a good one), it could be added to the MESS.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA18565 for ietf-smime-bks; Tue, 8 Dec 1998 00:56:59 -0800 (PST)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA18561 for <[e-mail]>; Tue, 8 Dec 1998 00:56:57 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.054 #1) id 0znJ2G-0004Mo-00; Tue, 8 Dec 1998 09:02:24 +0000
Message-ID: <000a01be22cc$414890a0$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Extensibility discussion
Date: Tue, 8 Dec 1998 09:00:24 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BE2289.319B0720"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01BE2289.319B0720
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Russ

OK,=20
but what about extending the choice, are you also opposed to that?

Regards

JR
    -----Original Message-----
    From: Russ Housley <[e-mail]>
    To: John Ross <[e-mail]>
    Cc: [e-mail] <[e-mail]>
    Date: Monday, December 07, 1998 8:36 PM
    Subject: Re: Extensibility discussion
   =20
   =20
    John:
   =20
    One bucket for unprotected attributes in the EnvelopedData structure =
is more than enough.  If we put two such buckets (by adding a second one =
to keyAgreeRecipientInfo), then the processing gets complex.
   =20
    I am strongly opposed.
   =20
    Russ
   =20
   =20
    At 03:12 PM 12/3/98 -0800, John Ross wrote:=20
    --Cut--
   =20
       =20
         The following is an example ASN.1:
       =20
         RecipientInfo ::=3D CHOICE {
                ktri KeyTransRecipientInfo,
                kari [1] KeyAgreeRecipientInfo,
                kekri [2] KEKRecipientInfo
                kext [3] ExternalyDefinedKeyAgreement --for future or =
private key management schemes }
       =20
       =20
        ExternalyDefinedKeyAgreement :: =3D OCTET STRING
       =20
       =20
        Alternatively,  the syntax of the externally defined key =
management use the OID extension mechanism:=20
       =20
        ExternalyDefinedKeyAgreement :: =3D SEQUENCE {
           ExternalID  OBJECT IDENTIFIER {
           ExternalValue ANY DEFINED BY  ExternalID =20
        }
       =20
       =20
        I slightly favor the OID extension but if there is objection to =
that extension mechanism, the OCTET STRING approach would be adequate.
       =20
       =20
        John Ross
       =20
   =20


------=_NextPart_000_0007_01BE2289.319B0720
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Russ</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>OK, </FONT></DIV>
<DIV><FONT size=3D2>but what about extending the choice, are you also =
opposed to=20
that?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Regards</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>JR</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
    </B>Russ Housley &lt;<A=20
    =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>To:=20
    </B>John Ross &lt;<A=20
    =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<B=
R><B>Cc:=20
    </B><A href=3D"mailto:[e-mail]">[e-mail]</A> =
&lt;<A=20
    =
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>Date:=
=20
    </B>Monday, December 07, 1998 8:36 PM<BR><B>Subject: </B>Re: =
Extensibility=20
    discussion<BR><BR></DIV></FONT>John:<BR><BR>One bucket for =
unprotected=20
    attributes in the EnvelopedData structure is more than enough.&nbsp; =
If we=20
    put two such buckets (by adding a second one to <FONT=20
    size=3D2>keyAgreeRecipientInfo), then the processing gets =
complex.<BR><BR>I am=20
    strongly opposed.<BR><BR>Russ<BR><BR><BR></FONT>At 03:12 PM 12/3/98 =
-0800,=20
    John Ross wrote: </BLOCKQUOTE>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">--Cut--<BR><FONT=20
    size=3D2></FONT>
    <BLOCKQUOTE cite type =3D cite><BR><FONT size=3D2>&nbsp;The =
following is an=20
        example ASN.1:</FONT><BR><BR>&nbsp;RecipientInfo ::=3D CHOICE=20
        {<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ktri=20
        =
KeyTransRecipientInfo,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        kari [1]=20
        =
KeyAgreeRecipientInfo,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        kekri [2] =
KEKRecipientInfo<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        kext [3] ExternalyDefinedKeyAgreement --for future or private =
key=20
        management schemes }<BR><BR><BR><FONT=20
        size=3D2>ExternalyDefinedKeyAgreement :: =3D OCTET=20
        STRING</FONT><BR><BR><BR><FONT size=3D2>Alternatively,&nbsp; the =
syntax of=20
        the externally defined key management use the OID extension =
mechanism:=20
        </FONT><BR><BR><FONT size=3D2>ExternalyDefinedKeyAgreement :: =
=3D SEQUENCE=20
        {</FONT><BR>&nbsp;&nbsp; ExternalID&nbsp; OBJECT IDENTIFIER=20
        {<BR>&nbsp;&nbsp; ExternalValue ANY DEFINED BY&nbsp; =
ExternalID&nbsp;=20
        <BR>}<BR><BR><BR><FONT size=3D2>I slightly favor the OID =
extension but if=20
        there is objection to that extension mechanism, the OCTET STRING =

        approach would be adequate.</FONT><BR><BR><BR><FONT =
size=3D2>John=20
        Ross</FONT><BR></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0007_01BE2289.319B0720--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08964 for ietf-smime-bks; Mon, 7 Dec 1998 20:31:02 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08959 for <[e-mail]>; Mon, 7 Dec 1998 20:31:01 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.126]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id UAA09518; Mon, 7 Dec 1998 20:36:16 -0800 (PST)
Message-Id: <4.1.19981207171025.00972470@209.172.119.123>
Message-Id: <4.1.19981207171025.00972470@209.172.119.123>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 07 Dec 1998 17:12:23 -0500
To: "John Ross" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Extensibility discussion
Cc: [e-mail]
In-Reply-To: <001b01be1f12$a45aa970$0400000a@jrwork>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<html>
John:<br>
<br>
One bucket for unprotected attributes in the EnvelopedData structure is
more than enough.&nbsp; If we put two such buckets (by adding a second
one to <font size=2>keyAgreeRecipientInfo), then the processing gets
complex.<br>
<br>
I am strongly opposed.<br>
<br>
Russ<br>
<br>
<br>
</font>At 03:12 PM 12/3/98 -0800, John Ross wrote: <br>
<font size=2><blockquote type=cite cite>The latest version of CMS (09)
has added plaintextAttrs to EnvelopedData which allows extension to be
defined for EnvelopedData,</font><br>
&nbsp;<br>
<font size=2>Is there any reason why keyAgreeRecipientInfo should not be
made extensible in the same way?</font><br>
&nbsp;<br>
<font size=2>The following is an example ASN.1:</font> <br>
<font size=2>&nbsp;</font><br>
&nbsp; KeyAgreeRecipientInfo ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to
3<br>
&nbsp;&nbsp;&nbsp;&nbsp; originator [0] EXPLICIT
OriginatorIdentifierOrKey,<br>
&nbsp;&nbsp;&nbsp;&nbsp; ukm [1] EXPLICIT UserKeyingMaterial
OPTIONAL,<br>
&nbsp;&nbsp;&nbsp;&nbsp; keyEncryptionAlgorithm
KeyEncryptionAlgorithmIdentifier,<br>
&nbsp;&nbsp;&nbsp;&nbsp; recipientEncryptedKeys RecipientEncryptedKeys
<br>
&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [2] IMPLICIT UnsignedAttributes
OPTIONAL }<br>
&nbsp;<br>
&nbsp;<br>
<font size=2>However, if CMS want to be able to support more key
agreement algorithms in the future, perhaps the best way to allow that
would be to allow the CHOICE of RecipientInfo to be extendable .
</font><br>
&nbsp;<br>
&nbsp;<br>
<font size=2>&nbsp;The following is an example ASN.1:</font><br>
&nbsp;<br>
&nbsp;RecipientInfo ::= CHOICE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ktri
KeyTransRecipientInfo,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kari [1]
KeyAgreeRecipientInfo,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kekri [2]
KEKRecipientInfo<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kext [3]
ExternalyDefinedKeyAgreement --for future or private key management
schemes }<br>
&nbsp;<br>
&nbsp;<br>
<font size=2>ExternalyDefinedKeyAgreement :: = OCTET STRING</font><br>
&nbsp;<br>
&nbsp;<br>
<font size=2>Alternatively,&nbsp; the syntax of the externally defined
key management use the OID extension mechanism: </font><br>
&nbsp;<br>
<font size=2>ExternalyDefinedKeyAgreement :: = SEQUENCE {</font><br>
&nbsp;&nbsp; ExternalID&nbsp; OBJECT IDENTIFIER {<br>
&nbsp;&nbsp; ExternalValue ANY DEFINED BY&nbsp; ExternalID&nbsp; <br>
}<br>
&nbsp;<br>
&nbsp;<br>
<font size=2>I slightly favor the OID extension but if there is objection
to that extension mechanism, the OCTET STRING approach would be
adequate.</font><br>
&nbsp;<br>
&nbsp;<br>
<font size=2>John Ross</font><br>
&nbsp;</blockquote><br>
</html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA08956 for ietf-smime-bks; Mon, 7 Dec 1998 20:30:30 -0800 (PST)
Received: from spyrus.com ([207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA08952 for <[e-mail]>; Mon, 7 Dec 1998 20:30:29 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([207.212.34.126]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id UAA09481; Mon, 7 Dec 1998 20:35:42 -0800 (PST)
Message-Id: <4.1.19981207133222.009b07d0@209.172.119.123>
Message-Id: <4.1.19981207133222.009b07d0@209.172.119.123>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 07 Dec 1998 13:32:43 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Comments on CMC-09, Section 12.3.1.1
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

Already done.  It will be in CMS-10.

Russ


At 11:38 PM 12/6/98 +0000, Peter Gutmann wrote:
>Russ Housley <[e-mail]> writes:
> 
>>People who want to use E-S D-H with other algorithms are free to assign 
>>additional algorithm identifiers for use in the KeyWrapAlgorithm.  In fact, 
>>these additional algorithms need not follow the technque specified in CMS 
>>Secion 12.6.  These additional assignments will not represent "must" 
>>implement or "should" implement algorithms.
> 
>Would it be possible to insert text to this effect either in section 6.2.3 or 
>12.6?  At the moment 12.6 seems to imply that you can only use the given wrap 
>algorithm, however in some cases it's useful to be able to support other key 
>wrap techniques, especially when implemented via crypto hardware over which 
>you have no control.
> 
>Peter.
> 
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA20860 for ietf-smime-bks; Sun, 6 Dec 1998 02:33:14 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA20856 for <[e-mail]>; Sun, 6 Dec 1998 02:33:12 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id XAA29200 for <[e-mail]>; Sun, 6 Dec 1998 23:38:26 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91294070620655>; Sun, 6 Dec 1998 23:38:26 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Comments on CMC-09, Section 12.3.1.1
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 6 Dec 1998 23:38:26 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Russ Housley <[e-mail]> writes:
 
>People who want to use E-S D-H with other algorithms are free to assign 
>additional algorithm identifiers for use in the KeyWrapAlgorithm.  In fact, 
>these additional algorithms need not follow the technque specified in CMS 
>Secion 12.6.  These additional assignments will not represent "must" 
>implement or "should" implement algorithms.
 
Would it be possible to insert text to this effect either in section 6.2.3 or 
12.6?  At the moment 12.6 seems to imply that you can only use the given wrap 
algorithm, however in some cases it's useful to be able to support other key 
wrap techniques, especially when implemented via crypto hardware over which 
you have no control.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA19155 for ietf-smime-bks; Sat, 5 Dec 1998 23:12:37 -0800 (PST)
Received: from wwpceqrfyibk (user-38lc2ie.dialup.mindspring.com [209.86.10.78]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA19151 for <[e-mail]>; Sat, 5 Dec 1998 23:12:33 -0800 (PST)
X-Reply-To:  [e-mail]
Message-ID: <udbfqxje>
To: [e-mail]
DATE: Sun, 06 Dec 1998 02:17:52 -0500
From: [e-mail]
Subject:  Unrecognized Market Potential
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Company: American Interactive media Group, Inc.
Symbol: AIME

AIME is trading below historical highs. Recent corporate activity leads one to believe this company is about to achieve high recognition as a unique and important Internet company.

AIME creates Portals for large affinity groups.  

Recently AIME announced that "MMG Direct", one of the countries largest telemarketing firms with over 30,000,000 in its membership base. Has agreed to offer AIME's services to the MMG Direct database. If the company only experiences a 2% penetration (600,000 subscribers). AIME will become a leader in the field of original content and programming.  MMG is only the first.

AIME has positioned itself in a similar position as many successful software co's in the early stages of the personal computer explosion.  "content is king" and AIME has the resources to take advantage of it. 

The ability for these newly created programs to migrate to cable shines a bright light on AIME's position as a company with outstanding long term potential.  

This email is confidential and for subscribers to the Small Cap Email News only. If you have received this in error please disregard. In order to correct errors please reply and place the word "error" in the subject line. Our system will remove your address at once.

From: The Small Cap Email News
P.O. Box 310520
Longwood Florida 32750 

This is not a solicitation to buy or sell any security. This is not a paid advertisement for the company reported upon. The Small Cap News is a auto news flash email system. Subscriber are alerted on subjects of their interest in the stock markets. Alert categories include: Short Alerts, Long Alerts, Activity Alert, and
Trading Slowdown Alerts.

Subscribers are warned to use the analytical properties of these alerts at their own risk. Small Cap News makes no claims or guarantees to the uses and results to be gained through this service. 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14353 for ietf-smime-bks; Fri, 4 Dec 1998 10:26:20 -0800 (PST)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA14348 for <[e-mail]>; Fri, 4 Dec 1998 10:26:19 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.054 #1) id 0zm00q-00011a-00; Fri, 4 Dec 1998 18:31:32 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Dec 1998 18:28:37 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Comments on CMC-09, Section 12.6.2
References: <4.1.19981203135230.0096cc00@209.172.119.123>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Russ Housley wrote:
> 
> Steve & Jim:
> 
> >> > > >15.  Section 12.6.2 - You have not modified the key wrap algorithm
> to allow
> >> > > >for arbitrary length RC2 key sources.
> >> > >
> >> > > Are you suggesting an explicit length field or something else?
> >> >
> >> > We need to either put in an explicit length field or use a known padding
> >> > algorithm.  I have no perference on which is used but something along this
> >> > lines is absolutely required.
> >>
> >> Speaking personally I'd prefer known padding. Known padding at least
> >> adds some consistency with the use of symmetric algorithms:
> >> they all use the "padded" forms.
> >>
> >> If an explicit length parameter is included the logical place to put it
> >> is in the EncryptedContentInfo structure because its a property of the
> >> content encryption key. You'd probably then have to make it OPTIONAL for
> >> v2 compatability only include it when at least one recipient used key
> >> agreement.
> >
> >If I was to put it some place I would put it into the encrypted content to
> >make for minimual changes from now.
> 
> Why not replace random padding with the technique specified in 6.3?  I do
> not see any advantage to the random block prior to the 6.3 padding.
> 
> I am going to change the text for CMS-10 this way.  Anyone object?
> 

No objections at all. I only included it because the original wrap
algorithm included the addition of a random padding.

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA12071 for ietf-smime-bks; Fri, 4 Dec 1998 05:59:47 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12067 for <[e-mail]>; Fri, 4 Dec 1998 05:59:46 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA16626; Fri, 4 Dec 1998 09:03:36 -0500
Message-Id: <4.1.19981203135230.0096cc00@209.172.119.123>
Message-Id: <4.1.19981203135230.0096cc00@209.172.119.123>
Message-Id: <4.1.19981203135230.0096cc00@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 03 Dec 1998 14:44:51 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Comments on CMC-09, Section 12.6.2
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5B19@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Steve & Jim:

>> > > >15.  Section 12.6.2 - You have not modified the key wrap algorithm
to allow
>> > > >for arbitrary length RC2 key sources.
>> > >
>> > > Are you suggesting an explicit length field or something else?
>> >
>> > We need to either put in an explicit length field or use a known padding
>> > algorithm.  I have no perference on which is used but something along this
>> > lines is absolutely required.
>> 
>> Speaking personally I'd prefer known padding. Known padding at least
>> adds some consistency with the use of symmetric algorithms: 
>> they all use the "padded" forms.
>> 
>> If an explicit length parameter is included the logical place to put it
>> is in the EncryptedContentInfo structure because its a property of the
>> content encryption key. You'd probably then have to make it OPTIONAL for
>> v2 compatability only include it when at least one recipient used key
>> agreement.
>
>If I was to put it some place I would put it into the encrypted content to
>make for minimual changes from now.

Why not replace random padding with the technique specified in 6.3?  I do
not see any advantage to the random block prior to the 6.3 padding.

I am going to change the text for CMS-10 this way.  Anyone object?

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA12061 for ietf-smime-bks; Fri, 4 Dec 1998 05:59:34 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12057 for <[e-mail]>; Fri, 4 Dec 1998 05:59:33 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA16630; Fri, 4 Dec 1998 09:03:37 -0500
Message-Id: <4.1.19981203142803.0092ac40@209.172.119.123>
Message-Id: <4.1.19981203142803.0092ac40@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 03 Dec 1998 14:37:51 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Comments on CMC-09, Section 12.3.1.1
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5B19@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim & Steve:

>> > > >16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV present and
is its
>> > > >value the constant 'A5' repeated n time?  The IV was not present in the
>> > > >previous versions but would appear to be present now.  We still have
the IV
>> > > >restriction on the key wrap algorithm however.
>> > >
>> > > There is no field needed to carry the IV as it is always "A5...A5".  For
3DES,
>> > > the parameter is always NULL, and for RC2 the parameter is the effective
key
>> > > length.  Where do you see an IV?
>> > 
>> > OK -- I see where I got confused.  I started with the second paragraph in
>> > section 12.3.1 and made a leap of incorrectness into the fact that the
>> > KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap.  I don't see
>> > any clarifications that need to be added to the text, I was just skimming
>> > the changes too fast.
>> 
>> Just to add a little comment of my own since I suggested part of this.
>> My primary reason for this change is to allow algorithms other than RC2
>> and 3DES to be used with key agreement. In the case of RC2 and 3DES a
>> special algorithm identifier form is defined without the IV. In other
>> cases, such as (single) DES the normal algorithm identifier would be
>> used which would include an IV: but in this case it would be ignored
>> and A5 used.
>
>Yes -- this is what I kind of expected to have happen.  I would however make
>an assert that the IV MUST be 'A5' and encoded as such.

Presetly, two key wrap algorithm identifiers are defined.  They are:

        id-alg-3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 3 }

        id-alg-RC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
            us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 4 }

People who want to use E-S D-H with other algorithms are free to assign
additional algorithm identifiers for use in the KeyWrapAlgorithm.  In fact,
these additional algorithms need not follow the technque specified in CMS
Secion 12.6.  These additional assignments will not represent "must" implement
or "should" implement algorithms.

I consider this issue closed.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA12032 for ietf-smime-bks; Fri, 4 Dec 1998 05:58:13 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12028 for <[e-mail]>; Fri, 4 Dec 1998 05:58:12 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA16560; Fri, 4 Dec 1998 09:03:13 -0500
Message-Id: <4.1.19981203090228.00999ee0@209.172.119.123>
Message-Id: <4.1.19981203090228.00999ee0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 03 Dec 1998 09:13:10 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: More X942-03 Comments
Cc: [e-mail], [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5B23@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>1.  The X9.42 document is the correct place to put sizing on the UKM
>material as it is going to be tied to items such as the hash algorithm being
>used.  I think this means that that the last sentence in the paragraph (on
>pubInfo) should be alted to be 
>"In CMS, it is provided as a parameter in the UserKeyingMaterial field
>(encoded as an OCTET STRING).  If provided this pubInfo MUST contain 512
>bits."

This is fine with me.

>2.  The number 512 represents a minimum value which is determined by looking
>at the hash function and making sure that a complete buffer has been filled.

Not quite.  The SHA-1 algorithm has an internal block size of 512 bits.
So, making the UKM longer than 512 bits does not add any additional entropy.

>3.  The number 512 is not a maximum number.  There is no real limit but 1023
>would be the maximum number that could possibly make sense as there is no
>additional benifit to filling the buffer more than twice.

There is not any limit.  SHA-1 will take arbitrary length inputs.  There is
diminishing benifit for values larger than 512 bits.

>4.  If (sizeof(ZZ) + sizeof(OtherInfo) - sizeof(pubInfo)) % 512 = 256, you
>fill out this complete block size with random material.  You then fill half
>of the next block with random material and half with fixed material.  Not
>knowing enough about how these things work, is there any true benifit to
>make sure that the half of fixed material is really random material?  From
>your message it would appear that the first fill is the most important
>portion and thus the minimum from step 1 is really what ever is needed to
>fill out the last block following ZZ.

The SHA-1 block is internal to the SHA-1 algorithm.  There is no reason for
us to align with the internal block.  We are simply using SHA-1 to mix
entropy from pubInfo into the key value.

Russ 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA12026 for ietf-smime-bks; Fri, 4 Dec 1998 05:58:03 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA12022 for <[e-mail]>; Fri, 4 Dec 1998 05:58:02 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA16555; Fri, 4 Dec 1998 09:03:12 -0500
Message-Id: <4.1.19981203090000.0099e8d0@209.172.119.123>
Message-Id: <4.1.19981203090000.0099e8d0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 03 Dec 1998 09:01:26 -0500
To: Sarbari Gupta <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: goals and milestones up to date?
Cc: [e-mail]
In-Reply-To: <51BF55C30B4FD1118B4900207812701E24F8F8@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

We were overly optimistic when we developed the milestones.  Patent and
algorithm discussions took much more time than expected.

Russ


At 02:44 PM 12/2/98 -0500, Sarbari Gupta wrote:
>I recently visited the S/MIME web page at
>http://www.ietf.org/html.charters/smime-charter.html and was a bit
>confused with the "Goals and Milestones" section. All the milestones
>seem to be referring to late 1997 and early 1998 dates. Is this the
>right information?
>
>Specifically, I was trying to find out the milestones/dates with respect
>to the "S/MIME Version 3 Message Specification" and "Cryptographic
>Message Syntax" I-Ds. 
>
>- Sarbari Gupta
>=================================
>Sarbari Gupta
>CygnaCom Solutions
>[phone] (voice)
>[phone](FAX)
>[e-mail]
>=================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA05884 for ietf-smime-bks; Fri, 4 Dec 1998 01:28:18 -0800 (PST)
Received: from post.mail.demon.net (post-22.mail.demon.net [194.217.242.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA05879 for <[e-mail]>; Fri, 4 Dec 1998 01:28:16 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.054 #1) id 0zlrc7-0000S3-00; Fri, 4 Dec 1998 09:33:27 +0000
Message-ID: <000001be1fab$f1b12660$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: <[e-mail]>, "Ietf distribution list" <[e-mail]>
Subject: Re: Extensibility discussion
Date: Thu, 3 Dec 1998 16:32:03 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

I personally think extending the choice will do, but it depends on how
flexible we need to be.

-----Original Message-----
From: Rich Ankney <[e-mail]>
To: John Ross <[e-mail]>; Ietf distribution list
<[e-mail]>
Date: Thursday, December 03, 1998 7:59 AM
Subject: Re: Extensibility discussion


>The attributes are outside the RecipientInfo, so they can be used
>with key transport recipients, key agreement recipients, or KEK
>recipients.  Is there really a need to put them inside the RecipientInfo?
>as well (or instead)?
>
>I do like the idea of adding an additional CHOICE to accommodate
>future key management mechanisms.  The OID/ANY approach seems
>the most flexible approach.

>
>/ Rich
>----------
>From: John Ross <[e-mail]>
>To: Ietf distribution list <[e-mail]>
>Subject: Extensibility discussion
>Date: Thursday, December 03, 1998 6:12 PM
>
>The latest version of CMS (09) has added plaintextAttrs to EnvelopedData
>which allows extension to be defined for EnvelopedData,
>
>Is there any reason why keyAgreeRecipientInfo should not be made extensible
>in the same way?
>
>The following is an example ASN.1:
>
>  KeyAgreeRecipientInfo ::= SEQUENCE {
>     version CMSVersion,  -- always set to 3
>     originator [0] EXPLICIT OriginatorIdentifierOrKey,
>     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>     recipientEncryptedKeys RecipientEncryptedKeys
>     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }
>
>
>
>However, if CMS want to be able to support more key agreement algorithms in
>the future, perhaps the best way to allow that would be to allow the CHOICE
>of RecipientInfo to be extendable .
>
>
> The following is an example ASN.1:
>
> RecipientInfo ::= CHOICE {
>        ktri KeyTransRecipientInfo,
>        kari [1] KeyAgreeRecipientInfo,
>        kekri [2] KEKRecipientInfo
>        kext [3] ExternalyDefinedKeyAgreement --for future or private key
>management schemes }
>
>
>ExternalyDefinedKeyAgreement :: = OCTET STRING
>
>
>Alternatively,  the syntax of the externally defined key management use the
>OID extension mechanism:
>
>ExternalyDefinedKeyAgreement :: = SEQUENCE {
>   ExternalID  OBJECT IDENTIFIER {
>   ExternalValue ANY DEFINED BY  ExternalID
>}
>
>
>I slightly favor the OID extension but if there is objection to that
>extension mechanism, the OCTET STRING approach would be adequate.
>
>
>John Ross
>
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04188 for ietf-smime-bks; Thu, 3 Dec 1998 09:26:39 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04184 for <[e-mail]>; Thu, 3 Dec 1998 09:26:38 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGCYKG>; Thu, 3 Dec 1998 09:29:41 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B33@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: Additional smime-type definition
Date: Thu, 3 Dec 1998 09:29:29 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I would like the working group to consider the addition of the following
paragraph(s) to the MSG draft.

(new section) 3.2.2  The smime-type parameter

The application/pkcs7-mime content type defines the optional "smime-type"
parameter.  The intent of this parameter is to convey details about the
security applied (signed or enveloped) along with infomation about the
contained content.  This draft defines the following smime-types.

Name				Security		Inner Content
enveloped-data		EnvelopedData	 id-data
signed-data			SignedData		 id-data
certs-only			SignedData		 none

In order that consistancy can be obtained with future, the following
guidelines should be followed when assigning a new smime-type parameter.

1.  If both signing and encryption can be applied to the content, then two
values for smime-type should be assigned "signed-*" and "encrypted-*".  If
one one operation can be assigned then this may be omitted.  Thus since
"certs-only" can only be signed, "signed-" is omitted.

2.  A common string for a content oid should be assigned.   We use "data"
for the id-data content OID when mime is the inner content.

3.  If no common string is assigned.  Then the common string of "OID.<oid>"
is recommended.





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04061 for ietf-smime-bks; Thu, 3 Dec 1998 09:17:27 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04057 for <[e-mail]>; Thu, 3 Dec 1998 09:17:26 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPL4WQS0>; Thu, 3 Dec 1998 09:20:38 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010F52B5DE@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: Key Wrap Algoritm
Date: Thu, 3 Dec 1998 09:20:21 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I gave the section on key wrapping to one of our developers to implement and
just finished reviewing the code which he produced.  As is not too
supprising, the code which was generated was incorrect and therefore I am
proposing changes to make it easier to implement the code correctly.


1.  In section 12.6.  Delete the last paragraph.  It is no longer needed due
to other changes being made.

2.  Replace section 12.6.2 with the following:

   1.  Modify the content-encryption key to meet any restrictions on the
key.  For example, adjust the parity bits for each DES key comprising a
Triple-DES key.
   2.  Compute a 16-bit key checksum value on the content-encryption key as
described above.
   3.  Generate a 32-bit random salt value.
   4.  Concatenate the salt, content-encryption key, and key checksum value.
   5.  Pad the data to a multiple block size of the key encryptoin algorithm
using the procedures from section 6.3.
   6.  Encrypt the result with the key-encryption algorithm key.  Use an IV
with each octet equal to 'A5' hexadecimal.

   Some key-encryption algorithm identifiers include an IV as part of the
parameters.  The IV should be encoded as above, but must be ignored and the
above constant used if not correctly encoded.

3.  No changes to section 12.6.3


jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA04056 for ietf-smime-bks; Thu, 3 Dec 1998 09:17:26 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA04052 for <[e-mail]>; Thu, 3 Dec 1998 09:17:25 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGCY2W>; Thu, 3 Dec 1998 09:20:28 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010F52B5DB@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: Additional smime-type definition
Date: Thu, 3 Dec 1998 09:20:20 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I would like the working group to consider the addition of the following
paragraph(s) to the MSG draft.

(new section) 3.2.2  The smime-type parameter

The application/pkcs7-mime content type defines the optional "smime-type"
parameter.  The intent of this parameter is to convey details about the
security applied (signed or enveloped) along with infomation about the
contained content.  This draft defines the following smime-types.

Name				Security		Inner Content
enveloped-data		EnvelopedData	 id-data
signed-data			SignedData		 id-data
certs-only			SignedData		 none

In order that consistancy can be obtained with future, the following
guidelines should be followed when assigning a new smime-type parameter.

1.  If both signing and encryption can be applied to the content, then two
values for smime-type should be assigned "signed-*" and "encrypted-*".  If
one one operation can be assigned then this may be omitted.  Thus since
"certs-only" can only be signed, "signed-" is omitted.

2.  A common string for a content oid should be assigned.   We use "data"
for the id-data content OID when mime is the inner content.

3.  If no common string is assigned.  Then the common string of "OID.<oid>"
is recommended.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA02919 for ietf-smime-bks; Thu, 3 Dec 1998 07:54:10 -0800 (PST)
Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02915 for <[e-mail]>; Thu, 3 Dec 1998 07:54:08 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-111-123.s123.tnt1.ann.erols.com [207.172.111.123]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id KAA14589; Thu, 3 Dec 1998 10:57:41 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "John Ross" <[e-mail]>, "Ietf distribution list" <[e-mail]>
Subject: Re: Extensibility discussion
Date: Thu, 3 Dec 1998 10:59:01 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

The attributes are outside the RecipientInfo, so they can be used
with key transport recipients, key agreement recipients, or KEK
recipients.  Is there really a need to put them inside the RecipientInfo?
as well (or instead)?

I do like the idea of adding an additional CHOICE to accommodate
future key management mechanisms.  The OID/ANY approach seems
the most flexible approach.

/ Rich
----------
From: John Ross <[e-mail]>
To: Ietf distribution list <[e-mail]>
Subject: Extensibility discussion
Date: Thursday, December 03, 1998 6:12 PM

The latest version of CMS (09) has added plaintextAttrs to EnvelopedData
which allows extension to be defined for EnvelopedData,
 
Is there any reason why keyAgreeRecipientInfo should not be made extensible
in the same way?
 
The following is an example ASN.1: 
 
  KeyAgreeRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys 
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }

 
 
However, if CMS want to be able to support more key agreement algorithms in
the future, perhaps the best way to allow that would be to allow the CHOICE
of RecipientInfo to be extendable . 
 

 The following is an example ASN.1:
 
 RecipientInfo ::= CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo
        kext [3] ExternalyDefinedKeyAgreement --for future or private key
management schemes }
 
 
ExternalyDefinedKeyAgreement :: = OCTET STRING
 
 
Alternatively,  the syntax of the externally defined key management use the
OID extension mechanism: 
 
ExternalyDefinedKeyAgreement :: = SEQUENCE {
   ExternalID  OBJECT IDENTIFIER {
   ExternalValue ANY DEFINED BY  ExternalID  
}
 

I slightly favor the OID extension but if there is objection to that
extension mechanism, the OCTET STRING approach would be adequate.
 

John Ross




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA02452 for ietf-smime-bks; Thu, 3 Dec 1998 07:11:16 -0800 (PST)
Received: from post.mail.demon.net (post-22.mail.demon.net [194.217.242.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02448 for <[e-mail]>; Thu, 3 Dec 1998 07:11:15 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.054 #1) id 0zlaUQ-0002TP-00 for [e-mail]; Thu, 3 Dec 1998 15:16:22 +0000
Message-ID: <001b01be1f12$a45aa970$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "Ietf distribution list" <[e-mail]>
Subject: Extensibility discussion
Date: Thu, 3 Dec 1998 15:12:41 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01BE1ECF.5EE545A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01BE1ECF.5EE545A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The latest version of CMS (09) has added plaintextAttrs to EnvelopedData =
which allows extension to be defined for EnvelopedData,
=20
Is there any reason why keyAgreeRecipientInfo should not be made =
extensible in the same way?
=20
The following is an example ASN.1:=20
=20
  KeyAgreeRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys=20
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }

=20
=20
However, if CMS want to be able to support more key agreement algorithms =
in the future, perhaps the best way to allow that would be to allow the =
CHOICE of RecipientInfo to be extendable .=20
=20

 The following is an example ASN.1:
=20
 RecipientInfo ::=3D CHOICE {
        ktri KeyTransRecipientInfo,
        kari [1] KeyAgreeRecipientInfo,
        kekri [2] KEKRecipientInfo
        kext [3] ExternalyDefinedKeyAgreement --for future or private =
key management schemes }
=20
=20
ExternalyDefinedKeyAgreement :: =3D OCTET STRING
=20
=20
Alternatively,  the syntax of the externally defined key management use =
the OID extension mechanism:=20
=20
ExternalyDefinedKeyAgreement :: =3D SEQUENCE {
   ExternalID  OBJECT IDENTIFIER {
   ExternalValue ANY DEFINED BY  ExternalID =20
}
=20

I slightly favor the OID extension but if there is objection to that =
extension mechanism, the OCTET STRING approach would be adequate.
=20

John Ross


------=_NextPart_000_000E_01BE1ECF.5EE545A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT color=3D#000000 size=3D2>The latest version of CMS (09) has =
added=20
plaintextAttrs to EnvelopedData which allows extension to be defined for =

EnvelopedData,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Is there any reason why =
keyAgreeRecipientInfo=20
should not be made extensible in the same way?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV>
<DIV><FONT size=3D2>The following is an example ASN.1:</FONT>=20
<DIV><FONT size=3D2>&nbsp;</FONT></DIV></DIV>
<DIV><FONT size=3D2>&nbsp; KeyAgreeRecipientInfo ::=3D SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =

3<BR>&nbsp;&nbsp;&nbsp;&nbsp; originator [0] EXPLICIT=20
OriginatorIdentifierOrKey,<BR>&nbsp;&nbsp;&nbsp;&nbsp; ukm [1] EXPLICIT=20
UserKeyingMaterial OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
recipientEncryptedKeys RecipientEncryptedKeys </FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [2] IMPLICIT=20
UnsignedAttributes OPTIONAL }<BR></FONT></DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>However, if CMS want to be able to =
support more=20
key agreement algorithms in the future, perhaps the best way to allow =
that would=20
be to allow the CHOICE of RecipientInfo to be extendable =
.&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;The following is an example =
ASN.1:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;RecipientInfo ::=3D CHOICE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ktri=20
KeyTransRecipientInfo,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
kari [1]=20
KeyAgreeRecipientInfo,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
kekri [2]=20
KEKRecipientInfo</FONT></DIV>
<DIV><FONT color=3D#000000 =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kext=20
[3] ExternalyDefinedKeyAgreement --for future or private key management =
schemes=20
}</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>ExternalyDefinedKeyAgreement :: =3D =
OCTET=20
STRING</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Alternatively,&nbsp; the syntax of =
the=20
externally defined key management use the OID extension mechanism: =
</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000=20
size=3D2>ExternalyDefinedKeyAgreement :: =3D SEQUENCE =
{</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000 =
size=3D2></FONT></FONT><FONT=20
size=3D2>&nbsp;&nbsp; ExternalID&nbsp; OBJECT IDENTIFIER {</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2>&nbsp;&nbsp; =
ExternalValue=20
ANY DEFINED BY&nbsp; <FONT size=3D2>ExternalID&nbsp; =
</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT size=3D2></FONT></FONT><FONT=20
size=3D2>}</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT color=3D#000000=20
size=3D2></FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I slightly favor the OID extension but if there is =
objection=20
to that extension mechanism, the OCTET STRING approach would be=20
adequate.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>John Ross</FONT></DIV>
<DIV>&nbsp;</DIV></DIV></BODY></HTML>

------=_NextPart_000_000E_01BE1ECF.5EE545A0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA03293 for ietf-smime-bks; Wed, 2 Dec 1998 19:00:57 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA03281 for <[e-mail]>; Wed, 2 Dec 1998 19:00:55 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id QAA11064; Thu, 3 Dec 1998 16:05:48 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91265434806510>; Thu, 3 Dec 1998 16:05:48 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: RecipientInfo vs SignerInfo key identification
Cc: [e-mail]
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Thu, 3 Dec 1998 16:05:48 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Russ Housley <[e-mail]> wrote:
 
>Further, some people argued that the key is not the only thing that is 
>important in verifying a signature.  Other fields in the certificate, like 
>policy, are important too.  If a signer has the same public key in two 
>certificates, then an attacker can swap the certificate carried in the 
>certificates field.  Since PKIX recommends a form of key identifier based on 
>hashing the public key, then the relying pary will probably not be able to 
>determine that the certificates were swapped.  Since the issuer / serial pair 
>specifies a certificate, not just a public key, it seems to be the prefered 
>method for signatures.
 
Ah, finally an explanation for the decision.  Thanks.
 
>Agreed, it could be added without breaking backward compatibility.  Support 
>for key identifiers could be added to SignerInfo, but as stated above, there 
>is less motivation to do so.
 
The reason I brought the issue up is that the lack of a key identifier in 
SignerInfo makes CMS impossible to use with SPKI and PGP.  There was a debate 
in two other lists a while back (OpenPGP and something else) in which someone 
commented on PGP <-> CMS compatibility, and I pointed out that it would 
*almost* work, but required the inclusion of a key identifier.  The same goes 
for SPKI, where the only way to identify a key is with the hash-of-key/key 
identifier.  In neither of these cases is it possible to use the 
issuerAndSerialNumber to specify the signers key, which means CMS is 
restricted to only one of the three IETF-standardised certificate management 
methods.  The addition of a key identifier would immediately extend this to 
both SPKI and PGP, since both already use an SHA-1 hash of the key as their 
identifier.  I think that extending the identifier in this way would be a 
significant win in terms of extending the usability of CMS to all three of the 
IETF certificate types.
 
Might I suggest the following text, based on the existing 
'rid RecipientIdentifier' descriptive text and Russ' comments:
 
-- Snip --
 
sid specifies the signer's certificate or key that was used by the sender to 
sign the content.  The SignerIdentifier provides two alternatives for 
specifying the signer's certificate, and thereby the signer's public key.  The 
issuerAndSerialNumber alternative identifies the signer's certificate by the 
issuer's distinguished name and the certificate serial number; the 
subjectKeyIdentifier identifies the signer's certificate by the X.509 
subjectKeyIdentifier extension value.  When used with X.509 certificates the 
signer MUST use the issuerAndSerialNumber form, since the key identifier only 
identifies the signing key and not the exact signing certificate, allowing an 
attacker to substitute other certificates which contain the same key.  When 
used with non-X.509 keys such as those used in SPKI or OpenPGP, the signer MAY 
use the key identifier form.
 
-- Snip --
 
This should keep both sides happy, the people grumbling about backwards 
compatibility can just ignore SPKI and PGP keys so there's no change required 
for their code, and the SPKI and PGP crowd are given a way to integrate their 
keys into CMS.  Since the two identifiers are now identical for RecipientInfo 
and SignerInfo, they could probably be merged into a unified type, keeping the 
text for signing as a special case for identifiers used for signing only.
 
This has a slight problem in that you don't know which key store to search to 
find a key corresponding to a given identifier.  Admittedly the chances of 
someone getting the same public key certified for X.509 and SPKI are pretty 
remote, but a slight improvement might be to indicate the type of identifier 
so that the recipient/relying party knew where to get their keys from:
 
WhateverIdentifier ::= CHOICE {
  issuerAndSerialNumber IssuerAndSerialNumber,
  keyIdentifier [0] SubjectKeyIdentifier,       -- SHA-1 hash
  spkiIdentifier [1] SPKIGloballyUniqueID,      -- SHA-1 hash for SPKI key
  pgpIdentifier [2] PGPKeyIdentifier,           -- SHA-1 hash for PGP key
  otherIdentifier [3] OtherIdentifier           -- For future expansion or
                                                   other key mgt.mechanisms
  }
 
OtherIdentifier ::= SEQUENCE {
  otherID OBJECT IDENTIFIER,
  otherValue ANY DEFINED BY otherID
  }
 
This is what was planned in PKCS7v2, at least in the last draft I saw.  If the 
S/MIME folks really are that upset about this, they can just require that the 
non-X.509 identifiers not be used, although it'd be a significant olive branch 
for the other factions if you could use any type of key.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29157 for ietf-smime-bks; Wed, 2 Dec 1998 11:42:32 -0800 (PST)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29153 for <[e-mail]>; Wed, 2 Dec 1998 11:42:30 -0800 (PST)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <YB7HNRGQ>; Wed, 2 Dec 1998 14:44:39 -0500
Message-ID: <51BF55C30B4FD1118B4900207812701E24F8F8@WUHER>
From: Sarbari Gupta <[e-mail]>
To: "'smime'" <[e-mail]>
Subject: goals and milestones up to date?
Date: Wed, 2 Dec 1998 14:44:37 -0500
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I recently visited the S/MIME web page at
http://www.ietf.org/html.charters/smime-charter.html and was a bit
confused with the "Goals and Milestones" section. All the milestones
seem to be referring to late 1997 and early 1998 dates. Is this the
right information?

Specifically, I was trying to find out the milestones/dates with respect
to the "S/MIME Version 3 Message Specification" and "Cryptographic
Message Syntax" I-Ds. 

- Sarbari Gupta
=================================
Sarbari Gupta
CygnaCom Solutions
[phone] (voice)
[phone](FAX)
[e-mail]
=================================


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29077 for ietf-smime-bks; Wed, 2 Dec 1998 11:35:17 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29073 for <[e-mail]>; Wed, 2 Dec 1998 11:35:16 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGCVQ4>; Wed, 2 Dec 1998 11:38:03 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B23@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: "'EKR'" <[e-mail]>, [e-mail]
Subject: RE: More X942-03 Comments
Date: Wed, 2 Dec 1998 11:37:53 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Russ,

I have been thinking about this for a while and I want to make sure that I
have this correct.  

1.  The X9.42 document is the correct place to put sizing on the UKM
material as it is going to be tied to items such as the hash algorithm being
used.  I think this means that that the last sentence in the paragraph (on
pubInfo) should be alted to be 
"In CMS, it is provided as a parameter in the UserKeyingMaterial field
(encoded as an OCTET STRING).  If provided this pubInfo MUST contain 512
bits."

2.  The number 512 represents a minimum value which is determined by looking
at the hash function and making sure that a complete buffer has been filled.

3.  The number 512 is not a maximum number.  There is no real limit but 1023
would be the maximum number that could possibly make sense as there is no
additional benifit to filling the buffer more than twice.

4.  If (sizeof(ZZ) + sizeof(OtherInfo) - sizeof(pubInfo)) % 512 = 256, you
fill out this complete block size with random material.  You then fill half
of the next block with random material and half with fixed material.  Not
knowing enough about how these things work, is there any true benifit to
make sure that the half of fixed material is really random material?  From
your message it would appear that the first fill is the most important
portion and thus the minimum from step 1 is really what ever is needed to
fill out the last block following ZZ.

jim

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, November 25, 1998 1:41 PM
> To: Jim Schaad (Exchange)
> Cc: 'EKR'; [e-mail]
> Subject: Re: More X942-03 Comments
> 
> 
> Jim:
> 
> >1.  Section 2.1.2 in the paragraph on pubInfo:  There is a 
> description that
> >appears to say CMS defined UserKeyingMaterial as a 512-bit 
> value.  There are
> >two problems with this: a) CMS does not say anything about 
> the length of ukm
> >and b) no justification is shown here for a length of 
> 512-bits.  Is this a
> >magic length?
> 
> 512 bits is the SHA-1 block size, so it is the maximum 
> entropy that can be
> inserted in this manner.
> 
> Russ 
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26478 for ietf-smime-bks; Wed, 2 Dec 1998 06:18:59 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26474 for <[e-mail]>; Wed, 2 Dec 1998 06:18:58 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA04363; Wed, 2 Dec 1998 09:24:02 -0500
Message-Id: <4.1.19981201204756.00996970@209.172.119.123>
Message-Id: <4.1.19981201204756.00996970@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 20:50:25 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: 43rd IETF: S/MIME WG Agenda
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

S/MIME Mail Security WG Agenda

1530    Introductions                   Russ Housley
1540    CMS Draft Discussion            Russ Housley
1555    X9.42 Draft Discussion          Russ Housley
1610    MSG Draft Discussion            Blake Ramsdell
1620    CERT Draft Discussion           Blake Ramsdell
1630    ESS Draft Discussion            Paul Hoffman
1640    CERTDIST Draft Discussion       Jim Schaad
1650    SIGATTR Draft Discussion        Jim Schaad
1700    DOMSEC Draft Discussion         Bill Ottaway
1715    New Samples Document            Paul Hoffman
1725    Wrap up                         Russ Housley
1730    Adjourn


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26472 for ietf-smime-bks; Wed, 2 Dec 1998 06:18:53 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26468 for <[e-mail]>; Wed, 2 Dec 1998 06:18:52 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA04331; Wed, 2 Dec 1998 09:23:52 -0500
Message-Id: <4.1.19981201132610.0098d700@209.172.119.123>
Message-Id: <4.1.19981201132610.0098d700@209.172.119.123>
Message-Id: <4.1.19981201132610.0098d700@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 14:32:46 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on CMC-09
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5B0E@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>> >9.  Section 9.2:  Was there a reason for removing the "rather than the
>> >implcit [0] .." phrase.  This exists in the process for signed data and I
>> >think should be here as well.
>> 
>> For authenticated-data, digests are only computed on the content.  They are
>> never computed on the attributes.  The IMPLICIT [0] stuff was about the
>> attribute encoding.
>
>I don't follow your response.  What I am looking at is the text relating to
>the creation of the authenticatedAttributes blob over which the MAC will be
>computed.  This is yet another location where the ASN which is encoded and
>sent is not the same as the ASN which is acutally MAC-ed.  I think this
>should be very explicit like in the other cases.
 
The text was reworded do to the introduction of the authAttributesInfo
structure. Due to your previous comments regarding one pass processing, that
structure has been split up.  Now, text desling with IMPLICIT [2] will be
added.

Proposed text:
If authenctiatedAttributes field is present, the content-type attribute (as
described in Section 11.1) and the message-digest attribute (as described in
section 11.2) must be included, and the input to the MAC calculation process is
the DER encoding of authenticatedAttributes.  A separate encoding of the
authenticatedAttributes field is performed for message digest calculation.  The
IMPLICIT [2] tag in the authenticatedAttributes field is not used for the DER
encoding, rather an EXPLICIT SET OF tag is used.  That is, the DER encoding of
the SET OF tag, rather than of the IMPLICIT [2] tag, is to be included in the
message digest calculation along with the length and content octets of the
authenticatedAttributes value.

 
>> >14.  Section 12.3.3 Last paragarph.  What is this paragraph doing here?  It
>> >is talking about key agreement in the symetric key-encryption section.
>> 
>> The output of a key agreement algorithm is a key-encryption key, and this
>> key-encryption key is used to encrypt the content-encryption key.  The last
>> paragraph is a backward pointer telling folks that the same techniques are
used
>> regardless of the source of the key-encryption key.  I will add an sentence
to
>> the front of this paragraph that hopefully makes this more clear.
> 
>I don't understand this even with your explination.

The last paragraph tells the implementor that the key wrapping algorithm will
also appear as a parameter to the key agreement algorithm identifier.

 
>> >15.  Section 12.6.2 - You have not modified the key wrap algorithm to allow
>> >for arbitrary length RC2 key sources.
>> 
>> Are you suggesting an explicit length field or something else?
> 
>We need to either put in an explicit length field or use a known padding
>algorithm.  I have no perference on which is used but something along this
>lines is absolutely required.

Please provide text.  I still am not sure what change you want.  Maybe you
should coordinate with with Eric ([e-mail]) to ensure consistency with the
X9.42 document.
 
Russ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26466 for ietf-smime-bks; Wed, 2 Dec 1998 06:18:51 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26462 for <[e-mail]>; Wed, 2 Dec 1998 06:18:49 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA04323; Wed, 2 Dec 1998 09:23:51 -0500
Message-Id: <4.1.19981201131107.009594c0@209.172.119.123>
Message-Id: <4.1.19981201131107.009594c0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 13:13:18 -0500
To: "Blake Ramsdell" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on MSG spec
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Blake:

>>         3.  Section 2.6, first sentence:  Is the reference to 
>> [DES] dangling? 
>> It would seem that one reference to tripleDES would be sufficient.
>
>Not dangling -- [DES] tells you how to implement DES, [3DES] tells you how
>to implement triple-DES, but not DES.
>
>By the way, I think that the 3DES reference sucks (a 1979 IEEE Spectrum
>article?).  Any suggestions?

Here are the best reference I can find:

3DES       American National Standards Institute.  ANSI X9.52-1998,
           Triple Data Encryption Algorithm Modes of Operation. 1998.

DES        American National Standards Institute.  ANSI X3.106, 
           "American National Standard for Information Systems - Data
           Link Encryption".  1983.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26459 for ietf-smime-bks; Wed, 2 Dec 1998 06:18:40 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26454 for <[e-mail]>; Wed, 2 Dec 1998 06:18:39 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA04251; Wed, 2 Dec 1998 09:23:28 -0500
Message-Id: <4.1.19981201095556.0096abd0@209.172.119.123>
Message-Id: <4.1.19981201095556.0096abd0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 01 Dec 1998 10:00:13 -0500
To: EKR <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: X942-03
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <Russ Housley's message of "Thu, 19 Nov 1998 16:55:40 -0500"> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric:

>> For consistency, please use the spelling that CMS inherited from PKCS#7
v1.5:
>> 	key-encryption key
>> 	content-encryption key
>All right.
Good.

>> I expected section 2.1.1 to include: g^q (mod p) == 1.
>I'm not sure that this is sufficient. However, it follows from
>the following criterion, (which I just added) which is listed 
>in FIPS-186
>
>      h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
>        (g has order q mod p)
Okay.

>> In section 2.1.2, you say: "algorithm is the ASN.1 algorithm OID of the
>> symmetric algorithm with which this KEK will be used."  I think it would be
>> more clear to say that is is the OBJECT IDENTIFIER protion of the symmetric
>> algorithm identifier; no parameters associated with the symmetric algorithm
>> identifier are used.
>How about:
>algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 
>  this KEK will be used. Note that this is NOT an AlgorithmIdentifier,
>  but simply the OBJECT IDENTIFIER. No paramters are used.
This is fine.

>> Later in section 2.1.2, you say: "Note that pubInfo is required in
>> Static-Static mode, but MAY appear in Ephemeral-Static mode."  I would
>> prefer to see the first half of the sentence reworded to include "MUST."
>Note that pubInfo MUST be used in Static-Static mode,
>but MAY appear in Ephemeral-Static mode.
Fine.

>> In section 2.1.5, you need to upcase "MAY NOT."
>Hmm... This makes me a little queasy. This is a descriptive, not
>prescriptive statement...
Okay.

>> In section 2.2, you say: " When symmetric ciphers stronger than DES are to
>> be used, a larer m may be advisable."  This screams for a paragraph in
>> Security Consderations.
Are you doing a paragraph?

>> Please add a section parallel to section 2.3 that describes Static-Static
>> Mode.  The term is used in the body of the document, so it probably needs a
>> description.
>All right.
Thanks.

>> Please add a paragraph is the security Considerations section regarding the
>> size of the private key, x, and the size of the generated symmetric keys.
>> In general, the private key need to be twices the size of the resulting
>> symmetric keys.  Note: KEA uses a 160 bit private key to generate 80 bit
>> SKIPJACK keys.
>I agree that you are correct here, but this puts us in very unpleasant
>waters: 
>The FIPS-186 key/parameter generation algorithm only describes how
>to generate for m==160. X9.42 DOES describe how to generate for
><arbitrary m. However, X9.42 isn't publicly available, so we shouldn't
>make a normative reference to it, but rather should describe the
>procedure inline.
>
>I suppose I could try to write something like:
>Follow FIPS-186, except substituting 'm' for 160, but I'm pretty
>nervous about that. 
>
>I'd like to get the sense of the group here.
Understand.  

Russ