Subject: FYI: RFC 2144 on CAST.
From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Fri, 27 Jun 1997 15:04:17 -0400

The informational RFC on CAST has been published, and is available from
http://ds.internic.net/rfc/rfc2144.txt and
ftp://ds.internic.net/rfc/rfc2144.txt.

>From section 3, "Intellectual Property Considerations":  "The CAST-128
cipher described in this document is available worldwide on a
royalty-free basis for commercial and non-commercial uses.".

For ease of implementation, note also section 2.5, "Variable Keysize":

The CAST-128 encryption algorithm has been designed to allow a key size
that can vary from 40 bits to 128 bits, in 8-bit increments (that is,
the allowable key sizes are 40, 48, 56, 64, ..., 112, 120, and 128
bits).

Note that although CAST-128 can support all 12 key sizes listed above,
40 bits, 64 bits, 80 bits, and 128 bits are the sizes that find utility
in typical environments.  Therefore, it will likely be sufficient for
most implementations to support some subset of only these four sizes.

pww

From: Tim Matthews <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: NEWS: RSA publishes RC2 description
Date: Fri, 27 Jun 1997 08:16:14 -0700
Sender: [email-masked]

All,

>I thought this might be of interest.  You can find the I-D @
ftp://ftp.ietf.org/internet-drafts/draft-rivest-rc2desc-00.txt.  

>Tim

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

>
>==============
>
>
>RSA Data Security Publishes RC2(R) Specification in IETF Forum 
>
>08:17 a.m. Jun 27, 1997 Eastern 
>
>
>REDWOOD CITY, Calif., June 27 /PRNewswire/ -- In a move to promote broad
>acceptance of a single standard for electronic messaging, RSA Data
>Security, Inc., a wholly-owned subsidiary of Security Dynamics
>Technologies, Inc. (Nasdaq: SDTI), today announced that it has published
>a description of its RC2(R) encryption algorithm for evaluation by the
>Internet Engineering Task Force (IETF).  The published description of RC2
>allows developers working in the IETF to scrutinize the algorithm as part
>of the process to establish S/MIME(TM) as a standard for electronic
>messaging.  The RC2 algorithm is a critical component of this standard
>because it provides for message privacy and interoperability between
>domestic and export versions of products using S/MIME. 
>
>
>Developed in 1987 by cryptography pioneer Ron Rivest, inventor of the RSA
>public key cryptosystem, RC2 is in widespread use in a number of
>commercial software packages, including Lotus Notes, Microsoft Windows,
>Internet Explorer and Netscape Communication's Navigator and
>Communicator.  RSA will continue to license RC2 in a variety of RSA
>security toolkits, including BSAFE and SMAIL, as a method of providing
>flexible data privacy. 
>
>
>RC2's flexibility lets vendors tailor the level of security in their
>products, allowing them to use long encryption keys where permitted, or
>to meet federal constraints on key size for exportable applications.  In
>addition, applications that utilize RC2 for privacy enjoy accelerated
>export approval from the federal government. 
>
>
>S/MIME is considered the de facto standard for interoperable, secure
>e-mail and is used by major vendors, including Microsoft, IBM, Netscape
>Communications and VeriSign, Inc.  S/MIME allows vendors to develop
>interoperable RSA-based security for electronic messaging products, so
>that an S/MIME message composed and encrypted on one vendor's application
>can be decrypted on another.  S/MIME is based on a combination of the
>standard MIME specification and the intervendor Public Key Cryptography
>Standards (PKCS), one of the most widely implemented suite of commercial
>cryptographic standards in the U.S. 
>
>
>"The worldwide deployment of secure, interoperable e-mail can be
>accelerated by the use of single standard, such as S/MIME, which has
>already gained the endorsement of many of the industry's leading vendors
>of e-mail and messaging products," said Jim Bidzos, president of RSA. 
>"By publishing the description of RC2, we are facilitating the IETF's
>approval of S/MIME as the industry's preferred solution for protecting
>sensitive e-mail communications." 
>
>
>"RSA is pleased to make its intellectual property available to the IETF
>in support of standards," added Steve Dusse, chief technology officer of
>RSA. 
>
>
>"The Internet Mail Consortium is pleased to be involved in making S/MIME
>an open standard in the IETF," said Paul Hoffman, director of the
>Internet Mail Consortium (IMC) and a co-author of the S/MIME draft. 
>"RSA's move to publish the RC2 description will help accelerate the
>standardization process and benefit the entire Internet mail community
>and the many vendors already committed to S/MIME." 
>
>
>To help assure the performance of e-mail products designed to the S/MIME
>specification, RSA is currently sponsoring a third round of
>Internet-based interoperability testing at the S/MIME Interoperability
>Center,
><<<underline><color><param>0000,0000,fefe</param>http://www.rsa.com/rsa/S</co
>lor></underline>><underline><color><param>0000,0000,fefe</param>http://www.rs
>a.com/rsa/S-MIME/html/interop_center.html.</color></underline>
> To date, eight e-mail products, including Netscape's Communicator, Frontier
>Technologies' Intranet Genie, ConnectSoft's E-mail Connection, Deming
>Software's Secure Messenger Entrust, NEL's Mahobin, OpenSoft's Express Mail,
>and freeware Premail, have earned the S/MIME-certified logo.  Companies
>participating in RSA's current round of interoperability testing include,
>Baltimore Technologies, Ltd., Microsoft Corporation, NTT Electronics
>Technology Corp., and SSE, Ltd. 
>
>
>While originally proposed as a standard for secure, interoperable e-mail,
>vendors have recently begun to evaluate S/MIME as the basis for creating
>other Internet-based secure messaging applications such as Electronic Data
>Interchange (EDI) and military communications.  Earlier this year, the
>CommerceNet Consortium selected S/MIME as the primary technology for its EDI
>Over the Internet initiative. 
>
>
>RSA is also working closely with a number of vendors and the U.S. government
>to incorporate S/MIME into the Defense Messaging System (DMS).  The
>blueprint, expected later this summer, is designed to allow the government to
>use off-the-shelf electronic messaging software, reducing government costs
>and expanding the market for vendors. 
>
>
>RSA Data Security, Inc. 
>
>
>RSA Data Security, Inc., a wholly-owned subsidiary of Security Dynamics
>Technologies, Inc., is the world's brand name for cryptography, with more
>than 80 million copies of RSA encryption and authentication technologies
>installed and in use worldwide.  RSA technologies are part of existing and
>proposed standards for the Internet and World Wide Web, CCITT, ISO, ANSI,
>IEEE, and business, financial and electronic commerce networks around the
>globe. The company develops and markets platform-independent developer's kits
>and end-user products and provides comprehensive cryptographic consulting
>services. 
>
>
>Founded in 1982 by the inventors of the RSA Public Key Cryptosystem, the
>company is headquartered in Redwood City, Calif. 
>
>
>NOTE:  RC2 is a registered trademark and BSAFE, SMAIL and S/MIME are
>trademarks of RSA Data Security Inc.  All other product or brand names are
>trademarks or registered trademarks of their respective owners. SOURCE  RSA
>Data Security Inc. 

