Subject: openpgp.net domain

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 27 Dec 1998 20:25:47 -0500

Hi,

You may or may not be aware that a while back I obtained the Openpgp.net
domain. I am currently talking with the ISP that is hosting my domain in
setting up shell accounts under the openpgp.net domain.

If this is something that you think you would be interested in e-mail me
off list. If there is enough interest I will move ahead on this and get it
set up.

I can also set up a limited number of mail aliases under this domain using
procmail. If you are interested in an openpgp.net e-mail address let me
know and I can set one up.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Sun, 27 Dec 1998 20:25:47 -0500
To: [email-masked]
Subject: openpgp.net domain
Sender: [email-masked]

Hi,

You may or may not be aware that a while back I obtained the Openpgp.net
domain. I am currently talking with the ISP that is hosting my domain in
setting up shell accounts under the openpgp.net domain.

If this is something that you think you would be interested in e-mail me
off list. If there is enough interest I will move ahead on this and get it
set up.

I can also set up a limited number of mail aliases under this domain using
procmail. If you are interested in an openpgp.net e-mail address let me
know and I can set one up.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

Date: Fri, 25 Dec 1998 14:12:37 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: OpenPGP testing at SecureConnect 2?
Sender: [email-masked]

Greetings again. IMC is planning SecureConnect 2 for February 23 and 24, in
San Jose. I would love it if some OpenPGP vendors were there to test
interoperability of OpenPGP, but it is up to the implementors. Please take
a look at <http://www.imc.org/imc-secureconnect/> and let me know if your
company might want to do interoperability testing. I think that we would
need at least three OpenPGP vendors to make it interesting, but welcome you
even if there are only two (one would not be interesting at all, of
course). The event would be a good place for us to start verifying all the
pieces needed to move RFC 2440 to draft standard as well.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 23 Dec 1998 18:23:40 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Twofish
Mail-Followup-To: [email-masked]
Sender: [email-masked]

uri <[email-masked]> writes:

> I suggest *replacing* Blowfish with Twofish. If you trust one, why not
> the other?

I aggree, but we have to keep the algorithm id for Blowfish because
there are documents which are encoded with Blowfish.  However, we
should state that Blowfish is one of depreciated algorithms.

  Werner

From: "Gawlick, Thomas" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: First call for papers
Date: Wed, 23 Dec 1998 16:14:43 +0100
Sender: [email-masked]

Hi everyone !

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

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

	secunet                             	
	Security Networks GmbH 
	CQRE - Team 

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

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

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

We are looking for papers and panel discussions covering:

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

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

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

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

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

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

PROGRAM CHAIR: 
--------------------------------------
Rainer Baumgart 
secunet Security Networks GmbH
Weidenauer Str. 223 - 225 
57076 Siegen Germany 
Tel.: +49-271-48950-15 
Fax: +49-271-48950-50 
[email-masked]

From: uri <[email-masked]>
Subject: Re: Twofish
To: [email-masked] (Lutz Donnerhacke)
Date: Wed, 23 Dec 1998 09:32:22 -0500 (EST)
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

Lutz Donnerhacke says:
> >So what about 10 (or replace 6) for Twofish with 128 bit key; it may
> >also be a good idea not to specify the used keysize at all.
> 
> Please wait a bit.

I suggest *replacing* Blowfish with Twofish. If you trust one, why not
the other?
-- 
Regards,
Uri		[email-masked]
-=-=-=-=-=-=-
<Disclaimer>

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Twofish
Date: 23 Dec 1998 10:49:01 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Werner Koch wrote:
>So what about 10 (or replace 6) for Twofish with 128 bit key; it may
>also be a good idea not to specify the used keysize at all.

Please wait a bit.

Date: Wed, 23 Dec 1998 10:48:26 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Twofish
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

because Twofish is one of most promising candidates for AES, I'd like
to have an OpenPGP algorithm identifier.  This enables us to put
Twofish into the preferences of newly created keys - with the
advantage that a user has no need to edit her preferences when we
actually have a Twofish implementation.

Current assignment is:

       0          - Plaintext or unencrypted data        
       1          - IDEA [IDEA]                     
       2          - Triple-DES (DES-EDE, as per spec -           
                    168 bit key derived from 192)                     
       3          - CAST5 (128 bit key, as per RFC 2144)
       4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
       5          - SAFER-SK128 (13 rounds) [SAFER]
       6          - Reserved for DES/SK
       7          - Reserved for AES with 128-bit key
       8          - Reserved for AES with 192-bit key
       9          - Reserved for AES with 256-bit key  

So what about 10 (or replace 6) for Twofish with 128 bit key; it may
also be a good idea not to specify the used keysize at all.

I further suggested to add a way to specifiy the keysize; this can
be done without much hassle in the encoded session key or calculated
from the length of the symmetrically encrypted data packet.

We should use a new packet version number for this and also add a 
way to specifiy whether and how the encrypted data is MACed.

  Werner

From: "[email-masked]" <[email-masked]>
Reply-To: [email-masked]
Subject:  (3688)
Date: Sun, 20 Dec 1998 12:02:11 -0400 (EDT)
Sender: [email-masked]

