RE: X9.42 and RFC2459 inconsistency?

["John Hughes" <[e-mail]>]

Andrew,

we had some discussion within Entegrity back in March on this whole issue -
and as we wanted to get D-H support out into the market with the Entegrity
SDP we had to make some decisions.  As I'm about to go on vacation
unfortunately I've not the time to detail what we did.  Hopefully some of my
colleagues who are also on the list can provide the input on what we did.


John


> -----Original Message-----
> From: Andrew Farrell [mailto:[e-mail]]
> Sent: 31 July 1999 15:23
> To: John Hughes
> Cc: [e-mail]; [e-mail]
> Subject: Re: X9.42 and RFC2459 inconsistency?
>
>
> In message <002701bedade$9c1f10138d90a@joh-laptop>you write:
> >We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
> >OID.
>
> You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
> "Permanent root for paying customer" certs using this out there? And if
> so, why? :)
>
> >John
>
> Andrew.
>




Received: by mail.proper.com (8.9.3/8.9.3) id WAA16943 for ietf-smime-bks; Sat, 31 Jul 1999 22:38:45 -0700 (PDT)
Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id WAA16939 for <[e-mail]>; Sat, 31 Jul 1999 22:38:42 -0700 (PDT)
Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by piglet.dstc.edu.au (8.8.7/8.8.7) with ESMTP id PAA25471 for <[e-mail]>; Sun, 1 Aug 1999 15:41:25 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: [e-mail]
Subject: Re: Compressed data type for S/MIME 
In-reply-to: Your message of "Thu, 29 Jul 1999 10:49:53 +0100." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 01 Aug 1999 15:41:25 +1000
From: Dean Povey <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

My $0.02 to this debate.

SSL/TLS has built in compression support as part of the protocol, but this
has been slow to come to market.  Why?  One of the reasons has been that
you want to turn compression on and off depending on the underlying content
(e.g. if it is a GIF or JPG or .gz etc, don't compress).  This has lead at
least some people to form the opinion that compression doesn't really
belong in a crypto protocol, but at the application layer where the 
information to make these sort of decisions is available.

Now of course the situation in S/MIME is somewhat different to SSL/TLS, as
you can be less concerned about the CPU wastage of compressing stuff that
is already compressed as a client is generally just decoding messages one
at a time (an exception to this is email "VPNs" such as WorldSecure which
convert plaintext mail to S/MIME and vice versa, thus CPU load for such
servers becomes significant). Nevertheless, it seems to me that S/MIME is
much better served by leaving compression out, and putting it into MIME. 
(Encoding-type: application/gzip perhaps?). 

As for Peter's argument about Non-MIME CMS applications I guess I can only
say that if the underlying content that CMS is encapsulating needs
compression, then the underlying content handler should do it.  We could 
make the same argument for any presentation-layer like service that we can 
for compression (e.g. content needs to be 7-bit clean), but this doesn't 
mean that all this encoding should be handled by CMS.

Lastly, the comment was made that it will be difficult to get MIME 
implementations to switch over to using a compressed type.  This has a 
grain of truth, but ask youself which is easier: supporting a compression 
MIME encoding, or supporting S/MIME?  Non-trivial architectural changes 
will always take a while to propagate.

This said, I can't see a real problem with supporting a CompressedData type
(apart from the fact that I don't like it), provided it is optional (i.e.
you have to know that the person at the other end supports it to use it).
While not the best solution it possibly has some value for encapsualting
legacy protocols in CMS blobs.

Cheers.

-- 
Dean Povey,         | e-m: [e-mail]     | Cryptozilla:
Research Scientist  | ph:  [phone]       |  www.cryptozilla.org/
Security Unit, DSTC | fax: [phone]       | Oscar - PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/




Received: by mail.proper.com (8.9.3/8.9.3) id NAA18397 for ietf-smime-bks; Sat, 31 Jul 1999 13:34:31 -0700 (PDT)
Received: from tantalum.btinternet.com (tantalum.btinternet.com [194.73.73.80]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA18184; Sat, 31 Jul 1999 13:28:12 -0700 (PDT)
Received: from [195.99.52.9] (helo=joh-laptop) by tantalum.btinternet.com with smtp (Exim 2.05 #1) id 11AfmG-0002E1-00; Sat, 31 Jul 1999 21:30:44 +0100
From: "John Hughes" <[e-mail]>
To: "Andrew Farrell" <[e-mail]>
Cc: "Sinisa Cicovic" <[e-mail]>, "Peter Siklosi" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency? 
Date: Sat, 31 Jul 1999 21:34:15 +0100
Message-ID: <000a01bedb94$0e50ed60$0138d90a@joh-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andrew,

we had some discussion within Entegrity back in March on this whole issue -
and as we wanted to get D-H support out into the market with the Entegrity
SDP we had to make some decisions.  As I'm about to go on vacation
unfortunately I've not the time to detail what we did.  Hopefully some of my
colleagues who are also on the list can provide the input on what we did.


John


> -----Original Message-----
> From: Andrew Farrell [mailto:[e-mail]]
> Sent: 31 July 1999 15:23
> To: John Hughes
> Cc: [e-mail]; [e-mail]
> Subject: Re: X9.42 and RFC2459 inconsistency?
>
>
> In message <002701bedade$9c1f10138d90a@joh-laptop>you write:
> >We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
> >OID.
>
> You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
> "Permanent root for paying customer" certs using this out there? And if
> so, why? :)
>
> >John
>
> Andrew.
>



Received: by mail.proper.com (8.9.3/8.9.3) id NAA18045 for ietf-smime-bks; Sat, 31 Jul 1999 13:03:33 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA18041 for <[e-mail]>; Sat, 31 Jul 1999 13:03:32 -0700 (PDT)
Received: by dfssl with Internet Mail Service (5.5.2650.14) id <PYWXRD4Q>; Sat, 31 Jul 1999 13:03:45 -0700
Message-ID: <2FBF98FC7852CF11912A00000000000114252936@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: Blake Ramsdell <[e-mail]>, "'Sean Turner'" <[e-mail]>, [e-mail]
Subject: RE: Cert Attributes in CERTDIST
Date: Sat, 31 Jul 1999 13:03:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.14)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That is one of the issues.  The reasons why this field is not used are as
follows:

1.  userCertificate holds X509 certificates for the use (there may be more
than one) and what we are publishing is a SignedData object not an X509
certificate.
2.  We want to include additional attributes which also are not certificates
and bind them together with the certificate in a cryptographic manner.  (The
main attributes being encryption algorithms and a publishing time.)

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[e-mail]]
Sent: Thursday, July 22, 1999 2:23 PM
To: 'Sean Turner'; [e-mail]
Subject: RE: Cert Attributes in CERTDIST


> -----Original Message-----
> From: Sean Turner [mailto:[e-mail]]
> Sent: Thursday, July 22, 1999 2:31 PM
> To: [e-mail]
> Subject: Cert Attributes in CERTDIST
> 
> I'm sorry if I'm coming at this a bit late, but why are the attributes
> that are used to store signature and encryption certificates not
> userCertificate as defined in the LDAP schema RFC from PKIX?

I think that the problem is because userCertificate refers to exactly one
certificate.  In order to put in a certificate chain, along with the S/MIME
capabilities of the certificate holder, a new convention must be used.

I may have some of this wrong, so anyone feel free to correct me.

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


Received: by mail.proper.com (8.9.3/8.9.3) id HAA14928 for ietf-smime-bks; Sat, 31 Jul 1999 07:20:11 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA14924; Sat, 31 Jul 1999 07:20:09 -0700 (PDT)
Received: by puma.baltimore.ie; id QAA18095; Sat, 31 Jul 1999 16:17:00 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma018090; Sat, 31 Jul 99 16:16:54 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA19736; Sat, 31 Jul 1999 15:24:18 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id PAA08136; Sat, 31 Jul 1999 15:22:59 +0100
Message-Id: <[e-mail]>
To: "John Hughes" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Fri, 30 Jul 1999 23:55:24 BST." <002701bedade$9c1f1470$0138d90a@joh-laptop> 
Date: Sat, 31 Jul 1999 15:22:59 +0100
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>

In message <002701bedade$9c1f1470$0138d90a@joh-laptop>you write:
>We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
>OID.

You mean the X9.42 oid with the pfc 2459 semantics? Do you have serious
"Permanent root for paying customer" certs using this out there? And if
so, why? :) 

>John

Andrew.


Received: by mail.proper.com (8.9.3/8.9.3) id PAA16363 for ietf-smime-bks; Fri, 30 Jul 1999 15:51:32 -0700 (PDT)
Received: from carbon.btinternet.com (carbon.btinternet.com [194.73.73.92]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA16178; Fri, 30 Jul 1999 15:49:28 -0700 (PDT)
Received: from [195.99.53.18] (helo=joh-laptop) by carbon.btinternet.com with smtp (Exim 2.05 #1) id 11ALVP-0007ZQ-00; Fri, 30 Jul 1999 23:51:59 +0100
From: "John Hughes" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: X9.42 and RFC2459 inconsistency?
Date: Fri, 30 Jul 1999 23:55:24 +0100
Message-ID: <002701bedade$9c1f1470$0138d90a@joh-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-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>

We can generate D-H certificates - and we use the rfc 2459 dhpublicnumber
OID.

John

(Entegrity Solutions)

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 31 July 1999 03:47
> To: [e-mail]; [e-mail]
> Subject: Re: X9.42 and RFC2459 inconsistency?
>
>
> Andrew Farrell <[e-mail]> writes:
>
> >(1) Are there any deployed codebases which would object to changing the
> >Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
> >semantics than in X9.42?
> >
> >I know that John Pawling has stated that Van Dyke's S/MIME
> Freeware Library
> >has no issues, and as far as I know Microsoft haven't shipped
> anything with
> >Diffie-Hellman, so that S/MIME would appear to be in the clear on this.
>
> Some of the OpenSSL people have complained in the past that they
> haven't been
> able to find any examples of DH certs to test, and I've never
> seen one either,
> so if anyone has implemented this they're keeping it very well hidden.
>
> Actually the solution to this problem is easy, just switch back
> to the PKCS #3
> OID which was the one which noone was using before they switched
> to not using
> X9.42.  This is far more sensible:
>
> DHPublicKey ::= INTEGER
>
> Parameters ::= SEQUENCE {
>     prime INTEGER,      -- p
>     base  INTEGER,      -- g
>     privateValueLength INTEGER OPTIONAL
>     }
>
> You can't get the parameters for that wrong (well, not without a lot of
> effort).
>
> (A problem with this is that it doesn't accommodate X9.42's q and
> j.  If PKIX
>  is going to define a new OID without the asking-for-trouble
> X9.42 semantics,
>  it'd be good to have q and j OPTIONAL to allow key generation techniques
>  other than the FIPS 186 kosherizer, which is both unnecessarily
> inefficient
>  (when used to generate DH keys) and generates unsafe keys,
> requiring further
>  band-aids - draft-ietf-smime-small-subgroup.txt - to make their
> use safe.  In
>  contrast key generation techniques like Lim-Lee are both faster
> and generate
>  keys which are immune to this problem, but are excluded from use
> by the need
>  to provide a q value in the AlgorithmIdentifier).
>
> Peter.
>
>



Received: by mail.proper.com (8.9.3/8.9.3) id IAA11026 for ietf-smime-bks; Fri, 30 Jul 1999 08:50:09 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id IAA10823; Fri, 30 Jul 1999 08:47:40 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Jul 1999 09:50:01 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Fri, 30 Jul 1999 09:49:53 -0600
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: X9.42 and RFC2459 inconsistency?
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 IAA10825
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A note to consider:
"DHPublicKey" has an implied meaning that the Diffie-Hellman algorithm is the discrete logarithm version based on unsigned integer operations. However, this is not the only version of DH. There is an integer version with cofactor exponentiation, and similarly there are elliptic curve versions, with and without cofactor multiplication. 
In the search of a "standard" OID and its associated parameters, these should be considered as well, including the naming, which may be misleading.
One place to look at would be the IEEE P1363 effort on public-key standards.

- Tolga

>>> Peter Gutmann <[e-mail]> 7/31/99 2:47:28 >>>
Andrew Farrell <[e-mail]> writes:

>(1) Are there any deployed codebases which would object to changing the
>Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
>semantics than in X9.42?
>
>I know that John Pawling has stated that Van Dyke's S/MIME Freeware Library 
>has no issues, and as far as I know Microsoft haven't shipped anything with 
>Diffie-Hellman, so that S/MIME would appear to be in the clear on this.

Some of the OpenSSL people have complained in the past that they haven't been 
able to find any examples of DH certs to test, and I've never seen one either,
so if anyone has implemented this they're keeping it very well hidden.

Actually the solution to this problem is easy, just switch back to the PKCS #3
OID which was the one which noone was using before they switched to not using
X9.42.  This is far more sensible:

DHPublicKey ::= INTEGER

Parameters ::= SEQUENCE {
    prime INTEGER,      -- p
    base  INTEGER,      -- g
    privateValueLength INTEGER OPTIONAL
    }

You can't get the parameters for that wrong (well, not without a lot of 
effort).

(A problem with this is that it doesn't accommodate X9.42's q and j.  If PKIX
 is going to define a new OID without the asking-for-trouble X9.42 semantics,
 it'd be good to have q and j OPTIONAL to allow key generation techniques 
 other than the FIPS 186 kosherizer, which is both unnecessarily inefficient 
 (when used to generate DH keys) and generates unsafe keys, requiring further 
 band-aids - draft-ietf-smime-small-subgroup.txt - to make their use safe.  In
 contrast key generation techniques like Lim-Lee are both faster and generate 
 keys which are immune to this problem, but are excluded from use by the need 
 to provide a q value in the AlgorithmIdentifier).

Peter.




Received: by mail.proper.com (8.9.3/8.9.3) id HAA09939 for ietf-smime-bks; Fri, 30 Jul 1999 07:51:40 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA09935; Fri, 30 Jul 1999 07:51:38 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id CAA19988; Sat, 31 Jul 1999 02:54:09 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93334604825242>; Sat, 31 Jul 1999 02:47:28 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Sat, 31 Jul 1999 02:47:28 (NZST)
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>