>Copyright 1997, PR Newswire   
>
>
>
>

Comments: Authenticated sender is <[email-masked]>
From: Nick Pope <[email-masked]>
To: Michel Ranger <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>, [email-masked]
Date: Tue, 24 Jun 1997 09:13:42 +0000
Subject: RE: Comparing email header fields with certificate contents...?
CC: [email-masked]
MMDF-Warning:  Parse error in original version of preceding line at relay-1.mail.demon.net
Sender: [email-masked]

I have not been watching this exchange closely, and so excuse me if 
this comment is out of place.

There is an extension field in X.509 which is explicetly put there to 
carry "alternative" name / address information such as Internet e-mail 
address: subjectAltName with rfc822Name in GeneralName.

This can marked as non-critical so that only those that are interested 
need take notice of the field.  Also, as this is protected within the 
certificate it can be "trusted".

Hope this helps.

Nick Pope

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

Security & Standards
Suite A
191 Moulsham St.
Chelmsford
Essex
CM2 0LG
U.K.

Tel: +44 1245 495018
Fax: +44 1245 494517

From: Michel Ranger <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Ron Craswell'" <[email-masked]>
Cc: "'Blake Ramsdell'" <[email-masked]>
Subject: RE: Comparing email header fields with certificate contents...?
Date: Mon, 23 Jun 1997 07:38:48 -0400
Sender: [email-masked]

>----------
>From: 	Ron Craswell[SMTP:[email-masked]]
>Sent: 	Friday, June 20, 1997 11:53 AM
>To: 	[email-masked]'
>Cc: 	Blake Ramsdell
>Subject: 	RE: Comparing email header fields with certificate contents...?
>
>This remark from Weston is from smime-dev:
>
>On Friday, June 20, 1997 8:05 AM, Nicolls, J. Weston
>[SMTP:[email-masked]] wrote:
>> 
>> A good secure email application should not make the recipient rely on an
>> untrusted email address or make comparing the cert alt-name to the given
>> email address a critical part of the cert path processing.  The app should
>> provide the DN of the validated user cert to the recipient (perhaps in the
>> same line/area as the From line) since that is what tells the recipient who
>> cryptographically sent the message.
>> 
>
>Which brings up a question I have with the following:
>
>"At a minimum, either the Distinguished Name used to identify an
>Internet mail entity MUST include an Internet mail address, or some
>other mechanism MUST be implemented in the user agent to provide for
>mapping Distinguished Names to Internet mail address."
>
>It seems apparent that this will generate a set of CAs that are creating
>certs without an internet-style EA attribute (under the assumption that
>the user agent will handle the mapping) and a set of user agents that
>will assume they don't have to handle the mapping (under the reverse
>assumption.)
>
>Shouldn't either one or the other case be mandated?  I'll vote for the
>UA mapping.
I vote for UA mapping as well.  Some CAs or companies may want to issue
certs that are not e-mail specific, where an e-mail address would not be
appropriate to enforce as mandatory.

