Subject: [[485343800]] Subscription to ietf-openpgp for [email-masked]

From: [email-masked]
Date: Sat, 31 Aug 2002 15:21:52 -0700 (PDT)

Greetings. This message is a periodic reminder that
     [email-masked]
is subscribed to the
     ietf-openpgp
mailing list.

There are two purposes for this message:
- If this message is bounced by your mail server, I can remove you from
  the mailing list and reduce waste of bandwidth and resources. (If you
  are reading this message, it clearly didn't get bounced!)
- Some people stay subscribed to mailing lists even though they do not
  want to because they do not know how to unsubscribe. 

If you want to stay subscribed to the ietf-openpgp mailing list,
you do not need to do anything. Feel free to delete this message.

On the other hand, if you want to unsubscribe from this list, simply go
to the following link:
     <http://www.imc.org/Unsubs/485343800>

If for some reason you cannot go to that web site, you can also
unsubscribe by email; however, doing so is not as likely to get you
unsubscribed as the web site is. To unsubscribe using email, you can
respond to this message and I will unsubscribe you by hand in the next
few days. Again, this is not assured to work because your mail system
may make it impossible for me to determine who you are or what you want
to unsubscribe to.

Alternatively, you can send a plain-text message to:
     [email-masked]
with the single word
     unsubscribe
in the body of the message. This last method assumes that the "From:"
address in your mail is "[email-masked]". Again, using the
web site above is more likely to work than this method (due to limitations
in Majordomo, the mailing list software we currently use).

If you have any questions, feel free to contact me.

--Paul Hoffman, list administrator

Date: Tue, 27 Aug 2002 16:38:17 -0700
To: (many IETF mailing lists)
From: Paul Hoffman / IMC <[email-masked]>
Subject: Nomcom call for volunteers
Sender: [email-masked]

Forwarded for Phil Roberts <[email-masked]>:

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering
to be on the nominations committee.

From: "Brian M. Carlson" <[email-masked]>
Date: Tue, 27 Aug 2002 01:24:40 +0000
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
Content-Conversion: prohibited
Sender: [email-masked]

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 24, 2002 at 11:47:39PM -0700, Jon Callas wrote:
>=20
> On 8/24/02 3:05 PM, "Brian M. Carlson" <[email-masked]> wrote:
>=20
> > I'd like to nitpick for a second. Section 12.6 states, "Note that prese=
nt
> > DSA is limited to a maximum of 1024 bit keys, which are recommended for
> > long-term use." Actually, it is DSS (the *standard*), not DSA (the
> > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we
> > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024
> > bits." This way, we can maintain backwards compatibility and compliance
> > with DSS, while providing adequate security for people who really want
> > it. Might I point out that IEEE P1363 allows for DSA keys longer than
> > 1024 bits, so there is precedent in the cryptographic community.
> >=20
>=20
> So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash
> algorithm does P1363 use with longer keys? What semantics does it have to=
 go
> with it?

I believe it uses SHA1, because it keeps the size of q the same. You will
have to subscribe to the mailing list to get the password to fetch the
document.

Mailing List:
http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html

If it doesn't exist anymore, you can email me and ask for it.
=20
> > I'd also like to suggest that we deprecate Elgamal type 16 in favor of
> > Elgamal type 20 combined with key flags. This is exactly what we did wi=
th
> > RSA types 2 and 3. It encourages implementations to implement key flags,
> > and it will lessen the usage of an encrypt-only type. It still allows
> > implementations to maintain backwards compatibility, because it does not
> > remove the type altogether.
>=20
> Well, there are people who believe that Elgamal signatures should be
> deprecated, and were a mistake to put in the standard to begin with. I th=
ink
> it's better to leave it as it is and let gentle persons continue to
> disagree.

My point is not that we enforce the use of Elgamal signatures, but that
we encourage the use of key flags to signal the purpose of the key. I
think sign-only/encrypt-only keys are broken. If someone wants to create
a type 20 key with key flags packet that says it is for encryption only,
then that person should not be required to create that key (rather,
subkey) with the strict additional conditions for signatures. I also
think implementations should accept such keys as they currently accept
type 16 keys (PGP does not, I think).

As an additional benefit, if some implementations just happen to accept
Elgamal signatures, well, ok.

--=20
Brian M. Carlson <[email-masked]> <http://decoy.wox.org/~bmc> 0x560553=
E7
Now hatred is by far the longest pleasure;
Men love in haste, but they detest at leisure.
		-- George Gordon, Lord Byron, "Don Juan"

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature
Content-Disposition: inline

Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--a8Wt8u1KmwUX3Y2C--

Date: Mon, 26 Aug 2002 15:35:11 -0700
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 8/26/02 1:56 PM, "Len Sassaman" <[email-masked]> wrote:

> I think Brian is right, though. While DSS (in FIPS 186 and ANSI X9.30)
> mandates SHA-1 and limits p to 1024 bits, OpenPGP is specifying DSA, not
> DSS.
> 

I think quibbling over the differences between DSS and DSA is as productive
as quibbling over the differences between DES and DEA. I have heard it
asserted that 3DES should actually be called 3DEA because the process of
tripling is violates the standard. Whatever. We all know what it means.

We need to figure out what the smart thing to do is, and if I need to edit
an S into an A or vice-versa, it's trivial to do that.

However, I want to quit tweaking and get a new RFC number on it.

> I understand DSA to be limited to 1024 bits when using a 160 bit hash.
> Using a larger hash would allow for larger key sizes. There has been some
> speculation that a revised DSS may be specified by NIST using the new
> larger SHA hashes. Should we anticipate this and add the new SHAs (at
> least SHA-512) to the spec?
> 

We anticipated this as of bis03, August 2000. All the wide SHAs are there.

> FWIW, I believe that one of the "ckt" unofficial builds of PGP used larger
> DSA keys with "double width SHA1". (I'm surprised, actually, that RFC 2440
> even specifies double-width SHA1, since it's my understanding that most
> cryptographers are skeptical that double-width SHA1 is any better than
> single-width SHA1 for DSA.) Shouldn't wide SHA1 be deprecated in favor of
> one of the newer NIST SHAs?

The double-wide SHA work was done pre-2440. It was done pre-me. As I
remember what I was told, it was experimental work done by Colin Plumb and
Derek Atkins, but maybe Hal Finney was involved. In any event, the present
language says, "Reserved for double-width SHA (experimental, obviated)." I
am happy to change that to say merely "Reserved" lest someone get the idea
it is useful. There are also no OIDs for DWSHA.

    Jon

Date: Mon, 26 Aug 2002 13:56:07 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: "Brian M. Carlson" <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
Sender: [email-masked]

On Sat, 24 Aug 2002, Jon Callas wrote:

> So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash
> algorithm does P1363 use with longer keys? What semantics does it have to go
> with it?

P1363 doesn't seem to be linked off of the IEEE site anymore. Does anyone
have a copy they can mirror?

I think Brian is right, though. While DSS (in FIPS 186 and ANSI X9.30)
mandates SHA-1 and limits p to 1024 bits, OpenPGP is specifying DSA, not
DSS.

I understand DSA to be limited to 1024 bits when using a 160 bit hash.
Using a larger hash would allow for larger key sizes. There has been some
speculation that a revised DSS may be specified by NIST using the new
larger SHA hashes. Should we anticipate this and add the new SHAs (at
least SHA-512) to the spec?

FWIW, I believe that one of the "ckt" unofficial builds of PGP used larger
DSA keys with "double width SHA1". (I'm surprised, actually, that RFC 2440
even specifies double-width SHA1, since it's my understanding that most
cryptographers are skeptical that double-width SHA1 is any better than
single-width SHA1 for DSA.) Shouldn't wide SHA1 be deprecated in favor of
one of the newer NIST SHAs?

--Len.

Date: Mon, 26 Aug 2002 13:11:58 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
Sender: [email-masked]

Brian M. Carlson wrote:
> I'd like to nitpick for a second. Section 12.6 states, "Note that present
> DSA is limited to a maximum of 1024 bit keys, which are recommended for
> long-term use." Actually, it is DSS (the *standard*), not DSA (the
> *algorithm*) that is limited to 1024 bits. I'd like to suggest that we
> replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024
> bits." This way, we can maintain backwards compatibility and compliance
> with DSS, while providing adequate security for people who really want
> it. Might I point out that IEEE P1363 allows for DSA keys longer than
> 1024 bits, so there is precedent in the cryptographic community.