Andrew Farrell <[e-mail]> writes:

>(1) Are there any deployed codebases which would object to changing the
>Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
>semantics than in X9.42?
>
>I know that John Pawling has stated that Van Dyke's S/MIME Freeware Library 
>has no issues, and as far as I know Microsoft haven't shipped anything with 
>Diffie-Hellman, so that S/MIME would appear to be in the clear on this.

Some of the OpenSSL people have complained in the past that they haven't been 
able to find any examples of DH certs to test, and I've never seen one either,
so if anyone has implemented this they're keeping it very well hidden.

Actually the solution to this problem is easy, just switch back to the PKCS #3
OID which was the one which noone was using before they switched to not using
X9.42.  This is far more sensible:

DHPublicKey ::= INTEGER

Parameters ::= SEQUENCE {
    prime INTEGER,      -- p
    base  INTEGER,      -- g
    privateValueLength INTEGER OPTIONAL
    }

You can't get the parameters for that wrong (well, not without a lot of 
effort).

(A problem with this is that it doesn't accommodate X9.42's q and j.  If PKIX
 is going to define a new OID without the asking-for-trouble X9.42 semantics,
 it'd be good to have q and j OPTIONAL to allow key generation techniques 
 other than the FIPS 186 kosherizer, which is both unnecessarily inefficient 
 (when used to generate DH keys) and generates unsafe keys, requiring further 
 band-aids - draft-ietf-smime-small-subgroup.txt - to make their use safe.  In
 contrast key generation techniques like Lim-Lee are both faster and generate 
 keys which are immune to this problem, but are excluded from use by the need 
 to provide a q value in the AlgorithmIdentifier).

Peter.



Received: by mail.proper.com (8.9.3/8.9.3) id GAA08131 for ietf-smime-bks; Fri, 30 Jul 1999 06:20:16 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA07956; Fri, 30 Jul 1999 06:18:55 -0700 (PDT)
Received: by puma.baltimore.ie; id PAA00195; Fri, 30 Jul 1999 15:15:21 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma000140; Fri, 30 Jul 99 15:14:56 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA21158; Fri, 30 Jul 1999 14:22:45 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id OAA06949; Fri, 30 Jul 1999 14:21:35 +0100
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Wed, 28 Jul 1999 18:36:56 BST." <[e-mail]> 
Date: Fri, 30 Jul 1999 14:21:35 +0100
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>

I wrote:

>Cool (and a welcome gesture towards fixing broken stuff). So why do we
>use their OID?

Sine there's been a deafing silence on this topic, I have two further
questions:

(1) Are there any deployed codebases which would object to changing the
Diffie-Hellman OID in rfc2459 to reflect the fact that it has different
semantics than in X9.42? 

I know that John Pawling has stated that Van Dyke's S/MIME Freeware
Library has no issues, and as far as I know Microsoft haven't shipped
anything with Diffie-Hellman, so that S/MIME would appear to be in the
clear on this.

(2) Are there any other groups that profile 2459 that we should ask
about this?.

Andrew


Received: by mail.proper.com (8.9.3/8.9.3) id FAA07708 for ietf-smime-bks; Fri, 30 Jul 1999 05:55:33 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id FAA07704 for <[e-mail]>; Fri, 30 Jul 1999 05:55:32 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA09818; Fri, 30 Jul 1999 08:58:01 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA09809; Fri, 30 Jul 1999 08:58:00 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA07225; Fri, 30 Jul 1999 08:57:57 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id IAA18352; Fri, 30 Jul 1999 08:57:20 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Fri, 30 Jul 1999 08:57:20 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Compressed data type for S/MIME
To: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: xgEklY6L5kKq5KSW5Rki7g==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: [e-mail] (Peter Gutmann)
> 
>  [... quoting Gunther Schadow]
>
> This is all said for encryption. For signatures it may be better not
> to compress so as to have an immediately readable cleartext to store
> with the signature. But hell, isn't S/MIME hiding the text behind a
> blob of DER anyway? (I hate S/MIME for this)
> 
>  [...]
>
> regards
> -Gunther


Nope, S/MIME signs the text and then blobs it.

CMS Section 5.4:

  "Specifically, the initial input [to the message digest calculation]
   is the ... eContent OCTET STRING to which the signing process is
   applied.  Only the octets comprising the value of the eContent
   OCTET STRING are input to the message digest algorithm, not the
   tag or length octets."




Received: by mail.proper.com (8.9.3/8.9.3) id EAA06895 for ietf-smime-bks; Fri, 30 Jul 1999 04:12:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id EAA06891 for <[e-mail]>; Fri, 30 Jul 1999 04:12:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26494; Fri, 30 Jul 1999 07:15:00 -0400 (EDT)
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-cmskea-02.txt
Date: Fri, 30 Jul 1999 07:15:00 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: CMS KEA and SKIPJACK Conventions
	Author(s)	: J. Pawling
	Filename	: draft-ietf-smime-cmskea-02.txt
	Pages		: 10
	Date		: 29-Jul-99
	
This document describes the conventions for using the Key Exchange 
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data 
content types.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cmskea-02.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-cmskea-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by mail.proper.com (8.9.3/8.9.3) id DAA04102 for ietf-smime-bks; Fri, 30 Jul 1999 03:02:54 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id DAA04097; Fri, 30 Jul 1999 03:02:51 -0700 (PDT)
Received: from DHARTER (d3-s48-208-telehouse.mistral.co.uk [195.184.228.208]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id KAA06954; Fri, 30 Jul 1999 10:04:02 +0100
Received: by DHARTER with Microsoft Mail id <01BEDA7B.5FAC1BE0@DHARTER>; Fri, 30 Jul 1999 11:05:03 +0100
Message-ID: <01BEDA7B.5FAC1BE0@DHARTER>
From: Darren Harter <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Compressed data type for S/MIME
Date: Fri, 30 Jul 1999 09:26:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

Thanks for this.
It's exactly the kind of thing I was looking for.
Looks like a WIN-WIN situation.

Regards,

Darren

------------------------------------------------------------------------
Darren Harter B.Sc (Hons) CEng MBCS
Application Development Group, UK
Entegrity Solutions Corp.
Tel: [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]
http://www.entegrity.com
http://www.entegrity.co.uk

-----Original Message-----
From:	Paul Hoffman / IMC [SMTP:[e-mail]]
Sent:	Thursday, July 29, 1999 5:42 PM
To:	Darren Harter; [e-mail]
Subject:	RE: Compressed data type for S/MIME

At 09:40 AM 7/29/1999 +0100, Darren Harter wrote:
>1. Are we really concerned with saving network bandwidth these days?  If 
>we are then clearly compression is essential.  If we're not, why are we 
>discussing it at all?

There is another aspect that is more relevant to non-S/MIME uses of CMS: 
speed of encrypting. Studies done by the IPsec folks found that the 
combination of compressing and encrypting with TripleDES is faster than 
encrypting uncompressed data. The fact that the resulting payload is 
smaller is obviously an additional advantage.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id SAA02766 for ietf-smime-bks; Thu, 29 Jul 1999 18:30:35 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA02751 for <[e-mail]>; Thu, 29 Jul 1999 18:30:32 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id NAA07673 for <[e-mail]>; Fri, 30 Jul 1999 13:32:53 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93329797326324>; Fri, 30 Jul 1999 13:26:13 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Compressed data type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 30 Jul 1999 13:26:13 (NZST)
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've asked Gunther Schadow, one of the authors of draft-ietf-ediint-hl7.txt 
(covering secure EDI transactions for HL7, which is used for healthcare), for 
his thoughts on compressing messages and on adding compression to S/MIME.  
Note that HL7 use has particular requirements (small messages of a few K to a
few hundred K, nothing like the multimegabyte FEDI monsters, a generally text-
only environment (no easy ability to handle binary data), batch-style 
processing, etc etc) which are reflected in the EDIINT-HL7 draft and the 
comments below.  One thing I'll have to add to the compression draft is a 
comment on the relative merits of compress-before-sign vs sign-before-
compress.

Some of the EDIINT drafts have the following (or some variant thereof) to say 
about S/MIME compression:

>The digital envelope does not perform data compression prior to encryption.  
>There is yet no standard way to compress MIME-EDI entities before encryption, 
>however, the EDIINT working group suggests using a header field named 
>Content-Encoding as per HTTP [RFC 2068].

The recommendation for compression is either (1) use PGP, (2) use the above, 
piping the data through compress or gzip (it works in this case because it's 
batch processing typically done on Unix boxes).  I'm only aware of one 
situation where this type of processing is being used, although they're not 
following the above recommendation but just assuming the other side knows 
it's compressed (you don't want to know what sort of a hack this involves 
under Windows now that sites are moving towards using NT for this - it was 
an obvious and easy solution under Unix, but almost impossible to move to
Windows).  The more general solution is to use zlib and assume that the other
side knows that id-data is sometimes compressed data (it works in this case
because EDI messages are always fixed-format text while compressed data is
binary).  Having been exposed to these kludges is one of the reasons why I
really want to see a standard representation for compressed content in 
S/MIME.

I saw the first EDIINT draft some time in 1996 (although I don't know what it 
had to say about compression back then), so they may have been waiting for 
over three years, beating the 14-month record by a considerable margin.

Peter.

-- Snip --

Hi,

Interestingly PGP has had automatic compression of payload from the
beginning. The reason is not just size of the message itself, but
other aspects may make compression before encryption favorable:

1. removing redundancy improves robustness against certain (or all?)
   decipherment attacks.

2. the payload to encrypt is smaller which is why compression before
   encryption can be more efficient than after encryption. I tested it
   on a 300 kB text file that compresses to 16% of the size and the
   pipe gzip|bdes ran still 20% faster than bdes only.

3. since encryption increases entropy of the message, compression
   is less efficient after encryption. Actually it's not possible
   at all: gzipping a DES-CBC cryptogram will actually increase
   the size!

This is all said for encryption. For signatures it may be better not
to compress so as to have an immediately readable cleartext to store
with the signature. But hell, isn't S/MIME hiding the text behind a
blob of DER anyway? (I hate S/MIME for this)

Notably hashing (MD5) is far less expensive then DES-CBC so that
compressing before signature would not gain any significant
throughput, and the cost of multiple decompression for every access to
the authenticated archive would be too high.

So, consider an ideal world where we were using MOSS (the real
SECURE-MIME, nice MIME-based plain text), the most useful steps would
be:

1. sign
2. compress
3. encrypt

Actually the little test I did has such a persuasive outcome that I'll
just show the figures here:

$ ls -l A*

-rw-r--r--  1 schadow  bin  335803 Jul 29 15:34 A       plain text
-rw-r--r--  1 schadow  bin  335808 Jul 29 15:39 Ac      DES-CBC cryptogram
-rw-r--r--  1 schadow  bin  335884 Jul 29 15:36 Acz     compressed crypto
-rw-r--r--  1 schadow  bin   55786 Jul 29 15:35 Az      compressed plain
-rw-r--r--  1 schadow  bin   55792 Jul 29 15:39 Azc     crypted compress

$ time gzip -c A | bdes -k onekeytwokeyslongkeyshortkey > Azc

real    0m0.335s
user    0m0.289s
sys     0m1.030s

$ time bdes -k onekeytwokeyslongkeyshortkey <A > Ac

real    0m0.433s
user    0m0.334s
sys     0m0.032s

$ time bdes -k onekeytwokeyslongkeyshortkey <A |gzip -f >Acz

real    0m0.666s
user    0m1.606s
sys     0m0.019s

$ time gzip -f <A >Az

real    0m0.257s
user    0m0.222s
sys     0m0.016s

I am not sure how much this matters for EDI since as far as I know
compressing EDI streams is quite uncommon. But why would you not want
to do it if the additional compression step can speed up the entire
encryption process?  I's a win/win situation: where else can you save
both channel bandwidth and CPU load?

regards
-Gunther

Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: [phone]
[e-mail] ---------------------- #include <usual/disclaimer>



Received: by mail.proper.com (8.9.3/8.9.3) id MAA21805 for ietf-smime-bks; Thu, 29 Jul 1999 12:14:20 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA21801 for <[e-mail]>; Thu, 29 Jul 1999 12:14:15 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id HAA08324 for <[e-mail]>; Fri, 30 Jul 1999 07:16:44 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93327540324266>; Fri, 30 Jul 1999 07:10:03 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Compressed data type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Fri, 30 Jul 1999 07:10:03 (NZST)
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>

Darren Harter <[e-mail]> writes:

>1. Are we really concerned with saving network bandwidth these days?  If we 
>are then clearly compression is essential.  If we're not, why are we 
>discussing it at all?

In the examples I cited (batch EDI), compression is absolutely essential.  I 
know of at least one nontrivial project where compression was ranked far above
any kind of security in terms of importance - you simply couldn't move the 
data over ISDN, X.25, or dialup links unless it was compressed.  Given that
even for more conventional business email use you're going to have bloatware
documents (150 copies of a 1.5MB Word memo reminding people not to forget the 
company picnic, 10MB spreadsheets with last month's sales figures, etc) 
typically going over modem (RAS) or ISDN links, and that the typical PC has
CPU cycles to burn, it doesn't make any sense *not* to include compression.

>2. If we need compression, how does the algorithm complexity of zlib 
>compression algorithm compare with 3DES encryption?  What's its average 
>compression rate?

Is it sufficient to say "b***y quick", or do I have to actually provide some 
figures:-)?  I really have no idea of the compression rate of something like 
zlib, it's hard to test by simply running zip because it's I/O bound, and a 
quick search hasn't located any details, but I can imagine that (especially 
in a speed-optimised mode like -1) it'd run circles around any crypto except 
RC4.  The only comparison figures I have are with LZO, which runs at about 
1/3 the speed of a memcpy().  zlib isn't nearly as fast, but it's much faster
than any crypto operation.  Also, don't forget that you're typically 
tripling[0] the speed not just of encryption and hashing but also the multiple
layers of base64 gunk which S/MIME wraps around every processing step.  If
nothing else, it'll stop the PGP crowd from laughing at S/MIME's 2:1 expansion
of everything you send with it while PGP gets 2:1 compression.

