Subject: Last Call: MIME Security with OpenPGP to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 27 Apr 2001 17:22:38 -0400

The IESG has received a request from the An Open Specification for
Pretty Good Privacy Working Group to consider MIME Security with
OpenPGP <draft-ietf-openpgp-mime-06.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by May 11, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: MIME Security with OpenPGP to Proposed Standard
Reply-to: [email-masked]
Date: Fri, 27 Apr 2001 17:22:38 -0400
Sender: [email-masked]

The IESG has received a request from the An Open Specification for
Pretty Good Privacy Working Group to consider MIME Security with
OpenPGP <draft-ietf-openpgp-mime-06.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by May 11, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-06.txt

Date: Mon, 23 Apr 2001 10:18:30 +0100
From: "Clive D.W. Feather" <[email-masked]>
To: Per Abrahamsen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Sender: [email-masked]

Per Abrahamsen said:
> Basically, I agree USEFOR should not attempt to overrule RFC 2015. 

Having thought about this, I agree.

We should not be modifying MIME in any shape, size, or form. Just using it.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646 

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: SHA256 ?
Date: Sat, 21 Apr 2001 12:22:11 -0400
Sender: [email-masked]

> isn't it time to define new algorithm numbers for SHA2 ?

I really don't understand the rush.  Last I checked, the new
variants were not even *draft* FIPS.

At the same time, I note that ECDSA is FIPS-approved, and has
a reserved algorithm number, but no details.

Note that I don't think NIST approval should always dictate inclusion
in OpenPGP, but at least in the SHA-256+ cases, they were
the originator and they may tweak them if something comes up during
evaluation (as happened with SHA-1).

Date: Thu, 19 Apr 2001 10:31:50 -0700
To: OpenPGP mailing list <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Shamelessly self-serving message from the Chair
Sender: [email-masked]

For those interested in writing extensions for Eudora, I have updated 
documentation on the 
horribly-named-but-nevertheless-I-am-forced-to-live-with Extended 
Messaging Services API (emsapi) for Eudora.  The documentation and 
kit hasn't been posted to our website, yet.  But I will make it 
available to anyone requesting it.  I'm sorry for the inconvenience, 
and we'll get it out to the site, but I figured that some of you 
would both like to know and not want to wait for that.
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

From: [email-masked]
Date: Thu, 19 Apr 2001 18:10:30 +0200
To: [email-masked], [email-masked], [email-masked]
Subject: Re: SHA256 ?
Sender: [email-masked]

[email-masked] wrote:
> [email-masked] writes:
> > there is OIDs for SHA256, SHA384, SHA512 !
> >
> >    The ASN.1 OIDs are:
> >      - SHA256:     2.16.840.1.101.3.4.2.1
> >      - SHA384:     2.16.840.1.101.3.4.2.2
> >      - SHA512:     2.16.840.1.101.3.4.2.3
> 
> This sounds plausible, although I haven't found an exact reference
> for it.
> 
> 2.16.840.1.101 is the U.S. Government
> 2.16.840.1.101.3 is CSOR, the Computer Security Objects Register.  Its
> home is http://csrc.nist.gov/csor/.
> 
> nistAlgorithms is {csor 4}, defined at http://csrc.nist.gov/csor/algorithms.htm.
> However while that page defines the .0 and .1 subtrees under
> nistAlgorithms (.1 being AES), it does not define the .2 values used
> above.  But that is about where we would expect to see the new SHA OIDs,
> so probably these pages have just not been updated yet.
> Hal

they realy are not listed there yet...

I found these OIDs in IEEE P1363a Draft D7.9:
http://grouper.ieee.org/groups/1363/P1363a/draft.html

== <EOF> ==
Disastry
http://i.am/disastry/

From: [email-masked]
Date: Thu, 19 Apr 2001 08:43:51 -0700
To: [email-masked], [email-masked], [email-masked]
Subject: Re: SHA256 ?
Sender: [email-masked]

[email-masked] writes:
> there is OIDs for SHA256, SHA384, SHA512 !
>
>    The ASN.1 OIDs are:
>      - SHA256:     2.16.840.1.101.3.4.2.1
>      - SHA384:     2.16.840.1.101.3.4.2.2
>      - SHA512:     2.16.840.1.101.3.4.2.3

This sounds plausible, although I haven't found an exact reference
for it.

2.16.840.1.101 is the U.S. Government
2.16.840.1.101.3 is CSOR, the Computer Security Objects Register.  Its
home is http://csrc.nist.gov/csor/.

nistAlgorithms is {csor 4}, defined at http://csrc.nist.gov/csor/algorithms.htm.
However while that page defines the .0 and .1 subtrees under
nistAlgorithms (.1 being AES), it does not define the .2 values used
above.  But that is about where we would expect to see the new SHA OIDs,
so probably these pages have just not been updated yet.

Hal

To: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Organization: The Church of Emacs
From: Per Abrahamsen <[email-masked]>
Date: 19 Apr 2001 16:12:50 +0200
Lines: 17
Sender: [email-masked]

Per Abrahamsen <[email-masked]> writes:

> This discussion seem to have degenerated into 

Oops, I hit the send key too soon.  

Basically, I agree USEFOR should not attempt to overrule RFC 2015. 

Just removing this section should do the trick:

>    Exceptionally, those application types defined in [RFC 1847] and
>    [RFC 2015] for use within "multipart/signed" articles, and the
>    type "application/pgp-keys" (or other similar types containing
>    digital certificates) may be used freely but, contrary to [RFC
>    2015] and unless the article is intended to be sent by mail also,
>    the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit"
>    as appropriate).

To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Organization: The Church of Emacs
From: Per Abrahamsen <[email-masked]>
Date: 19 Apr 2001 16:02:04 +0200
Lines: 110
Sender: [email-masked]

This discussion seem to have degenerated into 

Thomas Roessler <[email-masked]> writes:

> I'm writing as one of the co-authors of
> draft-ietf-openpgp-mime-06, which is hoped to become the
> successor of RFC 2015 (PGP/MIME) soon.
> 
> In section 6.21.3 of draft-*-article-04, you write the following:
> 
>    In the same way, Content-Types requiring special processing for
>    their display, such as "application", "image", "audio", "video"
>    and "multipart/related" are discouraged except in groups
>    specifically intended (by policy or custom) to include them.
>    Exceptionally, those application types defined in [RFC 1847] and
>    [RFC 2015] for use within "multipart/signed" articles, and the
>    type "application/pgp-keys" (or other similar types containing
>    digital certificates) may be used freely but, contrary to [RFC
>    2015] and unless the article is intended to be sent by mail also,
>    the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit"
>    as appropriate).
> 
> I consider this section harmful for various reasons.
> 
> 
> 
> First, it should be noted that problems with transmitting 8bit
> content are not the only reason for which an agent implementing
> PGP/MIME may elect to use quoted-printable or base64 as a body
> part's encoding.
> 
> In particular, draft-ietf-openpgp-mime-06 specifies that the signed
> material in a PGP/MIME multipart/signed entity MUST NOT include any
> trailing whitespace.  This may either be achieved by cutting off
> trailing whitespace, or by protecting it with an appropriate
> transfer encoding.
> 
> The reason for this lies in the definition of a text-mode signature
> in RFC 2440 [OpenPGP], which is incompatible with the definition
> used by traditional implementations (aka pgp version 2).
> 
> More precisely, a text-mode signature traditionally meant that any
> line feed has to be canonicalized to CR LF before hashing.  With
> OpenPGP, trailing whitespace is additionally snipped.  (That's the
> kind of processing which has traditionally been applied to
> clearsigned messages.)
> 
> Now, the processing rules for multipart/signed make sure that line
> feeds are canonical before they hit the signing engine.  With
> traditional PGP, that meant that text-mode and binary-mode hashes of
> the material would be identical.  This is no longer valid with
> OpenPGP, which has two consequences:  (1) In order to determine what
> hash is to be computed, a receiving agent would have to look at the
> signature.  This would break the possibility to process
> multipart/signed in one pass.   (2) In the presence of trailing
> whitespace, text-mode signatures wouldn't be interoperable between
> implementations using PGP 2 and OpenPGP implementations.
> 
> The best way to fix both problems is to make sure that no trailing
> whitespace is present, by applying appropriate encodings.  (With
> text/plain; format=flowed, this will be something which is
> encountered quite frequently.)
> 
> For this reason alone, mandating transparent encodings may not be
> the best idea at this point.
> 
> 
> It should also be noted it's impossible to convert a
> multipart/signed entity which contains 8bit body parts to any 7bit
> format without breaking the signature.  (Remember that MIME
> explicitly forbids nested MIME encodings: Recoding has to happen on
> the leaf level of a nested MIME structure.)
> 
> This implies, that a multipart/signed entity wihich contains 8bit
> body parts cannot be legally transported via Internet e-mail without
> ruining the signature - be it as part of message/rfc822
> encapsulation, be it as a direct attachment.
> 
> 
> Finally, I'd like to warn you that signature generation and
> verification interoperability may seriously be endangered by
> allowing 8bit body parts in a multipart/signed.
> 
> More precisely, a multipart/signed body part may generally contain
> textual data in various character sets - it may even contain a
> nested multipart/mixed with text/plain subparts which bear different
> character sets.
> 
> However, PGP signature generators and verifiers have traditionally
> been expecting that they are presented with data in a local
> character set when preparing text-mode signatures.  For this reason,
> signature generators and verifiers may attempt to recode data they
> are presented with to whatever character set is considered to be
> canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2).
> When applying such (unnecessary) transformations to 8bit messages in
> on-the-wire-format (which would inevitably happen when a

> of course, be ruined.
> 
> Restricting the signed material to 7bit data also helps to make
> signature generation and verification more robust against such
> problems, and implementations considerably simpler.
> 
> 
> For all these reasons, I urge the Usenet format working group to
> remove the reference to multipart/signed from section 6.21.3.
> 
> -- 
> Thomas Roessler			    <[email-masked]>

From: [email-masked]
Date: Thu, 19 Apr 2001 11:16:25 +0200
To: [email-masked], [email-masked]
Subject: Re: SHA256 ?
Sender: [email-masked]

Jon Callas wrote:
> At 3:49 PM +0200 4/11/01, [email-masked] wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >isn't it time to define new algorithm numbers for SHA2 ?
> >8 for SHA256 (and maybe 9,10 for SHA384,512?)
> >
> >the bigger problem however is with OIDs...
> >none of SHA2 have OIDs defined, just like HAVAL and TIGER :(
> >
> 
> That is, in fact, the bigger problem. We can either finesse it -- we agree
> on an OID to use for them -- or we wait for some other OID space to assign
> them.

there is OIDs for SHA256, SHA384, SHA512 !

   The ASN.1 OIDs are:
     - SHA256:     2.16.840.1.101.3.4.2.1
     - SHA384:     2.16.840.1.101.3.4.2.2
     - SHA512:     2.16.840.1.101.3.4.2.3
   The hexadecimal representations are:
     - SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
     - SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
     - SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
so
   The full hash prefixes for these are:
       SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
                   0x00, 0x04, 0x20
       SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
                   0x00, 0x04, 0x30
       SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
                   0x00, 0x04, 0x40

so how about assigning algorithm numbers for SHA2:
       ID           Algorithm                             Text Name
       --           ---------                             ---- ----
       8          - SHA256                                "SHA256"
       9          - SHA384                                "SHA384"
       10         - SHA512                                "SHA512"

?

== <EOF> ==
Disastry  http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
     AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)

Date: Tue, 17 Apr 2001 10:30:16 +0800
To: [email-masked], [email-masked]
From: Erron Criddle <[email-masked]>
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Sender: [email-masked]

Thought I'd clarify:

At 11:23 AM 14/04/2001 +0200, Thomas Roessler <[email-masked]> 
wrote:

>In section 6.21.3 of draft-*-article-04, you write the following:
>
>    In the same way, Content-Types requiring special processing for
>    their display, such as "application", "image", "audio", "video"
>    and "multipart/related" are discouraged except in groups
>    specifically intended (by policy or custom) to include them.
>    Exceptionally, those application types defined in [RFC 1847] and
>    [RFC 2015] for use within "multipart/signed" articles, and the
>    type "application/pgp-keys" (or other similar types containing
>    digital certificates) may be used freely but, contrary to [RFC
>    2015] and unless the article is intended to be sent by mail also,
>    the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit"
>    as appropriate).
>
>I consider this section harmful for various reasons.

