Re: Is PGP broken?

[Enzo Michelangeli]

- Original Message -
From: "Peter Gutmann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, December 05, 2000 4:45 AM
Subject: Re: Is PGP broken?


> "Enzo Michelangeli" <[EMAIL PROTECTED]> writes:
>
> >Apart from standards issues, one thing I'd like to see added to popular
S/MIME
> >agents is a mini-CA to issue self-signed certificates. This would allow
people
> >to use S/MIME as they use PGP (who relies on the WoT anyway?), breaking
the
> >dependency from hierarchical CA's. Creating such an agent would be now a
viable
> >OpenSource project, without any need for expensive toolkit licenses.
>
> I have an RFC draft for this which I wrote a while back but it was
rejected by
> the PKIX WG chair(s) ("I am concerned that we not turn PKIX into PGP with
ASN.1
> syntax"), and I haven't had the motivation to publish it as an independent
> draft - would anyone even notice?.

I don't think we need a draft for that: is there anything in the current
RFC's preventing an S/MIME user agent from verifying an attached cert
against a locally-stored copy, rather than traversing the certification path
up to the root? Or also from installing root certs made by arbitrary peers?

Enzo

Re: migration paradigm (was: Is PGP broken?)

[Enzo Michelangeli]

- Original Message -
From: "lcs Mixmaster Remailer" <[EMAIL PROTECTED]>
Sent: Tuesday, December 05, 2000 3:20 AM


> William Allen Simpson <[EMAIL PROTECTED]> writes:
> > My requirements were (off the top of my head, there were more):
> >
> >  4) an agreed algorithm for generating private keys directly from
> > the passphrase, rather than keeping a private key database.
> > Moving folks from laptop to desktop has been pretty hard, and
> > public terminals are useless.  AFS/Kerberos did this with a
> > "well-known" string-to-key algorithm, and it's hard to convince
> > folks to use a new system that's actually harder to use.  We need
> > to design for ease of use!
>
> This is a major security weakness.  The strength of the key relies
> entirely on the strength of the memorized password.  Experience has
> shown that keys will not be strong if this mechanism is used.
>
> There must be something more.  At a minimum it can be a piece of paper
> with the written-down, long passphrase.  Or it can be a smart card
> with your key on it.  Conceivably it could also be a secure server that
> you trust and access with a short passphrase, where the server can log
> incorrect passphrase guesses.  But if you can attack a public key purely
> by guessing the memorized passphrase which generated the secret part,
> the system will not be secure.

I'm not sure about this, unless you assume that the best attacks are based
on dictionary search (which, for PK algorithms, can be pretty
time-consuming). Let's suppose that the entropy of the passphrase only
amounts to 100 bits: my gut feeling is that breaking a discrete log problem
based on a 512-bit secure hash of that passphrase it much harder than
breaking a 100-bit discrete log problem, and is probably close to a "true"
512-bit problem.

Enzo

Re: /. Yahoo delivers encrypted email

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writ
es:
>
>
>>Yahoo's new system works like this: Once a message is composed, it
>>travels, unencrypted, to Yahoo,
>
>So feel no fear in sending anything you wouldn't mind being read before 
>it's encrypted?
>I'm surprised AOL isn't offering this "security feature" as well ... 
>I feel safer already :~)

While I don't like (what I've seen described here of) the Yahoo secure 
mail system, it isn't a priori preposterous.  In fact, in many cases it 
makes a great deal of sense.

The question is what your threat model is.  Although it's possible to 
pick up email on the wire, in many cases it's quite hard.  
Eavesdropping on an ISP's backbone is extremely difficult; the links 
are very fast, are often not Ethernet or some other easily-tapped 
medium, and providers have learned not to put general-purpose (and 
hence hackable) machines on their backbone.  

The real threats come near the edges, and in the spool files where the 
mail sits before being delivered or picked up.  The latter, in 
particular, is quite great.  If the encryption happens on a separate, 
secure machine before storage, it might be quite good against that 
threat -- and if both parties to a conversation are using dial-up 
links, there is little to worry about.

