Subject: Dash-escaping and the Usenet sig convention

From: Ian Bell <[email-masked]>
Date: Tue, 12 Dec 2000 10:23:24 +0000

It has been suggested that our mail/news client offer an option to "fix
up" the Usenet sig separator in clear-signed messages to
newsgroups/mailing lists - the problem being that the "-- " gets stuffed
to "- -- " with the result that recipients' clients will no longer
recognize and strip the personal signature in response messages.

The dash-escaping leads to complaints about clear-signed messages to
some groups and some users have taken to removing the dash-escaping by
hand. Although this breaks RFC2440, (NAI)PGP clients still seem to
correctly "de-escape" the message and verify the PGP signature.

The question is, how do openPGP clients cope with such messages and what
do other client vendors think about this? Since [open]PGP clients only
need to be able to correctly parse nested ASCII-armored header lines,
and these all begin with five hyphens, it would be possible to make an
exception for lines such as "-- " when doing the dash-escaping.

Munging the "- -- " back to "-- " does seem to yield benefits in inter-
operability (for the sig-sep convention) and acceptability of PGP-signed
messages, but it is important that it doesn't break inter-operability
between PGP clients.

Should RFC2440bis be updated to mention this? Do any existing clients
fall over by spotting that some lines are escaped at the "wrong" depth?

-- 
Ian Bell                                           T U R N P I K E

---

From: Werner Koch <[email-masked]>
Date: Tue, 12 Dec 2000 13:53:01 +0100

> to "- -- " with the result that recipients' clients will no longer

The preferred way to encapsulate OpenPGP messages in mail is by using
MIME as defined in RFC2015.  No need for the old fashioned cleartext
signing.

> The question is, how do openPGP clients cope with such messages and what

It is a matter of the MUA to handle this right.  Mutt for example
does remove the dash escaping even when it does not verify the
signature.

  Werner

---

From: Jon Callas <[email-masked]>
Date: Tue, 12 Dec 2000 08:06:12 -0800