there is precedent before that:
PGP5.5.3 can use up to 2048 bit DSA keys, but can not generate them.
PGP5.5.3ckt can use and generate up to 2048 bit DSA keys.
PGP6.5.8ckt can only use 'em.

__
Disastry  http://disastry.dhs.org/

To: OpenPGP <[email-masked]>
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sun, 25 Aug 2002 14:41:25 +0200
Lines: 27
Sender: [email-masked]

On Sat, 24 Aug 2002 23:47:39 -0700, Jon Callas said:

> Well, there are people who believe that Elgamal signatures should be
> deprecated, and were a mistake to put in the standard to begin with. I think

FWIW, the reason I implemented ElGamal for signature and encryption in
GnuPG was simply the fact that at I initially was not aware of the PGP
5 data format and there used to be claims that DSA may lead to similar
patent problems as we had with RSA.

> it's better to leave it as it is and let gentle persons continue to
> disagree.

I agree with Jon.  There are only 28 type 20 keys on the keyservers
and I see see no reason to promote the use of this type.  I'd like to
remove it from GnuPG but some folks more or less convinced me that
type 20 support should stay in GnuPG (in expert mode).

Salam-Shalom,

   Werner

Date: Sat, 24 Aug 2002 23:47:39 -0700
Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20
From: Jon Callas <[email-masked]>
To: "Brian M. Carlson" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 8/24/02 3:05 PM, "Brian M. Carlson" <[email-masked]> wrote:

> I'd like to nitpick for a second. Section 12.6 states, "Note that present
> DSA is limited to a maximum of 1024 bit keys, which are recommended for
> long-term use." Actually, it is DSS (the *standard*), not DSA (the
> *algorithm*) that is limited to 1024 bits. I'd like to suggest that we
> replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024
> bits." This way, we can maintain backwards compatibility and compliance
> with DSS, while providing adequate security for people who really want
> it. Might I point out that IEEE P1363 allows for DSA keys longer than
> 1024 bits, so there is precedent in the cryptographic community.
> 

So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash
algorithm does P1363 use with longer keys? What semantics does it have to go
with it?

> I'd also like to suggest that we deprecate Elgamal type 16 in favor of
> Elgamal type 20 combined with key flags. This is exactly what we did with
> RSA types 2 and 3. It encourages implementations to implement key flags,
> and it will lessen the usage of an encrypt-only type. It still allows
> implementations to maintain backwards compatibility, because it does not
> remove the type altogether.

Well, there are people who believe that Elgamal signatures should be
deprecated, and were a mistake to put in the standard to begin with. I think
it's better to leave it as it is and let gentle persons continue to
disagree.

    Jon

From: "Brian M. Carlson" <[email-masked]>
Date: Sat, 24 Aug 2002 22:05:06 +0000
To: [email-masked]
Subject: RFC: DSA key lengths; Elgamal type 16 v. type 20
Content-Conversion: prohibited
Sender: [email-masked]

--ZmUaFz6apKcXQszQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'd like to nitpick for a second. Section 12.6 states, "Note that present
DSA is limited to a maximum of 1024 bit keys, which are recommended for
long-term use." Actually, it is DSS (the *standard*), not DSA (the
*algorithm*) that is limited to 1024 bits. I'd like to suggest that we
replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024
bits." This way, we can maintain backwards compatibility and compliance
with DSS, while providing adequate security for people who really want
it. Might I point out that IEEE P1363 allows for DSA keys longer than
1024 bits, so there is precedent in the cryptographic community.

I'd also like to suggest that we deprecate Elgamal type 16 in favor of
Elgamal type 20 combined with key flags. This is exactly what we did with
RSA types 2 and 3. It encourages implementations to implement key flags,
and it will lessen the usage of an encrypt-only type. It still allows
implementations to maintain backwards compatibility, because it does not
remove the type altogether.

--=20
Brian M. Carlson <[email-masked]> <http://decoy.wox.org/~bmc> 0x560553=
E7
I will make you shorter by the head.
		-- Elizabeth I

--ZmUaFz6apKcXQszQ
Content-Type: application/pgp-signature
Content-Disposition: inline

Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex

--ZmUaFz6apKcXQszQ--

Date: Thu, 22 Aug 2002 19:23:13 +0100
From: Adam Back <[email-masked]>
To: OpenPGP <[email-masked]>
Cc: Adam Back <[email-masked]>
Subject: Re: Question about MDC Packets
Sender: [email-masked]

Wasn't this discussed at some point in the past and the suggestion
made that all 128 bit block ciphers use MDC as they were introduced at
roughly the same time.

That leaves the hushmail problem.  But due to their software
architecture presumably forced software upgrades are easy.  (Just
publish new java code, the fact that the cached code is more recent on
the server takes care of the rest.)  Any other implementations
ignoring this rule?

I'm guessing this discussed rule never made it into the spec.  (We
have a general issue with over laxness on compatibility issues -- as
long as it's possible in theory to interoperate, the concencus in the
past has seemed to be to stop there.)

All implementations MUST use MDC with > 64 bit block cipher algorithms
(such as AES).

Adam

On Thu, Aug 22, 2002 at 01:32:14PM -0400, David Shaw wrote:
> Seems to me that the draft already states that *all* implementations
> SHOULD be able to handle MDC packets, regardless of cipher ("An
> implementation SHOULD prefer this to the older Symmetrically Encrypted
> Data Packet when possible.").
> 
> The question is really what to do to determine when it is
> "possible". ;)

Date: Thu, 22 Aug 2002 13:32:14 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Question about MDC Packets
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Wed, Aug 21, 2002 at 10:43:19PM -0700, Len Sassaman wrote:

> We're in the process of adding AES and MDC support to Mixmaster. I need to
> decide whether to we want to go the "be liberal... but conservative" route
> and only use MDC if specified in the features subpacket, or the more
> secure route, and use MDC whenever a key lists prefs 7 through 10
> (presumably, we could do this even if we weren't actually choosing those
> ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do
> it in the latter fashion, but...
> 
> I just read over the source code for Hushmail's OpenPGP features. It
> appears that they were working off of RFC2440-bis2, and therefore didn't
> know anything about the MDC packets. Hushmail keys are generated with
> symmetric cipher prefs "9 8 7 3".  Consequently, Hushmail users cannot
> decrypt messages encrypted with AES using the MDC packet. An example key
> is attached at the bottom of this email.
> 
> It would be unfortunate to have more compatibility problems between
> implementations of OpenPGP. Would it be unreasonable to state in the spec
> that implementations supporting ciphers other than 0 through 4 SHOULD be
> able to handle the MDC packets (perhaps in the paragraph in 5.13 which
> mentions AES and Twofish currently)?

Seems to me that the draft already states that *all* implementations
SHOULD be able to handle MDC packets, regardless of cipher ("An
implementation SHOULD prefer this to the older Symmetrically Encrypted
Data Packet when possible.").

The question is really what to do to determine when it is
"possible". ;)

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Wed, 21 Aug 2002 22:43:19 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Question about MDC Packets
Sender: [email-masked]

On Mon, 22 Jul 2002, Jon Callas wrote:

> Do you know anything about who is going to be decrypting it? Do you have
> some reasonable expectation they can understand it? If so, then yes.
>
> There is nothing wrong with an implementation being somewhat weasely. If you
> make the guess that if someone wants to use AES, then the target is modern
> enough to understand an MDC, you'd probably be right. You could even
> convincingly harumph if someone does *not* use an MDC but went to the
> trouble to do AES.

Okay, hear me harumph.

We're in the process of adding AES and MDC support to Mixmaster. I need to
decide whether to we want to go the "be liberal... but conservative" route
and only use MDC if specified in the features subpacket, or the more
secure route, and use MDC whenever a key lists prefs 7 through 10
(presumably, we could do this even if we weren't actually choosing those
ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do
it in the latter fashion, but...

I just read over the source code for Hushmail's OpenPGP features. It
appears that they were working off of RFC2440-bis2, and therefore didn't
know anything about the MDC packets. Hushmail keys are generated with
symmetric cipher prefs "9 8 7 3".  Consequently, Hushmail users cannot
decrypt messages encrypted with AES using the MDC packet. An example key
is attached at the bottom of this email.

It would be unfortunate to have more compatibility problems between
implementations of OpenPGP. Would it be unreasonable to state in the spec
that implementations supporting ciphers other than 0 through 4 SHOULD be
able to handle the MDC packets (perhaps in the paragraph in 5.13 which
mentions AES and Twofish currently)?

This would place the burden of maintaining compatibility on the side of
the less secure implementation.

--Len.

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: possible new type of pgp plaintext attack ?
From: [email-masked]
Date: Wed, 21 Aug 2002 09:37:52 -0500
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 00505F1086256C1C_=
Content-Type: text/plain; charset="us-ascii"

No need to go through all the gyrations, since Bob's public key is public 
and known to her.  She can perform chosen plaintext attack on the key all 
she wants, with specialized tools and hardware.  No need to only use known 
session keys for whole messages encrypted by PGP; just run RSA or DSA 
yourself on any chosen material.

It is a fundimental requirement that a public key algorithm be able to 
withstand such an attack.  The existance of a "weak block" would imply 
that the function is not one-way after all.

--John

"vedaal" <[email-masked]>
Sent by: [email-masked]
08-20-2002 04:40 PM

        To:     <[email-masked]>
        cc: 
        Subject:        possible new type of pgp plaintext attack ?

atfer reading the paper on the pgp reply/plaintext attack,  was wondering 
if
there might be an additional way to mount a different type of plaintext
attack,
which is independent of the recipient's reply:

consider:

Alice pgp encrypts a message to Bob, and by default, simultaneously to
herself.

Alice can use gnupg to obtain the session key for the message, by
decrypting the default encrypted message to her own key.

The session key, can now be used as a known plaintext,
the packet of the session key encrypted to Bob's public key, is the
ciphertext,

and Bob's [ private key + passphrase hash ] the unknown, that is sought.

now,

if we assume that:
(a) Alice can use a watered-down implementation of pgp that does not use
'salt'

and

(b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt 
to
Bob's key
{like using an 'experimental algo' in gnupg, but finding/making one that 
is
easily cracked, or trivial to begin with}

then,
is it possible for Alice to retrieve Bob's [private key + passphrase 
hash],
which could then be used to decrypt  other messages encrypted to Bob's key 
?

TIA,

vedaal

--=_alternative 00505F1086256C1C_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">No need to go through all the gyrations, since Bob's public key is public and known to her. &nbsp;She can perform chosen plaintext attack on the key all she wants, with specialized tools and hardware. &nbsp;No need to only use known session keys for whole messages encrypted by PGP; just run RSA or DSA yourself on any chosen material.</font>
<br>
<br><font size=2 face="sans-serif">It is a fundimental requirement that a public key algorithm be able to withstand such an attack. &nbsp;The existance of a &quot;weak block&quot; would imply that the function is not one-way after all.</font>
<br>
<br><font size=2 face="sans-serif">--John</font>
<br>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;vedaal&quot; &lt;[email-masked]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">08-20-2002 04:40 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[email-masked]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;possible new type of pgp plaintext attack ?</font></table>
<br>
<br>
<br>
<br><font size=2><tt>atfer reading the paper on the pgp reply/plaintext attack, &nbsp;was wondering if<br>
there might be an additional way to mount a different type of plaintext<br>
attack,<br>
which is independent of the recipient's reply:<br>
</tt></font>
<br><font size=2><tt>consider:<br>
</tt></font>
<br><font size=2><tt>Alice pgp encrypts a message to Bob, and by default, simultaneously to<br>
herself.<br>
</tt></font>
<br><font size=2><tt>Alice can use gnupg to obtain the session key for the message, by<br>
decrypting the default encrypted message to her own key.<br>
</tt></font>
<br><font size=2><tt>The session key, can now be used as a known plaintext,<br>
the packet of the session key encrypted to Bob's public key, is the<br>
ciphertext,<br>
</tt></font>
<br><font size=2><tt>and Bob's [ private key + passphrase hash ] the unknown, that is sought.<br>
</tt></font>
<br>
<br><font size=2><tt>now,<br>
</tt></font>
<br><font size=2><tt>if we assume that:<br>
(a) Alice can use a watered-down implementation of pgp that does not use<br>
'salt'<br>
</tt></font>
<br><font size=2><tt>and<br>
</tt></font>
<br><font size=2><tt>(b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to<br>
Bob's key<br>
{like using an 'experimental algo' in gnupg, but finding/making one that is<br>
easily cracked, or trivial to begin with}<br>
</tt></font>
<br><font size=2><tt>then,<br>
is it possible for Alice to retrieve Bob's [private key + passphrase hash],<br>
which could then be used to decrypt &nbsp;other messages encrypted to Bob's key ?<br>
</tt></font>
<br>
<br><font size=2><tt>TIA,<br>
</tt></font>
<br><font size=2><tt>vedaal<br>
</tt></font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--=_alternative 00505F1086256C1C_=--

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: possible new type of pgp plaintext attack ?
Date: Tue, 20 Aug 2002 17:40:15 -0400
Sender: [email-masked]

atfer reading the paper on the pgp reply/plaintext attack,  was wondering if
there might be an additional way to mount a different type of plaintext
attack,
which is independent of the recipient's reply:

consider:

Alice pgp encrypts a message to Bob, and by default, simultaneously to
herself.

Alice can use gnupg to obtain the session key for the message, by
decrypting the default encrypted message to her own key.

The session key, can now be used as a known plaintext,
the packet of the session key encrypted to Bob's public key, is the
ciphertext,

and Bob's [ private key + passphrase hash ] the unknown, that is sought.

now,

if we assume that:
(a) Alice can use a watered-down implementation of pgp that does not use
'salt'

and

(b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to
Bob's key
{like using an 'experimental algo' in gnupg, but finding/making one that is
easily cracked, or trivial to begin with}

then,
is it possible for Alice to retrieve Bob's [private key + passphrase hash],
which could then be used to decrypt  other messages encrypted to Bob's key ?

TIA,

vedaal

Date: Tue, 20 Aug 2002 14:09:34 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Anybody know details about Schneier's "flaw"?
Sender: [email-masked]

David Hopwood <[email-masked]> writes:

>What on earth does this attack have to do with sending millions of messages?

The point was that, like the Bleichenbacher attack on email, there are a large
list of far more serious problems to worry about than something like this.
However, as someone else has pointed out, this isn't the right forum to
discuss them.  Shall we take it to cypherpunks perhaps?

Peter.

Date: Mon, 19 Aug 2002 18:36:19 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: Anybody know details about Schneier's "flaw"?
Sender: [email-masked]

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

Dominikus Scherkl wrote:
> Carl Ellison <[email-masked]> wrote:
> > Y'know, there's an even simpler attack with the same premise.  You
> > intercept an encrypted e-mail from Alice to Bob.  You take the mail
> > body out of the message and send that body to Bob under your e-mail
> > address (or under some address you control that Bob might mistake for
> > Alice's, which would be even better).  Bob decrypts the message and
> > replies to it, including the original message body by default.

In that case Bob sees the original message, and at least has the possibility
of noting that it is not consistent with the reply-to address. If he sees
garbage, that could be consistent with any reply-to address, unless Bob
knows about this attack.

This is all part of the same problem that has been pointed out before in
the context of signing: the message content and the headers (including
the reply-to address and hence the public key to be used to encrypt replies),
are not treated as a unit cryptographically.

> > The mistake here, on Bob's part, is to reply to a message without
> > paying attention to the e-mail address being used
>
> The Flaw I see (on the whole attack) is:
> Why should anybody reply cleartext to an encrypted message?

The attack does not depend on the victim replying in cleartext.
If the message is encrypted, it would be encrypted to the attacker's key.

Peter Gutmann wrote:
> On the grand scale of things, it has curiosity value, but not much more.  There
> are a pile of other attacks which fall into the same class, e.g. concern over
> the Bleichenbacher attack on SSL being used against S/MIME email (come to think
> of it, that one never came up on open-pgp).  My thoughts on this at the time,
> which also apply to this attack, were:
> 
> -- Snip --
> 
>   [...] this attack requires that an attacker send you around a million pieces
>   of CMS encrypted email with attached receipt requests, that you respond with
>   a million receipts indicating to the attacker the exact details of why the
>   decrypt failed, that you reuse the same per-message key for each of those
>   million messages.

What on earth does this attack have to do with sending millions of messages?
It requires one message, and is considerably more plausible than applying the
Bleichenbacher attack to email (or would be, if it is wasn't prevented in
practice by compression).

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

Date: Mon, 19 Aug 2002 11:38:42 -0700 (PDT)
From: Clifford Neuman <[email-masked]>
To: [email-masked]
Subject: CFP - Symposium on Network & Distributed Systems Security
Sender: [email-masked]

The Internet Society's (ISOC) annual Symposium on Network and Distributed
System Security (NDSS) brings together innovative and forward thinking
members of the Internet community including leading-edge security
researchers and implementers, globally-recognized security-technology
experts, and users from both the private and public sectors who design,
develop, exploit, and deploy the technologies that define network and
distributed system security.

If you are working on new and practical approaches to security problems
that are endemic to network and distributed systems, we invite you to
participate in NDSS'03 by submitting one or more technical papers and/or
panel proposals.  Submission details may be found at:

  http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml

NDSS'03 will again be held for three days in San Diego, California in
February, 2003.  One day of tutorials will be followed by two days of
technical sessions including refereed papers, invited talks, and panel
discussions and debates.

Please be aware that the NDSS'03 cut off date for paper and panel
submission is August 30, 2002.

All accepted papers will be published in The NDSS Proceedings by the
Internet Society.  There will also be an Outstanding Paper Award presented
at the Symposium to the author(s).  Submitted papers should not have been
previously published or be submitted simultaneously to a journal or to
another symposium or workshop with a published proceedings.

Please consider joining us at NDSS'03.  We look forward to hearing from you!

Clifford Neuman, 
Information Sciences Institute, University of Southern California
General Chair, NDSS'03 

Virgil Gligor, University of Maryland
Michael Reiter, Carnegie Mellon University
Program Chairs,  NDSS'03 

Date: Mon, 19 Aug 2002 13:52:33 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Notary signature implementation notes
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi folks,

I recently roughed in some support for notary signatures in GnuPG.
Here are some samples.  The first attachment is the file the original
signature was issued on.  The second attachment is a detached
signature on that file.  The third attachment is a v4 0x50 signature
on that signature, and the final attachment is a v3 0x50.

All of these signatures were issued by key 0xD8B2D20C, currently on a
friendly keyserver near you.

I used the canonicalization rules Hal Finney suggested in
http://www.imc.org/ietf-openpgp/mail-archive/msg04021.html except I
used the constant 0x88 rather than 0x84 for the canonical CTB.  I
believe 0x84 was a typo since that would be a CTB for a session key
packet.

It was suggested that notary signatures always contain a signature
target subpacket.  After implementing notary signatures, I'm not sure
how useful this would be given the current signature target subpacket.
To create the subpacket, the notary needs to have the public key of
the signer of the original signature in order to get the raw hash out
of the original signature.  That harms somewhat the nice feature of a
notary signature that the notary does not need to know anything about
the original document and its signer.  One possible solution to this
is to define the signature target subpacket as a canonical hash of the
original signature rather than as the actual hash from the original
signature.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=foo

notary
--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="foo.asc"

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="v4.sig"

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="v3.sig"

--6c2NcOVqGQ03X4Wi--

Subject: Re: Anybody know details about Schneier's "flaw"?
From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Date: 19 Aug 2002 14:54:18 +0200
Sender: [email-masked]

--=-c6HIAhDluoStiSC+MQqb
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2002-08-19 at 13:29, Peter Gutmann wrote:
>=20
> "Dominikus Scherkl" <[email-masked]> writes:
>=20
> >The whole attack looks very suspicious to me...
>=20
> On the grand scale of things, it has curiosity value, but not much more. =
 There
[...]

>   As a security threat, I'd say this rates somewhere down with "Router hi=
t by
>   meteorite", "Computer trampled by stampeding water buffalo", "Hard driv=
e
>   kidnapped by space aliens", and similar stuff.
>=20
> Sure, it is in theory possible, if you try really, really hard and are wi=
lling
> to bend over backwards to cooperate with an attacker, to allow this kind =
of
> attack to occur.  [...]  You're more likely to get someone's key by askin=
g them

As I've said in my other mail it's really a problem of some mailreaders
being unclear. For example, evolution does not display any indication
that the displayed message was encrypted. (You have to enter the
passphrase the first time you look at an encrypted msg, but I usually
tell it to store the passphrase for the session, causing it to
auto-decrypt any further messages.

In other words: on technical grounds, I absolutely agree with you. BUT
with bad UIs in some mailreaders, and with the experience that users
generally are more stupid than anyone would believe, this type of attack
is very realistic.

Bot, and here I'm sure that your opinion is the same, this discussion is
not really on-topic on a technical mailing list...=20

cheers
-- vbi

--=20
secure email with gpg                         http://fortytwo.ch/gpg

--=-c6HIAhDluoStiSC+MQqb
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-c6HIAhDluoStiSC+MQqb--

To: "Dominikus Scherkl" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 19 Aug 2002 13:59:10 +0200
Lines: 35
Sender: [email-masked]

On Mon, 19 Aug 2002 11:49:23 +0200, Dominikus Scherkl said:

> Why should anybody relpy cleartext to an encrypted messge?
> especialy if it contains (even parts) of the encrypted message?

You will often notice plaintext message like "I could not decrypt your
message - please use key 0x12345678" or "Where do I find your key".
So it is not unlikely to see a message "Hey, your encrypted mail was
garbled, please send it again.  Here is the problematic line..".

Most users don't know about the cryptograhic issues involved in
sending parts of the plaintext back.  A good MUA should protect
against that but well a user can always override it.

> If a reply is sent at all, it should be encrypted, so an interceptor
> has the same problem with the reply - he needs to break the key.

I am probably not the only one with this problem: Try to get my key
from a keyserver - it is probably not usable because the subkeys are
all garbled (Most people don't look at the mail header X-Request-PGP
to find out the canonical way to get my key).  So it is very likely to
get a plaintext response; users are thus used to that and they can't
imagine what serious consequences a reply with a very short and after
all unreadable quote should have.

All over the place OpenPGP is rightfully very paranoid and thus it
makes sense to do what we can to avoid shoot-your-self-in-the-foot
traps.

Salam-Shalom,

   Werner

Subject: Re: Anybody know details about Schneier's "flaw"?
From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Date: 19 Aug 2002 13:34:46 +0200
Sender: [email-masked]

--=-1G2tKlk5KHHHBs/KYBUY
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

[please leave attribution in when replying]

On Mon, 2002-08-19 at 11:49, Dominikus Scherkl wrote:

> > The mistake here, on Bob's part, is to reply to a message without
> > paying attention to the e-mail address being used
[...]

> The whole attack looks very suspicious to me...

I guess the correct 'solution' to prevent the 'attack' would be to file
bug reports with gpg-aware mail clients that do not at least display a
warning when replying to/forwarding an originally encrypted message
unencrypted.

cheers
-- vbi

--=20
secure email with gpg                         http://fortytwo.ch/gpg

--=-1G2tKlk5KHHHBs/KYBUY
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-1G2tKlk5KHHHBs/KYBUY--

Date: Mon, 19 Aug 2002 23:29:30 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Anybody know details about Schneier's "flaw"?
Sender: [email-masked]

"Dominikus Scherkl" <[email-masked]> writes:

>The whole attack looks very suspicious to me...

On the grand scale of things, it has curiosity value, but not much more.  There
are a pile of other attacks which fall into the same class, e.g. concern over
the Bleichenbacher attack on SSL being used against S/MIME email (come to think
of it, that one never came up on open-pgp).  My thoughts on this at the time,
which also apply to this attack, were:

-- Snip --

  [...] this attack requires that an attacker send you around a million pieces
  of CMS encrypted email with attached receipt requests, that you respond with
  a million receipts indicating to the attacker the exact details of why the
  decrypt failed, that you reuse the same per-message key for each of those
  million messages.

  Now maybe I'm being a bit optimistic here, but I do think that claiming this
  is a weakness is a pretty silly.  First of all you need to assume that an
  attacker can somehow send you a million pieces of email without you noticing
  and without it getting stopped by spam blockers.  Your own software then has
  to try to decrypt each of the one million pieces of email, find that it
  can't, and send out a receipt to the sender containing an indication of
  exactly how the decryption failed (this isn't possible even if you wanted to
  do it, although who knows what the Receipt Notification WG have been working
  on recently).  Finally, the whole attack only works if you reuse
  cryptovariables.  This is why the CERT advisory on this problem specifically
  points out "This vulnerability does not affect S/MIME or SET".

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

Sure, it is in theory possible, if you try really, really hard and are willing
to bend over backwards to cooperate with an attacker, to allow this kind of
attack to occur.  [...]  You're more likely to get someone's key by asking them
for it (I've seen this happen a number of times, in some cases without even
needing to ask for it, by people who assume that "PKCS #12 == certificate" and
send out their "certificate" for others to use) than by using this kind of
attack.

Just because it's (theoretically) possible to break into Fort Knox with a can
opener doesn't mean that Kentucky is going to start screening people at the
border for possession of said item.

-- Snip --

A better way of putting that last sentence is given in one of my favourite
computing quotes, by Chris Strachey:

  "The fact that it's possible to push a pea up a mountain with your nose
   doesn't mean that this is a sensible way of getting it there".

Peter.

Content-Class: urn:content-classes:message
Subject: Re: Anybody know details about Schneier's "flaw"?
Date: Mon, 19 Aug 2002 11:49:23 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> Y'know, there's an even simpler attack with the same premise.  You
> intercept an encrypted e-mail from Alice to Bob.  You take the mail
> body out of the message and send that body to Bob under your e-mail
> address (or under some address you control that Bob might mistake for
> Alice's, which would be even better).  Bob decrypts the message and
> replies to it, including the original message body by default.
> 
> The mistake here, on Bob's part, is to reply to a message without
> paying attention to the e-mail address being used
The Flaw I see (on the whole attack) is:
Why should anybody relpy cleartext to an encrypted messge?
especialy if it contains (even parts) of the encrypted message?
And if anybody does, why he's using encryption at all?!?

If a reply is sent at all, it should be encrypted, so an interceptor
has the same problem with the reply - he needs to break the key.

And if it's the sender himself who want's to cheat him, he knows
the message content very well, so what does he want to gain?!?

The whole attack looks very suspicious to me...

-- 
Dominikus Scherkl
[email-masked]

Date: Sat, 17 Aug 2002 05:42:29 -0700
To: [email-masked]
From: Carl Ellison <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
Sender: [email-masked]

At 03:13 AM 8/16/2002 +0100, Adam Back wrote:

>Also the attack for those who haven't read the paper is really
>low-tech.  They're just observing that if you can ask someone to
>decrypt a message you can use that to decrypt related messages.  So
>you intentionally garble a message, and hope the user sends you the
>garbled plaintext back to you to ask what went wrong.  The rest
>falls out of the fact that if you garble a few bits of a ciphertext
>most of the plaintext will still be intact.

Y'know, there's an even simpler attack with the same premise.  You
intercept an encrypted e-mail from Alice to Bob.  You take the mail
body out of the message and send that body to Bob under your e-mail
address (or under some address you control that Bob might mistake for
Alice's, which would be even better).  Bob decrypts the message and
replies to it, including the original message body by default.

The mistake here, on Bob's part, is to reply to a message without
paying attention to the e-mail address being used -- rather than
replying to a message with quoted garbage rather than just saying
"that was garbage -- send again".

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://world.std.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+

Date: Fri, 16 Aug 2002 03:13:42 +0100
From: Adam Back <[email-masked]>
To: Rodney Thayer <[email-masked]>
Cc: Derek Atkins <[email-masked]>, [email-masked]
Subject: Re: Anybody know details about Schneier's "flaw"?
Sender: [email-masked]

I agree.  Increasing use of MDC is a better more direct
solution. (It's also a more robust solution -- how long until someone
manages to propogate the attack through compression -- it's not as if
compression were designed to prevent it.)

Also the attack for those who haven't read the paper is really
low-tech.  They're just observing that if you can ask someone to
decrypt a message you can use that to decrypt related messages.  So
you intentionally garble a message, and hope the user sends you the
garbled plaintext back to you to ask what went wrong.  The rest falls
out of the fact that if you garble a few bits of a ciphertext most of
the plaintext will still be intact.

So it's related to the earlier observation that unless a message is
signed you can undetectably (to PGP) garble it's contents.  This also
was hard to do if the message was compressed.  This was the motivation
for the MDC.

Adam

On Thu, Aug 15, 2002 at 05:49:00PM -0700, Rodney Thayer wrote:
> 
> my point was, requiring implementors to do compression sucks,
> in my opinion.  this attack is insufficient justification.
> 
> the attack is a social engineering attack.  forcing implementors
> to add onerous code to defend against it is not a good idea.
> 
> At 12:51 PM 8/14/2002 -0400, Derek Atkins wrote:
> 
> >Rodney Thayer <[email-masked]> writes:
> >
> > > I think it's got too many odd things in it to require compression.
> >
> >Indeed.. As I said (perhaps incoherently), the attack only works if
> >you DO NOT compress.  If you compress the message then there is no way
> >to XOR against the message.
> 

Date: Thu, 15 Aug 2002 17:49:00 -0700
To: Derek Atkins <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
Cc: [email-masked]
Sender: [email-masked]

my point was, requiring implementors to do compression sucks,
in my opinion.  this attack is insufficient justification.

the attack is a social engineering attack.  forcing implementors
to add onerous code to defend against it is not a good idea.

At 12:51 PM 8/14/2002 -0400, Derek Atkins wrote:

>Rodney Thayer <[email-masked]> writes:
>
> > I think it's got too many odd things in it to require compression.
>
>Indeed.. As I said (perhaps incoherently), the attack only works if
>you DO NOT compress.  If you compress the message then there is no way
>to XOR against the message.

Date: Thu, 15 Aug 2002 11:59:41 +0200
From: Timo Schulz <[email-masked]>
To: [email-masked]
Subject: Re: Primary subkey subpacket
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu Aug 15 2002; 09:50, [email-masked] wrote:

> in which self signature?:
> 
> 5.2.3.3. Notes on Self-Signatures
[snip]

Yes, I'm aware we can't use the self signature but this packet would
need a central place because otherwise it would no make sense. The best
idea is somewhere in a signature which carries the public key because
there is only one public key and this would be central.

        Timo

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Anybody know details about Schneier's "flaw"?
Date: Thu, 15 Aug 2002 07:51:35 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Thu, 15 Aug 2002 07:51:35 +0000 (UTC)
Sender: [email-masked]

* Jon Callas wrote:
>The text that is in there is some talk in the sections on compression, which
>say that a decompression error should be considered to be a security
>problem, not a data problem (in other words, don't typically let the user
>have the damaged plaintext), and some language that recommends encouraging
>people to use MDCs. There is also a relatively long section in Security
>Considerations. Take a look, I think you'll like it.

Fine. I don't support Schneiers Claim to withdraw 'uncompressed'-compression.

Date: Thu, 15 Aug 2002 09:50:35 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: Primary subkey subpacket
Sender: [email-masked]

Timo Schulz wrote:
> On Wed Aug 14 2002; 14:27, [email-masked] wrote:
> 
> > > which is placed on the self signature to force the implementation
>                            ^^^^^^^^^^^^^^
> [snip]
> > where do you want to place it?
> 
> In the self signature.

in which self signature?:

5.2.3.3. Notes on Self-Signatures
   A self-signature is a binding signature made by the key the
   signature refers to. There are three types of self-signatures, the
   certification signatures (types 0x10-0x13), the direct-key signature
   (type 0x1f), and the subkey binding signature (type 0x18). For

__
Disastry  http://disastry.dhs.org/

Date: Wed, 14 Aug 2002 23:20:20 -0700
Subject: Re: Anybody know details about Schneier's "flaw"?
From: Jon Callas <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 8/14/02 2:27 PM, "[email-masked]" <[email-masked]> wrote:

> According to the link posted by someone else,
> (www.counterpane.com/pgp-attack.html), "We also recommend changes in the
> OpenPGP standard [3 ]to educe the
> effectiveness of ou attacks in these settings."
> 
> Are the people activly working on the -bis draft aware of this?

Yes, we are aware of it. We released bis-06 on Monday with language in it to
address this. We were advised about this a month ago, and have had quite a
good email conversation with the authors about it.

The text that is in there is some talk in the sections on compression, which
say that a decompression error should be considered to be a security
problem, not a data problem (in other words, don't typically let the user
have the damaged plaintext), and some language that recommends encouraging
people to use MDCs. There is also a relatively long section in Security
Considerations. Take a look, I think you'll like it.

    Jon

To: [email-masked]
Cc: OpenPGP <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
From: [email-masked]
Date: Wed, 14 Aug 2002 16:27:08 -0500
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0075D77A86256C15_=
Content-Type: text/plain; charset="us-ascii"

According to the link posted by someone else, (www.counterpane.com/pgp-attack.html), "We also recommend changes in the OpenPGP standard [3 ]to educe the 
effectiveness of ou attacks in these settings."

Are the people activly working on the -bis draft aware of this?

--John

--=_alternative 0075D77A86256C15_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">According to the link posted by someone else, (</font><font size=2><tt>www.counterpane.com/pgp-attack.html</tt></font><font size=2 face="sans-serif">), &quot;We also recommend changes in the OpenPGP standard [3 ]to educe the effectiveness of ou attacks in these settings.&quot;</font>
<br>
<br><font size=2 face="sans-serif">Are the people activly working on the -bis draft aware of this?</font>
<br>
<br><font size=2 face="sans-serif">--John</font>
<br>
--=_alternative 0075D77A86256C15_=--

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked], OpenPGP <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
Date: Wed, 14 Aug 2002 22:42:09 +0200
Content-Description: clearsigned data
Sender: [email-masked]

On Wednesday 14 August 2002 16:40, [email-masked] wrote:
> In http://netscape.com.com/2100-1105-949506.html?type=pt there is a
> vague mention of a problem:
<snip>
> Does anybody know more about this?  Can a minor improvement to the
> new -bis draft fix it?
<snip>

Do you mean this:
www.counterpane.com/pgp-attack.html
or something else?

Marc

- -- 
Mutig warf sich die kleine Überwachungskamera zwischen Täter Opfer!
                                        --Rena Tangens / FoeBuD e.V.

Date: Wed, 14 Aug 2002 13:05:53 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Primary subkey subpacket
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Aug 14, 2002 at 09:14:56AM +0200, Werner Koch wrote:
> 
> On Tue, 13 Aug 2002 23:58:44 +0200, Timo Schulz said:
> 
> > Recently I stumbled over a problems with multiple subkeys. I know
> > PGP doesn't let the user choose the key at all and GPG uses the
> > newest key by default. What about a "primary subkey" subpacket
> 
> I don't think this is needed.  If a subkey is published a sending
> implementation may choose any of the valid subkeys for encryption.
> Although not specified in OpenPGP, it should select the newest one as
> long as it has no creation date in the future.

I imagine a primary subkey flag as more of a tie-breaker.  If an
implementation wanted to ignore the flag (whether for PFS or other
reasons), that would be fine.  If the implementation did not care, or
could not reach a decision, the primary subkey would be chosen.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

To: Rodney Thayer <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
Date: 14 Aug 2002 12:51:48 -0400
Lines: 14
Sender: [email-masked]

Rodney Thayer <[email-masked]> writes:

> I think it's got too many odd things in it to require compression.

Indeed.. As I said (perhaps incoherently), the attack only works if
you DO NOT compress.  If you compress the message then there is no way
to XOR against the message.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

Date: Wed, 14 Aug 2002 09:34:03 -0700
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
Sender: [email-masked]

I think it's got too many odd things in it to require compression.
Basically it's a "if you let yourself get social engineered then
your crypto can be used against you" attack.

At 10:50 AM 8/14/2002 -0400, Derek Atkins wrote:

>[email-masked] writes:
>
> > Does anybody know more about this?  Can a minor improvement to the new
> > -bis draft fix it?
>
>a) this only works if you do NOT compress your messages before you encrypt.
>b) this only works if you do NOT sign the message AND you do NOT use an MDC
>
> > --John

Date: Wed, 14 Aug 2002 18:29:13 +0200
From: Timo Schulz <[email-masked]>
To: [email-masked]
Subject: Re: Primary subkey subpacket
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed Aug 14 2002; 14:27, [email-masked] wrote:

> > which is placed on the self signature to force the implementation
                           ^^^^^^^^^^^^^^
[snip]
> where do you want to place it?

In the self signature.

> I think it may be better to put this in userid self sig
> (this would allow different subkeys for different userids),
> but then format can't be like "primary user id" (5.2.3.19.) subpacket,

Yes, I see this is a problem. The easiest solution would be to put
it in a signature which is part of the public key to have a non-ambiguous
assignment.

        Timo

To: [email-masked]
Cc: OpenPGP <[email-masked]>
Subject: Re: Anybody know details about Schneier's "flaw"?
From: Derek Atkins <[email-masked]>
Date: 14 Aug 2002 10:50:21 -0400
Lines: 17
Sender: [email-masked]

[email-masked] writes:

> Does anybody know more about this?  Can a minor improvement to the new 
> -bis draft fix it?

a) this only works if you do NOT compress your messages before you encrypt.
b) this only works if you do NOT sign the message AND you do NOT use an MDC

> --John

-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

To: OpenPGP <[email-masked]>
Subject: Anybody know details about Schneier's "flaw"?
From: [email-masked]
Date: Wed, 14 Aug 2002 09:40:39 -0500
Sender: [email-masked]

This is a multipart message in MIME format.
--=_alternative 0050A08D86256C15_=
Content-Type: text/plain; charset="us-ascii"

In http://netscape.com.com/2100-1105-949506.html?type=pt there is a vague 
mention of a problem:

Schneier released information Monday about a separate flaw in the PGP 
(Pretty Good Privacy) program that is freely available and used to encrypt 
messages sent over the Internet. 
Schneier and Jonathan Katz of the University of Maryland at College Park 
found a way an attacker could intercept a PGP encrypted message, modify it 
without decrypting it, dupe the user into sending it back, and retrieve 
the original message

Does anybody know more about this?  Can a minor improvement to the new 
-bis draft fix it?

--John

--=_alternative 0050A08D86256C15_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">In http://netscape.com.com/2100-1105-949506.html?type=pt there is a vague mention of a problem:</font>
<br>
<br>
<table align=center>
<tr valign=top>
<td bgcolor=white><font size=2 face="Times New Roman"><br>
</font>
<table>
<tr>
<td><font size=3 face="Times New Roman">Schneier released information Monday about a separate flaw in the PGP (Pretty Good Privacy) program that is freely available and used to encrypt messages sent over the Internet. </font>
<p><font size=3 face="Times New Roman">Schneier and Jonathan Katz of the University of Maryland at College Park found a way an attacker could intercept a PGP encrypted message, modify it without decrypting it, dupe the user into sending it back, and retrieve the original message</font></table>
<br></table>
<br>
<br><font size=2 face="sans-serif">Does anybody know more about this? &nbsp;Can a minor improvement to the new -bis draft fix it?</font>
<br>
<br><font size=2 face="sans-serif">--John</font>
<br>
--=_alternative 0050A08D86256C15_=--

Date: Wed, 14 Aug 2002 14:27:53 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: Primary subkey subpacket
Sender: [email-masked]

Timo Schulz wrote:
> Recently I stumbled over a problems with multiple subkeys. I know
> PGP doesn't let the user choose the key at all and GPG uses the
> newest key by default. What about a "primary subkey" subpacket
> which is placed on the self signature to force the implementation
> to use a special subkey. The format should be similar to the 
> "primary user id" packet.

where do you want to place it?
in subkey binding sig?
that would be odd..
because this means creating another binding sig (when making new subkey(s)),
and OpenPGP does not allow multiple binding sigs (unlike userid self sig),
and then keyserver problems, etc..

I think it may be better to put this in userid self sig
(this would allow different subkeys for different userids),
but then format can't be like "primary user id" (5.2.3.19.) subpacket,
it can be like Issuer (5.2.3.5.) or even better
like Revocation key (5.2.3.15.) subpacket

__
Disastry  http://disastry.dhs.org/

From: Ian Brown <[email-masked]>
To: ietf-openpgp <[email-masked]>
Subject: RE: Primary subkey subpacket
Date: Wed, 14 Aug 2002 08:44:56 +0100
Importance: Normal
Sender: [email-masked]

Werner Koch wrote:
> Having such a default subkey flag would inhibit automatic key
> rollover.  If we really want to specify handling of subkeys we should
> first discuss Ian Brown's suggestions for PFS.

(and Adam Back and Ben Laurie's. They're at
http://www.cs.ucl.ac.uk/staff/I.Brown/draft-brown-pgp-pfs-03.txt, although
the draft has expired.)

Briefly, we suggested that for perfect forward secrecy, the subkey closest
to its expiration date should be used. This is because the owner can wipe
that subkey soonest, reducing the possibility that an attacker with a copy
of the message ciphertext will then be able to get the subkey required to
decrypt it.

The draft's progress has stalled as the IESG liked the idea and suggested we
go for standards track rather than informational publication; but I think
they are waiting from some positive response from the working group on that.
Do people think it's worth pursuing, either as informational or standards
track? John Noerenberg thought it might be useful to split the document into
a small standards track document defining the subkey flags we suggest (or
even incorporate that into the rfc2440-bis draft, although we're likely too
late for that now) along with a longer informational draft on using the
protocol features for PFS. But we weren't sure if this more convoluted route
was more useful.

Any thoughts?

Thanks,

Ian

To: [email-masked]
Subject: Re: Primary subkey subpacket
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 14 Aug 2002 09:14:56 +0200
Lines: 19
Sender: [email-masked]

On Tue, 13 Aug 2002 23:58:44 +0200, Timo Schulz said:

> Recently I stumbled over a problems with multiple subkeys. I know
> PGP doesn't let the user choose the key at all and GPG uses the
> newest key by default. What about a "primary subkey" subpacket

I don't think this is needed.  If a subkey is published a sending
implementation may choose any of the valid subkeys for encryption.
Although not specified in OpenPGP, it should select the newest one as
long as it has no creation date in the future.

Having such a default subkey flag would inhibit automatic key
rollover.  If we really want to specify handling of subkeys we should
first discuss Ian Brown's suggestions for PFS.

Shalom-Salam,

   Werner

Date: Tue, 13 Aug 2002 18:36:02 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Primary subkey subpacket
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Aug 13, 2002 at 11:58:44PM +0200, Timo Schulz wrote:

> Recently I stumbled over a problems with multiple subkeys. I know
> PGP doesn't let the user choose the key at all and GPG uses the
> newest key by default. What about a "primary subkey" subpacket
> which is placed on the self signature to force the implementation
> to use a special subkey. The format should be similar to the 
> "primary user id" packet.

This is interesting.  You'd have to tie it to the key flags subpacket
somehow, as the notion of "primary" is different for different key
types (primary signing subkey, primary encrypting subkey, etc.)

It could even be a bit set in the key flags subpacket itself.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Tue, 13 Aug 2002 18:33:38 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Mon, Aug 12, 2002 at 11:14:49PM -0700, Jon Callas wrote:
> 
> > I think that it would be nice to have the NAI X.509 packets documented.
> > Having quasi-offical data formats that implimentors need to deal with, but
> > are not documented, sounds like a bad idea to me. (Though, if it belongs
> > in a seperate Internet Draft, I have no problem with that. But there
> > should be some place to go other than the PGP source for this
> > information.)
> 
> It would be nice, but we have to get the owners of that code base to be
> willing to document it, or have someone else do it. I presume there's
> consensus that this is a good idea, as there are no further comments?

To a certain extent these are already documented in the draft.  The
X.509 signature subpackets are in the "private or experimental" range
(they use 100), and the signatures are also issued using public key
algorithm 100, also experimental.

It would be nice to see the format fully documented, though if it were
widely adopted, it would result in one of the experimental values
effectively losing its experimental status.

> I want to get soon a new RFC number, so let's look at what there is to
> finish up.
> 
> * I've completely spaced on the notary signatures, apparently, so I'll get
> those in soon. 

I've started roughing out some code for this (based on the discussion
a few weeks ago) so we can have some implementation experience for
this and the "revocation target" subpackets.  Could you post the
notary signature draft language when you put it together?

> * I'll look at signature subpackets, and if the spec needs changes to jibe
> with reality, I'll do it. MUSTs changed to SHOULDs, right?

Yes, and the "two or more" subpacket requirement for the hashed
section should probably be "zero or more".

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Tue, 13 Aug 2002 23:58:44 +0200
From: Timo Schulz <[email-masked]>
To: [email-masked]
Subject: Primary subkey subpacket
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi!

Recently I stumbled over a problems with multiple subkeys. I know
PGP doesn't let the user choose the key at all and GPG uses the
newest key by default. What about a "primary subkey" subpacket
which is placed on the self signature to force the implementation
to use a special subkey. The format should be similar to the 
"primary user id" packet.

        Timo

To: Jon Callas <[email-masked]>
Cc: Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Tue, 13 Aug 2002 13:29:05 +0200
Lines: 22
Sender: [email-masked]

On Mon, 12 Aug 2002 23:14:49 -0700, Jon Callas said:

> It would be nice, but we have to get the owners of that code base to be
> willing to document it, or have someone else do it. I presume there's
> consensus that this is a good idea, as there are no further comments?

I think it is far easier to allow PGP keys for TLS (there is a
specification and at least one implementation) than to intermix the
two protocol and raise the complexity even more.

Afaik, Peter Gutmann is working on a proposal on how to use X.509 keys
with PGP.

> * I'll look at signature subpackets, and if the spec needs changes to jibe
> with reality, I'll do it. MUSTs changed to SHOULDs, right?

Yes.

Salam-Shalom,

   Werner

Date: Mon, 12 Aug 2002 23:14:49 -0700
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[email-masked]>
To: Len Sassaman <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

> I think that it would be nice to have the NAI X.509 packets documented.
> Having quasi-offical data formats that implimentors need to deal with, but
> are not documented, sounds like a bad idea to me. (Though, if it belongs
> in a seperate Internet Draft, I have no problem with that. But there
> should be some place to go other than the PGP source for this
> information.)

It would be nice, but we have to get the owners of that code base to be
willing to document it, or have someone else do it. I presume there's
consensus that this is a good idea, as there are no further comments?

I want to get soon a new RFC number, so let's look at what there is to
finish up.

* I've completely spaced on the notary signatures, apparently, so I'll get
those in soon. 

* I'll look at signature subpackets, and if the spec needs changes to jibe
with reality, I'll do it. MUSTs changed to SHOULDs, right?

Anything else?

    Jon

Date: Tue, 13 Aug 2002 11:54:14 +0900 (JST)
To: [email-masked]
Subject: Fw: Secret Key Packet Formats
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

----Next_Part(Tue_Aug_13_11:54:15_2002_891)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

I sent the following message for 05.txt in June. But 06.txt does not
include my suggestions. To reminder, I post the message gain. I hope
my suggestions will be included in 07.txt.

--Kazu

----Next_Part(Tue_Aug_13_11:54:15_2002_891)--
Content-Type: Message/Rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Date: Thu, 27 Jun 2002 19:25:57 +0900 (JST)
Message-Id: <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Secret Key Packet Formats
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
 <[email-masked]>
X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

I have several comments on Section 5.5.3 (Secret Key Packet Formats)
of 2440bis-05. 

>     - [Optional] If secret data is encrypted, Initial Vector (IV) of
>       the same length as the cipher's block size.

The following might be more easy to understand.

      - [Optional] If secret data is encrypted(string-to-key usage
        octet was not 0), Initial Vector (IV) of the same length as
        the cipher's block size.

>     - Encrypted multi-precision integers comprising the secret key
>       data. These algorithm-specific fields are as described below.

If string-to-key usage octet was 0, this field is not encrypted. So,
this should be:

      - Plain or encrypted multi-precision integers comprising the
        secret key data. These algorithm-specific fields are as
        described below.

>     - If the string-to-key usage octet was 255, then a two-octet
>       checksum of the plaintext of the algorithm-specific portion (sum
>       of all octets, mod 65536). If the string-to-key usage octet was
>       254, then a 20-octet SHA-1 hash of the plaintext of the
>       algorithm-specific portion. This checksum or hash is encrypted
>       together with the algorithm-specific fields.

This does not corver the other values than 254 and 255. According to
RFC 2440, a two-octet checksum is necessary for the other values.

>   The 16-bit checksum that follows the algorithm-specific portion is
>   the algebraic sum, mod 65536, of the plaintext of all the
>   algorithm-specific octets (including MPI prefix and data).  With V3
>   keys, the checksum is stored in the clear.  With V4 keys, the
>   checksum is encrypted like the algorithm-specific data.  This value
>   is used to check that the passphrase was correct. However, this
>   checksum is deprecated; an implementation SHOULD NOT use it, but
>   should rather use the SHA-1 hash denoted with a usage octet of 254.
>   The reason for this is that there are some attacks on the private
>   key that can undetectably modify the secret key. Using a SHA-1 hash
>   prevents this.

"16-bit checksum" should be "two-octet checksum".

This paragraph should cover V2. Actually, old PGP commands produce
Secret Key Packet with V2.

Combination of string-to-key usage octet and format version is
unclear.

2440bis-05 is read like:

		V3			V4
  0 
254		encrypted sha1 hash	encrypted sha1 hash
255		clear checksum		encrypted checksum
others

But I think this matrix should be:

		V2/V3			V4
  0		clear checksum		clear checksum
254		clear checksum		encrypted sha1 hash
255		clear checksum		encrypted checksum
others		clear checksum		encrypted checksum

If this is correct, I hope improvement of this section will be made in
the next draft.

Thanks.

--Kazu

----Next_Part(Tue_Aug_13_11:54:15_2002_891)----

Date: Mon, 12 Aug 2002 17:02:23 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Mon, Aug 12, 2002 at 04:10:48PM -0400, Michael Young wrote:

> From: "David Shaw" <[email-masked]>
> > 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket 
> ...
> > Come to think, both PGP and GnuPG create v4 signatures with a hashed
> > timestamp, and an unhashed issuer.  Are they compliant? ;)
> 
> I don't think that the specification should require either.  It would be
> fair to note that many implementations will be unable (or unwilling) to
> interpret a signature without these things.
> 
> But even if the issuer remains a MUST, it certainly doesn't need
> to be in the hashed material.  As it stands, the specification doesn't
> say so exactly -- it merely suggests that they should be the first two
> subpackets, which is silly if the timestamp is hashed but the issuer
> is not.  I would just excise the suggestion entirely.

2440bis does say (well, imply) that they are both hashed.  In section
5.2.3. ("Version 4 Signature Packet Format"), it says that the hashed
section is made up of "two or more" subpackets, and the unhashed
section is made up of "zero or more" subpackets.  Given the language
elsewhere, I assume that these two hashed subpackets are the required
issuer and timestamp.

I agree with you though - I think that a signature should not require
any subpacket to be present (SHOULD perhaps, but not MUST).

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

From: "Michael Young" <[email-masked]>
To: "OpenPGP" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 12 Aug 2002 16:10:48 -0400
Sender: [email-masked]

From: "David Shaw" <[email-masked]>
> 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket 
...
> Come to think, both PGP and GnuPG create v4 signatures with a hashed
> timestamp, and an unhashed issuer.  Are they compliant? ;)