Sure, if you're a possible target of Carnivore, this is grossly 
insufficient.  But that doesn't descibe most people.  Their threat 
probably comes from their very own machines, and is best defeated by 
any mailer that doesn't leave plaintext lying around, either in a Trash 
folder or in a Web cache.

--Steve Bellovin

Re: Is PGP broken?

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Peter Gutmann writes:
>"Enzo Michelangeli" <[EMAIL PROTECTED]> writes:
>
>>Apart from standards issues, one thing I'd like to see added to popular S/MIM
>E
>>agents is a mini-CA to issue self-signed certificates. This would allow peopl
>e
>>to use S/MIME as they use PGP (who relies on the WoT anyway?), breaking the
>>dependency from hierarchical CA's. Creating such an agent would be now a viab
>le
>>OpenSource project, without any need for expensive toolkit licenses.
>
>I have an RFC draft for this which I wrote a while back but it was rejected by
>the PKIX WG chair(s) ("I am concerned that we not turn PKIX into PGP with ASN.
>1
>syntax"), and I haven't had the motivation to publish it as an independent
>draft - would anyone even notice?.

Purely procedurally, if you tried to get it published as an RFC it 
would probably be bounced by the IESG -- there's a policy against RFCs 
that are or appear to be end-runs around a working group.  If something 
is in a WG's area, it's up to them to publish it.

--Steve Bellovin

Re: Is PGP broken?

[L. Sassaman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4 Dec 2000, lcs Mixmaster Remailer wrote:

> Examples of the first case would be an identifier which indicates the
> signing key.  In PGP this would be the key ID; in SMIME, CMS and other
> PKCS-7 derived formats it is the IssuerAndSerialNumber.  These fields
> are not hashed.  This is not security critical because it is essentially
> a hint about where to find the key.  If this data is altered, the wrong
> key will be found and the signature won't verify.

Agreed. This is the main exception I pointed out to Ralf, and these are
the reasons I gave him in my private email to him.

> Examples of the second case would be other kinds of hints for finding the
> signing key, in the form of URLs or database pointers which might change.
> PGP's preferred key server subpacket might fall into this category.

I'm hesitant to put this outside the hashed area. The preferred key server
is a preference stated by the key owner; he should be the only one able
to change that.

> PGP might want to add a countersignature mechanism in the future and an
> unhashed subpacket would be a good place for it.

I'm not against unhashed subpackets. I'm against unhashed
security-critical subpackets. I would think that the best way to design a
program interpreting certificates with such packets would be to have a
"whitelist" of subpackets permitted outside the hashed area. Anything not
in this whitelist should be rejected or ignored.


- --Len.

__

L. Sassaman

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


-BEGIN PGP SIGNATURE-
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE6LCvtPYrxsgmsCmoRAhkKAJ42qvI3uMksU0VkQgVkO14ZkAtPpQCg7pUN
zJeRhi/+IXcqSDalM9MSLiE=
=wOQl
-END PGP SIGNATURE-

Re: Is PGP broken?

[lcs Mixmaster Remailer]

It is often useful to include some information associated with a signature
that is not in the hashed portion.  There are several reasons for this.

First, some information is not security critical and there is no reason
to hash it.  Second, some such information may be subject to change and
updates, and it is desirable for the document to be edited in place in
order to make changes without invalidating the siganture.  And third,
some information cannot be calculated until after the signature hash is
calculated due to the semantics involved.

Examples of the first case would be an identifier which indicates the
signing key.  In PGP this would be the key ID; in SMIME, CMS and other
PKCS-7 derived formats it is the IssuerAndSerialNumber.  These fields
are not hashed.  This is not security critical because it is essentially
a hint about where to find the key.  If this data is altered, the wrong
key will be found and the signature won't verify.

Examples of the second case would be other kinds of hints for finding the
signing key, in the form of URLs or database pointers which might change.
PGP's preferred key server subpacket might fall into this category.
Another example would be the KeyInfo field in the XML signature format
(http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/).  This has a
number of options for ways to identify and locate keys.  It is not in
the hashed area.

Examples of the third case would be the UnauthenticatedAttributes of the
PKCS-7 family.  CMS (RFC2630) uses this field to hold a countersignature,
which is a signature on a signature.  This cannot be calculated until
after the signature is calculated so it must be in the unhashed region.
PGP might want to add a countersignature mechanism in the future and an
unhashed subpacket would be a good place for it.

If you are really convinced that allowing unhashed data is wrong, you
should lend your expertise not only to PGP, but to the many other ongoing
cryptographic working groups and let them know that they are all on the
wrong track.

Re: migration paradigm (was: Is PGP broken?)

[lcs Mixmaster Remailer]

William Allen Simpson <[EMAIL PROTECTED]> writes:
> My requirements were (off the top of my head, there were more):
>
>  4) an agreed algorithm for generating private keys directly from 
> the passphrase, rather than keeping a private key database.  
> Moving folks from laptop to desktop has been pretty hard, and 
> public terminals are useless.  AFS/Kerberos did this with a 
> "well-known" string-to-key algorithm, and it's hard to convince 
> folks to use a new system that's actually harder to use.  We need 
> to design for ease of use!  

This is a major security weakness.  The strength of the key relies
entirely on the strength of the memorized password.  Experience has
shown that keys will not be strong if this mechanism is used.

There must be something more.  At a minimum it can be a piece of paper
with the written-down, long passphrase.  Or it can be a smart card
with your key on it.  Conceivably it could also be a secure server that
you trust and access with a short passphrase, where the server can log
incorrect passphrase guesses.  But if you can attack a public key purely
by guessing the memorized passphrase which generated the secret part,
the system will not be secure.

Re: /. Yahoo delivers encrypted email

[solaar]

>Yahoo's new system works like this: Once a message is composed, it
>travels, unencrypted, to Yahoo,

So feel no fear in sending anything you wouldn't mind being read before 
it's encrypted?
I'm surprised AOL isn't offering this "security feature" as well ... 
I feel safer already :~)
elyn