Everyone has the ability to receive a Fully Loaded 350 MHz MMX Computer Fully Loaded For FREE !!! And  $3,000 Referral Fee For everyone you share this with. 
(see  specs below for computer).

FOR THE RECORD  MAKE NO MISTAKE 
THIS IS NOT MULTI-LEVEL MARKETING.
WE ARE STRICTLY A REFERRAL-BASED COMPANY.

                   $3000 Referral Program/ROMA 3K

Incredible Concept!!! Incredible Opportunity!!! The ROMA "5 for 3"
incentive system is the most exciting, revolutionary business program
ever conceived. WE ARE NOT MLM. We are a referral-based company.
To put this in layman's terms  very simply, you personally refer 5
people who want a computer and you earn $3,000 for each and every FIVE (5)
closings. You are also eligible to earn your very own, fully paid-for
350 MHz Computer. Computers are delivered within 2 weeks. In other words, the
potential is totally INCREDIBLE!!!  5 = $3000  10 = $6,000 , 20 = $12,000  
30 = $18,000  and so on  FOREVER!!! AND ADDITIONAL  BONUSES EVERY SINGLE MONTH!!! It's that EASY.

Do you see the picture yet? You promote and generate interested people. Through internet promotion or any other way you wish to promote and the money will come your way  !!!

Everytime someone responds to your promotion, you very SIMPLY AND EASILY refer them to the company. All you need to do is direct them to our customer service representatives with your ID number, and staff takes over and does the rest. (You own personal ID number will be assigned to you upon joining). For the record, we have been delivering computers on a daily basis. AND, WE DO DELIVER WITHIN 2  WEEKS!!! Not 4, 6, 8, 10 or more weeks. Upon computer being delivered to your personal referrals, YOU GET PAID!!!  We have our OWN IN-HOUSE LEASING COMPANY. Which means, we do not have to depend on ANYONE ELSE. So if you are SERIOUSLY INTERESTED in hearing more about this incredible opportunity, we highly encourage you to call our toll-free 800 number right away – TODAY!!! DO NOT WAIT!!!

The Computer Package Consists of:
350 MHz Complete Desktop System
-AMD K6-2 350 MHz MMX Processor w/3D
-Ball Bearing Cooling Fan
-ATX ADP Motherboard w/512k L2 cache
-32 MB SD-RAM
-4.3 GB Hard Drive
-1.44 MB Floppy Drive
-32X CD ROM /3D Stereo Sound
-Amplified Speakers/Headphones/Microphone
-4 MB AGP Video Accelerator
-Rockwell Wavetable Sound Card
-Mini Tower Case
-56K v.90 Internal Fax/Modem
-2 Fast Serial/Parallel/Game ports
-Enhanced 104-Key Keyboard/Mouse
                                  PLUS:
                         15" SVGA Color Monitor
                       NEC Color Desk Jet Printer
                  MUS Twain Full Color Flatbed Scanner
                              Windows ' 98
    Lotus Suite-includes Lotus Notes, Lotus Spreadsheet and much more
                            Norton Anti-Virus
                       Quicken accounting software
        Cyberscape- 10 CD Portfolio and Reference w/Encyclopedia
                      DragonFax included with modem
  6 Months of unlimited Online Training: 25+ software titles to choose
                                  from
            3 Years Parts & Labor Warranty (1st Year In Home)
                     Ability to Process Credit Cards
                         Full-Service Help Desk

SO , IF YOU WANT THE ABILITY TO EARN ALL THE ABOVE AND/OR THE $3,000 FOR EVERY 5 REFERRALS, WE HIGHLY ENCOURAGE YOU TO CALL TODAY FOR FURTHER INFORMATION !!!

For further information please call : (800) 600-0343, ext. 2158
( 7days a week/24 hours a day)
(we have literally been overwhelmed with incoming calls, so if you
experience a busy signal, please try again)

THE POWER OF THE PLAN IS SIMPLICITY - "5 FOR 3" =  $3000 !!!!!!!
OVER AND OVER AND OVER AGAIN !!! IT'S ALL UP TO YOU. THE QUESTION IS HOW BAD DO YOU REALLY WANT TO MAKE $$$$$$

GIVE US A TRY AND SEE THE PHENOMINAL RESULTS!!!! 

70% of Americans still do not own a Computer and 80% of Americans are NOT yet on the INTERNET!!! WE ALSO SUPPLY WESITES TO OUR MEMBERS  AND ALSO THE ABILITY TO PROCESS CREDIT CARDS!!!!!!

SO DON'T WAIT ANOTHER DAY AND CLIMB ABOARD AND START REFERRING AND BEFORE YOU KNOW IT YOU'LL BE ON YOUR WAY TO $3000, $6000, $9000...AS MUCH MONEY AS YOU WANT TO MAKE SO CLIMB ABOARD AND GET STARTED. 

CALL TODAY!    1-800-600-0343    ext.    2158

91994

Date: Fri, 11 Dec 1998 15:37:25 -0800
To: Thomas Roessler <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: The Great Silence?
Cc: [email-masked]
Sender: [email-masked]

I'll publish minutes shortly.