>I think my bottom line questions here are: how important is processing speed 
>compared to network bandwidth? and how much time does this aspect of the 
>processing take compared with all those cert/crl processes going on in 
>S/MIME and/or CMS?

You're winning on security, processing speed, and network bandwidth, at the 
cost of adding a new OID and about an hours programming time.

Peter.

[0] Based on 3:1 - 4:1 compression figures for a random collection of Word 
    documents, for EDI it's even higher.



Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id LAA20415 for ietf-smime-bks; Thu, 29 Jul 1999 11:07:17 -0700 (PDT)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA20410 for <[e-mail]>; Thu, 29 Jul 1999 11:07:16 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id <PFHWKVA1>; Thu, 29 Jul 1999 14:10:33 -0400
Message-ID: <33BD629222C0D211B6DB0060085ACF3136092B@WFHQEX03>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: CMSKEA Proposed Changes
Date: Thu, 29 Jul 1999 14:10:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I made an error when I updated the "CMS KEA and SKIPJACK Conventions"
(CMSKEA) I-D in May 99 to address Jim Schaad's comments stated in the
attached message trail.  CMSKEA-01, Section 4.2.1, 5th paragraph, second
sentence erroneously states "The KeyAgreeRecipientInfo
keyEncryptionAlgorithm parameters field MUST be the id-fortezzaWrap80 OID
indicating that the FORTEZZA 80-bit wrap function is used to wrap the 80-bit
SKIPJACK CEK."  This must be changed to: "The KeyAgreeRecipientInfo
keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm as
specified in [CMS].  The algorithm field of KeyWrapAlgorithm MUST be the
id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is
used to wrap the 80-bit SKIPJACK CEK.  The parameters field of
KeyWrapAlgorithm MUST be absent."  Thanks to Pierce Leonberger for pointing
this out.  

Furthermore, CMSKEA-01, Section 4.3, 2nd paragraph, 2nd sentence states:
"The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be the
id-fortezzaWrap80 OID (with NULL parameters) indicating that the FORTEZZA
80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK."  This should
be: "The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be the
id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is
used to wrap the 80-bit SKIPJACK CEK.  The KEKRecipientInfo
keyEncryptionAlgorithm parameters field MUST be absent."  This makes the use
of the id-fortezzaWrap80 OID consistent in both sections.

I also clarified the definition of Skipjack-Parm and changed
"initialization_vector" to "initialization-vector" because underscore is an
invalid ASN.1 character.  Thanks to Phil Griffin for pointing this out.

I have submitted a new CMSKEA I-D (CMSKEA-02) to the Internet-Drafts editor
containing these changes.  VDA is developing the S/MIME Freeware Library
(SFL) Fortezza Cryptographic Token Interface Library (CTIL) to implement the
changes included in CMSKEA-02.

Please let me know if anybody disagrees with any of these changes.  Please
review CMSKEA-02 (once it is available) and provide comments, if any.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[e-mail]
============================================

-----Original Message-----
From: Jim Schaad (Exchange) [mailto:[e-mail]] 
Sent: Friday, May 07, 1999 1:45 PM
To: Pawling, John; Ietf-Smime (E-mail)
Subject: RE: More Re: Comments on cmskea


John,

After having worked my way through this, I think it is completely acceptable
and should be done.  This addresses the major problem I had and make things
more in line with the D-H items.

jim


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 06, 1999 10:36 AM
To: Ietf-Smime (E-mail)
Subject: More Re: Comments on cmskea


Jim and friends,

Please substitute "id-kEAKeyEncryptionAlgorithm" for "id-KEA" in my 
earlier message. 

Also, change the definition to: "id-kEAKeyEncryptionAlgorithm OBJECT
IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840) organization(1)
gov(101) dod(2) infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}.  

- John Pawling


Previous message:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Jim,

Thank you very much for your feedback regarding the "CMS KEA and SKIPJACK
Conventions" (CMSKEA) I-D.  I apologize for not answering your message
sooner. 

I believe that you make an excellent point that the id-keyExchangeAlgorithm
OID is overused in CMSKEA.  In fact, the situation is slightly worse than
what you describe.  I added bullet 2 to your list as follows.

1. RFC2528: id-keyExchangeAlgorithm is used in a certificate to identify the
algorithm type of the public key.  The parameters field in this case is an
OCTET STRING identifying the group parameters for the key.

2. CMSKEA, Sec 4.2, 3rd para: id-keyExchangeAlgorithm can be used in a
keyAgreementRecipientInfo originatorKey to identify the type of the public
key.  The parameters field in this case is an OCTET STRING identifying the
group parameters for the key.

3. CMSKEA, Sec 4.2.1, 4th para: id-keyExchangeAlgorithm is used in the
KeyAgreementRecipientInfo keyEncryptionAlgorithm field.  In this case the
parameters field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID).

4. CMSKEA, Sec 4.3, 2nd para: id-keyExchangeAlgorithm is used in
KEKRecipientInfo keyEncryptionAlgorithm field.  In this case the parameters
field is KeyWrapAlgorithm (using id-fortezzaWrap80 OID).

I agree with your proposed change for CMSKEA, Sec 4.3, 2nd para.  I don't
agree with your proposed change for CMSKEA, Sec 4.2.1, 4th para, because it
contradicts CMS section 12.3.1 which states: "Key agreement algorithm
identifiers are located in the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm...fields.  Key wrap algorithm
identifiers are located in the KeyWrapAlgorithm parameters within the
EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm
... fields."


Recommend the following:

1) Continue to use the id-keyExchangeAlgorithm OID as stated in bullets 1
and 2 above. 

2) Define a new OID for use as stated in bullet 3.  Recommend the following
OID be registered in the Registry of INFOSEC Technical Objects: id-kEA
OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) us(840)
organization(1) gov(101) dod(2) infosec(1) algorithms(1) kEA (23)}.  The
parameters field for this OID will be KeyWrapAlgorithm (using
id-fortezzaWrap80 OID).

3) As you proposed, change CMSKEA, Sec 4.3, 2nd para to state that the
id-fortezzaWrap80 OID (with NULL parameters) is used in KEKRecipientInfo
keyEncryptionAlgorithm field.  

Please let me know if you agree with these recommendations.  If anybody else
has comments, please let me know. If there are no objections from anybody,
then I will change the CMSKEA I-D to implement the aforementioned
recommendations and I will apply for the new id-kEA OID.

- John Pawling


At 09:37 PM 4/29/99 -0700, Jim Schaad (Exchange) wrote:
>John,
>
>I am having a big problem with the amount of overload going on for the the
>OID id-keyExchangeAlgorithm.  It appears to be used in three unique
>locations in encoding an encrypted message and has different meanings and
>two different set of parameters.
>
>
>1.  id-keyExchangeAlgorithm is used in a certificate to identify the
>asymmetric algorithm.  The parameters in this case are an OCTET STRING
>identifing the group parameters for the key.
>
>2.  id-keyExchangeAlgorithm is used in the KeyAgreementRecipientInfo
>keyEncryptionAlgorithm field.  In this case the parameters is
>KeyWrapAlgorithm (using id-fortezzaWrap80 as the algorithm).
>
>3.  id-keyExchangeAlgorithm is used in KEKRecipientInfo
>keyEncryptionAlgorithm field.  In this case a completely different
algorithm
>is being referenced and again the parameters are KeyWrapAlgorithm.
>
>
>I strong suggest that we change this as follows:
>
>1.  id-keyExchangeAlgorithm is used in certificate w/parameters and in
>KeyAgreementRecipeintInfo w/o parameters.
>
>2.  id-fortezzaWrap80 is used in KEKRecipientInfo for the KEK algorithm
>again w/o parameters are they are not needed.
>
>This should work unless we belive that there would ever be a different
>content encryption algorithm for KEA.
>
>
>jim


Received: by mail.proper.com (8.9.3/8.9.3) id JAA17936 for ietf-smime-bks; Thu, 29 Jul 1999 09:39:32 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA17931; Thu, 29 Jul 1999 09:39:30 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 29 Jul 1999 09:41:30 -0700
To: Darren Harter <[e-mail]>, "[e-mail]" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: Compressed data type for S/MIME
In-Reply-To: <01BED9A6.91EEAFD0@DHARTER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 09:40 AM 7/29/1999 +0100, Darren Harter wrote:
>1. Are we really concerned with saving network bandwidth these days?  If 
>we are then clearly compression is essential.  If we're not, why are we 
>discussing it at all?

There is another aspect that is more relevant to non-S/MIME uses of CMS: 
speed of encrypting. Studies done by the IPsec folks found that the 
combination of compressing and encrypting with TripleDES is faster than 
encrypting uncompressed data. The fact that the resulting payload is 
smaller is obviously an additional advantage.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by mail.proper.com (8.9.3/8.9.3) id IAA16611 for ietf-smime-bks; Thu, 29 Jul 1999 08:06:14 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA16607 for <[e-mail]>; Thu, 29 Jul 1999 08:06:13 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA12736 for <[e-mail]>; Thu, 29 Jul 1999 11:08:45 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA12731 for <[e-mail]>; Thu, 29 Jul 1999 11:08:44 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA29853 for <[e-mail]>; Thu, 29 Jul 1999 11:08:41 -0400 (EDT)
Received: from ara.missi.ncsc.mil (ara.missi.ncsc.mil [144.51.58.9]) by ara.missi.ncsc.mil (8.9.1b+Sun/8.9.1) with SMTP id LAA17859 for <[e-mail]>; Thu, 29 Jul 1999 11:08:07 -0400 (EDT)
Message-Id: <[e-mail]>
Date: Thu, 29 Jul 1999 11:08:07 -0400 (EDT)
From: "David P. Kemp" <[e-mail]>
Reply-To: "David P. Kemp" <[e-mail]>
Subject: RE: Compressed data type for S/MIME
To: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: pvyxnoFPXqQzqmvNz0HA6w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> From: "Pawling, John" <[e-mail]>
> 
> All,
> 
> Compression is not a security service, so it should not be included in the
> S/MIME specs.  Developing an Internet standard for compressing data is an
> issue that is related to Internet data communications, in general, not just
> S/MIME.  There may be folks who are not participating in the S/MIME WG that
> would greatly benefit from an Internet compression standard.  In summary, I
> believe that this discussion should take place in a more general data
> communications group, not the S/MIME WG.


Unfortunately, as Peter pointed out, the discussion hasn't happened,
and isn't likely to happen, at the MIME level.  And if a compressed
MIME-type did exist, it would not cover non-S/MIME applications of
CMS.  Perhaps CMS itself should be owned by a "more general data
communications group" such as WTS or CAT, but it isn't.  As long as
CMS is S/MIME-related, compression within CMS is S/MIME-related.

The philosophy adopted by other Security Area WGs is that if security
breaks something, security should ameliorate the damage to the extent
possible.  Thus PPP includes compression because PPP encryption breaks
modem compression.  IPsec includes it because IPsec breaks PPP
compression.  TLS includes it because TLS breaks IPsec compression.  As
long as CMS will be used with compressible data and with
compression-enabled lower layers (a network stack, or disk-doubler),
CMS should address the problem it causes.



Received: by mail.proper.com (8.9.3/8.9.3) id HAA15319 for ietf-smime-bks; Thu, 29 Jul 1999 07:18:32 -0700 (PDT)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id HAA15315 for <[e-mail]>; Thu, 29 Jul 1999 07:18:31 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id <PFHWKT48>; Thu, 29 Jul 1999 10:21:48 -0400
Message-ID: <33BD629222C0D211B6DB0060085ACF3136091A@WFHQEX03>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: Compressed data type for S/MIME
Date: Thu, 29 Jul 1999 10:21:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Compression is not a security service, so it should not be included in the
S/MIME specs.  Developing an Internet standard for compressing data is an
issue that is related to Internet data communications, in general, not just
S/MIME.  There may be folks who are not participating in the S/MIME WG that
would greatly benefit from an Internet compression standard.  In summary, I
believe that this discussion should take place in a more general data
communications group, not the S/MIME WG.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[e-mail]
============================================



Received: by mail.proper.com (8.9.3/8.9.3) id GAA14431 for ietf-smime-bks; Thu, 29 Jul 1999 06:27:49 -0700 (PDT)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id GAA14427 for <[e-mail]>; Thu, 29 Jul 1999 06:27:48 -0700 (PDT)
Received: from haggis.ma.certco.com (haggis.ma.certco.com [10.200.200.20]) by fwma1.certco.com (Postfix) with ESMTP id 86ED715531; Thu, 29 Jul 1999 09:29:49 -0400 (EDT)
Received: from macertco-srv1.ma.certco.com (macertco-srv1.ma.certco.com [10.200.200.42]) by haggis.ma.certco.com (Postfix) with ESMTP id B89D87C0A0; Thu, 29 Jul 1999 09:29:48 -0400 (EDT)
Received: by macertco-srv1.ma.certco.com with Internet Mail Service (5.5.2232.9) id <PFV8DR25>; Thu, 29 Jul 1999 09:29:32 -0400
Message-ID: <[e-mail]>
From: "Salz, Rich" <[e-mail]>
To: "'Graham Klyne'" <[e-mail]>, Darren Harter <[e-mail]>
Cc: [e-mail]
Subject: RE: Compressed data type for S/MIME
Date: Thu, 29 Jul 1999 09:29:24 -0400
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
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>FWIW, for the foreseeable future I think network bandwidth will usually be
>a greater bottleneck than processing speed.

Bandwidth or latency?


Received: by mail.proper.com (8.9.3/8.9.3) id FAA13832 for ietf-smime-bks; Thu, 29 Jul 1999 05:56:50 -0700 (PDT)
Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.9.3/8.9.3) with SMTP id FAA13828 for <[e-mail]>; Thu, 29 Jul 1999 05:56:49 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 29 Jul 1999 12:58:43 UT
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA07574; Thu, 29 Jul 1999 08:55:43 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2232.9) id <3QWX94RX>; Thu, 29 Jul 1999 09:01:13 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'Darren Harter'" <[e-mail]>, [e-mail]
Subject: RE: Compressed data type for S/MIME
Date: Thu, 29 Jul 1999 09:04:56 -0400
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
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Network bandwidth is one relevant consideration, but storage consumption may
be even more strongly motivating for messaging-oriented protocols like CMS.
It's quite possible that some CMS-encapsulated objects (including, but not
limited to, S/MIME messages) will be stored for long-term reference by
recipients.  It could be convenient for them to be sent and received in a
compressed form, to avoid the need to reprocess them for efficient storage.