RE: Is PGP broken?

[Bram Cohen]

On Mon, 4 Dec 2000, Ian Brown wrote:

> > Come to think of it, there are some tricky issues with regards to crypto
> > on mailing lists, it might make sense to have a
> > X-crypto-originator [EMAIL PROTECTED] line in the headers to specify that the
> > crypto information contained in that piece of mail applies to the address
> > [EMAIL PROTECTED] - otherwise there's no clear way of unraveling all the
> > possible mixes of from, to, and reply-to headers which could possibly be
> > sent to a mailing list.
> 
> The recipient would probably ignore the mail headers and use the userID(s)
> in the public key certificate included in the message.

To clarify - I think doing things based on PGP userIDs is unworkable, and
would like to do everything based on email addresses.

-Bram Cohen

Re: Is PGP broken?

[Arnold G. Reinhold]

At 9:55 AM +0100 11/29/2000, PA Axel H Horns wrote:
>On 29 Nov 2000, at 7:07, Stephan Eisvogel wrote:
>
>> Adam Back wrote:
>> > (And also without IDEA support for patent reasons even now
>> > that the RSA patent has expired.)
>>
>> Do you know when the IDEA patent will expire? I will hold a
>> small party myself then. B)
>
>The EP 0 482 154 of ASCOM TECH AG has been filed on May 16, 1991.
>Add 20 Years. If ASCOM TECH AG pays annual renewal fees to the
>respective national Patent Offices every year. Otherwise it might
>lapse earlier.
>
>Axel H Horns

There is also US patent 5214703 which was filed on Jan. 7, 1992.  See 
http://www.delphion.com/details?&pn=US05214703__

Arnold Reinhold

Re: Is PGP broken?

[Peter Gutmann]

"Enzo Michelangeli" <[EMAIL PROTECTED]> writes:

>Apart from standards issues, one thing I'd like to see added to popular S/MIME
>agents is a mini-CA to issue self-signed certificates. This would allow people
>to use S/MIME as they use PGP (who relies on the WoT anyway?), breaking the
>dependency from hierarchical CA's. Creating such an agent would be now a viable
>OpenSource project, without any need for expensive toolkit licenses.