At 10:58 PM 12/11/98 +0100, you wrote:
>Since Dec 7, we have some great silence on this mailing list.  Could
>someone who attended summarize the results of the Orlando meeting?
>
>tlr
>-- 
>Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
>     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

Date: Fri, 11 Dec 1998 22:58:12 +0100
From: Thomas Roessler <[email-masked]>
To: OpenPGP mailing list <[email-masked]>
Subject: The Great Silence?
Sender: [email-masked]

Since Dec 7, we have some great silence on this mailing list.  Could
someone who attended summarize the results of the Orlando meeting?

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

To: [email-masked]
Subject:  Unrecognized Market Potential
DATE: Sun, 06 Dec 1998 02:17:34 -0500
From: [email-masked]
Sender: [email-masked]

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

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

AIME creates Portals for large affinity groups.  

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

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

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

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

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

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

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

From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: open-pgp / s/mime interoperability
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Date: Fri, 4 Dec 1998 02:35:37 (NZDT)
Sender: [email-masked]

Adam Back <[email-masked]> writes:
>Peter Gutmann writes:
>>>open-pgp public keys aren't based on X.509 keys, so I would've thought
>>>s/mime implementation would barf on them.  
>> 
>>Actually S/MIME *could* support the use of PGP keys, but there's a field
>>(the SubjectKeyIdentifier) missing from the CMS SignerInfo which prevents
>>this.  
 
>Surely this in itself should be a compelling argument for inclusion of the 
>SubjectKeyIdentifier?  
 
I'm trying to get this adopted for CMS, the underlying data format for 
S/MIME.  The silly thing about this is that alternative key identifiers (like 
PGP keys) were going to be included in RSADSI's PKCS7v2, but aren't included 
in the IETF version of the same thing.  The result is that you have a private 
company going out of its way to accomodate open standards, and the IETF going 
out of its way to lock them out.  Weird.
 
>If it allows conversion of PGP keys into S/MIME X.509 keys.
 
You don't need this conversion, with key identifiers you can use both SPKI and 
PGP keys directly within S/MIME.  There's no need to convert them into an 
X.509-like format first.
 
Peter.

Date: Thu, 3 Dec 1998 12:39:44 GMT
From: Adam Back <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: open-pgp / s/mime interoperability
Sender: [email-masked]

Peter Gutmann writes:
> >open-pgp public keys aren't based on X.509 keys, so I would've thought
> >s/mime implementation would barf on them.  
> 
> Actually S/MIME *could* support the use of PGP keys, but there's a field
> (the SubjectKeyIdentifier) missing from the CMS SignerInfo which prevents
> this.  

Surely this in itself should be a compelling argument for inclusion of
the SubjectKeyIdentifier?  If it allows conversion of PGP keys into
S/MIME X.509 keys.

On the subject of whether one could get a PGP key to convert into an
X.509 key such that it would function in the X.509 / S/MIME world, I'm
not sure that much can be transferred into the S/MIME world.