--jl

> -----Original Message-----
> From: Darren Harter [mailto:[e-mail]]
> Sent: Thursday, July 29, 1999 4:41 AM
> To: [e-mail]
> Subject: RE: Compressed data type for S/MIME
> 
> 
> All,
> 
> I've been watching this thread with interest and I'd like to 
> raise a few observations/questions/issues.  I'd like to make 
> the point first though that what follows is not intended to 
> contradict or counter any of the messages that proceed this 
> one - I'd just like to widen the debate a little and firm up 
> my understanding of the relative merits of performing 
> compression or not.
> 
> 1. Are we really concerned with saving network bandwidth 
> these days?  If we are then clearly compression is essential. 
>  If we're not, why are we discussing it at all?
> 
> 2. If we need compression, how does the algorithm complexity 
> of zlib compression algorithm compare with 3DES encryption?  
> What's its average compression rate?
> 
> e.g. How does the time to process the data compare in the following:
> 
> 	a. Encrypt 10Mb of plaintext with 3DES
> 	b. Compress 10Mb to (say) 5Mb using zlib and then 
> encrypt using 3DES.
> 
> 3. If b. takes longer than a. and we're not that concerned 
> with network bandwidth why bother compressing?  
> 
> I think my bottom line questions here are: how important is 
> processing speed compared to network bandwidth? and how much 
> time does this aspect of the processing take compared with 
> all those cert/crl processes going on in S/MIME and/or CMS?
> 
> Regards,
> 
> Darren
> 
> --------------------------------------------------------------
> ----------
> Darren Harter B.Sc (Hons) CEng MBCS
> Application Development Group, UK
> Entegrity Solutions Corp.
> Tel: [phone]
> Fax: [phone]
> Cell: [phone]
> Email: mailto:[e-mail]
> http://www.entegrity.com
> http://www.entegrity.co.uk
> 