<snip>

>In particular, draft-ietf-openpgp-mime-06 specifies that the signed
>material in a PGP/MIME multipart/signed entity MUST NOT include any
>trailing whitespace.

<snip>

>The reason for this lies in the definition of a text-mode signature
>in RFC 2440 [OpenPGP]

<snip>

>Now, the processing rules for multipart/signed make sure that line
>feeds are canonical before they hit the signing engine.

ie, trailing white space is included.

<snip>

>The best way to fix both problems is to make sure that no trailing
>whitespace is present, by applying appropriate encodings.  (With
>text/plain; format=flowed, this will be something which is
>encountered quite frequently.)
>
>For this reason alone, mandating transparent encodings may not be
>the best idea at this point.

<snip>

>It should also be noted it's impossible to convert a
>multipart/signed entity which contains 8bit body parts to any 7bit
>format without breaking the signature.

This is important for 7-bit relays...

>This implies, that a multipart/signed entity wihich contains 8bit
>body parts cannot be legally transported via Internet e-mail without
>ruining the signature - be it as part of message/rfc822
>encapsulation, be it as a direct attachment.

True, if the raley server can only handle 7-bit ASCII

<snip>

>When applying such (unnecessary) transformations to 8bit messages in
>on-the-wire-format (which would inevitably happen when a
>multipart/signed is verified or generated), interoperability will,
>of course, be ruined.

This comment regards various character sets...

>Restricting the signed material to 7bit data also helps to make
>signature generation and verification more robust against such
>problems, and implementations considerably simpler.

True.

>For all these reasons, I urge the Usenet format working group to
>remove the reference to multipart/signed from section 6.21.3.

Ditto.

Regards

Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS  WA  6009
Australia

Fax: +61 8 9386 9473
Tel: + 61 8 9386 9534

http://www.comasp.com
[email-masked]

To: Brad Templeton <[email-masked]>
Cc: Russ Allbery <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
From: Derek Atkins <[email-masked]>
Date: 16 Apr 2001 21:29:55 -0400
Lines: 25
Sender: [email-masked]

You might want to take a look at draft-ietf-impp-msgfmt-??.txt (please
forgive me for not knowing the current revision number).  This draft
tries to describe a MIME format for encapsulating a MIME message with
it's associated meta-content (header information).  The purpose of
this draft was to allow a sender to sign a message and associated
message headers, and then allow a transport system to send the message
from the sender to the recipient(s).

Using MSGFMT does imply some duplication of headers if your transport
system requires them (e.g. IMPP, SMTP, etc).  But if you don't need
the transport-layer headers, you can stuff them into the MSGFMT part
and sign them.  Unfortunately this would be an incompatible change
with the current netnews protocols.

But I figured I'd point out that there are efforts to try to unify the
message/message-meta-data dichotomy.

Enjoy!

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Mon, 16 Apr 2001 17:16:00 -0700
From: Brad Templeton <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Mail-Followup-To: Russ Allbery <[email-masked]>, [email-masked], [email-masked]
Organization: http://www.templetons.com/brad
Sender: [email-masked]

On Mon, Apr 16, 2001 at 04:50:48PM -0700, Russ Allbery wrote:
> Brad Templeton <[email-masked]> writes:
> It seems reasonably easy to warn if the identity associated with the
> signature doesn't match the displayed identity derived from the From
> header, but I haven't thought a great deal about the user interface
> portion of this.

Indeed that's good.  That's header verification, which is what I'm
pushing for, though you should verify more than just the From header.

There are a variety of ways to do this.  The right "mime" way is ugly,
namely to embed another multipart in the 1st half of the mult/signed,
which in turn has the body and a representation of the header.

I have advocated (and the multipart/signed people I have talked to have
agreed, saying they should have done this in the first place) that the
multipart/signed form allow more than 2 parts, with semantics in the final
signature part controlling just how the signature is checked on parts
1...N-1.   USENET could be the first to include this extension.

If there were a body issuing certificates for email addresses, that could
be used to verify just the from line or other email lines, but again,
why stop there.

Somehow, somewhere in the body, a hash of the valid header needs to be
provided.   Putting it in the text is ugly, but is the only way the
existing multipart/signed spec would verify it.

The best option is probably to extend the spec.

> 
> There are some announce groups where all the content is signed.
> comp.os.linux.announce, for example.  There are some people who always
> sign all of their posts.

A group where everything is signed can be secured, if the software is
then programmed to reject or give warnings on the rare unsigned messages.
(ideally relays should just not carry them in such a group, just as they
in theory reject unauthorized postings in moderated groups.)

However, support for "people who signs all their posts" is the hard issue.
You need to spec a lot of extra stuff to make this work, somehow building
databases of people who are in this state, and getting software to use those
databases.

You must have a certificate system, because you can't just put this flag on
a user once they sign their first post, as the first one might be forged,
thus locking the user out from posting under his own email.

But even then, as I have indicated, it's easy for me to post as
"[email-masked]" even if you are the only one who can post
as "[email-masked]".   It would be tough for you to figure out every
form of your name and reserve it.

> So it's your position that this standard should *not* adopt MIME?

It should absolutely adopt MIME, and should make it a SHOULD, possibly
even a MUST.  At the same time, non-conformant readers will exist for
quite some time, so we must for some years be aware of the older readers,
and decide how we will _use_ MIME, comparing the tradeoff for those users
with the benefit of it.

Securing headers is well worth the ugly display to users of old newsreaders.
Signing bodies is less convincing a sell.

> To repeat myself (again), I feel very strongly that adopting MIME is a
> binary switch.  Either we adopt MIME or we don't.  The time to try to
> fiddle with MIME was when MIME was being developed, and should have been

MIME is meant to be extended, and major users of it are free to develop
extensions and try to get them adopted outside their space.

I fully agree we should throw that binary switch, but I also face reality.
I've seen newsgroups where people post with wasteful stuff, for no benefit
to most of the readers, and it gets a lot of antipathy.

Mime multipart/alternative was created so MIME systems could go through
evolutions, but it's a very bulky system, more suited to mail than news,
and so when it first started being used by Netscape, people were screamed
at to go away.  It's a little more accepted now but it took a lot.

That was, in part, why I pushed the concept of out of band markup, which
is a better migration to rich text than multipart/alternative. 

Note that at this time, the vast majority of USENET users have a reader
that handles not just MIME, but even HTML.

Still, some things are worth it and some are not.   Non-english
character sets, hyperlinks, structure, and securing headers are all worth
it. 

Signing bodies is something we've seen for a while, but I have yet to
see it actually be useful to anybody.

To: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 16 Apr 2001 16:50:48 -0700
Lines: 77
Sender: [email-masked]

Brad Templeton <[email-masked]> writes:
> On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote:

>> That seems to be a non-sequitur.  It's certainly possible to
>> automatically verify a multipart/signed message.  Some news readers and
>> many mail readers already do this.

> If all the software does is include a string about the verification,
> that is then manually checked, it's manual verification.  Humans ignore
> warnings which happen frequently.  Thus if most (or even just a lot,
> like a few percent) of otherwise valid messages have the warning, people
> learn to ignore the warning.

It seems reasonably easy to warn if the identity associated with the
signature doesn't match the displayed identity derived from the From
header, but I haven't thought a great deal about the user interface
portion of this.

> What are these "important announcements" though?  As I indicated, I mean
> that all the messages in a "class" have to be signed, so that it becomes
> worthy of note when a message in a class is not signed, and this can
> cause a warning that will be paid attention to.

There are some announce groups where all the content is signed.
comp.os.linux.announce, for example.  There are some people who always
sign all of their posts.

> I would rather solve the real problems the net faces with security,
> which are unauthorized control messages (and the resulting lack of trust
> in authorized control messages), most of all cancel, and large scale
> spam.