>
>Ron Craswell
>Deming Internet Security
>
>

From: Ron Craswell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Blake Ramsdell <[email-masked]>
Subject: RE: Comparing email header fields with certificate contents...?
Date: Fri, 20 Jun 1997 08:53:14 -0700
Sender: [email-masked]

This remark from Weston is from smime-dev:

On Friday, June 20, 1997 8:05 AM, Nicolls, J. Weston
[SMTP:[email-masked]] wrote:
> 
> A good secure email application should not make the recipient rely on an
> untrusted email address or make comparing the cert alt-name to the given
> email address a critical part of the cert path processing.  The app should
> provide the DN of the validated user cert to the recipient (perhaps in the
> same line/area as the From line) since that is what tells the recipient who
> cryptographically sent the message.
> 

Which brings up a question I have with the following:

"At a minimum, either the Distinguished Name used to identify an
Internet mail entity MUST include an Internet mail address, or some
other mechanism MUST be implemented in the user agent to provide for
mapping Distinguished Names to Internet mail address."

It seems apparent that this will generate a set of CAs that are creating
certs without an internet-style EA attribute (under the assumption that
the user agent will handle the mapping) and a set of user agents that
will assume they don't have to handle the mapping (under the reverse
assumption.)

Shouldn't either one or the other case be mandated?  I'll vote for the
UA mapping.

Ron Craswell
Deming Internet Security

From: "Nicolls, J. Weston" <[email-masked]>
To: ietf-smime <[email-masked]>
Subject: Re: Hello, is anyone out there?
Date: Fri, 20 Jun 97 11:16:00 EDT
Sender: [email-masked]

>>--------------------------------------------------------------------------  
 ----
>>At 6:58 PM -0700 6/12/97, Charles Breed wrote:
>>>1. When will the next version of the S/MIME spec be posted?
>>>   (hopefully, clarifying the FOO@40-bit issue)
>>
>>Soon. We're still waiting to hear from the RFC editor and Internet Drafts
>>editors with the draft that will replace RC2.
>>
>>>2. Is there going to be a working-group formed before the Jeff Schiller
>>>   July 1st date?
>>
>>Highly unlikely. No one has expressed much interest in a charter.

There were not many comments but I think the interest is there.  It states 
what is needed simply and accurately.  Let's get going!

What is going on with RSA and the 2 issues.  Was there ever any discussions 
or give-and-take on RC2 as the minimum mandatory algorithm by RSA?  Is there 
real intention on making S/MIME a formal vs defacto standard?

Weston Nicolls
NSA

Date: Thu, 19 Jun 97 15:34:14 PDT
From: [email-masked] (Matt Bishop)
To: [email-masked]
Subject: CFP: Symposium on Network and Distributed System Security (Mar. 1998)
Sender: [email-masked]

CALL FOR PAPERS

The Internet Society Symposium on Network and Distributed System Security

Where: San Diego, California
When: March 1998

GOAL: The symposium will foster information exchange between hardware and
software developers of network and distributed system security services.
The intended audience is those who are interested in the practical aspects
of network and distributed system security, focusing on actual system
design and implementation, rather than theory.  Encouraging and enabling
the Internet community to apply, deploy, and advance the state of available
security technology is the major focus of symposium.  Symposium proceedings
will be published by the Internet Society.  Topics for the symposium
include, but are not limited to, the following:

* Architectures for large-scale, heterogeneous distributed systems
* Security in malleable systems: mobile code, mobile agents, dynamic policy
  updates, etc.
* Special problems: e.g. interplay between security goals and other goals --
  efficiency, reliability, interoperability, resource sharing, and cost.
* Integrating security services with system and application security
  facilities and with application protocols, including message handling,
  file transport, remote file access,  directories, time synchronization,
  data base management, routing, voice and video multicast, network
  management, boot services, and mobile computing.