Received: by mail.proper.com (8.9.3/8.9.3) id CAA08115 for ietf-smime-bks; Thu, 29 Jul 1999 02:49:04 -0700 (PDT)
Received: from pegasus.group5.co.uk (mailhost.group5.co.uk [193.128.238.226]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id CAA08110 for <[e-mail]>; Thu, 29 Jul 1999 02:49:02 -0700 (PDT)
Received: from GK-Portable (unverified [193.149.74.246]) by pegasus.group5.co.uk (Rockliffe SMTPRA 2.1.5) with SMTP id <[e-mail]>; Thu, 29 Jul 1999 10:40:42 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Jul 1999 10:49:53 +0100
To: Darren Harter <[e-mail]>
From: Graham Klyne <[e-mail]>
Subject: RE: Compressed data type for 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 09:40 29/07/99 +0100, Darren Harter wrote:

>I think my bottom line questions here are: how important is processing
speed compared to network bandwidth? and how much time does this aspect of
the processing take compared with all those cert/crl processes going on in
S/MIME and/or CMS?

FWIW, for the foreseeable future I think network bandwidth will usually be
a greater bottleneck than processing speed.

#g

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



Received: by mail.proper.com (8.9.3/8.9.3) id BAA05902 for ietf-smime-bks; Thu, 29 Jul 1999 01:43:41 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id BAA05898 for <[e-mail]>; Thu, 29 Jul 1999 01:43:39 -0700 (PDT)
Received: from DHARTER (d5-s14-174-telehouse.mistral.co.uk [195.184.224.174]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id IAA18144 for <[e-mail]>; Thu, 29 Jul 1999 08:44:41 +0100
Received: by DHARTER with Microsoft Mail id <01BED9A6.91EEAFD0@DHARTER>; Thu, 29 Jul 1999 09:41:44 +0100
Message-ID: <01BED9A6.91EEAFD0@DHARTER>
From: Darren Harter <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Compressed data type for S/MIME
Date: Thu, 29 Jul 1999 09:40:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA05899
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I've been watching this thread with interest and I'd like to raise a few observations/questions/issues.  I'd like to make the point first though that what follows is not intended to contradict or counter any of the messages that proceed this one - I'd just like to widen the debate a little and firm up my understanding of the relative merits of performing compression or not.

1. Are we really concerned with saving network bandwidth these days?  If we are then clearly compression is essential.  If we're not, why are we discussing it at all?

2. If we need compression, how does the algorithm complexity of zlib compression algorithm compare with 3DES encryption?  What's its average compression rate?

e.g. How does the time to process the data compare in the following:

	a. Encrypt 10Mb of plaintext with 3DES
	b. Compress 10Mb to (say) 5Mb using zlib and then encrypt using 3DES.

3. If b. takes longer than a. and we're not that concerned with network bandwidth why bother compressing?  

I think my bottom line questions here are: how important is processing speed compared to network bandwidth? and how much time does this aspect of the processing take compared with all those cert/crl processes going on in S/MIME and/or CMS?

Regards,

Darren

------------------------------------------------------------------------
Darren Harter B.Sc (Hons) CEng MBCS
Application Development Group, UK
Entegrity Solutions Corp.
Tel: [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]
http://www.entegrity.com
http://www.entegrity.co.uk


Received: by mail.proper.com (8.9.3/8.9.3) id PAA25795 for ietf-smime-bks; Wed, 28 Jul 1999 15:49:52 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA25787 for <[e-mail]>; Wed, 28 Jul 1999 15:49:38 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id KAA32543; Thu, 29 Jul 1999 10:48:12 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93320169320657>; Thu, 29 Jul 1999 10:41:33 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Compressed data type for S/MIME
Cc: [e-mail]
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Jul 1999 10:41:33 (NZST)
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 certainly understand that an independent wrapping mechanism would provide
>more generality, but I am a little concerned that CMS may not be as widely 
>adopted as some might hope, whereas implementing it within a crypto algorithm
>would allow SSL, TLS, PSEC, etc., etc., to implement it within their suite of
>supported algorithms.

I think this one's already been addressed in a previous message.

>Also, don't some/most compression algorithms make use of previously 
>calculated symbol tables?  Couldn't those tables be transferred and referred 
>to independently, rather than being sent with the text, assuming they are 
>reasonably constant?
>
>This might argue that some parameters to the compression algorithm wold be 
>nice to have.

zlib uses semi-adaptive Huffman coding for statistical compression and LZ77
for dictionary compression, the codeword tables[0] are stored in a compressed
format[1] at the start of the data.  They're built by scanning the data and
building a fixed tree for each data block with more or less fixed statistics,
so there are no pre-calculated tables.  zlib does contain provisions for pre-
computed dictionaries (you can seed the model used by the compressor with data
you know will appear in the data to be compressed), but it's complex to manage
and doesn't have much effect unless you're sending very small messages.  I 
don't know of anything which uses it, it isn't worth the effort and 
complexity.

Peter.

[0] Strictly speaking the Huffman tree.
[1] Actually the tables aren't stored in any kind of form, what's stored is 
    the information required to reconstruct a canonical Huffman tree by the
    decoder.




Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id OAA23749 for ietf-smime-bks; Wed, 28 Jul 1999 14:32:41 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA23744 for <[e-mail]>; Wed, 28 Jul 1999 14:32:40 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 28 Jul 1999 15:35:01 -0600
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.5.2
Date: Wed, 28 Jul 1999 15:34:56 -0600
From: "Bob Jueneman" <[e-mail]>
To: <[e-mail]>
Cc: "<"<[e-mail]>
Subject: Re: Compressed data type for S/MIME
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 OAA23746
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, 

I don't know zlib from a zebra, but way back in the PEM days I argued for the 
same sort of thing.  The use of encryption obviously makes the use of statistical
modems, and other bandwidth-efficiency devices essentially impossible, and
so it is essential to compress the plaintext before encrypting it.

But a question. Rather than inventing a new CMS data type, couldn't this be
 implemented as a new encryption algorithm, such as zlib-with-triple-DES?

I certainly understand that an independent wrapping mechanism would provide 
more generality, but I am a little concerned that CMS may not be as widely adopted
as some might hope, whereas implementing it within a crypto algorithm would allow
SSL, TLS, PSEC, etc., etc., to implement it within their suite of supported algorithms.  
Just a thought.

Also, don't some/most compression algorithms make use of previously calculated
symbol tables?  Couldn't those tables be transferred and referred to independently, 
rather than being sent with the text, assuming they are reasonably constant?

This might argue that some parameters to the compression algorithm wold be nice to have.

Bob

>>> Peter Gutmann <[e-mail]> 07/28/99 11:16AM >>>
>From the "Why on earth hasn't anyone done this before?" department: I've just
spent the last hour or so adding zlib-based compression to an existing S/MIME 
implementation.  All this needs to work is a new content type, CompressedData.
Compressing data before processing has so many advantages (eliminates known
plaintext, speeds up processing by slow crypto algorithms, and reduces message
size, especially for the sorts of things you'd typically want to protect
(spreadsheets, documents, etc)) and implementing it with zlib is such a no-
brainer that I don't know why noone's looked at this before.  What do people 
think of the following as a new S/MIME draft?

Peter.

-- Snip --

Internet Draft                                      Editor: Peter Gutmann
draft-ietf-smime-compression-00.txt                 University of Auckland
July 20, 1999
Expires January 2000

                   Compressed Data Content Type for S/MIME

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt 

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The Cryptographic Message Syntax data format doesn't currently contain any
provisions for compressing data before processing it.  Compressing data before
transmission provides a number of advantages including the elimination of data
redundancy which could help an attacker, speeding up processing by reducing the
amount of data to be processed by later steps such as signing or encryption,
and reducing overall message size.  This document defines a format for using
compressed data as a CMS content type.

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

This document describes a compressed data content encryption type for S/MIME.
This is implemented as a new ContentInfo type and is an extension to the types
currently defined in CMS [CMS].

The format of the messages are described in ASN.1:1994 [ASN1].

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].

1.1 Compressed Data Content Type

The compressed-data content type consists of content of any type compressed
using a specified algorithm.  The following object identifier identifies the
compressed-data content type:

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

The compressed-data content type shall have ASN.1 type CompressedData:

  CompressedData ::= SEQUENCE {
    version CMSVersion,
    compressionAlgorithm CompressionAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo
    }

The fields of type CompressedData have the following meanings:

    version is the syntax version number.  It shall be 0.

    compressionAlgorithm is a compression algorithm identifier, as defined in
    section 2.

    encapContentInfo is the content which is compressed.

2. Compression Types

CMS implementations should include ZLIB [RFC 1950] [RFC 1951], which is free of
any intellectual property restrictions and has a freely-available, portable and
efficient reference implementation.  The following object identifier identifies
ZLIB:

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

The parameters for this algorithm are NULL.

3. Security Considerations

This RFC is not concerned with security, except for the fact that compressing
data before encryption can enhance the security provided by other processing
steps by reducing the quantity of known plaintext available to an attacker.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
[e-mail] 

References

  ASN1  Recommendation X.680: Specification of Abstract Syntax Notation
        One (ASN.1), 1994.

  CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ
        Housley, April 1999.

  RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels,
        S.Bradner, March 1997.

  RFC1950 ZLIB Compressed Data Format Specification version 3.3, P.Deutsch and
        J-L Gailly, May 1996.

  RFC1951 DEFLATE Compressed Data Format Specification version 1.3, P.Deutsch,
        May 1996.

Appendix A: ASN.1 Module

PasswordRecipientInfo
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    modules(0) compression(n+1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

CompressedData ::= SEQUENCE {
  version CMSVersion,       -- Always set to 0
  compressionAlgorithm CompressionAlgorithmIdentifier,
  encapContentInfo EncapsulatedContentInfo
  }

CompressionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
  { SYNTAX NULL IDENTIFIED BY id-alg-ZLIB },
  ...
  }

END

Full Copyright Statement

[etc]



Received: by mail.proper.com (8.9.3/8.9.3) id NAA19430 for ietf-smime-bks; Wed, 28 Jul 1999 13:00:10 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA19426 for <[e-mail]>; Wed, 28 Jul 1999 13:00:07 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id IAA15978 for <[e-mail]>; Thu, 29 Jul 1999 08:02:23 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93319174420554>; Thu, 29 Jul 1999 07:55:44 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Compressed data type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Jul 1999 07:55:44 (NZST)
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>

Paul Hoffman / IMC <[e-mail]> writes:

>I think it is something that would be good to address if we are honest
>about how long it will take to get into products. It doesn't need any MUST
>or SHOULD. Wording to the effect of "future revisions to CMS SHOULD include
>this extension" is appropriate.

OK... hmm, shouldn't it be "Future implementations of CMS SHOULD include this
extension"?  The intent is to specify the behaviour of implementations, not
standards authors (if the latter is actually the case then gimme a minute to
crank out draft-ietf-smime-buy-peter-dinner-00.txt: "Pizzas compliant with 
this document shall include one or more of the following: ...").

>I think that your initial draft should also describe an option in 
>sMIMECapabilities that says "receiver can handle compression types a, b,
>and c" so that S/MIME implementations can add this in in an orderly fashion.

Fairly easy, just include the compression AlgorithmIdentifier as a capability.
I strongly suspect that there'll never be anything other than zlib defined (at
least in the foreseeable future) so having to handle a single new OID 
shouldn't be much of a problem:

-- Snip --

Implementations SHOULD use the SMIMECapabilities attribute to indicate their
ability to process compressed content types.  A compression SMIMECapability
consists of the AlgorithmIdentifier for the supported compression algorithm, in
the case of the algorithm specified in this document this is is-alg-zlib with
parameters NULL.  Alternatively, the use of compression may be handled by prior
arrangement (for example as part of an interoperability profile).

-- Snip --

Peter.



Received: by mail.proper.com (8.9.3/8.9.3) id KAA13373 for ietf-smime-bks; Wed, 28 Jul 1999 10:41:35 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA13368 for <[e-mail]>; Wed, 28 Jul 1999 10:41:32 -0700 (PDT)
Received: by puma.baltimore.ie; id TAA02867; Wed, 28 Jul 1999 19:37:17 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma002845; Wed, 28 Jul 99 19:36:38 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA15859 for <[e-mail]>; Wed, 28 Jul 1999 18:44:48 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id SAA03750 for <[e-mail]>; Wed, 28 Jul 1999 18:43:53 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: X9.42 and RFC2459 inconsistency? 
In-Reply-To: Your message of "Thu, 29 Jul 1999 04:39:17." <[e-mail]> 
Date: Wed, 28 Jul 1999 18:43:53 +0100
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>

<apologies to those that might see this more than once>

Peter Gutmann wrote:

>"William Whyte" <[e-mail]> writes:
>
>>There seems to be an inconsistency between X9.42 and RFC 2459 about how to 
>>encode Diffie-Hellman public keys.
>
>During RFC 2459's draft stages this was changed to the current form when it
>was pointed out that the X9.42 version was essentially unworkable (it 
>required complicated and unnecessary processing of the value which is
>incompatible with the way any other subjectPublicKey is handled, and it's
>practically guaranteed that implementors will get it wrong in a variety of
>ways which will cause all sorts of headaches - the values will look right
>and even work properly, they just won't give the expected results when used
>with implementations which do it differently to however you're doing it).

Cool (and a welcome gesture towards fixing broken stuff). So why do we
use their OID?

>Peter.

Andrew.


Received: by mail.proper.com (8.9.3/8.9.3) id JAA11417 for ietf-smime-bks; Wed, 28 Jul 1999 09:56:30 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id JAA11408; Wed, 28 Jul 1999 09:56:11 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 28 Jul 1999 09:58:35 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Compressed data type for S/MIME
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think it is something that would be good to address if we are honest 
about how long it will take to get into products. It doesn't need any MUST 
or SHOULD. Wording to the effect of "future revisions to CMS SHOULD include 
this extension" is appropriate.

I think that your initial draft should also describe an option in 
sMIMECapabilities that says "receiver can handle compression types a, b, 
and c" so that S/MIME implementations can add this in in an orderly fashion.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by mail.proper.com (8.9.3/8.9.3) id IAA07303 for ietf-smime-bks; Wed, 28 Jul 1999 08:10:51 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id IAA07297 for <[e-mail]>; Wed, 28 Jul 1999 08:10:45 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA11532 for <[e-mail]>; Thu, 29 Jul 1999 03:13:06 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93317438719908>; Thu, 29 Jul 1999 03:06:27 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Compressed data type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Thu, 29 Jul 1999 03:06:27 (NZST)
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>

Andrew Farrell <[e-mail]> writes:

>Also, you're not putting it in CMS, you're writing a supplmentary draft to a 
>RFC that going towards the light, so it'll be six months before you can even 
>get a draft of "CMS for S/MIME 4", which might make support of CompressedData 
>mandatory.

Given that it seems to take 1-2 years to get things from draft -> <anything
beyond a draft>, I don't think starting now will cause any major problems in 
switching over - implementors will have at least twelve months before they 
even have to think about whether they'll dedicate an hour before lunch or an 
hour after lunch towards plugging zlib into their existing code (it took me
longer to write the draft than to implement it, it really is that simple).  As
far as I'm concerned a non-MUST requirement is fine (either make it an explicit
SHOULD or an informational RFC), all I'm really after is a standard, non-
propietary (ie other than "define your own content type") way to integrate 
compression into CMS.

[My motivation for bringing up compression at this time was a request from 
 someone who's transmitting batched EDI messages of up to 100MB secured with 
 CMS.  This is used for medical and financial EDI, these guys *really* need 
 compression.  So far the end users I know of have been using hacked-in zlib 
 compression but I'd prefer to provide something standard rather than a 
 proprietary add-on which nothing else supports.  For this particular use a 
 SHOULD/informational RFC is fine, since the interoperability spec for 
 whatever it is they're doing can require "CMS with compression as per RFC 
 xyz".  If any of the EDI/HL7 crowd are reading this, maybe they'd care to 
 comment]

What would be the best way to handle this?  I can see several possibilities:

1. Supplementary draft with something like "MUST after 2000/2001/whatever"
   (or just an implied "MUST once this reaches RFC stage", which is probably
   the same thing)
2. Supplementary draft with SHOULD.
3. Informational draft.
4. <anything else?>

>A solution I came up with the last time someone walked up to me and asked me 
>this (which works inside the current solidifying structure) is to define new 
>oids for "this compression followed by this encryption" and "this compression
>followed by this hashing", but that run the obvious problem that you end up 
>with (# of hash algs + # of symmetric algs) * # of compression algs new oids. 

Ick.  That rapidly becomes unmanageable because of the explosion of OIDs.

Peter.



Received: by mail.proper.com (8.9.3/8.9.3) id XAA10486 for ietf-smime-bks; Tue, 27 Jul 1999 23:15:18 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA10438 for <[e-mail]>; Tue, 27 Jul 1999 23:11:35 -0700 (PDT)
Received: by puma.baltimore.ie; id EAA06891; Wed, 28 Jul 1999 04:33:31 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma006889; Wed, 28 Jul 99 04:33:08 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id DAA14919 for <[e-mail]>; Wed, 28 Jul 1999 03:41:28 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id DAA02352 for <[e-mail]>; Wed, 28 Jul 1999 03:40:40 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Compressed data type for S/MIME 
In-Reply-To: Your message of "Wed, 28 Jul 1999 12:31:17." <[e-mail]> 
Date: Wed, 28 Jul 1999 03:40:40 +0100
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>

Peter Gutmann wrote:

>>Jim Schaad brought this up about 14 months ago, 

>Ah, I thought I'd seen it mentioned before somewhere, just couldn't remember
>where.

>In contrast putting it in CMS means you automatically get it when you
>use CMS, so any new mailer which supports CMS would also support
>compression.

Just like EnvelopedData.

Also, you're not putting it in CMS, you're writing a supplmentary draft
to a RFC that going towards the light, so it'll be six months before you
can even get a draft of "CMS for S/MIME 4", which might make support of
CompressedData mandatory.

A solution I came up with the last time someone walked up to me and
asked me this (which works inside the current solidifying structure) is to
define new oids for "this compression followed by this encryption" and
"this compression followed by this hashing", but that run the obvious
problem that you end up with (# of hash algs + # of symmetric algs) * #
of compression algs new oids. I mention this only in passing. Now that I
think about it a bit more, having an oid for a CMS version of
compression which has as its parameters the alg of the hashing/symmetric
function might be worth a look, but it's very late, and I'm just typing
out loud :)

>On a related point, there's my standard refrain that CMS stands for 
>Cryptographic Message Syntax, not MIME Bit-Bagging Scheme - having it at the
>MIME level is of no use if you're using CMS without MIME.

Point.

Andrew.


Received: by mail.proper.com (8.9.3/8.9.3) id XAA10400 for ietf-smime-bks; Tue, 27 Jul 1999 23:10:05 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id XAA10371 for <[e-mail]>; Tue, 27 Jul 1999 23:08:21 -0700 (PDT)
Received: by puma.baltimore.ie; id EAA06921; Wed, 28 Jul 1999 04:42:31 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma006919; Wed, 28 Jul 99 04:42:14 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id DAA15062 for <[e-mail]>; Wed, 28 Jul 1999 03:50:34 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id DAA02389 for <[e-mail]>; Wed, 28 Jul 1999 03:49:46 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Compressed data type for S/MIME 
In-Reply-To: Your message of "Wed, 28 Jul 1999 12:31:17." <[e-mail]> 
Date: Wed, 28 Jul 1999 03:49:46 +0100
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>

Hmph.

Just like EncryptedData, I meant. Not EnvelopedData, which is more
widespread, of course.

Andrew.


Received: by mail.proper.com (8.9.3/8.9.3) id TAA08332 for ietf-smime-bks; Tue, 27 Jul 1999 19:55:17 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id TAA08205; Tue, 27 Jul 1999 19:40:41 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 27 Jul 1999 19:41:26 -0700
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Compressed data type for S/MIME
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:31 PM 7/28/1999 +0000, Peter Gutmann wrote:
>In contrast putting it in CMS means
>you automatically get it when you use CMS, so any new mailer which supports
>CMS would also support compression.

Except that there are already many S/MIME and other CMS protocols out there 
that will choke if they get this content type. I'm not saying it shouldn't 
be done, just that you shouldn't send it out for any S/MIME v3 messages. It 
would be good to have it in for other new CMS-using protocols, or for 
future versions of S/MIME.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by mail.proper.com (8.9.3/8.9.3) id RAA05746 for ietf-smime-bks; Tue, 27 Jul 1999 17:36:21 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA05732 for <[e-mail]>; Tue, 27 Jul 1999 17:35:59 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id MAA16719 for <[e-mail]>; Wed, 28 Jul 1999 12:37:55 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93312187717481>; Wed, 28 Jul 1999 12:31:17 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Compressed data type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 28 Jul 1999 12:31:17 (NZST)
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>

Andrew Farrell <[e-mail]> writes:

>In message <[e-mail]>you write:
>>From the "Why on earth hasn't anyone done this before?" department: I've 
>>just spent the last hour or so adding zlib-based compression to an existing
>>S/MIME implementation.  All this needs to work is a new content type, 
>>CompressedData.

>Jim Schaad brought this up about 14 months ago, 

Ah, I thought I'd seen it mentioned before somewhere, just couldn't remember
where.

>the consensus was that this made a lot more sense applied on a MIME level. 
>What actually happened next isn't recorded :)

Nothing happened, which is the problem with applying it on a MIME level - it's
never going to happen because you'd have to convince an infinite[0] number of
MUA's and MTA's to implement it (I present as exhibit 1 the fact that it's 
gone nowhere after 14 months).  Given that people are still using mailers 
dating from the stone age, and that there's no incentive to implement it (look
at how long it's taking to disable relaying and other spammer aids, which is 
probably the No.1 critical mail problem at the moment) it's never going to 
happen if you leave it at the MIME level.  In contrast putting it in CMS means
you automatically get it when you use CMS, so any new mailer which supports 
CMS would also support compression.  In contrast noone can afford to support it
at the MIME level because 99.999% of all implementations won't be able to do 
anything with it.  Technically it might make more sense at the MIME level, but
in practice all that putting it there is doing is guaranteeing that it'll never
eventuate.

On a related point, there's my standard refrain that CMS stands for 
Cryptographic Message Syntax, not MIME Bit-Bagging Scheme - having it at the
MIME level is of no use if you're using CMS without MIME.

Peter.

[0] Figures exaggerated slightly for effect.



Received: by mail.proper.com (8.9.3/8.9.3) id QAA04709 for ietf-smime-bks; Tue, 27 Jul 1999 16:40:06 -0700 (PDT)
Received: from puma.baltimore.ie ([e-mail] [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA04701 for <[e-mail]>; Tue, 27 Jul 1999 16:40:03 -0700 (PDT)
Received: by puma.baltimore.ie; id BAA05707; Wed, 28 Jul 1999 01:35:31 +0100 (GMT/IST)
Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma005702; Wed, 28 Jul 99 01:34:40 +0100
Received: from ocelot.baltimore.ie (IDENT:[e-mail] [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id AAA12215 for <[e-mail]>; Wed, 28 Jul 1999 00:43:01 +0100
Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id AAA02103 for <[e-mail]>; Wed, 28 Jul 1999 00:42:14 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Compressed data type for S/MIME 
In-Reply-To: Your message of "Wed, 28 Jul 1999 11:16:07." <[e-mail]> 
Date: Wed, 28 Jul 1999 00:42:14 +0100
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>

In message <[e-mail]>you write:
>From the "Why on earth hasn't anyone done this before?" department: I've just
>spent the last hour or so adding zlib-based compression to an existing S/MIME 
>implementation.  All this needs to work is a new content type, CompressedData.
>Compressing data before processing has so many advantages (eliminates known
>plaintext, speeds up processing by slow crypto algorithms, and reduces message
>size, especially for the sorts of things you'd typically want to protect
>(spreadsheets, documents, etc)) and implementing it with zlib is such a no-
>brainer that I don't know why noone's looked at this before.  What do people 
>think of the following as a new S/MIME draft?

>Peter.

Jim Schaad brought this up about 14 months ago, and the consensus was
that this made a lot more sense applied on a MIME level. What actually
happened next isn't recorded :)

Andrew.


Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id QAA04237 for ietf-smime-bks; Tue, 27 Jul 1999 16:20:49 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA04212 for <[e-mail]>; Tue, 27 Jul 1999 16:20:27 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id LAA05884 for <[e-mail]>; Wed, 28 Jul 1999 11:22:45 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93311736716634>; Wed, 28 Jul 1999 11:16:07 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Compressed data type for S/MIME
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Wed, 28 Jul 1999 11:16:07 (NZST)
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>

>From the "Why on earth hasn't anyone done this before?" department: I've just
spent the last hour or so adding zlib-based compression to an existing S/MIME 
implementation.  All this needs to work is a new content type, CompressedData.
Compressing data before processing has so many advantages (eliminates known
plaintext, speeds up processing by slow crypto algorithms, and reduces message
size, especially for the sorts of things you'd typically want to protect
(spreadsheets, documents, etc)) and implementing it with zlib is such a no-
brainer that I don't know why noone's looked at this before.  What do people 
think of the following as a new S/MIME draft?

Peter.

-- Snip --

Internet Draft                                      Editor: Peter Gutmann
draft-ietf-smime-compression-00.txt                 University of Auckland
July 20, 1999
Expires January 2000

                   Compressed Data Content Type for S/MIME

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The Cryptographic Message Syntax data format doesn't currently contain any
provisions for compressing data before processing it.  Compressing data before
transmission provides a number of advantages including the elimination of data
redundancy which could help an attacker, speeding up processing by reducing the
amount of data to be processed by later steps such as signing or encryption,
and reducing overall message size.  This document defines a format for using
compressed data as a CMS content type.

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

This document describes a compressed data content encryption type for S/MIME.
This is implemented as a new ContentInfo type and is an extension to the types
currently defined in CMS [CMS].

The format of the messages are described in ASN.1:1994 [ASN1].

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].

1.1 Compressed Data Content Type

The compressed-data content type consists of content of any type compressed
using a specified algorithm.  The following object identifier identifies the
compressed-data content type:

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

The compressed-data content type shall have ASN.1 type CompressedData:

  CompressedData ::= SEQUENCE {
    version CMSVersion,
    compressionAlgorithm CompressionAlgorithmIdentifier,
    encapContentInfo EncapsulatedContentInfo
    }

The fields of type CompressedData have the following meanings:

    version is the syntax version number.  It shall be 0.

    compressionAlgorithm is a compression algorithm identifier, as defined in
    section 2.

    encapContentInfo is the content which is compressed.

2. Compression Types

CMS implementations should include ZLIB [RFC 1950] [RFC 1951], which is free of
any intellectual property restrictions and has a freely-available, portable and
efficient reference implementation.  The following object identifier identifies
ZLIB:

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

The parameters for this algorithm are NULL.

3. Security Considerations

This RFC is not concerned with security, except for the fact that compressing
data before encryption can enhance the security provided by other processing
steps by reducing the quantity of known plaintext available to an attacker.

Author Address

Peter Gutmann
University of Auckland
Private Bag 92019
Auckland, New Zealand
[e-mail]

References

  ASN1  Recommendation X.680: Specification of Abstract Syntax Notation
        One (ASN.1), 1994.

  CMS   Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ
        Housley, April 1999.

  RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels,
        S.Bradner, March 1997.

  RFC1950 ZLIB Compressed Data Format Specification version 3.3, P.Deutsch and
        J-L Gailly, May 1996.

  RFC1951 DEFLATE Compressed Data Format Specification version 1.3, P.Deutsch,
        May 1996.

Appendix A: ASN.1 Module

PasswordRecipientInfo
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
    modules(0) compression(n+1) }

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

CompressedData ::= SEQUENCE {
  version CMSVersion,       -- Always set to 0
  compressionAlgorithm CompressionAlgorithmIdentifier,
  encapContentInfo EncapsulatedContentInfo
  }

CompressionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= {
  { SYNTAX NULL IDENTIFIED BY id-alg-ZLIB },
  ...
  }

END

Full Copyright Statement

[etc]



Received: by mail.proper.com (8.9.3/8.9.3) id PAA03334 for ietf-smime-bks; Tue, 27 Jul 1999 15:03:43 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA03330 for <[e-mail]>; Tue, 27 Jul 1999 15:03:41 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id RAA09555 for <[e-mail]>; Tue, 27 Jul 1999 17:06:00 -0500 (CDT)]
Received: [from az33exi01.corp.mot.com ([129.188.39.10]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA08977 for <[e-mail]>; Tue, 27 Jul 1999 17:05:55 -0500 (CDT)]
Received: by az33exi01.corp.mot.com with Internet Mail Service (5.5.2580.0) id <30PCCZGB>; Tue, 27 Jul 1999 15:05:55 -0700
Message-ID: <[e-mail]>
From: Core Scott-P18750 <[e-mail]>
To: SMIME Working Group <[e-mail]>
Subject: Secure Mail Lists
Date: Tue, 27 Jul 1999 15:05:49 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2580.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Does anyone know if there have been any implementations of the secure mail
lists described in the ESS RFC. 

thanks

scott core
Motorola


Received: by mail.proper.com (8.9.3/8.9.3) id MAA01791 for ietf-smime-bks; Mon, 26 Jul 1999 12:41:08 -0700 (PDT)
Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA01540; Mon, 26 Jul 1999 12:37:40 -0700 (PDT)
Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id <PFHWKH7J>; Mon, 26 Jul 1999 15:40:17 -0400
Message-ID: <33BD629222C0D211B6DB0060085ACF313608DA@WFHQEX03>
From: "Pawling, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Whither DSA+KEA certificates?
Date: Mon, 26 Jul 1999 15:40:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

To my knowledge, there are no plans to use the combined DSA+KEA Fortezza v1
X.509 certs with S/MIME v3.  We are implementing the S/MIME Freeware Library
(SFL) to use standard X.509 certificates only.  I will send you more info
and sample certs in a separate message.

============================================
John Pawling, Director - Systems Engineering
J.G. Van Dyke & Associates, Inc.
[e-mail]
============================================


Received: by mail.proper.com (8.9.3/8.9.3) id LAA00629 for ietf-smime-bks; Mon, 26 Jul 1999 11:36:56 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id LAA00624; Mon, 26 Jul 1999 11:36:54 -0700 (PDT)
Received: from kahu.cs.auckland.ac.nz ([e-mail] [130.216.36.13]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id GAA27473; Tue, 27 Jul 1999 06:38:50 +1200 (NZST) (sender [e-mail])
Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <93301393403720>; Tue, 27 Jul 1999 06:32:14 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Whither DSA+KEA certificates?
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz
Date: Tue, 27 Jul 1999 06:32:14 (NZST)
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>

Does anyone know whether there's any need to try to support the combined DSA+
KEA certs which were going to be used with Fortezza?  Is anyone still using
these (characteristics: weird OID's, shared DSA parameters, combined DSA+KEA
keys in the cert)?  Are the post-declassification Fortezza cards using 
standard DSA and standard KEA certs, or still using the combined certs (can
anyone send me some samples)?  Are shared-parameter DSA certs still being
generated?  Apart from the fact that this allows cert signatures to be forged,
it's also a pain to check the certs... if these are still used, are things 
like root certs for them published anywhere?  SDN.706 specifies an algorithm 
to work with them, but doesn't say whether it's just for legacy support or 
not.

Related questions: Is MSP still alive?  Is Fortezza still alive?.  After 
brushing aside the cobwebs and dust on some MISSI-related sites I saw that the
standards are still being updated from time to time, but that doesn't really 
provide much indication of whether they're still live or not (feel free to 
reply in private/anonymously if answering questions about the viability of MSP
is a career-limiting move for you :-).

I haven't been able to find anything about whether the weird combined-key/
shared parameter certs are still being produced by anything and/or whether I 
need to support them.  Apparently they're covered in SDN.604, but this isn't
available online, draft-ietf-smime-cmskea.txt covers the use of the 
(declassified) KEA and Skipjack but doesn't touch on other legacies of MISSI.

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id UAA12299 for ietf-smime-bks; Sun, 25 Jul 1999 20:02:52 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id UAA12292 for <[e-mail]>; Sun, 25 Jul 1999 20:02:51 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 25 Jul 1999 20:03:42 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Clarification on the new mailing list
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just to be sure: you don't have to be on the ietf-smime-examples mailing 
list unless you want to see the discussion of the actual binary that's 
going in the drafts. If you want to make suggestions about what should and 
should not be in the draft, those discussions will go on here on the main 
list.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19743 for ietf-smime-bks; Sun, 25 Jul 1999 13:50:14 -0700 (PDT)
Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19739 for <[e-mail]>; Sun, 25 Jul 1999 13:50:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Sun, 25 Jul 1999 13:52:18 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: New mailing list for the examples draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Greetings again. As I announced in Oslo, I have set up a mailing list for 
discussing the S/MIME examples draft. The purpose of the new list is to 
discuss the actual examples in the draft, but not the question of what 
examples should go in the draft; the latter discussion should still happen 
here on the main mailing list. The purpose of the second mailing list is to 
prevent weenie little discussions among the contributors from swamping this 
list.

The new list is, of course, open to anyone who wants to participate in (or 
just watch) the formation of the draft. 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 list at 
<http://www.imc.org/ietf-smime-examples/>.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA17927 for ietf-smime-bks; Sun, 25 Jul 1999 08:16:35 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA17922 for <[e-mail]>; Sun, 25 Jul 1999 08:16:34 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com (dial02.spyrus.com [207.212.34.122]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA12198; Sun, 25 Jul 1999 08:13:17 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 23 Jul 1999 06:27:43 -0400
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: S/MIME Charter Revision
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff and Marcus:

Here is the proposed revised charter.

Russ

= = = = = = = = = =


S/MIME Mail Security (smime)

Chair:
      Russ Housley <[e-mail]>

Security Area Director:
      Jeffrey Schiller <[e-mail]>
      Marcus Leech <[e-mail]>

Mailing Lists:
      General Discussion: [e-mail]
      To Subscribe:       [e-mail]
      Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed five Proposed Standards that
comprise the S/MIME version 3 specification.  Current efforts build
on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement
key establishment mechanism may expose some implementations to
vulnerabilities based on "small subgroup" attacks.  An informational
document will be prepared describing techniques that can be used to
avoid these attacks.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent, yet there is always more than one way to use any algorithm.
To ensure interoperability, each algorithm should have a specification
that describes its use with CMS.  Specifications for the use of additional
cryptographic algorithms will be developed.  An additional suite of
"mandatory to implement" algorithms may be selected.

To aid implementers, documents containing example output for CMS will
be collected and published.  Some of the examples will include structures
and signed attributed defined in the Enhanced Security Services (ESS)
document.

Current methods of publishing certificates in the Directory do not
allow the inclusion of secondary support information such as the
SMimeCapabilities attribute.  A method of publishing certificates
along with authenticated secondary support information will be
defined.

In some situations it would be advantageous for the CMS RecipientInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords.  A mechanism to facilitate
the definition of additional key management techniques will be defined.

S/MIME version 3 permits the use of previously distributed symmetric
key-encryption keys.  Specifications for the distribution of
symmetric key-encryption keys to mmultiple message recipients will
be developed.  Mail List Agents (MLAs) are one user of symmetric
key-encryption keys.  The specification will be cryptographic
algorithm independent.

S/MIME version 3 supports security labels.  Specifications that show
how this feature can be used to implement an organizational security
policy will be developed.  Security policies from large organizations
will be used as examples.

S/MIME version 3 can be used to protect electronic mail to and from a
domain.  In such an environment, S/MIME v3 processing is performed by
message transfer agents, guards, and gateways in order to provide
"Domain Security Services."  Mechanisms are needed to solve a number of
interoperability problems and technical limitations that arise when
domains supporting different security policies wish to interoperate.

The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap.


Goals and Milestones:

History:
      First draft of small subgroup attack avoidance.
      First draft of certificate distribution specification.
      First draft of domain security services document.
      First draft of CMS and ESS examples document.
      First draft of KEA and SKIPJACK algorithm specification.
      First draft of IDEA algorithm specification.

July 1999:
      First draft of CMS RecipientInfo extension.
      First draft of security label usage specification.

August 1999:
      First draft of CAST algorithm specification.
      Last call on small subgroup attack avoidance.
      Last call on KEA and SKIPJACK algorithm specification.

September 1999:
      First draft of mail list key distribution.
      Last call on certificate distribution specification.

November 1999:
      Updated draft of domain security services document.
      Last call on CAST algorithm specification.
      Last call on security label usage specification.
      Submit small subgroup attack avoidance as Informational RFC.
      Submit KEA and SKIPJACK algorithm specification as Informational RFC.

December 1999:
      Last call on CMS and ESS examples document.
      Last call on IDEA algorithm specification.
      Last call on CMS RecipientInfo extension.

January 2000:
      Last call on mail list key distribution.
      Submit certificate distribution specification as a Proposed Standard.

February 2000:
      Submit CAST algorithm specification as Informational RFC.
      Submit security label usage specification as Informational RFC.

March 2000:
      Submit CMS and ESS examples document as Informational RFC.
      Submit IDEA algorithm specification as Informational RFC.
      Submit CMS RecipientInfo extension as a Proposed Standard.
      Submit mail list key distribution as a Proposed Standard.

July 2000:
      Last call on domain security services document.

September 2000:
      Submit domain security services as Experimental RFC.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA10921 for ietf-smime-bks; Thu, 22 Jul 1999 15:21:19 -0700 (PDT)
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 PAA10917 for <[e-mail]>; Thu, 22 Jul 1999 15:21:18 -0700 (PDT)
Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6); Thu, 22 Jul 99 15:22:46 -0700
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <38X3WLP4>; Thu, 22 Jul 1999 15:22:46 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Sean Turner'" <[e-mail]>, <[e-mail]>
Subject: RE: Cert Attributes in CERTDIST
Date: Thu, 22 Jul 1999 15:22:45 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1B89463C30805-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: Sean Turner [mailto:[e-mail]]
> Sent: Thursday, July 22, 1999 2:31 PM
> To: [e-mail]
> Subject: Cert Attributes in CERTDIST
> 
> I'm sorry if I'm coming at this a bit late, but why are the attributes
> that are used to store signature and encryption certificates not
> userCertificate as defined in the LDAP schema RFC from PKIX?

I think that the problem is because userCertificate refers to exactly one
certificate.  In order to put in a certificate chain, along with the S/MIME
capabilities of the certificate holder, a new convention must be used.

I may have some of this wrong, so anyone feel free to correct me.

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 PAA10479 for ietf-smime-bks; Thu, 22 Jul 1999 15:10:27 -0700 (PDT)
Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA10475 for <[e-mail]>; Thu, 22 Jul 1999 15:10:23 -0700 (PDT)
Received: from ieca.com (adsl-151-200-26-46.bellatlantic.net [151.200.26.46]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA06449 for <[e-mail]>; Thu, 22 Jul 1999 18:16:20 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 22 Jul 1999 17:31:16 -0400
From: Sean Turner <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Cert Attributes in CERTDIST
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I'm sorry if I'm coming at this a bit late, but why are the attributes
that are used to store signature and encryption certificates not
userCertificate as defined in the LDAP schema RFC from PKIX?

spt






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA09326 for ietf-smime-bks; Thu, 22 Jul 1999 14:24:18 -0700 (PDT)
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 OAA09322 for <[e-mail]>; Thu, 22 Jul 1999 14:24:14 -0700 (PDT)
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 JAA30382 for <[e-mail]>; Fri, 23 Jul 1999 09:25:56 +1200 (NZST) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93267875627606>; Fri, 23 Jul 1999 09:25:56 (NZST)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Suggested change to PasswordRecipientInfo
Reply-To: [e-mail]
X-Charge-To: pgut001
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 23 Jul 1999 09:25:56 (NZST)
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>

Currently PasswordRecipientInfo assumes you'll be feeding in something
(referred to in the text as a password, although this is a somewhat misleading
name since it's really "any keying material") and transforms it into a KEK
which it uses to wrap a content-encryption key (CEK), in the same way that
KeyTransRecipientInfo uses a public key to wrap the CEK, etc etc.  The process
is:

    password -> KEK -> CEK

with the steps "password -> KEK" and "KEK -> CEK" being identified by
AlgorithmIdentifiers.  Currently "password -> KEK" uses the PKCS #5v2 ID, and
"KEK -> CEK" uses any standard encryption algorithm ID (DES, 3DES, IDEA, CAST,
RC2, etc etc).

Someone recently asked how you'd use this when there was no password available
(ie how to avoid the "password -> KEK" step), in their case they wanted to use
an IDEA key on a crypto token (I'm guessing this was referring to a
PIN-protected smart card or something similar).  There are two ways to handle
this, either use a null ID for the "password -> KEK" ID, or make the use of
this field optional, ie change:

    PasswordRecipientInfo ::= SEQUENCE {
      version CMSVersion,   -- Always set to 0
      keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier,
      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
      encryptedKey EncryptedKey }

to:

    PasswordRecipientInfo ::= SEQUENCE {
      version CMSVersion,   -- Always set to 0
      keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier OPTIONAL,
      keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
      encryptedKey EncryptedKey }

with a corresponding change in the text to say that if the key derivation
information is absent then it's assumed the KEK is supplied from an external
source (in this case the crypto token).  This seems like a nice logical way to
handle it (if the derivation info is present, ask for a password and convert it
to a KEK, otherwise get the KEK via some other means), and is more sensible
than the use of a null ID to denote the absence of a password (using a special
value to denote that no special value should be used seems silly).

Comments?

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA02110 for ietf-smime-bks; Mon, 19 Jul 1999 06:24:33 -0700 (PDT)
Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA02106 for <[e-mail]>; Mon, 19 Jul 1999 06:24:32 -0700 (PDT)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id GAA16408 for <[e-mail]>; Mon, 19 Jul 1999 06:21:34 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 16 Jul 1999 09:08:46 -0400
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Updated Charter Revision
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have finally taken all of the comments that I received in e-mail and at 
the Oslo meeting.and combined them with stuff that I made up out of thin 
air.  Here is the updateded revised charter.  Please comment by 25 July 1999.

Russ

= = = = = = = = = =


S/MIME Mail Security (smime)

Chair:
      Russ Housley <[e-mail]>

Security Area Director:
      Jeffrey Schiller <[e-mail]>
      Marcus Leech <[e-mail]>

Mailing Lists:
      General Discussion: [e-mail]
      To Subscribe:       [e-mail]
      Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed five Proposed Standards that
comprise the S/MIME version 3 specification.  Current efforts build
on these base specifications.

The use of Diffie-Hellman Key Agreement as the mandatory to implement
key establishment mechanism may expose some implementations to
vulnerabilities based on "small subgroup" attacks.  An informational
document will be prepared describing techniques that can be used to
avoid these attacks.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm
independent, yet there is always more than one way to use any algorithm.
To ensure interoperability, each algorithm should have a specification
that describes its use with CMS.  Specifications for the use of additional
cryptographic algorithms will be developed.  An additional suite of
"mandatory to implement" algorithms may be selected.

To aid implementers, documents containing example output for CMS will
be collected and published.  Some of the examples will include structures
and signed attributed defined in the Enhanced Security Services (ESS)
document.

Current methods of publishing certificates in the Directory do not
allow the inclusion of secondary support information such as the
SMimeCapabilities attribute.  A method of publishing certificates
along with authenticated secondary support information will be
defined.

In some situations it would be advantageous for the CMS RecipientInfo
structure to support additional key management techniques, including
cryptographic keys derived from passwords.  A mechanism to facilitate
the definition of additional key management techniques will be defined.

S/MIME version 3 permits the use of previously distributed symmetric
key-encryption keys.  Specifications for the distribution of
symmetric key-encryption keys to mmultiple message recipients will
be developed.  Mail List Agents (MLAs) are one user of symmetric
key-encryption keys.  The specification will be cryptographic
algorithm independent.

S/MIME version 3 supports security labels.  Specifications that show
how this feature can be used to implement an organizational security
policy will be developed.  Security policies from large organizations
will be used as examples.

S/MIME version 3 can be used to protect electronic mail to and from a
domain.  In such an environment, S/MIME v3 processing is performed by
message transfer agents, guards, and gateways in order to provide
"Domain Security Services."  Mechanisms are needed to solve a number of
interoperability problems and technical limitations that arise when
domains supporting different security policies wish to interoperate.

The S/MIME Working Group will attempt to coordinate its efforts with the
OpenPGP Working Group in areas where the work of the two groups overlap.


Goals and Milestones:

History:
      First draft of small subgroup attack avoidance.
      First draft of certificate distribution specification.
      First draft of domain security services document.
      First draft of CMS and ESS examples document.
      First draft of KEA and SKIPJACK algorithm specification.
      First draft of IDEA algorithm specification.

July 1999:
      First draft of CMS RecipientInfo extension.
      First draft of security label usage specification.

August 1999:
      First draft of CAST algorithm specification.
      Last call on small subgroup attack avoidance.
      Last call on KEA and SKIPJACK algorithm specification.

September 1999:
      First draft of mail list key distribution.
      Last call on certificate distribution specification.

November 1999:
      Updated draft of domain security services document.
      Last call on CAST algorithm specification.
      Last call on security label usage specification.
      Submit small subgroup attack avoidance as Informational RFC.
      Submit KEA and SKIPJACK algorithm specification as Informational RFC.

December 1999:
      Last call on CMS and ESS examples document.
      Last call on IDEA algorithm specification.
      Last call on CMS RecipientInfo extension.

January 2000:
      Last call on mail list key distribution.
      Submit certificate distribution specification as a Proposed Standard.

February 2000:
      Submit CAST algorithm specification as Informational RFC.
      Submit security label usage specification as Informational RFC.

March 2000:
      Submit CMS and ESS examples document as Informational RFC.
      Submit IDEA algorithm specification as Informational RFC.
      Submit CMS RecipientInfo extension as a Proposed Standard.
      Submit mail list key distribution as a Proposed Standard.

July 2000:
      Last call on domain security services document.

September 2000:
      Submit domain security services as Experimental RFC.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA08522 for ietf-smime-bks; Sat, 17 Jul 1999 05:35:30 -0700 (PDT)
Received: from l1.lviv.net ([e-mail] [194.44.154.191]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA08518 for <[e-mail]>; Sat, 17 Jul 1999 05:35:24 -0700 (PDT)
Received: from web.ipm.lviv.ua (web.ipm.lviv.ua [194.44.154.166]) by l1.lviv.net (8.9.3/8.9.3) with ESMTP id PAA29392 for <[e-mail]>; Sat, 17 Jul 1999 15:36:41 +0300
Received: from alexey22 ([195.5.34.166]) by web.ipm.lviv.ua (post.office MTA v1.9.3b **** License # 1452-345-12 ****) with SMTP id AAA334 for <[e-mail]>; Sat, 17 Jul 1999 15:37:53 +0300
Message-ID: <006c01bed050$fdfd4e70$[e-mail]>
From: "Alexey Shamov" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: draft-ietf-smime-examples-01.txt question
Date: Sat, 17 Jul 1999 15:35:32 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, all

I've tried to verify RC2 key wrap example from the
draft-ietf-smime-examples-01.txt document. The results I've got were
identical with ones from the document when RC2 effective keylength for KEK
was set to 40. When I tried to set it to 128 results were completely
different (see below).

Alexey

======================================
10.1 Wrapping RC2

This example shows how to wrap an RC2 key.

The CEK to be wrapped is
b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9

The hash of the CEK is
0a6f f19f db40 4988

The random value used is
4845 cce7 fd12 50

The CEK initialization vector is
c7d9 0059 b29e 97f7

The KEK is
fd04 fd08 0607 07fb 0003 feff fd02 fe05

The "Pre Encrypt #1" is
10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
d9 4845 cce7 fd12 500a 6ff1 9fdb 4049 88

The "Pre Encrypt #2" is (** different **)
29ca 649e c8db 0886 ae46 67a2 bc3e e467
6621 5aa3 ba3d a0c4 c9c4 5cb1 2a97 5e03
f797 9eb2 5900 d9c7

The wrapped CEK is    (** different **)
f4d8 021c 1ea4 63d2 17a9 eb69 29ff a577
36d3 e203 86c9 0993 835b 4be4 ad8d 8a1b
c63b 25de 2bf7 7993






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29441 for ietf-smime-bks; Thu, 15 Jul 1999 10:20:01 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA29435 for <[e-mail]>; Thu, 15 Jul 1999 10:19:59 -0700 (PDT)
Received: 	id NAA16831; Thu, 15 Jul 1999 13:16:42 -0400
Received: by gateway id <NP65GAW6>; Thu, 15 Jul 1999 13:19:08 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: [e-mail], "'Tony Mione'" <[e-mail]>
Subject: RE: Quick comment on the Small Subgroup Attack draft
Date: Thu, 15 Jul 1999 13:19:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The first sentence should read:

The prime p could be chosen such that p-1=2*q*j where j is prime or the
product of large primes (large means greater than or equal to q).

That should make more sense.

> ----------
> From: 	Tony Mione[SMTP:[e-mail]]
> Sent: 	Thursday, July 15, 1999 11:43 AM
> To: 	[e-mail]
> Cc: 	Tony Mione
> Subject: 	Quick comment on the Small Subgroup Attack draft
> 
> 
> I noticed a subtle problem in the text in section 3.3. The first paragraph
> reads:
> 
> 
>  The prime p could be chosen such that p-1=2*q*j where j is the product 
>                                                  ^^^^^^^^^^^^^^^^^^^^^^
>  of large primes (large means greater than or equal to q).  This will 
>  ^^^^^^^^^^^^^^^
> 
>  prevent an attacker from being able to find an element of small order 
>  modulo p, thus thwarting the small-subgroup attack.  One method to 
>  produce primes of this form is to run the prime generation algorithm 
>  multiple times until an appropriate prime is obtained.  As an example, 
>  the value of j could be tested for primality.  If j is prime, then the 
>                                                 ^^^^^^^^^^^^^
>  value of p could be accepted, otherwise the prime generation algorithm 
>  would be run again, until a value of p is produced with j prime.
>                                                     ^^^^^^
> 
> Last time I read the definition, a number cannot be both prime and the
> product of 2 primes at the same time. Are we talking about j in the last
> sentence or one of the other variables in the expression 'p-1=...'?
> 
> Tnx.
> 
> Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ -
> 732-445-0650
> [e-mail]                        W3:
> http://noc.rutgers.edu/~mione/
> PGPFP:D4EEA987E870277C  24AAE6E9E6ABD088     ***** Important: Rom 10:9-11
> *****
> Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28387 for ietf-smime-bks; Thu, 15 Jul 1999 09:51:28 -0700 (PDT)
Received: from hinge.mistral.co.uk (hinge.mistral.co.uk [195.184.228.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28383 for <[e-mail]>; Thu, 15 Jul 1999 09:51:27 -0700 (PDT)
Received: from DHARTER (d3-s38-198-telehouse.mistral.co.uk [195.184.228.198]) by hinge.mistral.co.uk (8.8.5/8.6.9) with SMTP id QAA24475; Thu, 15 Jul 1999 16:50:30 +0100
Received: by DHARTER with Microsoft Mail id <01BECEEA.4EBFE2E0@DHARTER>; Thu, 15 Jul 1999 17:48:55 +0100
Message-ID: <01BECEEA.4EBFE2E0@DHARTER>
From: Darren Harter <[e-mail]>
To: "'Tony Mione'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Quick comment on the Small Subgroup Attack draft
Date: Thu, 15 Jul 1999 17:48:37 +0100
MIME-Version: 1.0
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 JAA28384
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony,

I believe it should read

The prime p could be chosen such that p-1=2*q*j where j is a large prime (large means greater than or equal to q). i.e. (p-1) is a product of large primes.

Regards,

Darren

------------------------------------------------------------------------
Darren Harter B.Sc (Hons) CEng MBCS
Application Development Group, UK
Entegrity Solutions Corp.
Tel: [phone]
Fax: [phone]
Cell: [phone]
Email: mailto:[e-mail]
http://www.entegrity.com
http://www.entegrity.co.uk

-----Original Message-----
From:	Tony Mione [SMTP:[e-mail]]
Sent:	Thursday, July 15, 1999 4:44 PM
To:	[e-mail]
Cc:	Tony Mione
Subject:	Quick comment on the Small Subgroup Attack draft


I noticed a subtle problem in the text in section 3.3. The first paragraph
reads:


 The prime p could be chosen such that p-1=2*q*j where j is the product 
                                                 ^^^^^^^^^^^^^^^^^^^^^^
 of large primes (large means greater than or equal to q).  This will 
 ^^^^^^^^^^^^^^^

 prevent an attacker from being able to find an element of small order 
 modulo p, thus thwarting the small-subgroup attack.  One method to 
 produce primes of this form is to run the prime generation algorithm 
 multiple times until an appropriate prime is obtained.  As an example, 
 the value of j could be tested for primality.  If j is prime, then the 
                                                ^^^^^^^^^^^^^
 value of p could be accepted, otherwise the prime generation algorithm 
 would be run again, until a value of p is produced with j prime.
                                                    ^^^^^^

Last time I read the definition, a number cannot be both prime and the
product of 2 primes at the same time. Are we talking about j in the last
sentence or one of the other variables in the expression 'p-1=...'?

Tnx.

Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[e-mail]                        W3: http://noc.rutgers.edu/~mione/
PGPFP:D4EEA987E870277C  24AAE6E9E6ABD088     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA27233 for ietf-smime-bks; Thu, 15 Jul 1999 08:41:43 -0700 (PDT)
Received: from hardees.rutgers.edu (hardees.rutgers.edu [165.230.165.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA27228 for <[e-mail]>; Thu, 15 Jul 1999 08:41:42 -0700 (PDT)
Received: from localhost (mione@localhost) by hardees.rutgers.edu (8.8.8/8.8.8) with SMTP id LAA24437; Thu, 15 Jul 1999 11:43:34 -0400 (EDT)
Date: Thu, 15 Jul 1999 11:43:33 -0400 (EDT)
From: Tony Mione <[e-mail]>
To: [e-mail]
cc: Tony Mione <[e-mail]>
Subject: Quick comment on the Small Subgroup Attack draft
Message-ID: <[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>

I noticed a subtle problem in the text in section 3.3. The first paragraph
reads:


 The prime p could be chosen such that p-1=2*q*j where j is the product 
                                                 ^^^^^^^^^^^^^^^^^^^^^^
 of large primes (large means greater than or equal to q).  This will 
 ^^^^^^^^^^^^^^^

 prevent an attacker from being able to find an element of small order 
 modulo p, thus thwarting the small-subgroup attack.  One method to 
 produce primes of this form is to run the prime generation algorithm 
 multiple times until an appropriate prime is obtained.  As an example, 
 the value of j could be tested for primality.  If j is prime, then the 
                                                ^^^^^^^^^^^^^
 value of p could be accepted, otherwise the prime generation algorithm 
 would be run again, until a value of p is produced with j prime.
                                                    ^^^^^^

Last time I read the definition, a number cannot be both prime and the
product of 2 primes at the same time. Are we talking about j in the last
sentence or one of the other variables in the expression 'p-1=...'?

Tnx.

Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[e-mail]                        W3: http://noc.rutgers.edu/~mione/
PGPFP:D4EEA987E870277C  24AAE6E9E6ABD088     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA24223 for ietf-smime-bks; Wed, 14 Jul 1999 07:09:58 -0700 (PDT)
Received: from barbar.esat.kuleuven.ac.be ([e-mail] [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA24215; Wed, 14 Jul 1999 07:09:55 -0700 (PDT)
Received: from domein.esat.kuleuven.ac.be ([e-mail] [134.58.189.69]) by barbar (version 8.8.5)  with ESMTP id QAA04539; Wed, 14 Jul 1999 16:10:32 +0200 (METDST)
Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 14 Jul 1999 16:10:30 +0200 (METDST)
From: "CMS'99" <[e-mail]>
To: Communications and Multimedia Security 1999 <[e-mail]>
Subject: CMS'99 - Communications and Multimedia Security
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id HAC24220
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[apologies if you receive this mail multiple times]


Communications and Multimedia Security is a joint working conference
of IFIP TC6 and TC11.

CMS'99 will be organized September 20-21, 1999
at the Katholieke Universiteit Leuven, Belgium.

On-line registration can be done at
http://www.esat.kuleuven.ac.be/cosic/cms99/

Reduced fee of 250 EURO until August 1, 1999.


Draft program:

-----------------------------------------------------------------------

Monday, September 20

  8u00-8u45 Registration

  8u45-9u00 Welcome

  9u00-10u30 Network security: ATM and ISDN

    Security On ATM Networks 
    Stelios Karanastasis, Ahmed Patel 

    ISDN Security Services 
    Herbert Leitold, Karl Christian Posch, Reinhard Posch 

    An Alternative Access Control Architecture for IP over ATM Networks 
    Olivier Paul, Maryline Laurent 

  10u30-10u50 Coffee

  10u50-11u50 Applied Cryptology I

    Verifiable Democracy 
    Yvo Desmedt, Brian King 

    Efficient Oblivious Proofs of Correct Exponentiation 
    Markus Jakobsson, Claus Peter Schnorr 

  11u50-13u30  Lunch

  13u30-14u30  Invited talk (to be announced)

  14u30-15u30 Entity Authentication and Key Agreement Protocols

    Weaknesses in EHA Authentication and Key Distribution Protocol 
    Martin Stanek, Daniel Olejár 

    Formal Design of Efficient Authentication and Key-Agreement
Protocols 
    Gunnar Jacobson 

  15u30-16u00 Coffee

  16u00-17u30 Network security: IP

    Protecting Key Exchange and Management Protocols Against Resource
Clogging Attacks 
    Rolf Oppliger 

    Secured Distributed Virtual Conferencing 
    W.A. Adamson, C.J. Antonelli, K.W. Coffman, P. McDaniel, J. Rees 

    PIM-SM Security: Interdomain Issues and Solutions 
    Thomas Hardjono, Brad Cain 

  17u30-18u00 Recent results

  19u30 Banquet

Tuesday, September 21

  8:30-10u00 Protocols for Mobile Applications

    Attacks against the WAP WTLS protocol 
    Markku-Juhani Saarinen 

    A New Authentication Protocol for Portable Communication Systems 
    Sheng-bo Xu, Cees Jansen, Henk van Tilborg 

    Token Based Authentication for Handover Security 
    Yi Cheng, Arne Norefors 

  10u00-10u30 Coffee Break

  10u30-12u00 Applications

    On Authentication, Digital Signatures and Signature Laws 
    Per Kaijser 

    Watermarking and Secure Distribution for Encrypted Video 
    T. Amornraksa, D.R.B. Burgess, P. Sweeney 

    Implementing a Secure Log File Download Manager for the Java Card 
    Constantinos Markantonakis, Simeon Xenitellis 

  12u00-14u00 Lunch

  14u00-15u30 Applied Cryptology II

    How to Securely Broadcast a Secret 
    Jörg Schwenk 

    Proofs of Work and Bread Pudding Protocols 
    Markus Jakobsson, Ari Juels 

    Attack on Liu/Farrel/Boyd Arithmetic Coding Encryption Scheme 
    Takeyuki Uehara, Reihaneh Safavi-Naini 

  15u30-16u00 Coffee

  16u00-17u00 Web security

    Secure Data-Transfer for Web-Based Applications 
    Wolfgang Platzer 

    Using SESAME to Secure Web Based Applications on an Intranet 
    Paul Ashley, Mark Vandenwauver, Joris Claessens 

-----------------------------------------------------------------------



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA20614 for ietf-smime-bks; Tue, 6 Jul 1999 09:55:52 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20610 for <[e-mail]>; Tue, 6 Jul 1999 09:55:50 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04572; Tue, 6 Jul 1999 12:55:53 -0400 (EDT)
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-password-00.txt
Date: Tue, 06 Jul 1999 12:55:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-00.txt
	Pages		: 8
	Date		: 01-Jul-99
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords
(and, by extension, any form of variable-length keying material which
isn't necessarily an algorithm-specific fixed-format key).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-00.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-password-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-password-00.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 FAA18935 for ietf-smime-bks; Fri, 2 Jul 1999 05:19:54 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA18931 for <[e-mail]>; Fri, 2 Jul 1999 05:19:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07397; Fri, 2 Jul 1999 08:23:07 -0400 (EDT)
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-password-00.txt
Date: Fri, 02 Jul 1999 08:23:06 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-00.txt
	Pages		: 
	Date		: 01-Jul-99
	
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption.  This document
provides a method of encrypting data using user-supplied passwords
(and, by extension, any form of variable-length keying material which
isn't necessarily an algorithm-specific fixed-format key).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-password-00.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-password-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-password-00.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 HAA02201 for ietf-smime-bks; Thu, 1 Jul 1999 07:40:03 -0700 (PDT)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA02196 for <[e-mail]>; Thu, 1 Jul 1999 07:39:58 -0700 (PDT)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2448.0) id <N7D7LAY3>; Thu, 1 Jul 1999 10:30:26 -0400
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Larry Stoddard'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Charter Revision
Date: Thu, 1 Jul 1999 10:33:12 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
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 HAA02197
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Larry,

	Decided to add my nickel's worth.  Please see "BF:" inline comments
below.

Best regards,

Bill Flanigan
> ----------
> From: 	Larry Stoddard[SMTP:[e-mail]]
> Sent: 	Wednesday, June 30, 1999 5:32 PM
> To: 	Antonio Maña
> Cc: 	[e-mail]
> Subject: 	Re: Charter Revision
> 
BF:  Don't see a "business case" yet for a charter revision.

> The problem with the key/cert management approach is that it requires
> many keys. 
> 
BF:  Yes, and I currently don't see anyway to avoid this in the foreseeable
commercial future (but see last comment below).

> This will eliminate smart card based solutions as there is
> not enough space to hold multiple keys and key histories. 
> 
BF:  Memory growth and cleaver memory use/management will help.  Then there
is physical size:  I wonder how many cert/key sets would fit into a palmtop
or kneetop?  Probably as many as one needs. 

> Unless you use
> multiple smart cards, which would mean playing musical smart cards to
> read all your mail.
> 
BF:  I think you will actually end up playing musical certs.  You will be
dealing with a large number of PKIs, as well as a number of cert flavors
that each PKI will have issued.  For example, a "modest" PKI might like to
issue nonRepudiation certs, dataEncipherment certs, and IPSec certs.  And
this hardly scratches the surface as far as the number of variations just
based on the PKIX profile.  (I'm ignoring for now the possibility of root CA
cross certification.)

>  [snip]
> 
> Also for those that lease PKI services there will be an additional
> charge for each cert issued, so there is an incentive to minimize the
> number of certificates required.
> 
BF:  But there seems to be not much incentive to do this as far as
commercial browsers are concerned.

[snip] 


> Issuing identity certs and then revoking them
> would seem to be an extreme way of handling this and means more work for
> LRA and CA administration, not to mention longer CRLs.
> 
BF:  Maybe not.  You might start with a "long-term" nonRepudiation cert as
the I&A basis for obtaining/issuing short-lived certs (SLCs).  If SLCs were
good for only one transaction (with validity periods of seconds or minutes),
CRL posting would not occur.  As for CA administration, this is already a
big problem--especially for big PKIs (with certs in the millions).  Just
think about the bottlenecks of, say, how many certs/second can be issued as
well as directory storage capacity.  So, perhaps, your concerns about all
those certs may go away because cert servers can't issue them fast enough
and directories can't store them!  A final note:  I'm not sure if this
thread needs to continue.  If it does, I really don't think it belongs on
the S/MINE list any longer. 

[snip] 

> Larry Stoddard


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA27902 for ietf-smime-bks; Thu, 1 Jul 1999 03:18:58 -0700 (PDT)
Received: from correo.uma.es (correo.uma.es [150.214.40.73]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA27893 for <[e-mail]>; Thu, 1 Jul 1999 03:18:13 -0700 (PDT)
Received: from sol10.lcc.uma.es (sol10.lcc.uma.es [150.214.108.1]) by correo.uma.es (8.9.3/8.9.3) with SMTP id MAA20072; Thu, 1 Jul 1999 12:20:18 +0200 (MET DST)
Received: from lcc.uma.es by sol10.lcc.uma.es (SMI-8.6/SMI-SVR4) id MAA04344; Thu, 1 Jul 1999 12:20:03 +0200
Message-ID: <[e-mail]>
Date: Thu, 01 Jul 1999 12:12:11 +0200
From: Antonio =?iso-8859-1?Q?Ma=F1a?= <[e-mail]>
Organization: Universidad de =?iso-8859-1?Q?M=E1laga?=
X-Mailer: Mozilla 4.5 [es] (Win95; I)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Larry Stoddard <[e-mail]>
CC: lista smime <[e-mail]>
Subject: Re: Charter Revision
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Larry,

first of all thank you for your comments,

Larry Stoddard escribió:
> 
> The problem with the key/cert management approach is that it requires
> many keys. This will eliminate smart card based solutions as there is
> not enough space to hold multiple keys and key histories. Unless you use
> multiple smart cards, which would mean playing musical smart cards to
> read all your mail.  Lending a token means that you are giving access to
> everything protected by the token, including the ability to sign. The
> problem with lending encryption keys is that some authentication schemes
> use encryption keys instead of signing keys to do anonymous
> authentication.

You are right about smart cards, but I think that the identity problem
can be solved without smart cards. Also it depends on the type of key
(specially the 'container' of the key not the key itself) that you can
store several keys in a smart card.

> Also for those that lease PKI services there will be an additional
> charge for each cert issued, so there is an incentive to minimize the
> number of certificates required. The goal is to separate authorization
> from identity as any change in authorization will result in revocation
> of the identity certificate. Also the management of roles is something
> that should be handled in as distributed a fashion as possible, ideally
> the role owner should be able to delegate his role without involving the
> CA.

Of course, ideally the authorization should be separated from the identity, 
but roles can be considered identities as well. The authorization of a role 
is in most cases intrinsic to that role, for example if I am sure that you
are part of the support team of some company I can trust that any answer I
receive from you regarding products of that company is correct. In that
case I don't need an authorization that says that your can answer questions
about products of that company. 
You say that the role owner should be able to delegate his role without
involving the CA. That's because you are thinking about a commercial CA
that issues generic 'identity' certificates. If the owner of the role can
act as CA the problem disappears. I don't see the difference between issuing
a 'identity' certificate that relates a role to a specific email address -and
the corresponding public key- (which could also contain attributes to solve the
authorization issues if needed) as I propose or issuing an 'authorization'
(which I suppose is also a certificate) related to an existing 'identity'
certificate. The second solution is more complex and, in most cases, I don't
care 'who' (what physical person) is answering if I know that (s)he is allowed
to play the role that corresponds to my request.
Looking from another perspective, who should give the authorization to play
some role? Probably not the role owner because otherwise there has to be
some root to that chain that has an auto-authorization. I think that the
authorization for some role (say [e-mail]) should come from
the upper level in the organization of the company (software.company.com in the
example)

> How do you foresee dealing with temporary delegation of signing
> authority for a role? Issuing identity certs and then revoking them
> would seem to be an extreme way of handling this and means more work for
> LRA and CA administration, not to mention longer CRLs. An attribute
> certificate with a short lifetime is more practical, especially if the
> attribute cert can be issued by the local role owner.

That's again because you are supposing an expensive 'identity' certificate
with a long lifetime, an using CRLs to revoke certs. Would you agree that
the solution I propose is at least equivalent to the identity+attribute
solution if my 'identity' certificate could be issued and revoked as
easily (locally) as the attribute certificate you propose?.

Cheers,
Antonio Maña.
 
                            \|||/
                           ( . . )
  +------------------o000-----U------000o------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [e-mail] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: [phone]        Fax: [phone] !
  +--------------------------------------------------------+
  ! PGP KEY TYPE:                                          !
  !   RSA 1024                                             !
  ! KEY FINGERPRINT:                                       !
  !   7900 CDBB 9766 AB87  F0CE 5B4F 3DF1 BA56             !
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+