Yes, I agree.  However, no one is asking you to solve any of these other
problems.  This thread started with the OpenPGP folks asking us to please
not arbitrarily mangle their existing standard.  That seems rather
reasonable to me.  We don't have to do any work at all beyond not
interfering with their (existing!) standard.

> We will eventually need to put all that mime stuff in, and it will annoy
> a lot of users (we've all seen this) but we should do it for something
> really useful, not mostly ignored signature of bodies.

So it's your position that this standard should *not* adopt MIME?

To repeat myself (again), I feel very strongly that adopting MIME is a
binary switch.  Either we adopt MIME or we don't.  The time to try to
fiddle with MIME was when MIME was being developed, and should have been
done as part of a different working group than this one; at this point,
it's just Not Invented Here syndrome.  Either netnews should continue to
track the mail standards (which I would argue should be the *default*
since that's been the policy behind netnews from the beginning), or we
should explicitly say that we're not adopting MIME, but trying to grab
bits and pieces creates exactly the kinds of internal inconsistencies that
are being pointed out in this thread.

If we want multipart messages, well-labelled character sets, the ability
to transfer non-text messages without unlabelled structural content like
uuencode, and the ability to take advantage of all of the work that the
(quite a bit larger, quite a bit better-funded, and quite a bit better at
developing and deploying new technology) mail community is doing, then I
think we should simply say that the MIME standard also applies to netnews
messages and then pick up the pieces, if any, within the framework already
laid out for extending MIME.  The current draft leans more in that
direction than in the direction of not adopting MIME, but currently in
some places is still trying to balance on the top of non-existent fences.

And lest people worry too much about some portions of that, let me point
out that (a) Usenet is not the only thing that netnews is used for and the
standard should be usable for things other than Usenet, and (b) it's still
perfectly reasonable for individual hierarchies to have their own policies
about acceptable message body formats above and beyond what the standard
*allows* for.  If they want to try to figure out how to get message/signed
working without QP, that's their lookout; it's a heck of a lot easier to
change hierarchy policies than it is to change an RFC.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 16 Apr 2001 16:20:37 -0700
From: Brad Templeton <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Mail-Followup-To: Russ Allbery <[email-masked]>, [email-masked], [email-masked]
Organization: http://www.templetons.com/brad
Sender: [email-masked]

On Mon, Apr 16, 2001 at 02:42:51PM -0700, Russ Allbery wrote:
> Brad Templeton <[email-masked]> writes:
> > Yes, but manual verification of signatures is of dubious value.
> 
> That seems to be a non-sequitur.  It's certainly possible to automatically
> verify a multipart/signed message.  Some news readers and many mail
> readers already do this.

If all the software does is include a string about the verification, that
is then manually checked, it's manual verification.    Humans ignore
warnings which happen frequently.  Thus if most (or even just a lot, like
a few percent) of otherwise valid messages have the warning, people learn
to ignore the warning.

> > For digital signature authentication to work properly, it is
> > unfortunately necessary that all messages in a class be signed, and that
> > the presence of an unsigned or improperly signed message be a major
> > anomaly which gets a fair bit of attention, or which is in fact
> > forbidden.
> 
> You're solving a different problem than I'm talking about.  For occasional
> use for important announcements, the multipart/signed protocol works just
> fine.  I understand that you're trying to solve the problem of fully
> authenticated message streams, which I agree is an interesting theoretical

What are these "important announcements" though?  As I indicated, I mean
that all the messages in a "class" have to be signed, so that it becomes
worthy of note when a message in a class is not signed, and this can cause
a warning that will be paid attention to.

So what is this class called "important annoucements" and how is it defined,
and how does the software detect it, and know when an important annoucement
comes that is not validly signed, so that it can warn me about it?

If you just mean that "before you say something important" be sure to sign
it, again the value of that is limited, though not zero.  It means that
people who are in the know, after reading something of some importance
(whatever that is) would then look to see if it is signed, or have their
brain pay attention to the "this is not signed" warning which appears on
almost all messages.

I would rather solve the real problems the net faces with security,
which are unauthorized control messages (and the resulting lack of trust
in authorized control messages), most of all cancel,  and large scale spam.

Don't get me wrong, I think bodies should be authenticated, but the value
from it, at least in today's net, is minimal, and the backlash over it,
namely a lot of mime stuff most readers don't know how to handle tacked on
the end of messages, far worse than the benefit.

We will eventually need to put all that mime stuff in, and it will annoy
a lot of users (we've all seen this) but we should do it for something
really useful, not mostly ignored signature of bodies.

To: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 16 Apr 2001 14:42:51 -0700
Lines: 48
Sender: [email-masked]

Brad Templeton <[email-masked]> writes:
> On Mon, Apr 16, 2001 at 02:07:07PM -0700, Russ Allbery wrote:

>> This depends rather heavily on the context.  What you say is true for
>> some applications (like control messages) and not true for others (like
>> official announcements from some entity or another that are posted to
>> Usenet).  At the worst, what it means that one has to include the
>> important information that should be authenticated by the signature,
>> such as the date and the author, in the body of the message.  Quite
>> frequently for things like announcements this is done as a matter of
>> course anyway.

> Yes, but manual verification of signatures is of dubious value.

That seems to be a non-sequitur.  It's certainly possible to automatically
verify a multipart/signed message.  Some news readers and many mail
readers already do this.

> For digital signature authentication to work properly, it is
> unfortunately necessary that all messages in a class be signed, and that
> the presence of an unsigned or improperly signed message be a major
> anomaly which gets a fair bit of attention, or which is in fact
> forbidden.

You're solving a different problem than I'm talking about.  For occasional
use for important announcements, the multipart/signed protocol works just
fine.  I understand that you're trying to solve the problem of fully
authenticated message streams, which I agree is an interesting theoretical
problem.  I don't expect to see such a thing show up on Usenet soon,
however, since most people currently using Usenet don't really have much
use for it.

*shrug*  I know you care more about it than I do, and I may be
underestimating the demand.

> People have been able to sign article bodies for some time.  It's not
> widely used and it's really not very useful.

It does, however, have the advantage of actually being deployed, working,
and standardized.  The sort of signature system that you're describing
would be more useful for some applications than multipart/signed, I agree,
should someone eventually write it and standardize it.

Making it work well within MIME would be quite difficult, as we've already
established in some of the previous rounds of discussion on that topic.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 16 Apr 2001 14:23:57 -0700
From: Brad Templeton <[email-masked]>
To: Russ Allbery <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Mail-Followup-To: Russ Allbery <[email-masked]>, [email-masked], [email-masked]
Organization: http://www.templetons.com/brad
Sender: [email-masked]

On Mon, Apr 16, 2001 at 02:07:07PM -0700, Russ Allbery wrote:
> Brad Templeton <[email-masked]> writes:
> 
> > Mulitpart/signed, while probably the best of the singature forms, is not
> > suitable to USENET.  It only signs the body.  Signing the body is not
> > just the least interesting thing we can do in USENET (99.9% of all
> > problems come from forged headers, not modification of bodies) it can
> > actually have negative value, if it leads people to think the article is
> > "signed" and thus can be trusted in ways that it actually can't.
> 
> This depends rather heavily on the context.  What you say is true for some
> applications (like control messages) and not true for others (like
> official announcements from some entity or another that are posted to
> Usenet).  At the worst, what it means that one has to include the
> important information that should be authenticated by the signature, such
> as the date and the author, in the body of the message.  Quite frequently
> for things like announcements this is done as a matter of course anyway.

Yes, but manual verification of signatures is of dubious value.  For
digital signature authentication to work properly, it is unfortunately
necessary that all messages in a class be signed, and that the presence
of an unsigned or improperly signed message be a major anomaly which gets
a fair bit of attention, or which is in fact forbidden.

If newsgroups allow both signed and unsigned messages, then it is trivial
to cause trouble by simply not signing your unsigned messages.  If a given
user signs all his messages, it is not even sufficient for the software to
be able to warn that a user who normally signs all his messages has not
signed one, because the forger can play any number of tricks, including
simply posting a message "From: [email-masked]" which looks like you to
the non-careful eye, or worse "From: [email-masked]" which *is*
you but the software is unlikley to trap the warning that all messages
from this address should be signed.  Or [email-masked]
or many other forms which point to you.

Of course you're even assuming something outside the multipart/signed spec,
that the software is checking the From line at all, based on parsing it
somehow out of the body.

People have been able to sign article bodies for some time.  It's not widely
used and it's really not very useful.   It would be a poor intermediate
step because it's the wrong problem, and can lead to problems as well
as limited benefit.

All signing bodies does, without other checks, is allow me to prove after
the fact that I really sent a message.  It doesn't prove that I _didn't_
send it, for I am free to post unsigned messages which I can later disclaim.
It also allows those who know my key to verify I sent a message, if they
check.

I've never been called upon to prove I sent a message.  I don't recall ever
seeing this for anybody else either.   I have seen cases where people wonder
if a person really sent a message, of course, but I've also seen a lot of
forgeries that were so blatantly obvious that nobody of the sort who would
check signatures would ever be fooled, and yet people are fooled.

What you need is a system that shows that messages are from who they say
they are from, and makes a big deal when they aren't.  If 90% of messages
start having a "The sender of this message could not be authenticated"
then people simply start ignoring the warning, and it becomes of limited value.

To: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: 16 Apr 2001 14:07:07 -0700
Lines: 19
Sender: [email-masked]

Brad Templeton <[email-masked]> writes:

> Mulitpart/signed, while probably the best of the singature forms, is not
> suitable to USENET.  It only signs the body.  Signing the body is not
> just the least interesting thing we can do in USENET (99.9% of all
> problems come from forged headers, not modification of bodies) it can
> actually have negative value, if it leads people to think the article is
> "signed" and thus can be trusted in ways that it actually can't.

This depends rather heavily on the context.  What you say is true for some
applications (like control messages) and not true for others (like
official announcements from some entity or another that are posted to
Usenet).  At the worst, what it means that one has to include the
important information that should be authenticated by the signature, such
as the date and the author, in the body of the message.  Quite frequently
for things like announcements this is done as a matter of course anyway.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Mon, 16 Apr 2001 12:51:55 -0700
From: Brad Templeton <[email-masked]>
To: Erland Sommarskog <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Mail-Followup-To: Erland Sommarskog <[email-masked]>, [email-masked], [email-masked]
Organization: http://www.templetons.com/brad
Sender: [email-masked]

On Mon, Apr 16, 2001 at 12:51:51PM -0000, Erland Sommarskog wrote:
> Thomas Roessler <[email-masked]> writes:
> > It should also be noted it's impossible to convert a
> > multipart/signed entity which contains 8bit body parts to any 7bit
> > format without breaking the signature.  (Remember that MIME
> > explicitly forbids nested MIME encodings: Recoding has to happen on
> > the leaf level of a nested MIME structure.)
> 
> Since I know very little about this signing business, I'll have to
> ask some really stupid questions.
> 
> What is in multipart/signed? Is it just the signature? Or is it any part
> of the message that a human is supposed to read?

Mulitpart/signed, while probably the best of the singature forms, is not
suitable to USENET.  It only signs the body.   Signing the body is not
just the least interesting thing we can do in USENET (99.9% of all problems
come from forged headers, not modification of bodies) it can actually
have negative value, if it leads people to think the article is "signed"
and thus can be trusted in ways that it actually can't.

To: [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
From: Florian Weimer <[email-masked]>
Date: 16 Apr 2001 20:01:04 +0200
Lines: 12
Sender: [email-masked]

[email-masked] (Erland Sommarskog) writes:

> Since I know very little about this signing business, I'll have to
> ask some really stupid questions.

I'm sorry but I've already replied on the USEFOR list only.  The
discussion will be continued over there. :-/

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: 16 Apr 2001 12:51:51 -0000
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
From: [email-masked] (Erland Sommarskog)
Sender: [email-masked]

Thomas Roessler <[email-masked]> writes:
> It should also be noted it's impossible to convert a
> multipart/signed entity which contains 8bit body parts to any 7bit
> format without breaking the signature.  (Remember that MIME
> explicitly forbids nested MIME encodings: Recoding has to happen on
> the leaf level of a nested MIME structure.)

Since I know very little about this signing business, I'll have to
ask some really stupid questions.

What is in multipart/signed? Is it just the signature? Or is it any part
of the message that a human is supposed to read?

If it's only the signature, I don't have any issue with it. If it is text
intended to be read by humans, is the problem both trailing white-space
and octets >= 128? If only trailing white-space is the problem, wouldn't
be better to define an encoding that took care of those and nothing else?

What I care about in the end is that text which is supposed to be read
by humans are not mutilated.
--
Erland Sommarskog, Stockholm, [email-masked]

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt
From: Florian Weimer <[email-masked]>
Date: 15 Apr 2001 19:12:22 +0200
Lines: 45
Sender: [email-masked]

Thomas Roessler <[email-masked]> writes:

> The text/binary mode interop problem is related to trailing
> whitespace.  It is not related to the presence or absence 8bit
> characters.

OpenPGP textmode signatures are not very well-defined.  First of all,
OpenPGP requires text to be encoded in UTF-8, a requirement which is
hardly followed in practice.  In addition, there are at least four
Unicode characters relating to line endings: U+000A, U+000D, U+0085
(NEXT LINE or NEL, somehow related to ISO 6429), U+2028 (LINE
SEPARATOR, native to the Unicode standard).  Especially U+0085 could
be considered as a line terminator by some implementations which are
closely related to an EBCDIC environment (AFAIK, this control
character is used to represent a line-terminating EBCDIC control
character when using one of the bijective EBCDIC <-> ISO 8859 maps).

So 8-bit data signed by a text-mode signature should not include the
following octets: 0x0a, 0x0d, 0x85 (ISO 8859 represenation of NEL),
the octet sequence 0xc2 0x85 (UTF-8 representation of NEL), and the
octet sequence 0xe2 0x80 0xa8, which is the UTF-8 representation of
the LINE SEPERATOR character.  This does not include any legacy ;-)
East-Asia encodings (which might be used instead of UTF-8 for encoding
the signed text), and overlong UTF-8 sequences (which are not
permitted in theory, but implementations might disagree).

Given these problems, I think it's not wise to assume that text-mode
signatures are binary-transparent in any way.

> > (USEFOR currently overrides the analogous requirement in RFC 2015.)
> 
> I hope you're joking.

No, I'm afraid. :-/

> Could you please send the relevant sections from the latest usefor
> draft to this list?

I think you've already found them.  I've raised this issue as well on
the list, hopefully it is addressed properly.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

From: [email-masked]
Date: Sun, 15 Apr 2001 00:20:44 -0700
To: [email-masked]
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Sender: [email-masked]

Thomas Roessler writes:
> Thus, Ulf's question remains valid: If you follow the old behaviour
> in one of the more important fields of application anyway, why on
> earth didn't you make sure RFC 2440 and your applications followed
> this kind of behaviour in general?  After all, he had indeed warned
> of the inconsistency introduced by RFC 2440.

It is true, Ulf posted on this twice, on 16 Sep 98:

   |   0x01: Signature of a canonical text document.
   |       Typically, this means the signer owns it, created it, or
   |       certifies that it has not been modified.  The signature is
   |       calculated over the text data with its line endings converted to
   |       <CR><LF> and trailing blanks removed.
   
   Trailing blanks are removed _only_ for cleartext signatures, in the
   transformation described in section 7.1. Otherwise (for signatures
   contained in a PGP message, and for detached signatures) they are part
   of the signature.
   
   BTW, there's no proper definition of detached signatures in the draft.
   They probably should be mentioned in section 10 because they are used
   for PGP/MIME.

and again on 13 Oct 98:

   Looks good, but the definition for the canonical text signature is
   still wrong. (Also I note you didn't include the note about PGP 2.6.x
   being unable to hande signature and pubkey packets of length type 0.)
   
   |   0x01: Signature of a canonical text document.
   |       Typically, this means the signer owns it, created it, or
   |       certifies that it has not been modified.  The signature is
   |       calculated over the text data with its line endings converted to
   |       <CR><LF> and trailing blanks removed.
   
   Trailing blanks are removed _only_ for cleartext signatures, in the
   transformation described in section 7.1. Otherwise (for signatures
   contained in a PGP message, and for detached signatures) they are part
   of the signature.

The RFC issued on 11 Nov 98 without this change.

I can't account for our overlooking these two comments.  It was an error
on my part and that of the other authors.  No process is perfect.

I note that the current RFC2440bis draft still has the incorrect language.

Should we change the new draft to document the way the commercial versions
of PGP, and versions 2.X, have always worked?

Hal

Date: Sat, 14 Apr 2001 20:30:14 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On 2001-04-14 11:06:18 -0700, [email-masked] wrote:

> First, my description above referred to the behavior of NAI's
> commercial implementation of PGP on PGP/MIME messages.  RFC 2440
> does not discuss PGP/MIME messages, so it would not be
> appropriate to put such information into RFC 2440.

PGP/MIME makes use of the OpenPGP format.  

It says very clearly what's the signed material, and that an OpenPGP
signatur is generated.  This means, of course, that no changes
should be done to the signed material beyond what the OpenPGP spec
mandates.

In particular, PGP/MIME does NOT define any new hash methods, or new
canonification methods to be performed by the back-end. It just
refers the reader to the OpenPGP (or PGP) specification for all
these points.

Thus, Ulf's question remains valid: If you follow the old behaviour
in one of the more important fields of application anyway, why on
earth didn't you make sure RFC 2440 and your applications followed
this kind of behaviour in general?  After all, he had indeed warned
of the inconsistency introduced by RFC 2440.

But, anyway, the new spec resolves this by prohibiting trailing
whitespace, which brings other problems, but seems to be the only
compatible way out of this mess.

-- 
Thomas Roessler			    <[email-masked]>

From: [email-masked]
Date: Sat, 14 Apr 2001 11:06:18 -0700
To: [email-masked]
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Sender: [email-masked]

From: Ulf =?iso-8859-1?Q?M=F6ller?= <[email-masked]>
> On Tue, Feb 13, 2001 at 03:59:37PM -0800, [email-masked] wrote:
>
> > I can tell you that on message receipt, the commercial versions of PGP
> > from Network Associates DO hash trailing whitespace on PGP/MIME messages.
> > That is, they are sensitive to the presence of trailing whitespace and
> > it is included in the hash.  This is true regardless of whether the
> > signature type byte is text or binary mode.  That may or may not be
> > compatible with the spec but that is how these versions work.
>
> Then why did you guys refuse to change the OpenPGP specification when
> the inconsistency was pointed out well before RFC 2440 was published?

First, my description above referred to the behavior of NAI's commercial
implementation of PGP on PGP/MIME messages.  RFC 2440 does not discuss
PGP/MIME messages, so it would not be appropriate to put such information
into RFC 2440.

Second, RFC 2440 is not perfect and does have errors.  These are not the
result of stubborn refusal to make changes and insistence on putting out
an imperfect draft.  Rather, mistakes are made in both the drafting and
editing process, and sometimes comments are overlooked.

Hal

From: Ulf =?iso-8859-1?Q?M=F6ller?= <[email-masked]>
To: [email-masked]
Date: Sat, 14 Apr 2001 10:37:37 -0400
Subject: Re: PGP/MIME implementors: text mode vs. binary mode?
Sender: [email-masked]

On Tue, Feb 13, 2001 at 03:59:37PM -0800, [email-masked] wrote:

> I can tell you that on message receipt, the commercial versions of PGP
> from Network Associates DO hash trailing whitespace on PGP/MIME messages.
> That is, they are sensitive to the presence of trailing whitespace and
> it is included in the hash.  This is true regardless of whether the
> signature type byte is text or binary mode.  That may or may not be
> compatible with the spec but that is how these versions work.

Then why did you guys refuse to change the OpenPGP specification when
the inconsistency was pointed out well before RFC 2440 was published?

Date: Sat, 14 Apr 2001 11:23:12 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-usefor-article-04.txt: 6.21.3 considered harmful.
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

I'm writing as one of the co-authors of
draft-ietf-openpgp-mime-06, which is hoped to become the
successor of RFC 2015 (PGP/MIME) soon.

In section 6.21.3 of draft-*-article-04, you write the following:

   In the same way, Content-Types requiring special processing for
   their display, such as "application", "image", "audio", "video"
   and "multipart/related" are discouraged except in groups
   specifically intended (by policy or custom) to include them.
   Exceptionally, those application types defined in [RFC 1847] and
   [RFC 2015] for use within "multipart/signed" articles, and the
   type "application/pgp-keys" (or other similar types containing
   digital certificates) may be used freely but, contrary to [RFC
   2015] and unless the article is intended to be sent by mail also,
   the Content-Transfer-Encoding SHOULD be left as "8bit" (or "7bit"
   as appropriate).

I consider this section harmful for various reasons.

First, it should be noted that problems with transmitting 8bit
content are not the only reason for which an agent implementing
PGP/MIME may elect to use quoted-printable or base64 as a body
part's encoding.

In particular, draft-ietf-openpgp-mime-06 specifies that the signed
material in a PGP/MIME multipart/signed entity MUST NOT include any
trailing whitespace.  This may either be achieved by cutting off
trailing whitespace, or by protecting it with an appropriate
transfer encoding.

The reason for this lies in the definition of a text-mode signature
in RFC 2440 [OpenPGP], which is incompatible with the definition
used by traditional implementations (aka pgp version 2).

More precisely, a text-mode signature traditionally meant that any
line feed has to be canonicalized to CR LF before hashing.  With
OpenPGP, trailing whitespace is additionally snipped.  (That's the
kind of processing which has traditionally been applied to
clearsigned messages.)

Now, the processing rules for multipart/signed make sure that line
feeds are canonical before they hit the signing engine.  With
traditional PGP, that meant that text-mode and binary-mode hashes of
the material would be identical.  This is no longer valid with
OpenPGP, which has two consequences:  (1) In order to determine what
hash is to be computed, a receiving agent would have to look at the
signature.  This would break the possibility to process
multipart/signed in one pass.   (2) In the presence of trailing
whitespace, text-mode signatures wouldn't be interoperable between
implementations using PGP 2 and OpenPGP implementations.

The best way to fix both problems is to make sure that no trailing
whitespace is present, by applying appropriate encodings.  (With
text/plain; format=flowed, this will be something which is
encountered quite frequently.)

For this reason alone, mandating transparent encodings may not be
the best idea at this point.

It should also be noted it's impossible to convert a
multipart/signed entity which contains 8bit body parts to any 7bit
format without breaking the signature.  (Remember that MIME
explicitly forbids nested MIME encodings: Recoding has to happen on
the leaf level of a nested MIME structure.)

This implies, that a multipart/signed entity wihich contains 8bit
body parts cannot be legally transported via Internet e-mail without
ruining the signature - be it as part of message/rfc822
encapsulation, be it as a direct attachment.

Finally, I'd like to warn you that signature generation and
verification interoperability may seriously be endangered by
allowing 8bit body parts in a multipart/signed.

More precisely, a multipart/signed body part may generally contain
textual data in various character sets - it may even contain a
nested multipart/mixed with text/plain subparts which bear different
character sets.

However, PGP signature generators and verifiers have traditionally
been expecting that they are presented with data in a local
character set when preparing text-mode signatures.  For this reason,
signature generators and verifiers may attempt to recode data they
are presented with to whatever character set is considered to be
canonical (utf-8 with OpenPGP, iso-latin-1 or koi-8 with pgp 2).
When applying such (unnecessary) transformations to 8bit messages in
on-the-wire-format (which would inevitably happen when a
multipart/signed is verified or generated), interoperability will,
of course, be ruined.

Restricting the signed material to 7bit data also helps to make
signature generation and verification more robust against such
problems, and implementations considerably simpler.

For all these reasons, I urge the Usenet format working group to
remove the reference to multipart/signed from section 6.21.3.

-- 
Thomas Roessler			    <[email-masked]>

Date: Sat, 14 Apr 2001 09:55:29 +0200
From: Thomas Roessler <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt
Mail-Followup-To: Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2001-04-14 01:33:53 +0200, Florian Weimer wrote:

>>   Multipart/signed and multipart/encrypted are to be treated by
>>   agents as opaque, meaning that the data is not to be altered
>>   in any way [2], [7]. However, many existing mail gateways
>>   will detect if the next hop does not support MIME or 8-bit
>>   data and perform conversion to either Quoted-Printable or
>>   Base64.  This presents serious problems for multipart/signed,
>>   in particular, where the signature is invalidated when such
>>   an operation occurs.  For this reason all data signed
>>   according to this protocol MUST be constrained to 7 bits
>>   (8-bit data MUST be encoded using either Quoted-Printable or
>>   Base64).

> of the 7 bit constraint fails to mention the binary/text mode
> signature interoperability problem which can only be addressed if
> there aren't any 8-bit characters.

Eh?  It may be because I didn't have any coffee so far, but somehow,
I don't understand what you are trying to say here.  

The text/binary mode interop problem is related to trailing
whitespace.  It is not related to the presence or absence 8bit
characters.  The next section basically says that, and makes
suggestions on how to fix things:

   Additionally, implementations MUST make sure that no trailing
   whitespace is present after the MIME encoding has been applied.
   
   Note: In most cases, trailing whitespace can either be removed,
   or protected by applying an appropriate
   content-transfer-encoding. However, special care must be taken
   when any header lines - either in MIME entity headers, or in
   embedded RFC 822 headers - are present which only consist of
   whitespace: Such lines must be removed entirely, since replacing
   them by empty lines would turn them into header delimiters, and
   change the semantics of the message.  The restrictions on
   whitespace are necessary in order to make the hash calculated
   invariant under the text and binary mode signature mechanisms
   provided by OpenPGP [1].  Also, they help to avoid compatibility
   problems with PGP implementations which predate the OpenPGP
   specification.

   Note: If any line begins with the string "From ", it is strongly
   suggested that either the Quoted-Printable or Base64 MIME
   encoding be applied.  If Quoted-Printable is used, at least one
   of the characters in the string should be encoded using the
   hexadecimal coding rule.  This is because many mail transfer and
   delivery agents treat "From " (the word "from" followed
   immediately by a space character) as the start of a new message
   and thus insert a right angle-bracket (>) in front of any line
   beginning with "From " to distinguish this case, invalidating the
   signature.
	    
Of course, implementations are free to find other
standards-compliant ways of protecting whitespace - however, I doubt
they'll find such ways.

> (USEFOR currently overrides the analogous requirement in RFC 2015.)

I hope you're joking.  Could you please send the relevant sections
from the latest usefor draft to this list?

-- 
Thomas Roessler			    <[email-masked]>

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt
From: Florian Weimer <[email-masked]>
Date: 14 Apr 2001 01:33:53 +0200
Lines: 31
Sender: [email-masked]

[email-masked] writes:

> 	Title		: MIME Security with OpenPGP
> 	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
> 	Filename	: draft-ietf-openpgp-mime-06.txt
> 	Pages		: 13
> 	Date		: 10-Apr-01

I know it's too late know, but while reviewing the current USEFOR
draft, I discovered that the explanation

|   Multipart/signed and multipart/encrypted are to be treated by agents
|   as opaque, meaning that the data is not to be altered in any way [2],
|   [7]. However, many existing mail gateways will detect if the next hop
|   does not support MIME or 8-bit data and perform conversion to either
|   Quoted-Printable or Base64.  This presents serious problems for
|   multipart/signed, in particular, where the signature is invalidated
|   when such an operation occurs.  For this reason all data signed
|   according to this protocol MUST be constrained to 7 bits (8-bit data
|   MUST be encoded using either Quoted-Printable or Base64).

of the 7 bit constraint fails to mention the binary/text mode
signature interoperability problem which can only be addressed if
there aren't any 8-bit characters.

(USEFOR currently overrides the analogous requirement in RFC 2015.)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Wed, 11 Apr 2001 10:22:23 -0700
To: [email-masked]
From: John  W Noerenberg II <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-mime-06.txt
Sender: [email-masked]

At 7:01 AM -0400 4/11/01, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the An Open Specification for Pretty 
>Good Privacy Working Group of the IETF.
>
>	Title		: MIME Security with OpenPGP
>	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
>	Filename	: draft-ietf-openpgp-mime-06.txt
>	Pages		: 13
>	Date		: 10-Apr-01

I have requested Jeff and Marcus review -06, and submit it to the 
IESG for promotion to Proposed Standard as soon as possible.  Thanks 
to everyone for your contributions to this!  Thanks especially to the 
editors who have worked diligently to get it to this point.  We'll 
have congratulations all around when the draft gets its RFC number.

Forgive my US-centric quote, but all the time I spend on PGP I think 
about what PGP means to everyone on the net, in the US and elsewhere. 
Dr. Lessig's observations about privacy and freedom of speech are 
never far from my mind.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   Two hundred years after the framers ratified the Constitution, the
   Net has taught us what the First Amendment really means.
   -- Lawrence Lessig, "Code And Other Laws of Cyberspace", 1999
   ----------------------------------------------------------------------

Date: Wed, 11 Apr 2001 09:55:37 -0700
To: Thomas Roessler <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: PGP/MIME: Last-minute editorial nits.
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]

At 7:06 PM +0200 4/9/01, Thomas Roessler wrote:
>John: I hope the last change is within the limits of due process for
>things which can be done after Last Call.  Please send me a short
>confirmation of that; I'll then finally submit draft-06. ;-)

This was just dandy. <grin>
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

Date: Wed, 11 Apr 2001 08:53:35 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: SHA256 ?
Sender: [email-masked]

At 3:49 PM +0200 4/11/01, [email-masked] wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>isn't it time to define new algorithm numbers for SHA2 ?
>8 for SHA256 (and maybe 9,10 for SHA384,512?)
>
>the bigger problem however is with OIDs...
>none of SHA2 have OIDs defined, just like HAVAL and TIGER :(
>

That is, in fact, the bigger problem. We can either finesse it -- we agree
on an OID to use for them -- or we wait for some other OID space to assign
them.

	Jon
-- 

From: [email-masked]
Date: Wed, 11 Apr 2001 15:49:21 +0200
To: [email-masked]
Subject: SHA256 ?
Sender: [email-masked]

isn't it time to define new algorithm numbers for SHA2 ?
8 for SHA256 (and maybe 9,10 for SHA384,512?)

the bigger problem however is with OIDs...
none of SHA2 have OIDs defined, just like HAVAL and TIGER :(

== <EOF> ==
Disastry  http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^---PGP 2.6.3ia-multi03 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
     AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-mime-06.txt
Date: Wed, 11 Apr 2001 07:01:16 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-06.txt
	Pages		: 13
	Date		: 10-Apr-01
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[email-masked]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
Subject: Re: Plug-ins and PGP/MIME (was RE: Java Implementation)
From: Florian Weimer <[email-masked]>
Date: 10 Apr 2001 18:22:32 +0200
Lines: 17
Sender: [email-masked]

[email-masked] writes:

> That makes sense, since we were testing against the Outlook plug-in.
> It seems that this issue is a real barrier against adoption of
> PGP/MIME, though.

Is it possible to write a plug-in for Exchange which removes or adds
some additional transport armor before a message distributed using
proprietary technology over the LAN is injected into the Net?

This way, access to message headers would not be strictly necessary at
the client system.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Tue, 10 Apr 2001 11:21:32 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: PGP/MIME aware MUAs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi,

is there a list of PGP/MIME aware clients available or could we
gather some newer info to enhance the table available under

http://cryptorights.org/pgp-users/pgp-mail-clients.html

?

Here is a first update:

Sylpheed support PGP/MIME natively (with gpg installed), signed and
encrypted mail is created using the canoncial PGP/MIME method.
The combined method can however be handled on recieving mails.

ciao,

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code           et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

Date: Mon, 9 Apr 2001 19:06:07 +0200
From: Thomas Roessler <[email-masked]>
To: John W Noerenberg II <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: PGP/MIME: Last-minute editorial nits.
Mail-Followup-To: John W Noerenberg II <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

I'll put the following last-minute changes which have not yet been
discussed or announced here into draft-ietf-openpgp-mime-06.txt:

- Replace OpenPGP Working Group by Network Working Group (Since
  that's what's on RFCs).

- Fix the copyright notes to say Copyright (C) ISOC 2001 (instead of
  2000).

- In section 5 (OpenPGP signed data), paragraph 2, I'd like to
  change the wording like this:
  
   The "micalg" parameter for the "application/pgp-signature" protocol
   MUST contain exactly one hash-symbol of the format
  -"pgp-<hash-symbol>", where <hash-symbol> identifies the Message
  +"pgp-<hash-identifier>", where <hash-identifier> identifies the
   Message Integrity Check (MIC) algorithm used to generate the
   signature. Hash-symbols are constructed from the text names
   registered in [1] or according to the mechanism defined in that
   document by converting

  This is to avoid any confusion which may be caused by the fact
  that, in the old wording, hash-symbol refers to pgp-md5 as well as
  to md5.

John: I hope the last change is within the limits of due process for
things which can be done after Last Call.  Please send me a short
confirmation of that; I'll then finally submit draft-06. ;-)

Thanks,
-- 
Thomas Roessler			    <[email-masked]>

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re:  purpose of the checksum?
Date: Sat, 7 Apr 2001 19:31:21 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0113_01C0BF99.53605EA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

>As this is so, what is the purpose of the checksum?
>=20
- From context, I gather you're talking about the ASCII armor checksum,
not the encrypted checksums inside key or session key packets?

The purpose is simply to reduce transmission accidents, which is the
point to armoring in general.  As you observed, the (dearmored) PGP
packets are complete without it, and can be properly interpreted.  An
OpenPGP implementation certainly *could* insist on it being complete.

Note that the armor checksum is done on the entire *encoded* message,
not the plaintext, so it does not deter malicious alterations.  The
OpenPGP draft now includes a modification detection code to address
malicious alteration or truncation.

------=_NextPart_000_0113_01C0BF99.53605EA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3314.2100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#f7efdd>
<DIV>-----BEGIN PGP SIGNED MESSAGE-----</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;As this is so, what is the purpose of the checksum?<BR>&gt; =
<BR>- From=20
context, I gather you're talking about the ASCII armor checksum,<BR>not =
the=20
encrypted checksums inside key or session key packets?</DIV>
<DIV>&nbsp;</DIV>
<DIV>The purpose is simply to reduce transmission accidents, which is=20
the<BR>point to armoring in general.&nbsp; As you observed, the =
(dearmored)=20
PGP<BR>packets are complete without it, and can be properly =
interpreted.&nbsp;=20
An<BR>OpenPGP implementation certainly *could* insist on it being=20
complete.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Note that the armor checksum is done on the entire *encoded*=20
message,<BR>not the plaintext, so it does not deter malicious =
alterations.&nbsp;=20
The<BR>OpenPGP draft now includes a modification detection code to=20
address<BR>malicious alteration or truncation.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-----BEGIN PGP SIGNATURE-----<BR>Version: PGP Personal Privacy =
6.5.3</DIV>
<DIV>&nbsp;</DIV>
<DIV>iQEVAwUBOs+jOmNDnIII+QUHAQGRiQf+MojoFO08xGr57VDGLXXCxHELqOMzfhGy<BR>=
PTmXfIT4JjVdd5q7ifEihXzcpzP+YNhyraDTqCvyBKH0jUZU9Tqjnb09IoMaOXd6<BR>YOTM5=
HKXW6+C+MURcbQb3v5jzolnEKI4kc5whk9Zq331oFNSDbQlGcTRrD/LS4p0<BR>NbqkxEVEsy=
AeDczUMv4BZuj5GjaIRX5BRY1zm3ycjoDeQgbdVOHAvfZPxx8XxDqZ<BR>VrNRaBjISjTfDMv=
X11O3VO7W84ozdZYA6X0Je1aVdBhHDDL3Oa0XhSZESgKJWgA1<BR>V7mGncQzwqJ29unLZTSv=
rpsE1+6r68Jjb9SVb9YCwlr71Iy0Y4Fr0Q=3D=3D<BR>=3DRO9X<BR>-----END=20
PGP SIGNATURE-----<BR></DIV></BODY></HTML>

------=_NextPart_000_0113_01C0BF99.53605EA0--

From: [email-masked]
Date: Sun, 8 Apr 2001 13:03:31 +0000 (GMT+01:00)
Cc: <[email-masked]>
To: <[email-masked]>
Subject: Plug-ins and PGP/MIME (was RE: Java Implementation)
Sender: [email-masked]

--Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO
Content-type: text/plain

That makes sense, since we were testing against the Outlook plug-in.  It 
seems that this issue is a real barrier against adoption of PGP/MIME, though. 
 Outlook is so far and away the dominant email client that it doesn't seem 
likely that PGP/MIME will get far if it can't be used in a plug-in.  (I 
don't really see Microsoft building in an OpenPGP implementation anytime 
in the near future.)

Brian Smith

At Sat, 7 Apr 2001 10:46:05 -0400, "Damon Gallaty" <[email-masked]> wrote:

>
>Actually, we do implement PGP/MIME where we can. Naturally, it requires
>access to the mail headers, and not all mail apps give plug-ins that 
>kind of
>control. Unfortunately, out of all the plug-ins we currently have, only 
>the
>Eudora plug-in is able to both create and interpret PGP/MIME.
>
>- Damon Gallaty
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of [email-masked]
>> Sent: Saturday, April 07, 2001 6:13 AM
>> To: [email-masked]
>> Subject: Re: Java Implementation
>>
>>
>> Since the toolkit is intended for use with the same key servers that 
>are
>> used for HushMail.com, our standard licensing is on a per-key-registered
>> basis.  I'm sure we could work something out for use outside that 
>context.
>>
>> It is fully compliant with 2440, but some of the "SHOULD"
>> algorithms aren't
>> packaged with it at this point.  Our approach to MIME is
>> initially not standard,
>>  because, among other things, we wanted interoperability with the 
>Network
>> Associates PGP users, and Network Associates PGP doesn't seem to
>> implement
>> PGP/MIME, even though there's a checkbox for it?!?
>>
>> Get in touch with me off the list, let me know what your specific
>> requirements
>> are, and we'll see what we can work out.
>>
>> Thanks,
>> Brian
>>
>> At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), [email-masked] wrote:
>>
>> >
>> >    Under what kind of licensing will it be released ?
>> >    Will this SDK comply fully with OpenPGP ?
>> >
>> >    Thanks in advance,
>> >    Jacques
>> >
>> >----- Original Message -----
>> >From: <[email-masked]>
>> >To: <[email-masked]>; <[email-masked]>
>> >Sent: Sunday, April 01, 2001 9:30 AM
>> >Subject: Java Implementation
>> >
>> >
>> >> Jacques Exelrud was recently inquiring about the availability of 
>a
>> >complete
>> >> Java implementation of OpenPGP.  We have one in our SDK, which 
>will
>> >be
>> >powering
>> >> the soon-to-be-released HushMail Version 2.  It's intended for 
>use
>> >with
>> >> our keyserver network and OpenPGP CA.  The source will be published
>> >with
>> >> the release of HushMail V2.  If interested, let me know.
>> >>
>> >> Regards,
>> >> Brian Smith
>> >>
>> >>
>> >> * * * * * * * * * * * * * * * * * * * * *
>> >> S. Brian Smith
>> >> Director of Research and Development
>> >> Hush Communications
>> >> Email: [email-masked]
>> >> Mobile: +353 86 809 2163
>> >> Tel: +353 1 241 0325
>> >> Fax:  +353 1 241 0370
>> >> Website: www.hush.com
>> >>
>> >>

Free, encrypted, secure Web-based email at www.hushmail.com
--Hushpart_boundary_lQVjiCHfziJByKyzKWziTTmrlwCjrmEO--

Reply-To: <[email-masked]>
From: "Damon Gallaty" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Java Implementation
Date: Sat, 7 Apr 2001 10:46:05 -0400
Importance: Normal
Sender: [email-masked]

Actually, we do implement PGP/MIME where we can. Naturally, it requires
access to the mail headers, and not all mail apps give plug-ins that kind of
control. Unfortunately, out of all the plug-ins we currently have, only the
Eudora plug-in is able to both create and interpret PGP/MIME.

- Damon Gallaty

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Saturday, April 07, 2001 6:13 AM
> To: [email-masked]
> Subject: Re: Java Implementation
>
>
> Since the toolkit is intended for use with the same key servers that are
> used for HushMail.com, our standard licensing is on a per-key-registered
> basis.  I'm sure we could work something out for use outside that context.
>
> It is fully compliant with 2440, but some of the "SHOULD"
> algorithms aren't
> packaged with it at this point.  Our approach to MIME is
> initially not standard,
>  because, among other things, we wanted interoperability with the Network
> Associates PGP users, and Network Associates PGP doesn't seem to
> implement
> PGP/MIME, even though there's a checkbox for it?!?
>
> Get in touch with me off the list, let me know what your specific
> requirements
> are, and we'll see what we can work out.
>
> Thanks,
> Brian
>
> At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), [email-masked] wrote:
>
> >
> >    Under what kind of licensing will it be released ?
> >    Will this SDK comply fully with OpenPGP ?
> >
> >    Thanks in advance,
> >    Jacques
> >
> >----- Original Message -----
> >From: <[email-masked]>
> >To: <[email-masked]>; <[email-masked]>
> >Sent: Sunday, April 01, 2001 9:30 AM
> >Subject: Java Implementation
> >
> >
> >> Jacques Exelrud was recently inquiring about the availability of a
> >complete
> >> Java implementation of OpenPGP.  We have one in our SDK, which will
> >be
> >powering
> >> the soon-to-be-released HushMail Version 2.  It's intended for use
> >with
> >> our keyserver network and OpenPGP CA.  The source will be published
> >with
> >> the release of HushMail V2.  If interested, let me know.
> >>
> >> Regards,
> >> Brian Smith
> >>
> >>
> >> * * * * * * * * * * * * * * * * * * * * *
> >> S. Brian Smith
> >> Director of Research and Development
> >> Hush Communications
> >> Email: [email-masked]
> >> Mobile: +353 86 809 2163
> >> Tel: +353 1 241 0325
> >> Fax:  +353 1 241 0370
> >> Website: www.hush.com
> >>
> >>
> >>
> >>
> >> Free, encrypted, secure Web-based email at www.hushmail.com
> >
> >
> >
> >Free, encrypted, secure Web-based email at www.hushmail.com
> >
> Free, encrypted, secure Web-based email at www.hushmail.com

From: "Al Sutton" <[email-masked]>
To: <[email-masked]>
Subject: Key sharing
Date: Sat, 7 Apr 2001 13:00:09 +0100
Sender: [email-masked]

All,

Would this be the right group to look at OpenPGP key servers and the
protocols used to obtain keys from them, and the protocols they use to share
information between them.

The reason I ask is that there seem to be some de facto standards with
little or no documentation.

Regards,

Al.

From: [email-masked]
Date: Sat, 7 Apr 2001 10:12:37 +0000 (GMT+01:00)
To: [email-masked]
Subject: Re: Java Implementation
Sender: [email-masked]

--Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK
Content-type: text/plain

Since the toolkit is intended for use with the same key servers that are 
used for HushMail.com, our standard licensing is on a per-key-registered 
basis.  I'm sure we could work something out for use outside that context.

It is fully compliant with 2440, but some of the "SHOULD" algorithms aren't 
packaged with it at this point.  Our approach to MIME is initially not standard,
 because, among other things, we wanted interoperability with the Network 
Associates PGP users, and Network Associates PGP doesn't seem to implement 
PGP/MIME, even though there's a checkbox for it?!?

Get in touch with me off the list, let me know what your specific requirements 
are, and we'll see what we can work out.

Thanks,
Brian

At Sat, 7 Apr 2001 10:11:26 +0000 (GMT+01:00), [email-masked] wrote:

>
>    Under what kind of licensing will it be released ?
>    Will this SDK comply fully with OpenPGP ?
>
>    Thanks in advance,
>    Jacques
>
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Sunday, April 01, 2001 9:30 AM
>Subject: Java Implementation
>
>
>> Jacques Exelrud was recently inquiring about the availability of a
>complete
>> Java implementation of OpenPGP.  We have one in our SDK, which will 
>be
>powering
>> the soon-to-be-released HushMail Version 2.  It's intended for use 
>with
>> our keyserver network and OpenPGP CA.  The source will be published 
>with
>> the release of HushMail V2.  If interested, let me know.
>>
>> Regards,
>> Brian Smith
>>
>>
>> * * * * * * * * * * * * * * * * * * * * *
>> S. Brian Smith
>> Director of Research and Development
>> Hush Communications
>> Email: [email-masked]
>> Mobile: +353 86 809 2163
>> Tel: +353 1 241 0325
>> Fax:  +353 1 241 0370
>> Website: www.hush.com
>>
>>
>>
>>
>> Free, encrypted, secure Web-based email at www.hushmail.com
>
>
>
>Free, encrypted, secure Web-based email at www.hushmail.com
>
Free, encrypted, secure Web-based email at www.hushmail.com
--Hushpart_boundary_fXDrMIjykrYRSxYOioNaQRCvgnpVNSbK--

content-class: urn:content-classes:message
Subject: Elliptic Curves
Date: Fri, 6 Apr 2001 17:24:30 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Now that we are done with mime, is anybody interessted in adding
ECC/ECDSA to the open-pgp standard?

I think it would be time to do so and it won't be hard to specify
(for those who had implemented elliptic curves in some context it
is very clear what algorithm-specific values are needed).

-- 
Dominikus Scherkl

From: [email-masked]
Date: Thu, 5 Apr 2001 09:16:35 -0700
To: [email-masked]
Subject: RE: Interesting attack to DSA
Sender: [email-masked]

The newsgroup posting by Vlastimil Klima, one of the Czech researchers
who identified the problems associated with potential modifications to
the secret key file, has now appeared on my local news server.  (He also
sent me a copy personally.)  It also includes the text of the attack
posted to sci.crypt which could work even with mathematical checks of
the consistency of the DSS key.  This attack is far less powerful than
the original Czech attack, which was itself of highly limited impact
IMO. But here are the messages, for future reference:

> From: "Vlastimil Klima" <[email-masked]>
> Newsgroups: sci.crypt
> References: <[email-masked]> <[email-masked]> <[email-masked]>
> Subject: Re: Is this a solution to the PGP flaw
> Date: Tue, 3 Apr 2001 12:00:10 +0200
> Lines: 68
> Organization: Decros Ltd., ICZ Group, Prague, Czech Republic
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> NNTP-Posting-Host: brana.i.cz
> X-Original-NNTP-Posting-Host: brana.i.cz
> Message-ID: <[email-masked]>
> X-Trace: 3 Apr 2001 11:02:25 +0100, brana.i.cz
> Path: news.cvut.cz!brana.i.cz
> Xref: news.cvut.cz sci.crypt:151235
>
> Great observation!
>
> In the article "Breaking Public Key Cryptosystems on Tamper Resistance
> Devices in the Presence of Transient Faults" by Bao, Deng, Han,
> Jeng,Narasimhalu and Ngair (Security Protocols, 1997, Springer-Verlag, LNCS
> vol. 1361, pp.115-124) is a very similar idea.
>
> Your attack needs more iterations, but it is very interesting.
>
> In our paper ( http://www.i.cz/en/pdf/openPGP_attack_ENGvktr.pdf), section
> 7, we proposed "temporary tests (say for a patch) " and "future
> countermeasures".  On the temporary tests we said
> "....We stress out that the aforesaid test is not to be a substitute for the
> missing check of integrity of the file with the private key but it is to
> serve as a temporary measure which prevents the herein specified attack..."
> and at section 7.2 we said:
> "...Let us also note that whereas such type of tests as we already mentioned
> is trusted a lot, for instance in RSA, in case of DSA we have to be careful.
> Unlike RSA there is only one value here (private key x), unknown by the
> attacker. Other parameters are known by the attacker and it may change them
> at its own discretion. This is a reason, why this test is considered only a
> temporary solution, which must be replaced as soon as possible with another
> type of check of integrity of the discussed records, as hereafter specified.
> "
>
> Our recommendations are expressed in section 7.4 of the paper.
>
> Vlastimil Klima and Tomas Rosa
>
> "lcs Mixmaster Remailer" <[email-masked]> wrote in message
> news:[email-masked]...
> > Here is another variant on the attack which will still work even if
> > the recommended mathematical checks are done.  However it leaks only a
> > small amount of information about the secret key.
> >
> > We have g^q = 1 mod p; g^x = y mod p; q | (p-1), etc.  Now suppose an
> > attacker wants to learn if x is even or odd.
> >
> > He can toggle the low order bit of x by xoring into the ciphertext.
> > As is well known, in CFB mode, such an xor goes through to the
> > plaintext at the cost of disturbing the following block of plaintext.
> > (CBC has similar properties, but with the roles of the two plaintext
> > blocks reversed.)
> >
> > Toggling the low order bit of x will either increment it or decrement
> > it, depending on whether x is even or odd.  This will cause y to be
> > either multiplied by g, or divided by g.
> >
> > The attacker makes a guess about x being even or odd, toggles the bit
> > and adjusts y accordingly.  (He also has to adjust the checksum, which
> > he can do with 50% success.)  The resulting key is perfectly
> > consistent mathematically, if his guess was correct.
> >
> > Then he sees if the user is able to use the key, or if he gets an
> > error.  If there is no error, the attacker knows he guessed right
> > about the low bit of x.
> >
> > In some circumstances it may be possible for the attack to be mounted
> > repeatedly and gradually learn more bits.  For example, if the attack
> > is possible because the key is stored on a network file system, as Dr.
> > Klima proposes, the user may re-run PGP repeatedly when he gets an
> > error, thinking he is typing his passphrase wrong.  In some
> > configurations this will re-fetch the secret key ring each time, and
> > the attacker can modify a different bit of x each time.  He can learn
> > almost 128 bits of x in the best case.  With this advantage, brute
> > forcing the remaining bits of x may be possible.

From: "Rita de Groot" <[email-masked]>
To: <[email-masked]>
Subject: huidziekte
Date: Thu, 5 Apr 2001 10:59:50 +0200
Sender: [email-masked]

Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose 
reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. 
Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien..........
http://www.naardedokter.com/testimonials/sys_lup_eryth.htm

From: [email-masked]
Date: Wed, 4 Apr 2001 13:04:05 -0700
To: [email-masked], [email-masked]
Subject: Re: purpose of the checksum?
Sender: [email-masked]

vedaal nistar writes:
> As this is so, what is the purpose of the checksum?

It's to detect line noise from your 2400 baud modem.

Hal

Date: Wed, 4 Apr 2001 12:51:54 -0700
To: [email-masked]
From: John  W Noerenberg II <[email-masked]>
Subject: WG Last Call - draft-ietf-openpgp-mime - Done!
Sender: [email-masked]

At 9:55 PM -0600 3/20/01, John  W Noerenberg II wrote:
>This the Last Call for WG comments on draft-ietf-openpgp-mime.

WG LAST CALL IS NOW OVER. <sound of gavel on table><grin>  Thomas 
Roessler has a -06 draft ready, which I will submit to the ADs.
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject:  purpose of the checksum?
Date: Wed, 4 Apr 2001 15:30:52 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

The checksum of a pgp message block, can be deleted together with the
footer, from any pgp signed/encrypted/signed & encrypted message without
affecting decryptability or verifiability.
{as long as the pgp footer is deleted together with it.  if only the
checksum is deleted without the footer, there will be a message of =
<ascii
armor incomplete>}

As this is so, what is the purpose of the checksum?

vedaal nistar

- ---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.237 / Virus Database: 115 - Release Date: 3/7/01

------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4613.1700" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#f7efdd>
<DIV><FONT face=3DArial size=3D2>-----BEGIN PGP SIGNED =
MESSAGE-----</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The checksum of a pgp message block, =
can be deleted=20
together with the<BR>footer, from any pgp signed/encrypted/signed &amp;=20
encrypted message without<BR>affecting decryptability or =
verifiability.<BR>{as=20
long as the pgp footer is deleted together with it.&nbsp; if only=20
the<BR>checksum is deleted without the footer, there will be a message =
of=20
&lt;ascii<BR>armor incomplete&gt;}</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As this is so, what is the purpose of =
the=20
checksum?</FONT></DIV>
<DIV>&nbsp;</DIV><FONT face=3DArial size=3D2>
<DIV><BR>vedaal nistar</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>- ---<BR>Outgoing mail is certified Virus Free.<BR>Checked by =
AVG=20
anti-virus system (<A=20
href=3D"http://www.grisoft.com">http://www.grisoft.com</A>).<BR>Version: =
6.0.237 /=20
Virus Database: 115 - Release Date: 3/7/01</DIV>
<DIV>&nbsp;</DIV>
<DIV>-----BEGIN PGP SIGNATURE-----<BR>Version: 6.5.8ckt: build =
4&nbsp;&nbsp;=20
&lt; <A =
href=3D"http://www.ipgpp.com/">http://www.ipgpp.com/</A>&gt;<BR>Comment: =
{=20
Acts of Kindness better the World, and protect the Soul }<BR>Comment: =
KeyID:=20
0x6A05A0B785306D25<BR>Comment: Fingerprint: 96A6 5F71 1C43 8423&nbsp; =
D9AE 02FD=20
A711 97BA</DIV>
<DIV>&nbsp;</DIV>
<DIV>iQEVAwUBOsty4moFoLeFMG0lAQHpiAf+OqLfs7jdQ3/LyE8JxqKSLD7RBlPOSr2G<BR>=
CMpNtYIuLHzumbOuai/mzuSIlahJMhuRjgelqSkBXNb1s+GqkfJZ3cNdPkkrr9VC<BR>gFixg=
E1zI0ODMCcTGt4k1wIqdn2MiBrNH12pUXAebzqXQ5TgtRKJ09+hV23VLNyd<BR>K07vbZw4qU=
tj8RGdYwRXocr1CiCmqnaqtLLKKryqSfAxX4+Og3D5pPC08XNWm4vy<BR>/dIKspyjpe2dcz/=
/19I1nUn+j8AwZ1nO0j4TVtMXhpFfuAywZujTxAch8hrK1tXs<BR>uaskaKe1C8pTnTBKL1IS=
avQKddXdADQs686lteyYKpDwQzVwGwRLZA=3D=3D<BR>=3DAsoF<BR>-----END=20
PGP SIGNATURE-----<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_00BF_01C0BD1C.3C0EA2E0--

From: [email-masked]
Date: Wed, 4 Apr 2001 11:16:03 -0700
To: [email-masked]
Subject: RE: Interesting attack to DSA
Sender: [email-masked]

The answer referred to below has not yet appeared on my news reader.
Can someone who has seen it forward it to this list?

On first analysis, the attack in the thread forwarded by Lutz is not
really worth worrying about.  You have to assume a combination of an
incredibly clueless user and an extremely powerful attacker who can
control the user's file accesses to a high degree.

Hal

> From: Klima Vlastimil <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
>
> You can find our answer in the thread sci.crypt.
>
> Tomas Rosa and Vlastimil Klima
>
> Best regards
> Dr.Vlastimil Klima, Cryptologist
> DECROS Ltd. - ICZ a.s., V Olsinach 75,  100 97 Prague 10, Czech Republic
> [email-masked], http://www.decros.cz, http://www.i.cz
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 03, 2001 9:14 AM
> To: [email-masked]
> Subject: Interesting attack to DSA
>
>
> The thread news:[email-masked] and above contains a
> serious attack to DSA keys which seems to be indefeatable by the currently
> recommented secret key data.

From: Klima Vlastimil <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'mailto:[email-masked]'" <mailto:[email-masked]>
Subject: RE: Interesting attack to DSA
Date: Tue, 3 Apr 2001 12:12:04 +0200 
Sender: [email-masked]

You can find our answer in the thread sci.crypt.

Tomas Rosa and Vlastimil Klima

Best regards
Dr.Vlastimil Klima, Cryptologist
DECROS Ltd. - ICZ a.s., V Olsinach 75,  100 97 Prague 10, Czech Republic
[email-masked], http://www.decros.cz, http://www.i.cz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 03, 2001 9:14 AM
To: [email-masked]
Subject: Interesting attack to DSA

The thread news:[email-masked] and above contains a
serious attack to DSA keys which seems to be indefeatable by the currently
recommented secret key data.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Interesting attack to DSA
Date: 3 Apr 2001 07:13:49 GMT
Organization: IKS GmbH Jena
Lines: 3
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

The thread news:[email-masked] and above contains a
serious attack to DSA keys which seems to be indefeatable by the currently
recommented secret key data.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Date fields
Date: Sun, 1 Apr 2001 14:07:26 -0400
Sender: [email-masked]

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

>     For split-keys (hope that's a OpenPGP feature and not just a PGP
> feature, have not checked the rfc) it may happen that parts of this

It's an NAI feature, not part of the OpenPGP spec.  The format
of share files does not resemble a "packet" (but the encrypted
data deep inside does).  While I'd like OpenPGP to include
a "split key" packet, I certainly wouldn't suggest the NAI format.
[Note that the split key is really a split symmetric key, not
a split of the whole secret key.]

I don't think the split material has any timestamp itself.

>     For non split-keys the problem may not be as serious. What may
> happen is that the user may receive an encrypted message with the

There should never be a problem *decrypting* using an expired key.

> security/legal problem. At most the lack of certain on the date the
> message was generated because there is a one day lag the the key have

Moreover, timestamps are only as trustworthy as the party
generating them.  You can always forge an old timestamp by
setting your clock (or adjusting your software :-).

I guess I don't understand the problem you're considering.

From: "Jacques Exelrud" <[email-masked]>
To: <[email-masked]>
Subject: Re: Java Implementation
Date: Sun, 1 Apr 2001 14:18:26 -0300
Sender: [email-masked]

    Under what kind of licensing will it be released ?
    Will this SDK comply fully with OpenPGP ?

    Thanks in advance,
    Jacques

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, April 01, 2001 9:30 AM
Subject: Java Implementation

> Jacques Exelrud was recently inquiring about the availability of a
complete
> Java implementation of OpenPGP.  We have one in our SDK, which will be
powering
> the soon-to-be-released HushMail Version 2.  It's intended for use with
> our keyserver network and OpenPGP CA.  The source will be published with
> the release of HushMail V2.  If interested, let me know.
>
> Regards,
> Brian Smith
>
>
> * * * * * * * * * * * * * * * * * * * * *
> S. Brian Smith
> Director of Research and Development
> Hush Communications
> Email: [email-masked]
> Mobile: +353 86 809 2163
> Tel: +353 1 241 0325
> Fax:  +353 1 241 0370
> Website: www.hush.com
>
>
>
>
> Free, encrypted, secure Web-based email at www.hushmail.com

From: [email-masked]
Date: Sun, 1 Apr 2001 12:30:04 +0000 (GMT+01:00)
To: [email-masked], [email-masked]
Subject: Java Implementation
Sender: [email-masked]

--Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD
Content-type: text/plain

Jacques Exelrud was recently inquiring about the availability of a complete 
Java implementation of OpenPGP.  We have one in our SDK, which will be powering 
the soon-to-be-released HushMail Version 2.  It's intended for use with 
our keyserver network and OpenPGP CA.  The source will be published with 
the release of HushMail V2.  If interested, let me know.

Regards,
Brian Smith

* * * * * * * * * * * * * * * * * * * * *
S. Brian Smith
Director of Research and Development
Hush Communications
Email: [email-masked]
Mobile: +353 86 809 2163
Tel: +353 1 241 0325
Fax:  +353 1 241 0370
Website: www.hush.com

Free, encrypted, secure Web-based email at www.hushmail.com
--Hushpart_boundary_LpRIDuTDrOxWLsVbiGRgCYakmjYIZElD--