In our last episode ("Re: Dash-escaping and the Usenet sig convention",

>MIME as defined in RFC2015.  No need for the old fashioned cleartext

I disagree completely. The correct way to encapsulate messages is with
cleartext. I often delete PGP-MIME messages without reading them because
it's such a pain to deal with them. I commonly use five different mail
readers on four different OSes, and none of them do PGP-MIME reliably.
That's Eudora on Mac and Windows, Outlook on Windows, Netscape and Pine on
Linux and OSX. The biggest pain is on Windows, where it's hard to scrape up
the attachment to put it in a text editor.

>does remove the dash escaping even when it does not verify the

I agree that this is a MUA and newsreader issue. They should parse out the
quoting. The dash-escape may be ugly, but it's been a part of PGP since day
2, if not day 1.

	Jon

---

From: Ian Bell <[email-masked]>
Date: Tue, 12 Dec 2000 16:42:20 +0000

On Tue, 12 Dec 2000, Werner Koch <[email-masked]> wrote:
>MIME as defined in RFC2015.

In an ideal world, PGP/MIME would be the only way anyone would send PGP
in email...

>  No need for the old fashioned cleartext
>signing.

...however, the reality is that most clients (in terms of numbers
deployed) seem not to be able to cope.

We have been asked to munge the dash-stuffed clear text as in practice
the use of PGP/MIME signed messages causes more complaints than clear-
signed messages, but clear-signing messages causes complaints about
broken sig-seps :-(

>does remove the dash escaping even when it does not verify the

As does Turnpike. However, it will be the openPGP client that has to
deal with the clear-text message with dash-stuffing that breaks RFC-
2440. As an example I have signed this message and broken the dash-
stuffing (behind Turnpike's back, I might add!). I'd be interested if it
causes any problems.

-- 
Ian Bell                                           T U R N P I K E

---

From: Ian Bell <[email-masked]>
Date: Thu, 21 Dec 2000 11:47:39 +0000

>>does remove the dash escaping even when it does not verify the

MUAs in general won't handle this right because for the most part MUAs
are PGP-unaware. The interoperability problem here is between PGP-aware
MUAs and PGP-unaware MUAs . Clear-signed messages are more acceptable to
PGP-unaware MUAs if the sig-sep is not hyphen-stuffed, and hence clear-
signing will be more acceptable in newsgroups and mailing-lists.

In order to increase the acceptability of PGP signed messages in
general, could 7.1 in 2440bis be amended as follows?

7.1. Dash-Escaped Text

   The cleartext content of the message must also be dash-escaped.

   Dash escaped cleartext is the ordinary cleartext where every line
   starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
   (0x2D) and space ' ' (0x20). This prevents the parser from
   recognizing armor headers of the cleartext itself. The message
   digest is computed using the cleartext itself, not the dash escaped
   form.

*  Note: dash-escaping can cause interoperability problems between PGP-
*  aware clients and PGP-unaware clients because some commonly used 
*  separator conventions use lines starting with multiple dashes. To 
*  improve interoperability in these cases, clients MAY omit the dash-
*  escaping for lines that cannot be armor headers and that are not 
*  already dash-escaped. Lines beginning with dash-space (0x2D, 0x20),
*  or with five dashes MUST be dash-escaped.

   As with binary signatures on text documents, a cleartext signature
   is calculated on the text using canonical <CR><LF> line endings.
   The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
   SIGNATURE-----' line that terminates the signed text is not
   considered part of the signed text.

   Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
   any line is ignored when the cleartext signature is calculated.

-- 
Ian Bell                                           T U R N P I K E

---

From: Werner Koch <[email-masked]>
Date: Thu, 21 Dec 2000 13:41:48 +0100

> *  already dash-escaped. Lines beginning with dash-space (0x2D, 0x20),

I am not sure whether yoy are talking about an OpenPGP implementaion
or an MUA.  We can't do that in the OpenPGP protocol.

The only thing we could do is to allow dash escaping in certain
situations like we do it for '^From '.  But it may break other
applications and I don't know why it should make sense at all.

  Werner

---

From: Ian Bell <[email-masked]>
Date: Thu, 21 Dec 2000 14:38:08 +0000

>applications and I don't know why it should make sense at all.

It makes sense from a MUA perspective because it increases
interoperability between MUAs in the real world. The problem can indeed
be ignored by open PGP implementations when they create clear-signed
text and can be dealt with by MUAs changing the dash-escaping before
posting in the way we have been asked to do. 

However this pushes the problem on to the receiving openPGP
implementation. It is the receiving openPGP implementation that has to
parse the results of clear-signed messages with some dash-escaping
removed. They can either cope, or treat the message as an invalid clear-
signed message (as old versions of Turnpike used to do!). In the real
world, some users are changing the dash-escaping by hand and they have
found that PGP (NAI) copes well.

I feel that there should be at least a note to reflect what is being
done to the dash-escaping in order to make openPGP implementations
robust when they encounter such messages and hopefully to encourage them
to correctly verify signatures in such messages as PGP itself would do.

-- 
Ian Bell                                           T U R N P I K E

---

From: Rodney Thayer <[email-masked]>
Date: Sat, 30 Dec 2000 12:42:33 -0800

I agree with Jon on this.  Insisting that the world suddenly change
to MIME is not helping the adoption of PGP, in fact, it makes it harder
as people tend to delete these nasty MIME messages.  It's even worse with
windows, as the (almost unreadable) "...ems" message looks annoyingly
similar to a (usually unreadable) SMIME message.  I too tend to
delete these messages, as they are functionally equivalent to spam.

I think we should be be building systems that INCREASE the usage of
this technology, not decrease it.

I agree it's the MUA's job to handle this civilly, but until that
happens, the cleartext solution is much more likely to be usable in
the real world.

At 08:06 AM 12/12/00 -0800, Jon Callas wrote:
>it's such a pain to deal with them.

Date: Sat, 30 Dec 2000 12:57:30 -0800
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Fwd: Re: rfc2440bis-02 comments
Sender: [email-masked]

this sounds way too vague.  how are the other implementors
with this?

>On Fri, 8 Dec 2000, Marc Horowitz wrote:
>
> > 3. Subpacket 23 (key server preferences) is specified to be "found
> >    only on a self-signature".  It should say if that means a direct
> >    key signature (which makes the most sense to me), or something
>
>As with many other subpackets there is no clear definition on what
>to do and it is left to the implementor to decide this.  From my
>understanding it does make sense to handle such things this way:
>
>   * If it is on any direct key signature, use this one (or exactly
>     the one on the latest direct key signure.
>
>   * Otherwise take it from the latest self-signature.
>
>(I have worked out some more rules and checked them with Hal.
>Currently I can't access them - please ask me next week, if you are
>interested)

"I have worked out some more rules" implies he had to work out
rules, which implies the text merits changing.

Date: Sat, 30 Dec 2000 12:42:33 -0800
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

I agree with Jon on this.  Insisting that the world suddenly change
to MIME is not helping the adoption of PGP, in fact, it makes it harder
as people tend to delete these nasty MIME messages.  It's even worse with
windows, as the (almost unreadable) "...ems" message looks annoyingly
similar to a (usually unreadable) SMIME message.  I too tend to
delete these messages, as they are functionally equivalent to spam.

I think we should be be building systems that INCREASE the usage of
this technology, not decrease it.

I agree it's the MUA's job to handle this civilly, but until that
happens, the cleartext solution is much more likely to be usable in
the real world.

At 08:06 AM 12/12/00 -0800, Jon Callas wrote:
>it's such a pain to deal with them.

Date: Thu, 28 Dec 2000 20:33:12 -0600 (CST)
From: Frank Tobin <[email-masked]>
To: <[email-masked]>
cc: <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

[email-masked], at 10:34 +0900 on Fri, 29 Dec 2000, wrote:

    perhaps a survey announced on the various user-oriented pgp lists
    would be useful for collecting feedback on the issue of deleting keys
    from keyservers?

Of course, in the future, people's needs are going to change.  They're
going to want new policies about how keyservers (and other entities)
handle their keys, and have other metadata associated with them.  To try
to "guess" what people are going to really need or want two years from now
is a reach at best.  If there is no attempt to use an extensible format
that accounts for the many different key-handling policies and metadata
that different people/entities are going to want to use, evil, bad hacks
are going to start occuring eventually.

One of the problems, I feel, is that we're trying to jam too much into the
few bits available in the OpenPGP spec.  Simple boolean's just don't cut
it.

This is me dreaming here, but what'd really be good is to have the
metadata for keys separated out from the OpenPGP spec, and handled by
another, extensible mechanism, quite possibly/preferably XML.  This could
allow the metadata to be extended via namespaces by however one wishes.
There is no tie-down by specification mandating what policies can be
accomodated.  OpenPGP need not know about this extensible spec, since it's
pretty much finalized, but clients could adapt, and handle the specs in
pair.

In the end, I forsee troubles for OpenPGP if we try to quantify what
policies OpenPGP keys should be capable of holding metadata about.

- -- 
Frank Tobin		http://www.uiuc.edu/~ftobin/

From: [email-masked]
Date: Fri, 29 Dec 2000 10:34:49 +0900 (JST)
To: [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

From: Marc Horowitz <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Date: 26 Dec 2000 22:36:38 -0500

> Why do these people want to delete their keys?

[ text of various reasons deleted ]

> - I don't want my key on the keyservers at all.

for reference, below is part of an edited recent post from the
[email-masked] mailing list of someone who doesn't want their
key on a keyserver at all.

perhaps a survey announced on the various user-oriented pgp lists
would be useful for collecting feedback on the issue of deleting keys
from keyservers?

Subject: Re: Deleting Keys on Keyservers
From: Lazarus Long [address deleted]
To: GnuPG Users List <[email-masked]>
Date: Thu, 28 Dec 2000 15:50:23 +0000

On Wed, Dec 27, 2000 at 09:49:55PM +0100, Martin wrote:
 > From: Martin [address deleted]
  
 > im just curious. Is there a way to delete a key from a keyserver?

Nope.  Once your key is there, you are hanging out there in the wind for
spambots to come harvest for all eternity.

From: [email-masked]
Date: Thu, 28 Dec 2000 17:53:15 +0900 (JST)
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: rfc2440bis-02 comments 
Sender: [email-masked]

i am about to give up...i think we're going off-topic.  perhaps we
should continue this off-list.  the points i wish to make are:

  -expiring keys from keyservers is not necessarily a bad idea -- at least 
   your example does not convince me that we would be significantly worse
   off than the current situation.  i like Dave Del Torto's statement:

     Storing your key on a public keyserver is a privilege, not a right.
     If you can't do the most basic things to maintain it, you're not
     doing anyone any good, least of all yourself if you want people to
     use it.

  -out-of-band channels for verification are necessary for using these
   kinds of systems well -- keyservers can help reduce the total amount of 
   out-of-band verification, but it is not a substitute on its own.
   (both web-of-trust and x.509 require at least some out-of-band verification
   at some point)

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Date: Thu, 28 Dec 2000 13:24:02 +0900
Sender: [email-masked]

> my guess is that you are saying that addressing the example scenario
> you gave is a design goal of public key distribution and verification.

I meant that PGP's conventional (simple, oldstyle, or whatever :-)
digital signature can use in very simple digital signature scheme.  My
scenario will be applied to not only PGP but also almost current
digital signature tools.

I guess that you want more sophisticated digital signature scheme than
current PGP digital signature scheme.

> but having a key from the keyserver that might be alice's
> key is not enough.  olive must also establish that the key is alice's.

Web-of-trust, X.509, and some certification schemes give us the
capability of public key trustness without contacting public-key
owner.

					--hironobu

From: [email-masked]
Date: Thu, 28 Dec 2000 11:21:56 +0900 (JST)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Sender: [email-masked]

From: Hironobu SUZUKI <[email-masked]>
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 15:50:44 +0900

...

> > i don't think the example in question should dictate everyone's
> > policy.
> 
> Alice, Bob and Olive story may be vulnerability of public key
> distribution and verification, is not sort of policy.

i'm sorry, but i wasn't able to understand what you meant.

my guess is that you are saying that addressing the example scenario
you gave is a design goal of public key distribution and verification.

is that what you meant?  if not, please elaborate.

i don't think the current keyserver structure alone addresses the
scenario you gave.  you also need to establish that a particular key
belongs to a particular entity -- this is not possible using only the
keyservers -- you need to perform at least one key fingerprint
verification and depending on the situation, you may also need a trail
of appropriate signatures to the entity's key.  

in your example scenario:

  in step 3, bob is not certain that the text was written by alice
  until he verifies that the key is hers.  he can do that via
  contacting alice, or if an appropriate chain of signatures exist,
  he can do it via that method (it depends on his policy).  once bob
  has verified the relationship between alice and the key he downloaded,
  then he can be certain (actually he can be certain w/o this, but he 
  will be foolish for being certain ;-) )

  in step 5, it is true that olive can't verify alice's text because
  she doesn't have alice's public key.  but having a key from the
  keyserver that might be alice's key is not enough.  olive must also
  establish that the key is alice's.

so to summarize, verifying signed text is going to require verifying
entity-key associations.  that's going to require communication
between entities.  imo, this communication should clear up
difficulties in most cases.

i think there will be pathological cases where verification of
signatures will not be possible.  

in fact, the current situation does provide examples of such
situations -- for example, there are already keys on the keyservers
for which no one can establish relationships to owning entities:

  any key that no one has done a fingerprint verification for and the 
  secret key material is lost

if there is some text signed w/ such a key floating out there, no one
will be able to verify the signature.  even if one person has
performed a key fingerprint verification for the key, if no one else
trusts this person as a verifying entity, no one else will be able to
verify the signature.

imo, those kinds of pathelogical situations need to manage their risks
using additional means.

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 15:50:44 +0900
Sender: [email-masked]

> i don't think the example in question should dictate everyone's
> policy.

Alice, Bob and Olive story may be vulnerability of public key
distribution and verification, is not sort of policy.

If you mention about privacy, I mean hiding personal information,
PGP's (simple) digital signature scheme is not enough to solve it.
You might need blind signature, undeniable signature, non-transitive
or other digital signature scheme.
						--hironobu

From: [email-masked]
Date: Wed, 27 Dec 2000 15:02:15 +0900 (JST)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Sender: [email-masked]

From: Hironobu SUZUKI <[email-masked]>
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 14:41:13 +0900

> Removing from keyserver is bad idea. After public key was issued,
> there are two status for public keys which are "Valid" or "Not-Valid"
> (removked).

[ example snipped ]

i don't think the example in question should dictate everyone's
policy.

if it really is the case that in step 1 alice distributes her public
key to the world for verifying her signed text by everyone, that is
her policy decision and she has to figure out a way to make that work
-- assuming that the mechanisms exist, she can express that in her key
info by setting an expire time significantly in the future and perhaps
some other field that expresses the idea that she cannot go back on
her word.

other people may not want that kind of policy.  i know i don't for
every key i make.

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 14:41:13 +0900
Sender: [email-masked]

>   -keys expire from servers by default.  perhaps 6 months or 1 year.

Removing from keyserver is bad idea. After public key was issued,
there are two status for public keys which are "Valid" or "Not-Valid"
(removked).

Alice, Bob and Olive story.

 Step 1: Alice distribute her public key to the world for verifying
	her signed text by everyone.

 Step 2: Alice sign text and distribute signed text to the world.

 Step 3: Bob get Alice's public key and verify Alice's signed text.
         Bob is certain that this text was written by Alice.

 Step 4: Alice remove her public key from all of the world.

 Step 5: Olive get Alice's signed text. But she can't get Alice's 
	 public key and can't verify Alice's signed text.
	 Olive is not certain that this text was written by Alice.

 Step 6: Bob says "this is Alice's text", Olive says "I'm not sure 
	 this is Alice's text".

This is a kind of chaos. 
					--hironobu

From: [email-masked]
Date: Wed, 27 Dec 2000 14:02:58 +0900 (JST)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Sender: [email-masked]

hello all,

From: Hironobu SUZUKI <[email-masked]>
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 13:33:38 +0900

> 2 years ago, I got a complain e-mail about adding public key by a
> third party.  Then I thought multi-phase commit for keyserver.  But my
> idea looks crypto-over-kill for our public keyserver.

[ detailed description of pk-based challenge-response scheme snipped ]

> This solution is not simple and powerful CPU is required for
> keyserver. But I'm not sure that it is too much cost for keyserver.
> 
> Please note that this is only idea and I don't recommend it.

to add more hypothetical information to the situation...

if keyservers are going to do authentication-like things (a big "if"),
why not do the following:

  -before adding a key from the queue to a database, use an email confirmation
   system to solicit confirming email (don't need to use pk-based
   challenge-response for this) -- just use what many mailing list
   systems use.  if confirmation is obtained, add the key to the database.

  -in order to remove a key from the database, use a challenge-response 
   system like Hironobu described.

  -keys expire from servers by default.  perhaps 6 months or 1 year.

points to observe:

  -if deletions are relatively scarce events, you don't need much cpu
   power.  keyservers can even decide to only service delete requests
   periodically in bulk.

  -in the case that the confirmation by email process is "spoofed" and
   a third party adds someone's key, the holder of the secret key can remove
   the key using the above method.  i'm assuming the spoofing shouldn't
   be something that should continue to happen to a particular individual -- 
   if it does, imo, that person has other problems that need to deal with 
   first.

  -an "expire-from-server" time field (only allowed in the hashed area)
   could be defined in rfc 2440, support for this in keyservers and
   openpgp client implementations seems like one way to accomplish the
   expiration idea.

  -unused keys will be removed from servers over time.  less garbage is
   collected and people who lose their secret keys can relax after a while.
   new users can be encouraged to choose short "expire-from-server" times.
   i think it's important to be able to update one's "expire-from-server"
   time -- i don't understand how key information on keyservers gets
   updated (which key information takes priority?  always what gets submitted
   later in time?  if so, may be something like a "timestamp" field is 
   necessary in the hashed area so that a keyserver can decide which key info
   is more recent).

  -it's not required that keys have email address info associated w/ them.
   it's not clear to me whether one would bother w/ confirmation for these.

thoughts?

From: Hironobu SUZUKI <[email-masked]>
To: Marc Horowitz <[email-masked]>
cc: Derek Atkins <[email-masked]>, "L. Sassaman" <[email-masked]>, Dave Del Torto <[email-masked]>, [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments 
Date: Wed, 27 Dec 2000 13:33:38 +0900
Sender: [email-masked]

Hi, Marc.

> - I don't want my key on the keyservers at all.
>    
>   Your proposal solves this problem, but in my experience, this almost
>   never happens. 

2 years ago, I got a complain e-mail about adding public key by a
third party.  Then I thought multi-phase commit for keyserver.  But my
idea looks crypto-over-kill for our public keyserver.

 Step 1: User submit their public key to keyserver.

 Step 2: Keyserver save this public key in queue database.

 Step 3: keyserver returns "ticket (challenge random number)"
	 which is encrypted by user's public key.

 Step 4: After User decrypt received "ticket", user sign "ticket" by
	their secret key and send "signed ticket" to keyserver.
 
 Step 5: Keyserver check "signed ticket" by user's queued public
	 key. 

	 Ture -> move it to public-open database.

	 False -> delete from queue database.

  Note: When keyserver use this scheme, Sync data must be signed
	or something against forge sync data. 
	(Also adding MAC looks good).

This solution is not simple and powerful CPU is required for
keyserver. But I'm not sure that it is too much cost for keyserver.

Please note that this is only idea and I don't recommend it.

					--hironobu

From: Marc Horowitz <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: "L. Sassaman" <[email-masked]>, Dave Del Torto <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Date: 26 Dec 2000 22:36:38 -0500
Lines: 32
Sender: [email-masked]

Len, exactly what problem is you proposal intended to solve?  You
said:

    One of the major complaints I hear about PGP key servers is the inability
    to delete keys once they are sent to the server. I'd like to request the
    addition of two new flags for subpacket 23:

Why do these people want to delete their keys?

- They lost the private key or forgot the passphrase.

  Like Derek, this is by far the most common reason I get email from
  people who want their keys deleted.  Your proposal doesn't solve
  this problem, since they can't modify the key to change the
  keyserver preferences.

- They don't want anybody to know they have a key.

  It doesn't solve this problem, either, as others have pointed out.

- The key is compromised.

  In this case, they should revoke it.

- I don't want my key on the keyservers at all.
   
  Your proposal solves this problem, but in my experience, this almost
  never happens. 

or is there another problem I've missed?

                Marc

From: [email-masked]
Date: 21 Dec 00 1:39:39 PM
Subject: Improve your stepfamily life
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Sender: [email-masked]

Does your stepfamily life resemble a soap opera more than it does the Brady
Bunch?

The Stepfamily Association of America invites you to participate in THE
NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans
Marriott Hotel.

This is an opportunity, designed by knowledgeable professionals, in
stepfamilies themselves, to help you:
* Make your remarriage a success
* Create bonds with your stepchildren
* Help your children adjust emotionally
* Manage money matters unique to your family
* Get more help from legal, financial, psychological advisors
* Overcome stepfather and stepmother stereotypes
* Elicit cooperation from your children's schools
* Bring more harmony into family life

Complete conference details at http://www.edupr.com
REGISTER ONLINE!

Attend, and also enjoy Mardi Gras week in New Orleans!

Special discounts for couples, students, groups.

HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND
AIRLINE SEATS FILL Special rates for conference attendees. Visit
http://www.edupr.com for discounts. Childcare available through a bonded
local service.

Up to 17 professional development credits available if you are an 			
educator, clinician, financial planner, social worker.

Questions? Email [email-masked]

If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.

Date: Thu, 21 Dec 2000 10:45:01 -0500
From: Robert Guerra <[email-masked]>
To: [email-masked]
cc: Keyserver-Folk-Mailinglist <[email-masked]>
Subject: [PGP-USERS] (mac) PGP 6.5.8 -> Request for patchfix comments.. (fwd)
Sender: [email-masked]

---------- Forwarded Message ----------
Date: Thursday, December 21, 2000 8:17 AM -0500
From: Robert Guerra <[email-masked]>
To: [email-masked]
Subject: [PGP-USERS] (mac) PGP 6.5.8 -> Request for patchfix comments..

Hi there:

A couple days back I detailed a persistant problem in which the first
couple of lines of pgp cyphertext appears in the Header section of email.

I've consulted with the developper of the the email client I use (eudora)
and the email server I use (EIMS 3.02) and they both point fingers to it
being a problem with the pgp-plugin on the mac end.

As it's not a security hole, and since NAI won't issue a specific bug
fix...it leaves it to me to see what to do..

Consequently I have dowloaded the (mac) PGP 658 source code from the
www.pgpi.org site and quickly looked over the code.

I currently don't have the time nor resources to recompiple the code..so
i've included my suggested patches in an archive for peer review.

http://www.cryptorights.org/pgp-users/resources/mac-pgpfix.sit.Hqx

I'm hoping those more knowleable with the code will :

1. take a look at it
2. ok the changes and/or correct it further
3. post any comments and/or additional suggestions
4. re-compile the code for the community

looking forward to everyone's comments

regards

robert

....................................................................
Unsubscribe: <mailto:[email-masked]?body=unsubscribe>
Automated Help/Info: <mailto:[email-masked]?body=help>
List Homepage: <http://cryptorights.org/pgp-users/>
List Admin (human): <mailto:[email-masked]>
Please do not send administrative commands to the list address!  Thanks.

---------- End Forwarded Message ----------

Date: Thu, 21 Dec 2000 14:38:08 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

-- 
Ian Bell                                           T U R N P I K E

Date: Thu, 21 Dec 2000 13:41:48 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping and the Usenet sig convention
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

Date: Thu, 21 Dec 2000 11:47:39 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

7.1. Dash-Escaped Text

-- 
Ian Bell                                           T U R N P I K E

Date: Tue, 19 Dec 2000 19:59:25 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: Don't Get Ripped Off!
Organization: 
Sender: [email-masked]

I'm sure... If my competitors get a hold of this letter,
I might as well move out of the country!

Let me explain.

I'm in the business of setting people up to do
business on the Internet. As you probably know, there's only
a few things that you actually need to accomplish this....

1. Something to sell
2. A working website
3. Traffic to the website
4. A way for people to pay you over the net.

Here's my point. While my competitors are charging anywhere from $695
to a few thousand to get people set up to do business on the net,
my company does it all for -- a one time -- complete price of $195!

Maybe that's the reason we currently have over 180,000 clients
using our services. (We list a large number of them on our website).

The $195 includes everything... Your own Domain (website), Free
website hosting unlimited email accounts, autoresponders, shopping
cart system, online credit card acceptace (processing) system,
Internet merchant account, Free software that creates your website,
Free instructions on getting traffic to your website, and many other
Free tools to neumerous to list in a short email message.

Anyway, If you've been thinking about selling online, but
thought it was too expensive or complicated or too confusing,
you've been paying to much attention to my competitors.

If you're interested and want to find out more, It's very simple to do.
Simply call my office -- toll free -- 888-269-7960 and I'll
be glad to explain everything to you in detail. Just be aware,
that I might be on the phone helping someone else out.
So kindly leave a message and I'll get right back to you.

If you're not interested, just delete this message. 
You'll never hear from me again. I guarantee it!

Merchant Systems

Date: Tue, 19 Dec 2000 14:50:14 -0800 (PST)
From: [email-masked]
To: [email-masked]
Subject: FREE Catalog
Organization: Lindale USA
Sender: [email-masked]

--=200012191751=
Content-Type: text/plain;charset=US-ASCII

Happy Holidays from Linda and Dale!

YOU have been selected to receive a FREE "Showcase" catalog!

As our Holiday gift to you, we will send you our BEAUTIFUL full-color "Showcase" catalog just for the asking!  All you have to do is click here... http://www.wholesalespecialties.com/showcasecatalogorder.htm

It's jam-packed with our best high-quality gift merchandise that is PERFECT for every gift occasion.  We even have a way for you to make money while you shop for gifts!

Please click here to order your FREE "Showcase" catalog... http://www.wholesalespecialties.com/showcasecatalogorder.htm and click here to visit our online gift shop... http://www.wholesalespecialties.com

Thanks again and have a WONDREFUL hoilday season!

Linda and Dale
Lindale USA 

Your email address was submitted to us by a visitor to our web site.  They want to let you know about our fabulous offer so that you can have your own FREE catalog too.  If your email address has been given to us by mistake or if you have received this email offer by mistake, please click here to be automatically removed from our list... [email-masked] 
--=200012191751=--

Date: Mon, 18 Dec 2000 05:54:56 -0800
To: [email-masked]
From: Dave Del Torto <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 2:42 pm +0900 2000-12-18, [email-masked] wrote:
>one authentication-less way that occurred to me is to have keys have
>life times on servers (default being 1 year perhaps?).  then, though
>you might have to wait a while, at least your old keys could disappear
>from servers after a certain period of time.

I agree that the default should be one year. I've been calling for
this for a very long time, and I'm definitely not alone. There are so
many confused users out there on these key management points: I'm
beginning to wonder if the development community is really paying
attention to usability issues. PGP 7's Key Reconstruction is a very
nice idea, but I've tried to get some newbies to use it and their
reaction to being confronted by a dialog asking them to come up with
five questions in case they forgot their passphrase was "are you
kidding me?!"

Also consider the idea of keyservers employing "flushing routines"
for potentially "dead" keys. In one possible scenario, a key has
languished on a server (e.g. hasn't been accessed for n ticks) for
two years, has no expiration and is about to disappear as described
above. The keyserver could email it to all of the email addresses on
the key (this would encourage people to keep their userids current,
yet another extremely common key hygiene problem). If the key wasn't
updated by anyone within another time period (set by the admin), the
key would be dropped.

Storing your key on a public keyserver is a privilege, not a right.
If you can't do the most basic things to maintain it, you're not
doing anyone any good, least of all yourself if you want people to
use it.

>your client software can remind you that you need to upload your key
>when it gets close to the "expiration" date/time.

It would make sense if *all* OpenPGP-compliant implementations had
some basic HCI features like this: a warning when one's key is about
to expire seems extremely obvious -- or even when signatures made by
one's key on others' keys (stored on one's local keyring) are about
to expire.

Jon, perhaps expiration packets can be mentioned in 2440bis as being
potential triggers for this mechanism. Implementors could also be
encouraged to consider providing expiration warning mechanisms.

    dave

From: [email-masked]
Date: Mon, 18 Dec 2000 14:42:52 +0900 (JST)
To: [email-masked], [email-masked]
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

From: Derek Atkins <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Date: 17 Dec 2000 12:21:05 -0500

> Unfortunately this particular approach will not solve what I believe
> to be the bigger problem: "I reinstalled my machine and lost my secret
> key; can you remove it from the keyserver, please?" or "I forgot my
> passphrase, can you please delete my key from the keyservers?"  If I
> had a dollar for every time I received one of these messages, I'd be a
> very rich man right now ;)

is it possible to address this issue w/o the keyservers doing any sort
of authentication?  i had thought that there was a fairly strong
feeling that the keyservers should not do any sort of authentication.

has this changed?

one authentication-less way that occurred to me is to have keys have
life times on servers (default being 1 year perhaps?).  then, though
you might have to wait a while, at least your old keys could disappear
from servers after a certain period of time.  

your client software can remind you that you need to upload your key
when it gets close to the "expiration" date/time.

[ of course the "expire-from-server" date needs to be in the hashed area. ]

To: "L. Sassaman" <[email-masked]>
Cc: Dave Del Torto <[email-masked]>, Marc Horowitz <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: rfc2440bis-02 comments
From: Derek Atkins <[email-masked]>
Date: 17 Dec 2000 12:21:05 -0500
Lines: 24
Sender: [email-masked]

Unfortunately this particular approach will not solve what I believe
to be the bigger problem: "I reinstalled my machine and lost my secret
key; can you remove it from the keyserver, please?" or "I forgot my
passphrase, can you please delete my key from the keyservers?"  If I
had a dollar for every time I received one of these messages, I'd be a
very rich man right now ;)

The additional packets really don't help much more than being able to
revoke one's key.  If one could 'disable' a key themselves, they could
also revoke that same key.  The problem is that most of the requests
come from people who cannot modify their key (due to circumstances
that may or may not be out of their control).

If we're going to solve the "key disable" problem, we need to do so in
a manner that helps the user who lost their own key.  Otherwise the
solution really doesn't solve the real problems that exist today.

-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: Fri, 15 Dec 2000 16:53:55 -0800 (PST)
From: "L. Sassaman" <[email-masked]>
To: Dave Del Torto <[email-masked]>
cc: Marc Horowitz <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

On Fri, 15 Dec 2000, Dave Del Torto wrote:

> The threat, perhaps a theoretical one at this point in time, is
> that if you're trying to mask the very existence of your key on
> one or more keyservers (for example to thwart an improperly coercive
> demand for keying material from rogue officials), you will not be able
> to do so with these flags. You would only be able to do this by
> deleting them via an LDAPS (or similarly secure) keyserver connection.

Sure. That isn't the threat these flags were intended to solve. In fact, I
am not sure this threat you mention isn't an intractable problem; once a
key is deleted from the server, it can always be re-added by a third
party.

(Unless, of course, the no-modify flag is set. Then the owner of the key
would be required to authenticate himself prior to adding the key to the
server.)

> BTW, the trail of evidence that Deletion would involve, reminds me of
> another thread I wanted to raise (wearing my CryptoRights hat) with
> the keyserver managers, regarding the need for standardized
> mechanisms permitting secure, UNauthenticated, UNlogged connections
> to keyservers. Deleting a key would still require a passphrase, but
> it would permit one to clear a key if one was under threat.

Hrmm. guaranteeing that connections are unlogged isn't really possible, I
don't think. Though if this became a really important issue, I suspect you
could set up some sort of key request system using the anonymous remailer
network... but that seems a bit extreme.

Rodney Thayer and I are working on an Internet Draft for key server
behavior. We'll try to cover all these issues in there, and will welcome
any comments on it when we publish.

(Key server issues are really beyond the scope of 2440. The only reason
I've brought this up now is that I would like to see these flags added so
we can utilize them in the key servers.)

Thanks for your comments,

- --Len.

__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting

Date: Fri, 15 Dec 2000 15:48:57 -0800
To: "L. Sassaman" <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Cc: Marc Horowitz <[email-masked]>, <[email-masked]>, [email-masked]
Sender: [email-masked]

At 2:46 pm -0800 2000-12-15, L. Sassaman wrote:
>On Fri, 15 Dec 2000, Dave Del Torto wrote:
>>However, if the intent is to "mask" the presence of Bob's key on
>>the keyserver in lieu of Deleting it, it's hard to see what sort of
>>keyserver response behaviour would prevent Eve from trying to
>>determine the presence of Bob's key on the server -- by deducing
>>that information using the very 0x40 flag you describe in
>>conjunction with the keyserver behaviour. This simply shifts the
>>policy focus from the pksd's delete policy to its search policy.
>>
>>All Eve would need to do is upload the public component to the
>>keyserver in order to determine the status of the subpacket 23
>>enable/disable flags: if the key is present but disabled, it will
>>"vanish," confirming that it's disabled. If not present, it will be
>>returned by a subsequent search. A rudimentary traffic analysis
>>technique.
>
>Where is the threat here?

The threat, perhaps a theoretical one at this point in time, is
that if you're trying to mask the very existence of your key on
one or more keyservers (for example to thwart an improperly coercive
demand for keying material from rogue officials), you will not be able
to do so with these flags. You would only be able to do this by 
deleting them via an LDAPS (or similarly secure) keyserver connection.

BTW, the trail of evidence that Deletion would involve, reminds me of
another thread I wanted to raise (wearing my CryptoRights hat) with
the keyserver managers, regarding the need for standardized
mechanisms permitting secure, UNauthenticated, UNlogged connections
to keyservers. Deleting a key would still require a passphrase, but
it would permit one to clear a key if one was under threat.

>The reason I prefer a "disable" approach to a "delete" approach is
>that deleted keys can always reappear. The behavior you describe
>seems to me to be the appropriate one.

We can agree on that much. I guess I'm just applying a more stringent
threat model -- speculating that regimes like RIPA may someday soon
negatively impact the human rights of crypto users. I still like your
key-disable flag idea, Len.

    dave

Date: Fri, 15 Dec 2000 14:46:48 -0800 (PST)
From: "L. Sassaman" <[email-masked]>
To: Dave Del Torto <[email-masked]>
cc: Marc Horowitz <[email-masked]>, <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

On Fri, 15 Dec 2000, Dave Del Torto wrote:

> If the intent is to allow a Alice to effectively Remove her public
> key -- even if the keyserver's policy/software doesn't allow her to
> Delete it -- then I think this is useful. Of course, this presumes
> that Alice still retains her ability to modify the public key.

Of course.

> However, if the intent is to "mask" the presence of Bob's key on the
> keyserver in lieu of Deleting it, it's hard to see what sort of
> keyserver response behaviour would prevent Eve from trying to
> determine the presence of Bob's key on the server -- by deducing that
> information using the very 0x40 flag you describe in conjunction with
> the keyserver behaviour. This simply shifts the policy focus from the
> pksd's delete policy to its search policy.
>
> All Eve would need to do is upload the public component to the
> keyserver in order to determine the status of the subpacket 23
> enable/disable flags: if the key is present but disabled, it will
> "vanish," confirming that it's disabled. If not present, it will be
> returned by a subsequent search. A rudimentary traffic analysis
> technique.

Where is the threat here? The reason I prefer a "disable" approach to a
"delete" approach is that deleted keys can always reappear. The behavior
you describe seems to me to be the appropriate one.

> The big question of course, is "who can set these flags?" IMHO, they
> musn't be outside the hashed subpackets: they need to be set by the
> key-owner, lest they contribute to a DoS attack on any given public
> key. This means that Alice or Bob could just as easily Revoke (or,
> pksd policy permitting, Delete) their keypairs. If the keyserver
> admmin is to be allowed to set the flag, this raises a serious key
> management policy question, again just shifting the problem
> elsewhere, but not solving it entirely.

Right, no one, not even the key server admin, would be able to set these
flags besides the key owner. I didn't feel that needed stating, since
these flags are an addition to an existing subpacket which is already only
found in self-signatures.

They MUST NOT be placed outside the hashed area.

- --Len.

__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting

Date: Fri, 15 Dec 2000 14:22:43 -0800
To: "L. Sassaman" <[email-masked]>
From: Dave Del Torto <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Cc: Marc Horowitz <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 3:11 am -0800 2000-12-15, L. Sassaman wrote:
>One of the major complaints I hear about PGP key servers is the inability
>to delete keys once they are sent to the server. I'd like to request the
>addition of two new flags for subpacket 23:
>
>     0x40 = Disabled
>     the key holder requests that this key not be returned upon
>     a search of the key server.
>
>     0x60 = Enabled
>     the key holder requests that this key be returned upon a
>     search of the key server.
>
>Keys bearing the disabled flag would either reside on the key server and
>never be returned in a search (except perhaps to the administrator), or
>they would be immediately deleted upon receipt by the key server.

Len,

I'm intrigued by your idea of "disabling" keys as a solution to this
problem. I think it could be a useful addition, even with the
questions it raises.

If the intent is to allow a Alice to effectively Remove her public
key -- even if the keyserver's policy/software doesn't allow her to
Delete it -- then I think this is useful. Of course, this presumes
that Alice still retains her ability to modify the public key.

However, if the intent is to "mask" the presence of Bob's key on the
keyserver in lieu of Deleting it, it's hard to see what sort of
keyserver response behaviour would prevent Eve from trying to
determine the presence of Bob's key on the server -- by deducing that
information using the very 0x40 flag you describe in conjunction with
the keyserver behaviour. This simply shifts the policy focus from the
pksd's delete policy to its search policy.

All Eve would need to do is upload the public component to the
keyserver in order to determine the status of the subpacket 23
enable/disable flags: if the key is present but disabled, it will
"vanish," confirming that it's disabled. If not present, it will be
returned by a subsequent search. A rudimentary traffic analysis
technique.

The big question of course, is "who can set these flags?" IMHO, they
musn't be outside the hashed subpackets: they need to be set by the
key-owner, lest they contribute to a DoS attack on any given public
key. This means that Alice or Bob could just as easily Revoke (or,
pksd policy permitting, Delete) their keypairs. If the keyserver
admmin is to be allowed to set the flag, this raises a serious key
management policy question, again just shifting the problem
elsewhere, but not solving it entirely.

    dave

Date: Fri, 15 Dec 2000 03:11:03 -0800 (PST)
From: "L. Sassaman" <[email-masked]>
To: Marc Horowitz <[email-masked]>
cc: <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

Marc mentioned 5.2.3.17 (Key server preferences) and that reminded me of a
suggestion I wanted to make.

One of the major complaints I hear about PGP key servers is the inability
to delete keys once they are sent to the server. I'd like to request the
addition of two new flags for subpacket 23:

    0x40 = Disabled
    the key holder requests that this key not be returned upon
    a search of the key server.

    0x60 = Enabled
    the key holder requests that this key be returned upon a
    search of the key server.

Keys bearing the disabled flag would either reside on the key server and
never be returned in a search (except perhaps to the administrator), or
they would be immediately deleted upon receipt by the key server.

(The reason for the enabled flag is to reverse the effects of the disabled
flag at a later date. And of course, if neither the disabled not the
enabled flags are set, keys are implicitly enabled.)

__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting

Date: Tue, 12 Dec 2000 16:42:20 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

-- 
Ian Bell                                           T U R N P I K E

Date: Tue, 12 Dec 2000 08:06:12 -0800
To: Werner Koch <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

	Jon

Date: Tue, 12 Dec 2000 13:53:01 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Dash-escaping and the Usenet sig convention
Mail-Followup-To: [email-masked]
Sender: [email-masked]

  Werner

Date: Tue, 12 Dec 2000 10:23:24 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

-- 
Ian Bell                                           T U R N P I K E

Date: Mon, 11 Dec 2000 17:59:27 -0500 (EST)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01)
Sender: [email-masked]

                   R E G I S T E R   N O W ! !

THE INTERNET SOCIETY'S
2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) 
February 8-9, 2001
Catamaran Resort Hotel, San Diego, California
General Chair:   Steve Welke, Trusted Computer Solutions
Program Chairs:  Avi Rubin, AT&T Labs - Research
                 Paul Van Oorschot, Entrust Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss01
EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2001

The 8th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges.  The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented.  NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.

THIS YEAR'S TOPICS INCLUDE:
* IP Traceback
* Authenticating Streamed Data
* ATM Encryption
* Source Authentication for Multicast
* Distributed Certified E-Mail
* Wireless Security
* Multi-Security Domain Networks
* Authentication And Key Agreement
* Access Control Language for Security Policies
* Limiting the Disclosure of Access Control Policies
* Principles of Policy in Secure Groups
* Trust Management for IPsec
* Building Certification Paths
* Decentralized Jini Security
* Termination in Language-based Systems
* Cryptography as a Network Service
* Implementation of Kerberos Crossrealm Referral Handling
* Security Risks of Peer-to-Peer Networking

PRE-CONFERENCE TECHNICAL TUTORIALS:
* Network Security Protocol Standards, Stephen Kent
* Deployed & Emerging Security Systems for the Internet, Radia Perlman &
  Charlie Kaufman
* Building Secure Software, Gary McGraw
* Intrusion Detection, Dan Nadir
* Biometrics, Jim Wayman
* Group Security, Thomas Hardjono & Hugh Harney

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Torryn Brazell at the Internet Society
at +1-703-326-9880 or send e-mail to [email-masked].

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

From: Mail Sender<[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Russian Goods and Service from Moscow
Reply-To: [email-masked]
Date: 09.12.2000
Sender: [email-masked]

www.rusgoods.com    www.rusgoods.ru
================================================================
We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical 
watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . 
  It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes 
watches for the Russian Air Forces , Russian Naval Forces. 
  All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the 
warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any 
middlemans.
 The submarine "Kursk" had on board mechanical marine hronometr 6MX. 
 ===============================================================
The "table" of orders.    Here you can to order, to find, to know almost everything, than the Russia is rich, 
everything 
that does not contradict Russian Federation laws. 
Here you can receive or order:

The information about any enterprise, firm, organization, or person in Russia 
The production or any goods of Russian manufactories, and other things if it is possible. 
===============================================================
www.rusgoods.com    www.rusgoods.ru

Date: Fri, 8 Dec 2000 13:04:27 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: rfc2440bis-02 comments
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 8 Dec 2000, Marc Horowitz wrote:

> 3. Subpacket 23 (key server preferences) is specified to be "found
>    only on a self-signature".  It should say if that means a direct
>    key signature (which makes the most sense to me), or something

As with many other subpackets there is no clear definition on what
to do and it is left to the implementor to decide this.  From my
understanding it does make sense to handle such things this way:

  * If it is on any direct key signature, use this one (or exactly
    the one on the latest direct key signure.

  * Otherwise take it from the latest self-signature.  

(I have worked out some more rules and checked them with Hal.
Currently I can't access them - please ask me next week, if you are
interested)

> 4. The document is vague on what constitures "advisory information" in
>    a signature subpacket (section 5.2.3).  I believe that unhashed
>    signature subpackets were a mistake (I can expound on this if

No, they make sense.  It may happen that you need to store some meta
information about a signature which you have to calculate after
signature creation. 

However, a big warning about unhashed stuff should be present.

> 5. There should be a note that the critical bit MUST be ignored on
>    unhashed signature subpackets.  Otherwise, an attacker can easily
>    cause any signature to fail to verify.

Does not make sense.  An attacker can make _any_ signature fail but
just flipping one bit.

  Werner

From: Marc Horowitz <[email-masked]>
To: [email-masked]
Subject: rfc2440bis-02 comments
Date: 08 Dec 2000 00:51:19 -0500
Lines: 62
Sender: [email-masked]

Many of these comments come from notes I took on rfc2440, so I may
have some section numbers wrong.  I did compare these notes to the
I-D, and I believe all of them are still relevant.

1. Section 5.2 is vague about how to compute signature types 0x30 and
   0x40.  The document should specify over what data to compute the
   hash to be signed.  There was also a comment in the list archives
   about the description of signature type 0x18, which says

	This signature is calculated directly on the subkey itself,
	not on any User ID or other packets.

   This is tremendously misleading, since the signature is actually
   computed on a hash over a prefix, the key packet, the subkey
   packet, and a trailer.  Section 5.2.4 gives a more detailed
   description of how to compute a subkey binding signature.

2. Section 5.2.4 contains another error.  It states

	Key revocation signatures (types 0x20 and 0x28) hash only the
	key being revoked.

   However, analysis of existing implementations indicates that this
   is incorrect for subkey revocation signatures (type 0x28); like
   type 0x18, both the primary key and the subkey are included in the
   hash.

3. Subpacket 23 (key server preferences) is specified to be "found
   only on a self-signature".  It should say if that means a direct
   key signature (which makes the most sense to me), or something
   else.

4. The document is vague on what constitures "advisory information" in
   a signature subpacket (section 5.2.3).  I believe that unhashed
   signature subpackets were a mistake (I can expound on this if
   people want).  If existing implementations did not include unsigned
   subpackets, I would suggest removing them from the spec entirely.
   However, current implementations usually include the issuer key id
   subpacket (type 16) in the unhashed subpackets.

   Therefore, I suggest that implementations MUST NOT generate any
   unhashed subpackets, SHOULD accept type 16 unsigned subpackets in
   order to process existing signatures, and MUST NOT accept any other
   subpacket types in the unhashed subpackets.

5. There should be a note that the critical bit MUST be ignored on
   unhashed signature subpackets.  Otherwise, an attacker can easily
   cause any signature to fail to verify.

6. The terms used in 11.1 are inconsistent with the rest of the
   document, and in some places, the rest of the document is also
   inconsistent.  Where 11.1 uses "revocation self signature", the
   rest of the document uses "key revocation signature".  Where 11.1
   uses "direct key self signature", the rest of the document uses
   "direct key signature", "direct-key signature", and "Signature
   directly on a key".  Where 11.1 uses
   "binding-signature-revocation", the rest of the document uses
   "subkey revocation signature".  Where 11.1 uses
   primary-key-binding-signature", the rest of the document uses
   "subkey binding signature".

                Marc

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Encoding of hash in El-Gamal signatures
Date: Fri, 1 Dec 2000 14:04:19 -0500
Sender: [email-masked]

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

The specification already mentions precautions in ElGamal
signature handling, and provides a reference.

The original question is still valid, though, and I'd also
be interested in seeing clarification.  If the specification
includes ElGamal signatures, it should provide sufficient
definition to achieve interoperability.  For other
algorithms, there is a discussion of how the hash is padded
(where applicable) and what the algorithm-specific fields in
the signature should be.  One might guess that the same
PKCS-1 padding scheme should be used, and that the MPIs
should be the "r" (=g^k mod p) and "s" (=(h-r*x)/k mod p)
values, in that order.  Is that right?  Yes, I could use the
GnuPG source as the specification, but that shouldn't be
necessary.

If you want to argue that OpenPGP shouldn't support this
algorithm, and that it should be removed from the
specification entirely, I wouldn't object.