I have an RFC draft for this which I wrote a while back but it was rejected by
the PKIX WG chair(s) ("I am concerned that we not turn PKIX into PGP with ASN.1
syntax"), and I haven't had the motivation to publish it as an independent
draft - would anyone even notice?.

Peter.

Carnivore meta-report released

[Matt Blaze]

I've been part of a group of five security researchers (with Steve Bellovin,
David Farber, Peter Neumann, and Gene Spafford) who were asked by the
Chief Scientist at the Justice Department to identify technical issues
with the FBI's "Carnivore" system that should be addressed by an
independent review.  As readers of this list know, the contractor
chosen by DoJ to conduct the review, IITRI, recently released a
draft report of its findings.  We've studied that report
and continue to have serious concerns about Carnivore.  Our report,
which we've released this morning, can be found at
  http://www.crypto.com/papers/carnivore_report_comments.html

-matt

RE: UK intelligence agencies want 7 years of records of all phone calls, emails and internet connections

[Caspar Bowden]

>Clive D.W. Feather
...
>Calling this "NCIS carnivore" is misleading. It's concerned with
>transaction logs (who logged in when, web site logs, the sort of thing
>covered as "communications data" in RIP). Nothing to do with
>the contents of phone calls or email.

Carnivore does both. Note proposals in 6.8 (below) that allow Agencies to
maintain their own databases, mix-and-matych souced however they see fit.

"Inter-connectivity between certain CSPs and the law enforcement agencies
(LEAs) has provided direct, automated access to data"

"that LEAs have retained this data means it can be quickly analysed in-house
with information from other sources to develop intelligence on the global
scaleLEAs need the statutory authority to maintain their own
communications data intelligence database."

>I've been aware of these proposals for some time. Basically, the police
>*have* the power to obtain this data *where the CSP has
>retained it*.

After RIP yes. Shame NCIS didn't see fit to tell Parliament about all this
when it was going through.

>could be useful, and for ease of access (under lawful
>authority, of course) consolidate it in a single database.

Nope. There will be many different databases sprawling across Whitehall as
well as the centreal data warehouse

>It is pointed out that defence lawyers have use for such data as well.

Isn't this nonsense? The authorities may use this information to demolish
false alibis, but the defence could not rely on communications data to
verify an alibi, since there is never any assurance that a particular person
made a call or was online  - otherwise you would get people laying false
alibi trails just by lending their phone or passwords to eachother.

All that "interests of justice" baloney is just got up to provide flannel
for ministers spouting "striking a balance". There is marvellously careful
wordsmithing whenever Criminal Cases Review Commission are mentioned in the
NCIS document. Between the lines I bet they are saying "crap idea for
corroborating innocence, but handy for eliminating bogus appeals by the
guilty"

--
Caspar Bowden   Tel: +44(0)20 7354 2333
Director, Foundation for Information Policy Research
RIP Information Centre at:www.fipr.org/rip#media


6.8 RETENTION OF DATA OBTAINED BY POLICE AND CUSTOMS
6.8.1 The retention of communications data for evidence or intelligence
purposes once obtained by police and customs is another important area,
which needs to be addressed in parallel with retention by CSPs.
Inter-connectivity between certain CSPs and the law enforcement agencies
(LEAs) has provided direct, automated access to data. This has made good
commercial sense in relation to high volume areas, such as
subscriber-related and billing data. For example, over the past 12 months
the Metropolitan Police Service SPOC required access to 63,590 subscriber
details and 4,256 billing accounts. Consequently more CSPs are going live
with these services relying on the expedience of secure electronic transfer
of data to the LEAs via the Internet.

6.8.2 Most Police Forces and HM Customs and Excise retain such data obtained
electronically on their own individual databases, in particular subscriber
identities and itemised billing. Where such systems do not exist, such data
is held by the Agencies in paper form. The data relates to specific
investigations and includes information that may originally have been sought
for intelligence purposes only. Most of that data will have been retained
regardless of whether or not it was subsequently produced in evidence. All
the data will have been lawfully obtained under the Data Protection Act
exemption provisions or through the Courts by way of a Production Order.
Having acquired it lawfully, there is no appropriate authority allowing
further retention.