I don't think that the specification should require either.  It would be
fair to note that many implementations will be unable (or unwilling) to
interpret a signature without these things.

But even if the issuer remains a MUST, it certainly doesn't need
to be in the hashed material.  As it stands, the specification doesn't
say so exactly -- it merely suggests that they should be the first two
subpackets, which is silly if the timestamp is hashed but the issuer
is not.  I would just excise the suggestion entirely.

Date: Mon, 12 Aug 2002 14:35:08 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Mon, Aug 12, 2002 at 10:55:27AM -0700, Len Sassaman wrote:
> 
> On Mon, 12 Aug 2002, Werner Koch wrote:
> 
> > I see no more problem with the draft.  How lets try again to kick off
> > the the interop tests.
> 
> I think that it would be nice to have the NAI X.509 packets documented.
> Having quasi-offical data formats that implimentors need to deal with, but
> are not documented, sounds like a bad idea to me. (Though, if it belongs
> in a seperate Internet Draft, I have no problem with that. But there
> should be some place to go other than the PGP source for this
> information.)

Speaking about the X.509 signatures, I wonder if they are strictly
compliant with this draft.  2440bis seems to say that v4 signatures
require (MUST) an issuer subpacket and a timestamp subpacket, and that
those subpackets are both hashed (as per the "two or more" language in
section 5.2.3, and section 5.2.4.1. Subpacket Hints).  The X.509 sigs
don't have an issuer subpacket at all.  If this reading is incorrect,
it may be good to clarify things a bit.  I suppose it could be argued
that since the X.509 sigs are made with an experimental public key
algorithm (100), the signature format does not necessarily follow.