I think the public key parameters (actual bigints will transfer.  I am
less confident about certification transferring (third party
signatures and self signatures on public keys).  The reason I am
unsure about this is that what is signed is not codified in ASN.1 in
such a way that it would be ignored as an extension, but still hashed
by an S/MIME implementation to obtain the same hash.  Or perhaps more
that it would cause an S/MIME implementation to complain of a
corrupted certificate, even though the contents could theoretically be
hashed to get the same hash for signature verification.

Or, more specifically, how could a PGP certificate (self signed, or
signed by someone in your web of trust) be transferred into X.509 such
that the message digest of the signed information would be the same.

Where a PGP certificate includes

0       1       CTB for secret-key-encrypted (signed) packet
1       2       16-bit (or maybe 8-bit) length of packet
3       1       Version byte, may affect rest of fields that follow.
                (=2) for PGP versions <= 2.5
                (=3) for PGP versions >= 2.6
4       1       Length of following material that is implicitly included 
                in MD calculation (=5).
5       1       Signature classification field (see below). 
                Implicitly append this to message for MD calculation.
6       4       32-bit timestamp of when signature was made.  
                Implicitly append this to message for MD calculation.
10      8       64-bit Key ID
18      1       Algorithm byte for public key scheme (RSA=0x01).  
                --Algorithm byte affects field definitions that follow.
19      1       Algorithm byte for message digest (MD5=0x01).
20      2       First 2 bytes of the Message Digest inside the 
                RSA-encrypted integer, to help us figure out if we 
                used the right RSA key to check the signature.

All of these fields are non meaningful for an ASN.1 parser.

Adam

To: [email-masked]
Subject: Re: OpenPGP agenda for Dec 7
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Thu, 03 Dec 1998 14:54:00 +0900
Lines: 27
Sender: [email-masked]

From: "William H. Geiger III" <[email-masked]>
Subject: Re: OpenPGP agenda for Dec 7
Date: Wed, 02 Dec 1998 12:29:45 -0500

> As you can see we no longer have the black and white scenario of
> pass/fail on signature verification. I am not sure if we can really
> codify how to handle partial failure of parallel signatures in the
> ID and it may be best to leave this up to the application.

Please don't jump to a conclusion. :-)

Many people discussed in many places many times. Some thought the same
as you. Some enumerated and categorized semantics. If time allows, I'd
suggest read the archives of pem-dev ml and ietf-pgp-mime ml. 

As you said, there is no spec to define the syntax of multiple
signature. One spec (without semantics definition) is better than
nothing.

It is fine to me that you will define syntax only, and leave semantics
to applications. I like such slow start since we should not repeat the
same history.

I'd suggest that your ID should keep the door open for future
definitions of semantics.

--Kazu

Date: Wed, 2 Dec 1998 17:32:34 -0800
To: [email-masked]
From: "John  W. Noerenberg" <[email-masked]>
Subject: OpenPGP Agenda
Cc: OpenPGP mailing list <[email-masked]>
Sender: [email-masked]

LDAP & PGP - Roland Hedberg
Discussion concerning how to store PGP keys in LDAP directories.  Do 
we expand the charter to include this?

PGP/MIME  - Kazu Yamamoto
Discussion concerning how to update RFC2015.

RFC2440 - Jon Callas, Tony Mione, John Noerenberg
Review of RFC2440, Tony Mione's and Phil Zimmerman's lists. 
Discussion about advancing it to DRAFT Standard.

john noerenberg
[email-masked]
  ----------------------------------------------------------------------
  no matter what a waste one has made of one's life, it is ever
  possible to find some path to redemption
  -- Charles Frazier, "Cold Mountain", Vintage Books, 1997
  ----------------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 02 Dec 1998 16:14:47 -0500
To: Thomas Roessler <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP agenda for Dec 7
Sender: [email-masked]

In <[email-masked]>, on 12/02/98 
   at 09:29 PM, Thomas Roessler <[email-masked]> said:

>On Wed, Dec 02, 1998 at 12:29:45PM -0500, William H. Geiger III wrote:

>> Well this is going to depend on how the signatures are being used.

>precisely.  This means that it is useless to define specific semantics in
>a format description since user agents following the trivial variant of
>displaying _all_ signature integrity information to the user behave
>optimally.

Well curently there is no format at all for creating parallel signatures. This should be documented in the ID. What the users do with those parallel signatures is another matter that should be left to the application and is outside the scope of an ID.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

Date: Wed, 2 Dec 1998 21:29:41 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP agenda for Dec 7
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Dec 02, 1998 at 12:29:45PM -0500, William H. Geiger III wrote:

> Well this is going to depend on how the signatures are being used.

precisely.  This means that it is useless to define specific
semantics in a format description since user agents following the
trivial variant of displaying _all_ signature integrity information
to the user behave optimally.

tlr
-- 
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
     2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 02 Dec 1998 12:29:45 -0500
To: Kazu.Yamamoto ($B;3K\OBI'(B) <[email-masked]>)
Cc: [email-masked]
Subject: Re: OpenPGP agenda for Dec 7
Sender: [email-masked]

In <[email-masked]>, on 12/02/98 
   at 10:07 PM, Kazu Yamamoto ($B;3K\OBI'(B) <[email-masked]> said:

>My experience says that the most difficult point is how to define
>semantics of multiple signatures. (e.g. if verification of the first
>signature succeeds and that of the second fails, how can we treat
>this?)

Well this is going to depend on how the signatures are being used.

Example #1

We have a contract that 3 people need to sign off on. For the contract to be valid all three signatures must be valid.

Example #2 **

We have a memo that is being circulated through the office. After each person reads it they must sign off on it verifying that the memo has been read. In this case a failure of one signature is a minor issue and can be resolved by generating a new signature.

Example #3

A message posted to a public forum is signed with both the authors RSA key and his DSA key to resolve compatibility issues between the various versions. The validity of the message will depend on the capabilities of the verifiers software (if one of the 2 signatures fail).

As you can see we no longer have the black and white scenario of pass/fail on signature verification. I am not sure if we can really codify how to handle partial failure of parallel signatures in the ID and it may be best to leave this up to the application.

It should be noted that when I am discussing multiple signatures I am talking about parallel signatures where all signatures are for the same block of data (as opposed to encapsulated signatures where a signed document is then signed a second time with the hash calculated over the data and first signature).

I will look over the 2 documents mentioned and get back to you on this.

** The inter-office memo becomes real interesting when you have the readers who want to sign off on the memo but also add comments but still be left with a single document in the end.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

To: [email-masked]
Subject: Re: OpenPGP agenda for Dec 7
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Wed, 02 Dec 1998 22:07:52 +0900
Lines: 39
Sender: [email-masked]

From: "William H. Geiger III" <[email-masked]>
Subject: Re: OpenPGP agenda for Dec 7
Date: Tue, 01 Dec 1998 15:21:38 -0500

> Just reading through the ID here and I would really like to see the
> functionality of multiple signatures added. There are several
> scenarios where multiple signatures per data object would be useful
> and it would be helpful to have this outlined so there is
> compatibility between the openpgp apps in processing such messages.
>
> I can write something up on it after I have gone through the
> complete ID.

OK. Let me give you historical information on such efforts.

I wrote a multi-signature extension for PGP/MIME and submitted to
IETF. Since it has been expired, I put it on web.

	http://pgp.iijlab.net/draft-kazu-pgpmime-multisig-00.txt

Then, when the ietf-pgp-mime ml was active, Dave Del Torto worte a
revision of RFC 2015, called P/MIME. This draft was not submitted to
IETF but sent the ML only. I also put this draft on web (I'm very
sorry if this is agaist Dave's intentional.)

	http://pgp.iijlab.net/pmime

Both approaches are based on multipart/*. I would ask William to
compare both the multipart/* approach and the PGP packet approach.
(e.g. the multipart/* approach can handle both PGP/MIME and S/MIME
signature at one but the latter can't.)

My experience says that the most difficult point is how to define
semantics of multiple signatures. (e.g. if verification of the first
signature succeeds and that of the second fails, how can we treat
this?)

--Kazu

From: [email-masked]
Date: Wed, 02 Dec 98 04:25:08 EST
To: [email-masked]
Subject: x04-004 toner
Sender: [email-masked]

BENCHMARK PRINT SUPPLY
1091 REDSTONE LANE
ATLANTA GA 30338

CALL---->       770-399-0953   FOR TONER SUPPLIES ORDERS/PRICING ONLY  

CALL---->       770-399-5505   CUSTOMER SERVICE/SUPPORT ISSUES 
                 
CALL---->       770-399-5614    E-MAIL REMOVAL COMPLAINTS LINE

OUR  LASER PRINTER/FAX/COPIER TONER CARTRIDGE PRICES
NOW AS LOW AS $39 & UP. SPECIALS WEEKLY ON ALL LASER PRINTER
SUPPLIES. WE CARRY MOST ALL LASER PRINTER CARTRIDGES, FAX SUPPLIES
AND COPIER TONERS AT WAREHOUSE PRICES INCLUDING:

HEWLETT PACKARD SERIES 2/3/4/2P/4P/5P/4L/5L/3SI/4SI/5SI
IBM/LEXMARK OPTRA SERIES 4019/4029/4039/4049/4059
EPSON SERIES 2/1100/1500/6000/7000/8000
NEC SERIES 90/95
CANON COPIER PC SERIES INCLUDING 3/6RE/7/11/320/720/10/20/25 ETC...
HP FAX SERIES 700/720/5000/7000/FX1/FX2/FX3/FX4/FX5
CANON FAX ALL MODELS  
PRICES CHANGE WEEKLY PLEASE CALL TO GET THE MOST
RECENT PRICING/AVAILABILTY AND SPECIALS OF THE WEEK!!!!

PLEASE PLEASE PLEASE  MAKE NOTE OF THE FOLLOWING BEFORE YOU CALL:

-----> WE DO NOT HAVE CATALOGS OR PRICE LISTS BECAUSE OUR PRICES CHANGE WEEKLY!!
-----> WE DO NOT FAX QUOTES OR PRICES BECAUSE OUR ORDER LINE IS NOT SET UP  TO DO THAT
-----> WE DO NOT SELL  TO  RESELLERS OR BUY FROM DISTRIBUTERS
-----> WE DO NOT CARRY : BROTHER -MINOLTA-KYOSERA- PANASONIC - XEROX - FUJITSU - OKIDATA - SHARP!!
-----> WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES!!!!!    
-----> WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES!!!!                    

NEW,NEW,NEW $10 MAIL IN REBATE ON SELECTED  CARTRIDGES
SIMPLY ORDER YOUR NEW CARTRIDGE, WHEN IT ARRIVES MAIL BACK                        
YOUR REBATE CERTIFICATE WITH ANY USED CARTRIDGE FOR INSTANT CREDIT

WE ACCEPT ALL MAJOR CREDIT CARDS OR COD ORDERS
CORPORATE ACCOUNTS AVAILABLE WITH APPROVED CREDIT
ALL PACKAGES SHIPPED UPS GROUND UNLESS SPECIFIED OTHERWISE

Date: Tue, 1 Dec 1998 17:15:18 -0800
From: Michael Elkins <[email-masked]>
To: [email-masked]
Subject: Re: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
Sender: [email-masked]

On Tue, Dec 01, 1998 at 09:55:34AM -0800, Thomas Roessler wrote:
> Kazu Yamamoto wrote:
> >>    Additionally, one should note that a PGP/MIME document doesn't
> >>   need to define any semantics which are a consequence of other
> >>   MIME documents or of the OpenPGP spec.
> 
> > Why don't you claim that the OpenPGP RFC shouldn't talk about
> > PGP/MIME?
> 
> Because it doesn't do so (beyond referencing RFC 2015)?

If you are planning on doing a complete rewrite of RFC2015, it doesn't make
sense to reference it.  The new document should be self contained in order
to avoid confusion.

> >>   The PGP/MIME document should note that there is a canonical
> >>   one-to-one mapping from OpenPGP hash algorithm identifiers to
> >>   PGP/MIME micalg parameters. This mapping should be desribed;
> >>   additionally, the currently defined micalg parameters should be
> >>   listed.  Doing so will avoid revising the PGP/MIME document every
> >>   time a new OpenPGP hash algorithm identifier is defined.
> 
> > In my conceptual model, how the MIME composer know what kind of hash
> > algorithm is actually used?
> 
> It asks the OpenPGP composer about it?  Come on, Kazu, this is
> trivial.
> 
> > And my proposal avoids revising the PGP/MIME document every time a
> > new OpenPGP hash algorithm identifier is defined.
> 
> Yes, by not using it.  Describing the mapping seems to be more
> useful to me.

I agree.  It MUST be fully specified if it is going to appear anywhere in
the spec, even if it is optional.  It does not really seem all that likely
that new hash algorithms will come out so fast that updating the spec in
the future will be a problem.  Right now we mostly see MD5 and SHA-1.

> > > - Some of the semantic notes (like permitting the user to select the
> > >   secret key to use for signatures) have nothing at all to do with
> > >   the definition of PGP/MIME content types.  
> 
> > Sorry. I don't understand this. Please explain this more concretely.
> 
> 6., first implementation note: "OpenPGP/MIME composers SHOULD
> provide a user with a mechanism to select which secret key is used
> for signature calculation."

I agree with this as well.  OPENPGP/MIME should stick to discussing how
to encapsulate an OPENPGP protected message in MIME for transport.  Anything
beyond that is out of scope for this document.

> > > - Interesting points, such as the question how to permit multiple
> > >   signatures, are left out.  (This would be an extension of the
> > >   Secure Multiparts RFC and should be carefully considered.)
> 
> > Yes, this is a very interesting point. I also hope that someone will
> > propose a good one.
> 
> Extend the multipart/signed mechanism to include multiple
> signatures.  Encapsulating them into yet another
> multipart/alternative (?) part doesn't seem to make too much sense
> to me.

I discussed this with Jim Galvin (one of the Security Multiparts authors)
a while back, and his take on it was that Security Multiparts does not
prevent you from changing the "signature" portion to be a multipart/mixed
which could contain various signature types.  Example:

	Content-Type: multipart/signed; boundary=foo;
		micalg=openpgp-sha1,openpgp-md5; protocol="mutipart/mixed"

	--foo
	Content-Type: text/plain

	This is the signed data portion.

	--foo
	Content-Type: multipart/mixed; boundary=bar

	--bar
	Content-Type: application/pgp-signature
	Content-Description: signature #1

	-----BEGIN PGP SIGNATURE-----

	-----END PGP SIGNATURE-----
	
	--bar
	Content-Type: application/pgp-signature
	Content-Description: signature #2

	-----BEGIN PGP SIGNATURE-----

	-----END PGP SIGNATURE-----

	--bar--

	--foo--

me

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 01 Dec 1998 15:21:38 -0500
To: Kazu.Yamamoto ($B;3K\OBI'(B) <[email-masked]>)
Cc: [email-masked]
Subject: Re: OpenPGP agenda for Dec 7
Sender: [email-masked]

In <[email-masked]>, on 12/01/98 
   at 09:52 AM, Kazu Yamamoto ($B;3K\OBI'(B) <[email-masked]> said:

>    There are two ways to support multiple signatures.  One is storing
>    them in an OpenPGP object.  The other is storing a multipart/*
>    object in the second part.  Such functionality is outside the scope
>    of this memo.

Hi,

Just reading through the ID here and I would really like to see the functionality of multiple signatures added. There are several scenarios where multiple signatures per data object would be useful and it would be helpful to have this outlined so there is compatibility between the openpgp apps in processing such messages.

I can write something up on it after I have gone through the complete ID.

Thanks,

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
---------------------------------------------------------------

Date: Tue, 1 Dec 1998 18:55:34 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Kazu Yamamoto wrote:

> Even if your observation is ture, it's a trade-off problem. If you
> restrict an object to be signed 7bit, implementation of
> OpenPGP/MIME will be very complex.

It's no more complex than, e.g., forwarding messages encapsulated in
message/rfc822 attachments.  Additionally, there have been
implementations of this.  We had that discussion already, didn't we?

>> - The author's assumption about the non-importance of ASCII armor
>>   with non-MIME aware user agents is wrong.  More specifically,
>>   such MUAs could still PGP-decrypt PGP/MIME encapsulated encrypted
>>   messages.  They won't be able to do this with MIME encoding of
>>   these messages.

> This aslo sounds unfair to me. You at least agreed that ASCII armor
> for multipart/signed is not friendly to PGP-aware but MIME-unaware
> viewers. 

That's why I've been talking about multipart/_encrypted_ above.

>>    Additionally, one should note that a PGP/MIME document doesn't
>>   need to define any semantics which are a consequence of other
>>   MIME documents or of the OpenPGP spec.

> Why don't you claim that the OpenPGP RFC shouldn't talk about
> PGP/MIME?

Because it doesn't do so (beyond referencing RFC 2015)?

>>   On the other hand, the micalg parameter is _permitted_ with
>>   signed-then-encrypted body parts where it doesn't belong: Adding
>>   it would mean leaking encrypted content.

> Sorry. I don't understand. Please expalin this more concretely?

Quite simple: The complete signed text is encrypted, including all
information on _how_ the signature was generated, and whether the
encrypted text was signed at all.  Thus, including the micalg
parameter with encrypted bodies leaks encrypted content and should
be avoided.

>>   The PGP/MIME document should note that there is a canonical
>>   one-to-one mapping from OpenPGP hash algorithm identifiers to
>>   PGP/MIME micalg parameters. This mapping should be desribed;
>>   additionally, the currently defined micalg parameters should be
>>   listed.  Doing so will avoid revising the PGP/MIME document every
>>   time a new OpenPGP hash algorithm identifier is defined.

> In my conceptual model, how the MIME composer know what kind of hash
> algorithm is actually used?

It asks the OpenPGP composer about it?  Come on, Kazu, this is
trivial.

> And my proposal avoids revising the PGP/MIME document every time a
> new OpenPGP hash algorithm identifier is defined.

Yes, by not using it.  Describing the mapping seems to be more
useful to me.

> > - Some of the semantic notes (like permitting the user to select the
> >   secret key to use for signatures) have nothing at all to do with
> >   the definition of PGP/MIME content types.  

> Sorry. I don't understand this. Please explain this more concretely.

6., first implementation note: "OpenPGP/MIME composers SHOULD
provide a user with a mechanism to select which secret key is used
for signature calculation."

> >   Other notes, e.g., that
> >   there may be multiple levels of PGP/MIME encapsulation, are not
> >   needed because they are a corollary from the general MIME semantics.
> > 
> >   These notes should not be part of a PGP/MIME document.
> 
> Which part are you referring to?

8.1.1 and 8.2.  Requiring viewers to accept the format described in
8.1.1 is not necessary as it is a consequence of MIME semantics and
what has been described before.  The point behind 8.1 as a whole is
that RFC 1847 and OpenPGP signed-then-encrypted bodies are to be
considered equivalent (and may be transformed into each other
according to RFC 2015 - this is missing from your text).  8.2
doesn't seem to be needed at all.

> > - Interesting points, such as the question how to permit multiple
> >   signatures, are left out.  (This would be an extension of the
> >   Secure Multiparts RFC and should be carefully considered.)

> Yes, this is a very interesting point. I also hope that someone will
> propose a good one.

Extend the multipart/signed mechanism to include multiple
signatures.  Encapsulating them into yet another
multipart/alternative (?) part doesn't seem to make too much sense
to me.

tlr

To: [email-masked]
Cc: [email-masked]
Subject: Re: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Date: Wed, 02 Dec 1998 01:32:08 +0900
Lines: 126
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
Subject: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
Date: Tue, 1 Dec 1998 15:12:12 +0100

> I don't want to go into the details, but just enumerate some basic
> objections against Kazu Yamamoto's internet-draft document.

May I discuss with you?

> - This draft _duplicates_ the length of RFC 2015 without adding
>   essential new information.  Instead, the wheel is re-invented from
>   the beginning.  I'd prefer using an appropriately modified version
>   of RFC 2015.

My draft clarifies, at least, version control between PGP and OpenPGP.

And your observation seems unfair to me.  Please remember the history
of MIME. RFC 1521 doesn't provide any new information againt RFC 1341
(in your words). But I think it is worth publishing. Other exapmles
are found in IPv6, IPsec, and etc.

> - The author's assumption that most E-Mail gateways are 8-bit clean
>   nowadays is simply not true.  There is an incredible amount of
>   broken gateways out there, so a revised version of 2015 should
>   stick with the conservative model of that RFC (and the Security
>   Multiparts standard) and not emit any 8-bit-data.

Even if your observation is ture, it's a trade-off problem. If you
restrict an object to be signed 7bit, implementation of OpenPGP/MIME
will be very complex. You should compare this trade-off. Please don't
just say there are still some broken MTAs.

> - The author's assumption about the non-importance of ASCII armor
>   with non-MIME aware user agents is wrong.  More specifically, such
>   MUAs could still PGP-decrypt PGP/MIME encapsulated encrypted
>   messages.  They won't be able to do this with MIME encoding of
>   these messages.

This aslo sounds unfair to me. You at least agreed that ASCII armor
for multipart/signed is not friendly to PGP-aware but MIME-unaware
viewers. 

Yes, PGP-aware but MIME-unaware viewers can decrypt PGP/MIME but the
content header must be removed by hand. Also, my draft says that
Open/MIME composers SHOULD generate PGP objects encoded with ASCII
armor.

> - The conceptual model (section 4) doesn't belong into this
>   document.  MUAs _may_ decide to use it, but they may as well
>   decide to do something completely different, like true one-pass
>   processing using a complex state machine.  

My draft says that "This conceptual model is descriptive and does NOT
impose any restrictions or requirements on implementations."

>   Nevertheless, it's correct and important to have in mind that a
>   PGP/MIME document should _not_ touch the definition of internals
>   of OpenPGP objects.  

I agree.

>    Additionally, one should note that a PGP/MIME
>   document doesn't need to define any semantics which are a
>   consequence of other MIME documents or of the OpenPGP spec.

Why don't you claim that the OpenPGP RFC shouldn't talk about
PGP/MIME?

> - The conceptual model the author describes leads to some funny
>   conclusions and even funnier "definitions" with respect to the
>   micalg parameter of multipart/signed body parts.  There is no
>   proper definition of this parameter's value, and finally, we read
>   that it MUST be ignored.  

True.

>   On the other hand, the micalg parameter
>   is _permitted_ with signed-then-encrypted body parts where it
>   doesn't belong: Adding it would mean leaking encrypted content.

Sorry. I don't understand. Please expalin this more concretely?

>   The PGP/MIME document should note that there is a canonical
>   one-to-one mapping from OpenPGP hash algorithm identifiers to
>   PGP/MIME micalg parameters. This mapping should be desribed;
>   additionally, the currently defined micalg parameters should be
>   listed.  Doing so will avoid revising the PGP/MIME document every
>   time a new OpenPGP hash algorithm identifier is defined.

In my conceptual model, how the MIME composer know what kind of hash
algorithm is actually used?

And my proposal avoids revising the PGP/MIME document every time a new
OpenPGP hash algorithm identifier is defined.

> - Some of the semantic notes (like permitting the user to select the
>   secret key to use for signatures) have nothing at all to do with
>   the definition of PGP/MIME content types.  

Sorry. I don't understand this. Please explain this more concretely.

>   Other notes, e.g., that
>   there may be multiple levels of PGP/MIME encapsulation, are not
>   needed because they are a corollary from the general MIME semantics.
> 
>   These notes should not be part of a PGP/MIME document.

Which part are you referring to?

> - Interesting points, such as the question how to permit multiple
>   signatures, are left out.  (This would be an extension of the
>   Secure Multiparts RFC and should be carefully considered.)

Yes, this is a very interesting point. I also hope that someone will
propose a good one.

> For these reasons, I'd like to porpose to start from RFC 2015 and
> add the absolutely necessary points to that text.  If there is
> interest in following this direction of work, I'm willing to make up
> a revised version of 2015 in ID format and post it to this mailing
> list within the next two days, possibly even this evening (European
> time).

Please do what you think is right. :)

--Kazu

Date: Tue, 1 Dec 1998 15:12:12 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Revising RFC 2015 (was: OpenPGP agenda for Dec 7)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I don't want to go into the details, but just enumerate some basic
objections against Kazu Yamamoto's internet-draft document.

- This draft _duplicates_ the length of RFC 2015 without adding
  essential new information.  Instead, the wheel is re-invented from
  the beginning.  I'd prefer using an appropriately modified version
  of RFC 2015.

- The author's assumption that most E-Mail gateways are 8-bit clean
  nowadays is simply not true.  There is an incredible amount of
  broken gateways out there, so a revised version of 2015 should
  stick with the conservative model of that RFC (and the Security
  Multiparts standard) and not emit any 8-bit-data.

- The author's assumption about the non-importance of ASCII armor
  with non-MIME aware user agents is wrong.  More specifically, such
  MUAs could still PGP-decrypt PGP/MIME encapsulated encrypted
  messages.  They won't be able to do this with MIME encoding of
  these messages.

- The conceptual model (section 4) doesn't belong into this
  document.  MUAs _may_ decide to use it, but they may as well
  decide to do something completely different, like true one-pass
  processing using a complex state machine.  

  Nevertheless, it's correct and important to have in mind that a
  PGP/MIME document should _not_ touch the definition of internals
  of OpenPGP objects.  Additionally, one should note that a PGP/MIME
  document doesn't need to define any semantics which are a
  consequence of other MIME documents or of the OpenPGP spec.

- The conceptual model the author describes leads to some funny
  conclusions and even funnier "definitions" with respect to the
  micalg parameter of multipart/signed body parts.  There is no
  proper definition of this parameter's value, and finally, we read
  that it MUST be ignored.  On the other hand, the micalg parameter
  is _permitted_ with signed-then-encrypted body parts where it
  doesn't belong: Adding it would mean leaking encrypted content.

  I'd suggest a complete revision of this part of the draft in the
  spirit of the Security Multiparts spec.  (Alternatively, stick
  with 2015's wording.) 

  The PGP/MIME document should note that there is a canonical
  one-to-one mapping from OpenPGP hash algorithm identifiers to
  PGP/MIME micalg parameters. This mapping should be desribed;
  additionally, the currently defined micalg parameters should be
  listed.  Doing so will avoid revising the PGP/MIME document every
  time a new OpenPGP hash algorithm identifier is defined.

- Some of the semantic notes (like permitting the user to select the
  secret key to use for signatures) have nothing at all to do with
  the definition of PGP/MIME content types.  Other notes, e.g., that
  there may be multiple levels of PGP/MIME encapsulation, are not
  needed because they are a corollary from the general MIME semantics.

  These notes should not be part of a PGP/MIME document.

- Interesting points, such as the question how to permit multiple
  signatures, are left out.  (This would be an extension of the
  Secure Multiparts RFC and should be carefully considered.)

For these reasons, I'd like to porpose to start from RFC 2015 and
add the absolutely necessary points to that text.  If there is
interest in following this direction of work, I'm willing to make up
a revised version of 2015 in ID format and post it to this mailing
list within the next two days, possibly even this evening (European
time).

tlr