6.8.3 These databases are an invaluable tool enabling police and customs to
search for association links between live and past investigations where they
cut across each other. It is vitally important to identify where the same
criminal elements are involved in a range of activities over many years,
most notably when significant individuals, who have been dormant for some
time, become active again.

6.8.4 The fact that LEAs have retained this data means it can be quickly
analysed in-house with information from other sources to develop
intelligence on the global scale of organised criminal groups and thereby
identify the full extent of their operations and associates.

6.8.5 LEAs need the statutory authority to maintain their own communications
data intelligence database. It is proposed that the agencies should be
regulated in the following manner. Access is subject to the provisions of
RIPA; A designated chief officer has oversight; Data less than 12 months old
should be available live; and After 12 months the data can be archived and
retained for a maximum of 6 years. Reviews are undertaken to ensure that the
purpose for which data is retained is still relevant.

Re: Is PGP broken?

[Ralf Senderek]

-BEGIN PGP SIGNED MESSAGE-

On Sun, 3 Dec 2000, L. Sassaman wrote:

> Though, as I pointed out to Ralf in private email, subpacket 16 should be
> permitted outside of the signature. Other than that, I can see no packet
> that needs to be placed outside the signature, 

I still can not see why it should be allowed to have the packet which
specifies the key used for the signature outside the hashed field (signature).
Creating an exception from the "zero-unhashed-packet-rule" makes no sense to me.
Yes I know old version 3 keys had the key-ID outside the hashed part too, 
but that seemed unjustified to me as well.

>and agree with Ralf that
> they should be disallowed. (If someone has a reason why any of the others
> would need to be in the unsigned area, please let me know.)

Me too please, I asked Phil for reasons but he has not come out with any 
yet.

Cheers, 

   Ralf

*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
* Ralf Senderek  <[EMAIL PROTECTED]> * What is privacy *
* http://senderek.de* without *
* Tel.: 02432-3960Sandstr. 60   D-41849 Wassenberg  *   PGP-2.6.3i?   *
*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOiuzUymc/oJTgiNJAQHH7wP+MsEGgIMQBz7cSodN3vEVdbfbeUGMXyIF
sZD3A7ypksg3vfAxogueOjtQuVlk+IQwDS7/5tkdQmZlGWEexzCtb/glH8lLOTdu
W5YQN4auLFjOp/NG6ttOaOon5Mj8h47+kW6vyAkvWhJ+YFzYpsPaUC7vyVrnKsIi
FFsu6JmMw3U=
=ZFU/
-END PGP SIGNATURE-

migration paradigm (was: Is PGP broken?)

[William Allen Simpson]

David Bird wrote:
> 
> In my opinion, cryptography should be seen as an evolutionary
> process. Protocols are continuously evaluated for their "fitness" in the
> context of current number theory, advances in computers/CPUs, and many
> individual/company/implementation specific requirements. It may be
> impossible to get the ideal solution, but we optimize to what we consider
> vital for survival.
> 
I've read with interest the thread, and I'd thought that we all came 
to this conclusion some years back.  That's why we had the SPKI 
response to PKIX, OpenPGP, etc.

We could use the excuse of AES implementation to foster a move to a 
new common denominator.  That implies a willingness among ourselves 
to move, abandoning the older solutions (with perhaps some migration 
and translation programs to process archived information).

I once (circa 1996-1997) tried to foster this with PSPKI (Pretty Simple Public Key 
Infrastructure), combining what I saw as
the strengths of 
OpenPGP, SPKI, SPEKE, etc.  Maybe it's time to try again?

My requirements were (off the top of my head, there were more):

 1) simple, easy to process and debug data formats.  Like SPKI and 
KeyNote, not PKIX or even OpenPGP.

 2) possibility of translation of public keys between systems (but 
not the OpenPGP "sub-packets") for easier migration.

 3) explicit inclusion of roles and capabilities.  There are many 
flavors of this -- I simply indicated a "group" of things to be 
signed, but KeyNote attributes might serve better.

 4) an agreed algorithm for generating private keys directly from 