Come to think, both PGP and GnuPG create v4 signatures with a hashed
timestamp, and an unhashed issuer.  Are they compliant? ;)

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Mon, 12 Aug 2002 10:55:27 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: OpenPGP <[email-masked]>, Werner Koch <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Sender: [email-masked]

On Mon, 12 Aug 2002, Werner Koch wrote:

> I see no more problem with the draft.  How lets try again to kick off
> the the interop tests.

I think that it would be nice to have the NAI X.509 packets documented.
Having quasi-offical data formats that implimentors need to deal with, but
are not documented, sounds like a bad idea to me. (Though, if it belongs
in a seperate Internet Draft, I have no problem with that. But there
should be some place to go other than the PGP source for this
information.)

--Len.

Date: Mon, 12 Aug 2002 13:47:25 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I noticed the "notary signature" specification was not present.  I
thought we had sufficiently specified how that would work?

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
From: Florian Weimer <[email-masked]>
Date: Mon, 12 Aug 2002 19:28:41 +0200
Lines: 23
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> On 8/12/02 7:07 AM, "Florian Weimer" <[email-masked]> wrote:
>
>> IMHO, the draft does not specify the semantics of expiration in a way
>> which would warrant such statement.  I don't believe we can agree on a
>> specific set of expiration semantics even in the limited circle of
>> this WG.
>> 
>> BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html)
>> is definitely worth a read.
>
> That particular change was correcting a typo in the previous draft. It has
> nothing to do with the new paper.