* Fundamental services:  authentication, integrity, confidentiality,
  authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification
  infrastructures, audit, and intrusion detection.
* Telecommunications security, especially for emerging technologies -- very
  large systems like the Internet, high-speed systems like the gigabit 
  testbeds, wireless systems, and personal communication systems.
* Controls: firewalls, packet filters, application gateways
* Object security and security objects
* Network information resources and tools such as World Wide Web (WWW),
  Gopher, Archie, and WAIS.
* Electronic commerce:  payment services, fee-for-access, EDI, notary;
  endorsement, licensing, bonding, and other forms of assurance; intellectual 
  property protections

GENERAL CHAIR:
	David Balenson, Trusted Information Systems
PROGRAM CHAIRS:
	Matt Bishop, University of California at Davis
	Steve Kent, BBN
PROGRAM COMMITTEE:
	Steve Bellovin, AT&T Labs -- Research
	Doug Engert, Argonne National Laboratories
	Warwick Ford, VeriSign
	Li Gong, JavaSoft
	Rich Graveman, Bellcore
	Ari Juels, RSA Laboratories
	Tom Longstaff, CERT/CC
	Doug Maughan, National Security Agency
	Dan Nessett, 3Com Corporation
	Rich Parker, NATO
	Michael Roe, Cambridge University
	Rob Rosenthal, DARPA
	Wolfgang Schneider, GMD Darmstadt
	Christoph Schuba, Purdue University
	Win Treese, Open Market, Inc.
	Jonathan Trostle, Novell
	Gene Tsudik, USC/Information Sciences Institute
	Steve Welke, Institute for Defense Analyses
LOCAL ARRANGEMENTS CHAIR:
	Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
	Steve Welke, Institute for Defense Analyses
LOGISTICS CHAIR:
	Torryn Brazell, Internet Society

SUBMISSIONS: The committee invites technical papers and panel
proposals, for topics of technical and general interest.  Technical
papers should be 10-20 pages in length.  Panel proposals should be two
pages and should describe the topic, identify the panel chair, explain
the format of the panel, and list three to four potential panelists.
Technical papers will appear in the proceedings.  A description of each
panel will appear in the proceedings, and may at the discretion of the
panel chair, include written position statements from each panelist.

Each submission must contain a separate title page with the type of
submission (paper or panel), the title or topic, the names of the
author(s), organizational affiliation(s), telephone and FAX numbers,
postal addresses, Internet electronic mail addresses, and must list a
single point of contact if more than one author.  The names of authors,
affiliations, and other identifying information should appear only on
the separate title page.

Submissions must be received by 1 August 1997, and should be made via
electronic mail in either PostScript or ASCII format.  If the committee
is unable to print a PostScript submission, it will be returned and
hardcopy requested.  Therefore, PostScript submissions should arrive
well before 1 August.  If electronic submission is difficult,
submissions should be sent via postal mail.

All submissions and program related correspondence (only) should be
directed to the program chair:  Matt Bishop, Department of Computer
Science, University of California at Davis, Davis CA  95616-8562,
Email: [email-masked]. Phone: +1 (916) 752-8060,
FAX: +1 (916) 752-4767,

Dates, final call for papers, advance program, and registration
information will be available at the URL:
http://www.isoc.org/conferences/ndss98.

Each submission will be acknowledged by e-mail.  If acknowledgment is
not received within seven days, please contact the program chair as in-
dicated above.  Authors and panelists will be notified of acceptance by
1 October 1997.  Instructions for preparing camera-ready copy for the
proceedings will be sent at that time.  The camera-ready copy must be
received by 1 November 1997.

Date: Fri, 13 Jun 1997 11:18:00 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Hello, is anyone out there?
Sender: [email-masked]

> From [email-masked] Thu Jun 12 22:26:03 1997
> Date: Thu, 12 Jun 1997 19:18:27 -0700
> To: [email-masked]
> From: "Paul E. Hoffman" <[email-masked]>
> Subject: Re: Hello, is anyone out there?
> 
> At 6:58 PM -0700 6/12/97, Charles Breed wrote:
> >1. When will the next version of the S/MIME spec be posted?
> >   (hopefully, clarifying the FOO@40-bit issue)
> 
> Soon. We're still waiting to hear from the RFC editor and Internet Drafts
> editors with the draft that will replace RC2.
> 
> >2. Is there going to be a working-group formed before the Jeff Schiller
> >   July 1st date?
> 
> Highly unlikely. No one has expressed much interest in a charter.

That was a rhetorical wake-up call, right?  I thought there was much
interest expressed in Memphis for forming a working group *even if*

1) the name had to be changed because the trademark/change-control issue
    couldn't be resolved, and

2) the IETF spec wouldn't require backward interoperability because the
    RC2 IPR issue couldn't be resolved