the passphrase, rather than keeping a private key database.  
Moving folks from laptop to desktop has been pretty hard, and 
public terminals are useless.  AFS/Kerberos did this with a 
"well-known" string-to-key algorithm, and it's hard to convince 
folks to use a new system that's actually harder to use.  We need 
to design for ease of use!  

What support is there among us for evolving together?

Are there other requirements?

Is it time?

Re: UK intelligence agencies want 7 years of records of all phone calls, emails and internet connections

[John Young]

Clive Feather wrote:

>Calling this "NCIS carnivore" is misleading. It's concerned with
>transaction logs (who logged in when, web site logs, the sort of thing
>covered as "communications data" in RIP). Nothing to do with the contents
>of phone calls or email.
>
>I've been aware of these proposals for some time.

The connection to Carnivore was made by the anonymous source
of the document, probably a person within one of the CSPs which
had been given the document for consultation -- as it sets forth. A
person who likely has access to other yet undisclosed consultations,
as Clive suggests is a fact of life for providers.

In the US we have learned that the capabilities of Carnivore are more 
than has been publicly admitted, that it is only one in a series of 
developing surveillance technologies, one of a series of legislative 
initiatives, one of a series of trial balloons lofted for public reaction.

The major ISPs in the US are being consulted on these rapidly
developing means and methods, as were the telcos in days past 
and telecomms in the present. And it has been established that these 
corporations have been presented with, and themselves initiated, 
surveillance and interception programs, as ever, in the national 
interest -- which means in the interest of favorable regulation
and economic advantage, now global not merely national.

"Carnivore" is an apt term for the process of ravenous cooperation 
between telecommunications providers and their regulators in all
the countries where that is occurring -- the list of admitted participants 
is growing daily. And the FBI and DoJ make no secret of their drive 
to have seamless global cooperation, helped as ever by US legal and 
technological prowess and lubricated by financial incentives.

What is striking is how often HMG is willing to serve as stalking
horse for draconian surveillance programs that later get adopted in 
some form by other countries. What the dark side of HMG is being 
promised for that contemptible role is worth sunshining by whoever
gets hands on evidence.

Re: UK intelligence agencies want 7 years of records of all phone calls, emailsand internet connections

[Ken Brown]

Yes, the headlines along the lines of "Secret plans to spy on phone
calls" are misleading. I think we are all pretty sure that the various
militarised security organisations do that already if they want. These
proposals are meant to force companies to keep their logs for a long
time, just in case someone does want to RIP them. The scary thing isn't
so much the extra invasion of privacy as the evidence of the
authoritarian personality of the authors. 

Ken Brown

"Clive D.W. Feather" wrote:
> 
> Caspar Bowden said:
> > <<..Britain's intelligence services are seeking powers to seize all records
> > of telephone calls, emails and internet connections made by every person
> > living in this country. A document circulated to Home Office officials and
> > obtained by The Observer reveals that MI5, MI6 and the police are demanding
> > new legislation to log every phone call made in this country and store the
> > information for seven years at a vast government-run 'data warehouse', a
> > super computer that will hold the information...>>
> >
> > The document referred to in the Observer front page story today appears to
> > have been posted on the US website "Cryptome".
> >
> > ==> http://cryptome.org/ncis-carnivore.htm
> 
> Calling this "NCIS carnivore" is misleading. It's concerned with
> transaction logs (who logged in when, web site logs, the sort of thing
> covered as "communications data" in RIP). Nothing to do with the contents
> of phone calls or email.
> 
> I've been aware of these proposals for some time. Basically, the police
> *have* the power to obtain this data *where the CSP has retained it*. What
> this paper wants is to retain all the data for the length of time that it
> could be useful, and for ease of access (under lawful authority, of course)
> consolidate it in a single database.
> 
> It is pointed out that defence lawyers have use for such data as well.
> 
> [I disagree strongly with the proposals, both on civil liberties grounds
> and because I think maintaining a "clean" database will be impractical.]

RE: Is PGP broken?

[Ian Brown]

> A problem with including a public key with every plaintext message is that
> it isn't very discreet - actually looks kind of ugly in some peoples's
> email clients.

You could use a separate PGP/MIME bodypart...