Oh, I didn't want to imply *that* (hence "BTW").

I still think that the change is misleading.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898

Date: Mon, 12 Aug 2002 10:26:10 -0700 (PDT)
To: Florian Weimer <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Lines: 20
Sender: [email-masked]

On Mon, 12 Aug 2002 16:07:27 +0200, Florian Weimer said:

> IMHO, the draft does not specify the semantics of expiration in a way
> which would warrant such statement.  I don't believe we can agree on a
> specific set of expiration semantics even in the limited circle of

PNX (PGP is not X.509) ;-)

> BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html)
> is definitely worth a read.

And the reason why Jon released the draft and sharped the MDC wording.

I see no more problem with the draft.  How lets try again to kick off
the the interop tests.

Salam-Shalom,

   Werner

Date: Mon, 12 Aug 2002 10:23:26 -0700
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
From: Jon Callas <[email-masked]>
To: Florian Weimer <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 8/12/02 7:07 AM, "Florian Weimer" <[email-masked]> wrote:

> IMHO, the draft does not specify the semantics of expiration in a way
> which would warrant such statement.  I don't believe we can agree on a
> specific set of expiration semantics even in the limited circle of
> this WG.
> 
> BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html)
> is definitely worth a read.

That particular change was correcting a typo in the previous draft. It has
nothing to do with the new paper.

    Jon