>From Laurence's minutes:

   "Jeff (area director): S/MIME IPR issue must be resolved by July 1,
    1997 or working group cannot be formed

    Tim (RSA Inc.): RSA can work with that time frame

and

   (editor's summary: RSA must resolve two issues before a working group
   can begin work towards a standard.
   1) S/MIME must not rely on a trade secret (RC2),
   2) Change control must be with the IETF (e.g., the rights to the
    "S/MIME" trademark must be neutrally held.) These must be resolved by
    July 1, 1997.  The RSA representive acknowledged this)."

Has RSA made a statement yet resolving these two points?

Regardless of what that statement says/will say, there is interest in
forming a working group, and working around the name and/or algorithm
problems if necessary.  (I assume that it will be necessary to replace
RC2).

As for the charter itself, who could argue with the current one? :-)
Just slip all the dates by 6 months and it's good to go.

> >4. Are the two S/MIME specs going on the Informational (FYI) track?
> 
> We won't know that until we finish them. We're still hoping for standards
> track, of course, but a lot has to happen between here and there.

How can there be a standards track progression without a working group?
Technically it's possible according to the rules, but it hardly serves
the purpose of generating a document with buy-in from most of the
interested parties (rough consensus).

Date: Thu, 12 Jun 1997 19:18:27 -0700
To: [email-masked]
From: "Paul E. Hoffman" <[email-masked]>
Subject: Re: Hello, is anyone out there?
Sender: [email-masked]

At 6:58 PM -0700 6/12/97, Charles Breed wrote:
>1. When will the next version of the S/MIME spec be posted?
>   (hopefully, clarifying the FOO@40-bit issue)

Soon. We're still waiting to hear from the RFC editor and Internet Drafts
editors with the draft that will replace RC2.

>2. Is there going to be a working-group formed before the Jeff Schiller
>   July 1st date?

Highly unlikely. No one has expressed much interest in a charter.

>3. Is the S/MIME working-group going to meet in Munich (August)?