> Come to think of it, there are some tricky issues with regards to crypto
> on mailing lists, it might make sense to have a
> X-crypto-originator [EMAIL PROTECTED] line in the headers to specify that the
> crypto information contained in that piece of mail applies to the address
> [EMAIL PROTECTED] - otherwise there's no clear way of unraveling all the
> possible mixes of from, to, and reply-to headers which could possibly be
> sent to a mailing list.

The recipient would probably ignore the mail headers and use the userID(s)
in the public key certificate included in the message.

Ian :0)

Re: UK intelligence agencies want 7 years of records of all phone calls, emails and internet connections

[Clive D.W. Feather]

Caspar Bowden said:
> <<..Britain's intelligence services are seeking powers to seize all records
> of telephone calls, emails and internet connections made by every person
> living in this country. A document circulated to Home Office officials and
> obtained by The Observer reveals that MI5, MI6 and the police are demanding
> new legislation to log every phone call made in this country and store the
> information for seven years at a vast government-run 'data warehouse', a
> super computer that will hold the information...>>
> 
> The document referred to in the Observer front page story today appears to
> have been posted on the US website "Cryptome".
> 
> ==> http://cryptome.org/ncis-carnivore.htm

Calling this "NCIS carnivore" is misleading. It's concerned with
transaction logs (who logged in when, web site logs, the sort of thing
covered as "communications data" in RIP). Nothing to do with the contents
of phone calls or email.

I've been aware of these proposals for some time. Basically, the police
*have* the power to obtain this data *where the CSP has retained it*. What
this paper wants is to retain all the data for the length of time that it
could be useful, and for ease of access (under lawful authority, of course)
consolidate it in a single database.

It is pointed out that defence lawyers have use for such data as well.

[I disagree strongly with the proposals, both on civil liberties grounds
and because I think maintaining a "clean" database will be impractical.]

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

Re: Is PGP broken?

[John Kelsey]

-BEGIN PGP SIGNED MESSAGE-

At 05:52 PM 12/3/00 -0800, Bram Cohen wrote:

...
>If I recieve mail from a mailing list, it potentially might
>have info about both how to encrypt mail sent to the sender,
>and how to encrypt mail sent to the list - it really should
>be able to include both, and specify which is which.

>-Bram Cohen

>[Personally, I'm not sure it is worthwhile worrying about
>how to encrypt mail to a large mailing list -- a secret
>known by more than a couple of people is never secret for
>long. Signatures on list mail are another matter. --Perry]

It seems like it might be really useful to have encryption
on mailing lists for small groups, but I agree that lists
with a hundred people on them may as well be in cleartext,
for most purposes.

It seems like a much more immediately useful feature would
be to have mailing-list software that required a valid PGP
signature from a known subscriber's key to allow posting,
and then would sign all outgoing messages with the list
software's public key.  If subscribers automatically have to
send in their public key, and receive the list software's
public key, then at least the key distribution part of the
problem would be handled more-or-less automatically.  If
that initial signup isn't interfered with, the mailing list
gets signed messages, and the receivers all have the right
key to check the message signatures.  Interestingly, this
kind of application would do what people usually want
certificates to do, but without anyone in the role of a CA.

 --John Kelsey, [EMAIL PROTECTED]
PGP Fingerprint: 5D91 6F57 2646 83F9  6D7F 9C87 886D 88AF
...| ``Slavery's most important legacy may be a painful insight
...| into human nature and into the terrible consequences of
...| unbridled power.'' --Thomas Sowell, _Race and Culture_


-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.1 Int. for non-commercial use

Comment: foo

iQCVAwUBOitPbiZv+/Ry/LrBAQF1xgQAucB4sFrxXOs6QQUPXlmZQuGzM0S2me7I
79ulcUnCOqgZYJs2l/Z8H3a8g3DRvQMQGEBaOdkrALSsQJamevJIskEoUPe1CDQj
DGn/2h49a9c9JFVqOFGCOSlL8d0/Kn52tNwtsX8XPpLeg40Zkq6E/5HzclxGSFb5
M16nl46FzJk=
=NAv6
-END PGP SIGNATURE-