To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
From: Florian Weimer <[email-masked]>
Date: Mon, 12 Aug 2002 16:07:27 +0200
Lines: 15
Sender: [email-masked]

|  Revoking a self-signature or allowing it to expire has a defined
|  semantic meaning.

IMHO, the draft does not specify the semantics of expiration in a way
which would warrant such statement.  I don't believe we can agree on a
specific set of expiration semantics even in the limited circle of
this WG.

BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html)
is definitely worth a read.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt
Date: Mon, 12 Aug 2002 07:20:37 -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		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney, R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-06.txt
	Pages		: 71
	Date		: 09-Aug-02
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc2440bis-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-rfc2440bis-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-rfc2440bis-06.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-josefsson-cert-openpgp-00.txt
Date: Tue, 06 Aug 2002 07:14:25 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: OpenPGP data in the CERT RR
	Author(s)	: S. Josefsson
	Filename	: draft-josefsson-cert-openpgp-00.txt
	Pages		: 9
	Date		: 05-Aug-02
	
This draft describes the decisions made in one pair of applications
[4][5] that respectively serves and retrieve OpenPGP [3] Certificates
and Revocation Signatures using the CERT Resources Record [2].  The
intent is to provide a discussion on the kind of general updates
needed to the CERT specification, and some suggested specific updates
for the OpenPGP sub-type.  It is offered in the hope that this
specification, together with similar efforts for other applications,
can be reviewed when designing a generic solution or guidelines for
storing application keying material in the Domain Name System (DNS),
should it ever happen.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-josefsson-cert-openpgp-00.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-josefsson-cert-openpgp-00.txt

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

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

--OtherAccess--

--NextPart--