No, since it won't exist. :-) Further, as we made clear at the second
S/MIME BOF in Memphis, there can be no more BOFs (two's the max).

>4. Are the two S/MIME specs going on the Informational (FYI) track?

We won't know that until we finish them. We're still hoping for standards
track, of course, but a lot has to happen between here and there.

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

Date: Thu, 12 Jun 1997 18:58:18 -0700
To: [email-masked]
From: Charles Breed <[email-masked]>
Subject: Hello, is anyone out there?
Sender: [email-masked]

Can anyone answer...

1. When will the next version of the S/MIME spec be posted?
   (hopefully, clarifying the FOO@40-bit issue)

2. Is there going to be a working-group formed before the Jeff Schiller 
   July 1st date?

3. Is the S/MIME working-group going to meet in Munich (August)?

4. Are the two S/MIME specs going on the Informational (FYI) track?

Charles

Date: Fri, 6 Jun 1997 14:13:47 -0700
To: Cryptography List <[email-masked]>, [email-masked], Censor List <[email-masked]>, IETF PGP/MIME List <[email-masked]>, Linux-IPSEC List <[email-masked]>, [email-masked], Mac Crypto List <[email-masked]>, PGP Dev List <[email-masked]>, PGP Users <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Dave Del Torto <[email-masked]>
Subject: [ANNOUNCE] Phil Zimmermann on recent FUD and PGP 5.0 plans
Cc: Mike Nelson <[email-masked]>
Sender: [email-masked]

A message from our Fearless Leader...

   dave

................................. cut here .................................

-----BEGIN PGP SIGNED MESSAGE-----

Last month, Pretty Good Privacy Inc went through a  reorganization in
its top management.  We were spending too much money, too fast.  Tom
Steding was replaced by Phil Dunkelberger as the president of PGP, and
I handed over the chairman title to Jonathan Seybold, who had been, with
me, the original cofounder of the company.  Jonathan is devoting his time
to the business side of things, while I am focussing my attention on my
role as chief technology officer.

I have seen some speculation in some usenet newsgroups that these changes
were in some way connected with the fact that PGP was recently sued by RSA
Data Security over some dispute regarding royalties for use of the RSA
patent, which PGP holds a license to.  Let me set the record straight
on this.  There are sound business reasons why this shuffling of top
management occurred at PGP, and these reasons are known to all of our
employees.  The RSA lawsuit against PGP is absolutely not one of the
reasons, not even remotely.  I don't think shuffling top management is
a likely reaction for any company to take in response to a lawsuit, even
if the lawsuit had merit, which this one does not.  We fully expect the
RSA matter to be resolved in arbitration proceedings, in our favor.

I know that it is common practice for some companies to issue statements
to "spin" the story about certain events, sometimes at the expense of
truth.  This makes a lot of people understandably skeptical about such
explanations.  I do have responsibilities toward my company, but no
one could get me to deny a truth about the reasons for the restructuring.
The truth is, the restructuring had absolutely nothing at all to do with
the RSA lawsuit.

I would now like to announce that we will be releasing PGP 5.0 in mid-June.
It's in beta release right now on our web page (www.pgp.com).  In keeping
with my own dedication to personal freedom and privacy, we will be releasing
a freeware version for noncommercial use through MIT's web site
(web.mit.edu/pgp), just like in the old days before the company was formed.
And we do plan to publish the full PGP source code for Mac, Windows 95,
and Linux.

There are a lot of new exciting features, including automatic key lookups
from remote key servers on the Internet, which will likely result in the
rapid growth of a ready-made nationwide PGP public-key infrastructure,
on an unprecedented scale.  We are also encouraging the migration to new
public key algorithms in addition to RSA, namely the NIST Digital
Signature Standard (DSS), as well as Diffie-Hellman (Elgamal) keys.
We expect most of the new users to be using these new algorithms instead
of RSA, in part because they offer new features, better performance, and
better security for the same key sizes.  I hope that you will all join me
in this opportunity to move to these new algorithms, allowing everyone to
finally enjoy the use of public key cryptography without the encumberances
of patents.

Philip Zimmermann
Chief Technology Officer, PGP Inc.

Date: Wed, 4 Jun 1997 10:52:37 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: ASN.1 dump/diagnostic utility updated
Sender: [email-masked]

> From: [email-masked] (Peter Gutmann)
> To: [email-masked], [email-masked], [email-masked]
>  
> I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit 
> better, which means you can now display things like PKCS #7 objects and (in 
> general) anything else which mixes BER and DER-encoded data.  The program is 
> aware of most of the common crypto-related object identifiers and types, so 
> it'll give you a proper description of what it is you're looking at.  Here's 
> some sample output from the start of a cert:
>  
>    0 30  618: SEQUENCE {
>    4 30  467:   SEQUENCE {
>    8  2    4:     INTEGER 830525701
>   14 30   13:     SEQUENCE {
>   16  6    9:       OBJECT IDENTIFIER
>             :         md5withRSAEncryption (1 2 840 113549 1 1 4)
>   27  5    0:       NULL
>             :       }
>   29 30  125:     SEQUENCE {
>   31 31   11:       SET {
>   33 30    9:         SEQUENCE {
>   35  6    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
>   40 13    2:           PrintableString 'Ca'
>             :           }
>             :         }
>   [etc]

Peter,

Thanks for publicising the program, making it available on your
website, and including an acknowledgement of the original in a
comment.  I had made a few changes since the version I sent you, to
make the output a bit more readable, in addition to supporting BER
data.  The following is what the new output looks like, from a posting
to ietf-pkix on April 15:

 offs tag lenbytes length        value
 ---- -- --------- ---  ----------------------
 0000 30 80        859: SEQUENCE 
 0002 30 82 02 c0  704: . SEQUENCE 
 0006 a0 03          3: . . [0] 
 0008 02 01          1: . . . INTEGER 2
 0011 02 02          2: . . INTEGER 256
 0015 30 0d         13: . . SEQUENCE 
 0017 06 09          9: . . . OID 1.2.840.113549.1.1.2: md2WithRSAEncryption
 0028 05 00          0: . . . NULL 
 0030 30 68        104: . . SEQUENCE 
 0032 31 0b         11: . . . SET 
 0034 30 09          9: . . . . SEQUENCE 
 0036 06 03          3: . . . . . OID 2.5.4.6: C
 0041 13 02          2: . . . . . PrintableString  'ES'

   [etc]

If you agree that the expanded header bytes and the alignment dots
(instead of braces) help readability, you may wish to add them to your
version.  Of course, indentation style is all a matter of taste, so
some people may prefer the earlier format :-).

Regards,
    dpk

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: pkcs7-md5 and pkcs7-sha1 micalg values 
Date: Mon, 02 Jun 1997 17:37:53 -0600
Sender: [email-masked]

The point that I was making for future micalgs about having the pkcs7-
prefix was to make sure that if PKCS #7 was still the underlying message
format, then any future digest algorithms would use the pkcs7- prefix to
make sure they kept the association with the protocol.

Oh.  *that's* fine with me.  I just don't want to constrain S/MIME
to always use pkcs7 if something else turns out to be better.

Keith

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: ASN.1 dump/diagnostic utility updated
Reply-To: [email-masked]
Date: Tue, 3 Jun 1997 11:22:48 (NZST)
Sender: [email-masked]

[I've had quite a few requests for this so I'm sending this annoucement to the 
 three most appropriate lists, apologies if you see it more than once]
 
I've just updated my ASN.1 dump/diagnostic utility to handle the BER a bit 
better, which means you can now display things like PKCS #7 objects and (in 
general) anything else which mixes BER and DER-encoded data.  The program is 
aware of most of the common crypto-related object identifiers and types, so 
it'll give you a proper description of what it is you're looking at.  Here's 
some sample output from the start of a cert:
 
   0 30  618: SEQUENCE {
   4 30  467:   SEQUENCE {
   8  2    4:     INTEGER 830525701
  14 30   13:     SEQUENCE {
  16  6    9:       OBJECT IDENTIFIER
            :         md5withRSAEncryption (1 2 840 113549 1 1 4)
  27  5    0:       NULL
            :       }
  29 30  125:     SEQUENCE {
  31 31   11:       SET {
  33 30    9:         SEQUENCE {
  35  6    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
  40 13    2:           PrintableString 'Ca'
            :           }
            :         }
  [etc]
 
Hopefully the program will prove useful for picking apart certs and data 
objects for debugging and diagnostic purposes, especially now that it handles 
BER data properly.  You can get it from 
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c.
 
Peter.

From: Blake Ramsdell <[email-masked]>
To: "'Keith Moore'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: pkcs7-md5 and pkcs7-sha1 micalg values 
Date: Mon, 2 Jun 1997 15:40:26 -0700
Sender: [email-masked]

On Monday, June 02, 1997 3:05 PM, Keith Moore [SMTP:[email-masked]]
wrote:
> I can see using a "pkcs7-" prefix for anything that uses pkcs7, and
> I understand that micalgs have sometimes been specific to a particular
> protocol.  But I can't see any reason to require that all future 
> S/MIME micalgs use pkcs7.  
> 
> It would seem far more desirable to move toward protocol-independent 
> micalgs, so that a message can be signed with a single micalg
> but using more than one signature protocol.  If I could sign the
> same message with both PGP and S/MIME, then a lot more people could
> verify that I signed it!

Oh, man, get over to IETF-PGP-MIME as soon as you can and check out the
messages about this.  This exact discussion has been progressing with
input from both Ned Freed and Jim Galvin.  The separation between the
definition of micalg and protocol is being discussed, as well as the use
of multiple values for each of those parameters.

The point has come up that supplying multiple values for the micalg and
protocol parameters could be a useful construct, and that in the event
multiple signatures from different protocols are desired, that the
second part of multipart/signed could contain all of those signatures
(my suggestion was to use multipart/alternative to further enforce the
semantics that they are equivalent signatures using different
protocols.)

For instance (the example I used from there):

Content-Type:
multipart/signed;micalg="rsa-md5;pgp-md5;pkcs7-md5";protocol="applicatio
n/moss-signature;application/pgp-signature;application/x-pkcs7-signature
";boundary="a"

-a
< first part of multipart/signed goes here>

-a
Content-Type: multipart/alternative;boundary="b"

-b
Content-Type: application/moss-signature

<MOSS signature goes here>
-b
Content-Type: application/pgp-signature

<PGP signature goes here>
-b
Content-Type: application/x-pkcs7-signature

<S/MIME signature goes here>
-b-
-a-

With the same disclaimer I used over there -- the MIME might be broken,
but the concept still remains.

The point that I was making for future micalgs about having the pkcs7-
prefix was to make sure that if PKCS #7 was still the underlying message
format, then any future digest algorithms would use the pkcs7- prefix to
make sure they kept the association with the protocol.  Certainly if
there is an evolutionary turn that causes PKCS #7 *not* to be underneath
it all, then the pkcs7- would be nothing more than nostalgic...

Blake

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "'Keith Moore'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: pkcs7-md5 and pkcs7-sha1 micalg values 
Date: Mon, 02 Jun 1997 16:05:29 -0600
Sender: [email-masked]

I can see using a "pkcs7-" prefix for anything that uses pkcs7, and
I understand that micalgs have sometimes been specific to a particular
protocol.  But I can't see any reason to require that all future 
S/MIME micalgs use pkcs7.  

It would seem far more desirable to move toward protocol-independent 
micalgs, so that a message can be signed with a single micalg
but using more than one signature protocol.  If I could sign the
same message with both PGP and S/MIME, then a lot more people could
verify that I signed it!

Keith

From: Blake Ramsdell <[email-masked]>
To: "'Keith Moore'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: pkcs7-md5 and pkcs7-sha1 micalg values 
Date: Mon, 2 Jun 1997 14:56:52 -0700
Sender: [email-masked]

On Monday, June 02, 1997 2:46 PM, Keith Moore [SMTP:[email-masked]]
wrote:
> > I propose that the micalg parameter for multipart/signed messages with
> > the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and
> > pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively.  I
> > further propose that any future digest algorithms that are supported for
> > S/MIME keep the "pkcs7-" prefix.
> 
> Why?  What technical purpose would be served by doing this?

Good point, and I just found out the answer myself.  I have been keeping
track of some of the other mailing lists, and this issue is being
debated this very moment on IETF-PGP-MIME at the IMC.  Ned Freed
summarized it this way (my apologies if the citation out of context is
inappropriate -- the whole message is on IETF-PGP-MIME):

Ned Freed said:
>
> I note in passing that there is some confusion about the interpretation of
> micalgs. The answer to this is simple: Micalgs names are pure names. You
cannot
> assume anything from the name unless you recognize it in its entirety; it is
> quite possible for a micalg name to include the string "md5" yet not use the
> MD5 hash, and it is also possible for a micalg to not include the string
"md5"
> yet use MD5. The fact that micalg names appear to be composite is simply an
> artefact of our attempts to make them humand-readable; it is nothing a
machine
> should rly on.

This statement by Ned is reinforced by PGP-MIME's use of "pgp-md5" (as
opposed to the "rsa-md5" of MOSS and currently used by S/MIME) which
seems to indicate that the identifiers are typically protocol-dependent,
and identify not just the hashing algorithm, but the semantics of its
use (that is, the data that is hashed, along with any optional
parameters that might be supplied to the hashing algorithm).

Blake

From: Keith Moore <[email-masked]>
To: Blake Ramsdell <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: pkcs7-md5 and pkcs7-sha1 micalg values 
Date: Mon, 02 Jun 1997 17:45:56 -0400
Sender: [email-masked]

> I propose that the micalg parameter for multipart/signed messages with
> the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and
> pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively.  I
> further propose that any future digest algorithms that are supported for
> S/MIME keep the "pkcs7-" prefix.

Why?  What technical purpose would be served by doing this?

Keith

From: Blake Ramsdell <[email-masked]>
To: "'Charles Breed'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Alternative public key and signature algorithms (was RE: pkcs7-md5 and pkcs7-sha1 micalg values)
Date: Mon, 2 Jun 1997 13:44:59 -0700
Sender: [email-masked]

On Monday, June 02, 1997 10:29 AM, Charles Breed [SMTP:[email-masked]]
wrote:
> Keeping future S/MIME digest algorithms with the "pkcs7-" prefix is fine,
but
> will PKCS #7 undergo any changes to allow for additional... 
> 
> 1. Public-Key algorithms, (elliptic curve, DSA-ElGamal,...) or will S/MIME
be
> RSA (asymmetric) forever?

Both of these can definitely be defined in an alternative
interoperability profile (as an informational RFC, perhaps).  I'm not
sure they fit into the base interoperability profile, since the goal of
that is to provide the minimum required for interoperability.

Blake

Date: Mon, 02 Jun 1997 10:28:30 -0700
To: Blake Ramsdell <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Charles Breed <[email-masked]>
Subject: Re: pkcs7-md5 and pkcs7-sha1 micalg values
Sender: [email-masked]

After reviewing the draft informational rfc for PKCS #7 at http://www.imc.org/draft-hoffman-pkcs-crypt-msg, I believe...

Keeping future S/MIME digest algorithms with the "pkcs7-" prefix is fine, but
will PKCS #7 undergo any changes to allow for additional... 

1. Public-Key algorithms, (elliptic curve, DSA-ElGamal,...) or will S/MIME be RSA (asymmetric) forever?

2. ContentEncryptionAlgorithmIdentifier ::=  "for EP2 / as well as RC2"

cb

At 11:09 PM 6/1/97 -0700, Blake Ramsdell wrote:
>I propose that the micalg parameter for multipart/signed messages with
>the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and
>pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively.  I
>further propose that any future digest algorithms that are supported for
>S/MIME keep the "pkcs7-" prefix.
>
>Comments?
>
>Blake
>
>

From: Blake Ramsdell <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: pkcs7-md5 and pkcs7-sha1 micalg values
Date: Sun, 1 Jun 1997 23:09:56 -0700
Sender: [email-masked]

I propose that the micalg parameter for multipart/signed messages with
the "application/pkcs7-signature" protocol be defined as pkcs7-md5 and
pkcs7-sha1 for the MD5 and SHA-1 digest algorithms respectively.  I
further propose that any future digest algorithms that are supported for
S/MIME keep the "pkcs7-" prefix.

Comments?

Blake