Subject: RE: Trust Packets

From: [email-masked] (Peter Gutmann)
Date: Sat, 31 Jan 2004 16:42:39 +1300

"Richard Laager" <[email-masked]> writes:

>No, X.509 propagates trust. The root certificates in your browser's
>certificate store are there because you trust them.

Nope, they're there because I don't have a choice.  I *trust* that if I report
an unauthorised credit card charge to my CC vendor within 30-60 days, it won't
come out of my pocket.  I am forced to *depend* on hardcoded CA certs in my
browser because without that I can't exercise my trust in Reg.E/Reg.Z.  The
only thing I trust about a commercial CA-issued cert is that it proves that at
some point money changed hands, to the CA's benefit (admittedly this provides
at least a small amount of trust by proving that either the web site takes
itself seriously enough that it's willing to burn money to make this point or
that the script kiddie who r00ted it was skillful enough to get away with it
unnoticed).

>If you don't trust VeriSign to issue signatures, remove them from the root
>certificate store.

I could disable the 100+ certs in my browser (a mere 700 mouse clicks, only a
day or so's work) but then I'd constantly have warning dialogs popping up and
annoying me while I'm exercising my trust in Reg.E/Reg.Z.  In addition
disabling only the Verisign roots won't prevent Verisign certs from being
accepted, because of the implicit universal cross-certification in browsers
any other CA could issue Verisign certs and they'd be treated no diferently
from the real thing.

Peter.

---

From: "Richard Laager" <[email-masked]>
Date: Fri, 30 Jan 2004 22:48:29 -0600

Peter Gutmann wrote:

> annoying me while I'm exercising my trust in Reg.E/Reg.Z.

Hmm. I just tested this with IE. Highlight the first certificate,
hold shift, click the last, hit Delete. Any browser which requires
you to individually delete certificates has a broken UI that's beyond
the scope of this discussion. So much for your 700 mouse clicks.

As for the warning dialogs: These can be disabled in IE. Again, if
the browser doesn't let you disable them, that's a UI issue.

Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are
sites as this is the most logical example given this discussion) is
NOT the same as trusting the certificate alleging to be from
Reg.E/Reg.Z. Their certificates could easily have been swapped out by
a MITM attack. Now, if you have a trusted out-of-band channel where
you obtained the certificate or its fingerprint, then add the
certificate to your browser's trusted store. Otherwise, exercising
trust in the certificate is pointless because you're not sure of its
origin. As I said before, in this scenario, HTTPS is effectively
reduced in security to HTTP.

The trust in a normal HTTPS situation flows like this:
User -> Computer Vendor -> OS Vendor -> Bundled Browser (optionally
- -> signed browser upgrades from [Alternate] Browser Vendor) -> Root
CAs (optionally -> intermediate CAs) -> Site Operator & Site
Certificate -> HTTPS Session

If you add an alternate certificate that you've verified some other
way:
User -> Site Operator & Site Certificate -> HTTPS Session

>                                                            In
> addition disabling only the Verisign roots won't prevent Verisign 
> certs from being

The only way this would work is if one of the VeriSign certificates
in the certification path was signed by another CA. Furthermore, it
would only work if the server sending its SSL certificate included
the VeriSign intermediate certificate signed by the other root
authority. Who would explicitly configure a server this way when the
VeriSign certificates are in basically every product that uses SSL?
And, in this example then, the certificate ceases to be a VeriSign
certificate and is by definition a certificate which inherits its
trust through the other root. So, if you don't trust that root,
delete it. In any case, none of this is "implicit" or "universal".

Stop making excuses. Commercial certification authorities and the
X.509 hierarchical structure make it easy for the non-technical
masses to use HTTPS. Not everyone has the desire to participate in a
fragile web of trust just to order the latest gadget off a website.
Due to capitalism, the CAs make money providing their service. While
I share your distrust of VeriSign in some ways, especially in the CA
business after the Microsoft fiasco, this is not a protocol or
implementation detail. The system is designed and can be used to
prevent 

This thread is off-topic so I will refrain from any further response.

Richard Laager

---

From: Ian Grigg <[email-masked]>
Date: Sat, 31 Jan 2004 02:08:27 -0500

Richard Laager wrote:

> Their certificates could easily have been swapped out by
> a MITM attack.

Whoa, you're pushing my buttons!  Curiosity strikes,
have you any *empirical* evidence of this?

I hold out hope that we'll see MITMs reach reality in
HTTP systems before their decade is out, but others
have given up.  It's 2004, 10 years almost since SSL
was mooted, and we are yet to see an empirical case
made against the humble MITM.

> Now, if you have a trusted out-of-band channel where

That's a stretch.  It is based on logical possibilities,
not real life risks.  For an example, look at SSH, which
happily secures a squillion sysadmin connections without
any 3rd party certs.

My prediction - SSH will take over SSL in the next 10
years, and so will opportunistic encryption.

> Certificate -> HTTPS Session

The trust in a normal HTTPS-enabled scenario seems to
lose thusly:  scammer sends spoof email claiming things
of great import -> user clicks on recommended site ->
user sees standard site -> user enters details -> scammer
scores details -> and raids account.

Maybe it's just the fact that I lurk in places where trust
is *necessary* as there be hard money but there be no Reg
Alphabet Soup (I speak here of digital gold currencies).
There, it's pretty much the case that the Certificate stuff
is ... so far from the issue of security and trust that some
DGCs don't even use them to protect their (hard) multi-kilo-
gram transactions.

> masses to use HTTPS.

ADH would work just as well, and at no cost.  Economically,
it's a slam dunk.  There is approximately zero risk of an
MITM, so one should spend approximately zero dollars, or
grams, to defend against.  Self-signed certs would also
work well, and are also compatible with the current
architecture.

> Due to capitalism, the CAs make money providing their service.

That would be a .... very interesting thread!

> This thread is off-topic so I will refrain from any further response.

Dragging it back to OpenPGP - and I agree we are way
off threat - OpenPGP's strength is that, to the limited
extent that it does, it delivers some small basis in
trust architectures.

iang

Date: Sat, 31 Jan 2004 02:08:27 -0500
From: Ian Grigg <[email-masked]>
To: Richard Laager <[email-masked]>
CC: [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

Richard Laager wrote:

> Their certificates could easily have been swapped out by
> a MITM attack.

Whoa, you're pushing my buttons!  Curiosity strikes,
have you any *empirical* evidence of this?

I hold out hope that we'll see MITMs reach reality in
HTTP systems before their decade is out, but others
have given up.  It's 2004, 10 years almost since SSL
was mooted, and we are yet to see an empirical case
made against the humble MITM.

> Now, if you have a trusted out-of-band channel where

That's a stretch.  It is based on logical possibilities,
not real life risks.  For an example, look at SSH, which
happily secures a squillion sysadmin connections without
any 3rd party certs.

My prediction - SSH will take over SSL in the next 10
years, and so will opportunistic encryption.

> Certificate -> HTTPS Session

The trust in a normal HTTPS-enabled scenario seems to
lose thusly:  scammer sends spoof email claiming things
of great import -> user clicks on recommended site ->
user sees standard site -> user enters details -> scammer
scores details -> and raids account.

Maybe it's just the fact that I lurk in places where trust
is *necessary* as there be hard money but there be no Reg
Alphabet Soup (I speak here of digital gold currencies).
There, it's pretty much the case that the Certificate stuff
is ... so far from the issue of security and trust that some
DGCs don't even use them to protect their (hard) multi-kilo-
gram transactions.

> masses to use HTTPS.

ADH would work just as well, and at no cost.  Economically,
it's a slam dunk.  There is approximately zero risk of an
MITM, so one should spend approximately zero dollars, or
grams, to defend against.  Self-signed certs would also
work well, and are also compatible with the current
architecture.

> Due to capitalism, the CAs make money providing their service.

That would be a .... very interesting thread!

> This thread is off-topic so I will refrain from any further response.

Dragging it back to OpenPGP - and I agree we are way
off threat - OpenPGP's strength is that, to the limited
extent that it does, it delivers some small basis in
trust architectures.

iang

Date: Sat, 31 Jan 2004 18:16:41 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Trust Packets
Sender: [email-masked]

"Richard Laager" <[email-masked]> writes:

>Hmm. I just tested this with IE. Highlight the first certificate, hold shift,
>click the last, hit Delete. Any browser which requires you to individually
>delete certificates has a broken UI that's beyond the scope of this
>discussion. So much for your 700 mouse clicks.

Oh, they must have fixed it in recent versions.

>Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are sites as
>this is the most logical example given this discussion) is NOT the same as
>trusting the certificate alleging to be from Reg.E/Reg.Z. 

Regulation E and Regulation Z are US consumer-protection legislation covering
use of credit and ATM cards.  I trust Reg.E/Reg.Z to keep me from harm.  I
don't trust a CA-issued to cert to do this (although it can't hurt, for
reasons given in my previous post).

>The only way this would work is if one of the VeriSign certificates in the
>certification path was signed by another CA. Furthermore, it would only work
>if the server sending its SSL certificate included the VeriSign intermediate
>certificate signed by the other root authority. 

Yup.

>Who would explicitly configure a server this way when the VeriSign
>certificates are in basically every product that uses SSL? 

Who would explicitly configure a server to pretend to be Paypal when it isn't?
The answer is the same in both cases.

>In any case, none of this is "implicit" or "universal".

In a browser, every CA is trusted equally, and can usurp every other CA.  The
technical term for this is "implicit universal cross-certification".

Peter.

Date: Fri, 30 Jan 2004 23:46:21 -0500
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

I hope the original poster can now see why it is that
trust is not defined in the standard at least - because
we can't as yet agree what it is.  For whatever reason.

iang

From: "Richard Laager" <[email-masked]>
To: <[email-masked]>
Subject: RE: Trust Packets
Date: Fri, 30 Jan 2004 22:48:29 -0600
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

Richard Laager

Date: Sat, 31 Jan 2004 16:42:39 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Trust Packets
Sender: [email-masked]

Peter.

Date: Sat, 31 Jan 2004 15:37:05 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

Lutz Donnerhacke <[email-masked]> writes:

>Furthermore it's easy to implement a keyserver, because you notice how many
>new keys/signatures/userid etc. pp. occured. So merging keys is very simple.

Yup, and real-time status queries are also incredibly trivial, the user
submits a request (e.g. via HTTP, http://......?keyID=abcd), you translate it
into "SELECT COUNT(*) FROM validKeys WHERE keyID=abcd" and return the output
to the user (there's an RFC draft on this floating around somehere on
ietf.org).

>>You forgot:
>> - Maintaining 10 tables at once is entertaining for the software developer.
>
>Yep. Obtaining standard query strings from you local DB developer (it's fun
>for him) and using them as black box is plain recovery. ;-)

While we're rhapsodising about the joys of SQL keyservers, it also makes
debugging incredibly easy, you just drop your favourite SQL browse tool onto
the database and you can check everything that happens, arranged/filtered by
whatever criteria you want.

Peter.

From: "Richard Laager" <[email-masked]>
To: <[email-masked]>
Subject: RE: Trust Packets
Date: Fri, 30 Jan 2004 20:36:50 -0600
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

Peter Gutmann wrote:
...
>                                                For example if 
> I make a CC
> purchase from foo.com, I don't trust them because of their 
> Verisign cert, but
> I have no choice but to depend upon them because if I don't I 
> can't make my
> purchase.  So PGP's mechanisms propagate trust, X.509's 
> propagate dependency.

No, X.509 propagates trust. The root certificates in your browser's
certificate store are there because you trust them. I realize that
the browser vendor pre-loads a bunch of certificates. This is to make
things easier for the end user. If you don't trust VeriSign to issue
signatures, remove them from the root certificate store. Now, once
that's done, does the certificate for foo.com appear valid? No.
You've revoked your trust of VeriSign, so it shouldn't. Using the
site is NOT dependent on VeriSign. You can make the SSL connection
without trusting the certificate. Then, it becomes the same
(security-wise) as HTTP; you can't be sure you're avoiding a MITM
attack.

This would be exactly the same if a Linux vendor preloaded
/etc/skel/.gnupg/ with default keys marked as trusted. There is no
dependency introduced, just pre-loaded trust. If you didn't trust the
pre-loaded keys, you could just remove them.

X.509 has its flaws, but it's trust model is in fact based on trust.
It's just different from PGP's Web-of-Trust. If you disagree with it
because it forces you into rigid hierarchies (typically promoted by
commercial interests), fine. But, the underlying technology isn't
creating any sort of trust-like dependency.

A good definition of "trust" in a computer security context is, "An
entity which can break your security policy." (I don't know if this
is attributable to the DoD or whom.) In other words, if you have
VeriSign in your root certificates, they can break your security
policy by issuing a bad certificate. This is not dependence.

Richard Laager

To: [email-masked]
Subject: Meeting in Seoul -- call for Agenda Items.
From: Derek Atkins <[email-masked]>
Date: Fri, 30 Jan 2004 14:01:43 -0500
Sender: [email-masked]

Hi,

I'd like to schedule a meeting in Seoul.  Do people have specific
items they would like to talk about?  I know Jon can't make it
but I'd like someone to present a 2440bis status (Jon, can you
find someone to provide the status).

I'll work on the list of open issues and mail that out early next
week.

We also need to update the milestones for the WG.  I'll work with
the document editors to flush out that proposal and present it here
ASAP.

Are there other orders of business for Seoul?  Any other presentations
to be made?

-derek

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

Date: Fri, 30 Jan 2004 13:28:38 +0100
From: Lutz Donnerhacke <[email-masked]>
To: [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

On Sat, Jan 31, 2004 at 01:20:57AM +1300, Peter Gutmann wrote:
> Lutz Donnerhacke <[email-masked]> writes:
> >I distribute the keys over a bunch of tables.
> 
> Hmm, I was afraid you were going to say that.  OTOH once it's all set up you
> can do some powerful stuff using the SQL query capabilities, e.g. list all
> keys that are about to expire, or all keys signed by X, or whatever.

Exactly. I added some stuff to automatically remove signatures from revoked
keys, etc. pp.

Furthermore it's easy to implement a keyserver, because you notice how many
new keys/signatures/userid etc. pp. occured. So merging keys is very simple.

> (In case anyone's interested, I did a paper on using relational databases as

Thanx. I should publish the sql based keyserver, too.

> You forgot:
>  - Maintaining 10 tables at once is entertaining for the software developer.

Yep. Obtaining standard query strings from you local DB developer (it's fun
for him) and using them as black box is plain recovery. ;-)

Date: Fri, 30 Jan 2004 13:28:38 +0100
From: Lutz Donnerhacke <[email-masked]>
To: [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

On Sat, Jan 31, 2004 at 01:20:57AM +1300, Peter Gutmann wrote:
> Lutz Donnerhacke <[email-masked]> writes:
> >I distribute the keys over a bunch of tables.
> 
> Hmm, I was afraid you were going to say that.  OTOH once it's all set up you
> can do some powerful stuff using the SQL query capabilities, e.g. list all
> keys that are about to expire, or all keys signed by X, or whatever.

Exactly. I added some stuff to automatically remove signatures from revoked
keys, etc. pp.

Furthermore it's easy to implement a keyserver, because you notice how many
new keys/signatures/userid etc. pp. occured. So merging keys is very simple.

> (In case anyone's interested, I did a paper on using relational databases as

Thanx. I should publish the sql based keyserver, too.

> You forgot:
>  - Maintaining 10 tables at once is entertaining for the software developer.

Yep. Obtaining standard query strings from you local DB developer (it's fun
for him) and using them as black box is plain recovery. ;-)

Date: Sat, 31 Jan 2004 01:20:57 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

Lutz Donnerhacke <[email-masked]> writes:

>I distribute the keys over a bunch of tables.

Hmm, I was afraid you were going to say that.  OTOH once it's all set up you
can do some powerful stuff using the SQL query capabilities, e.g. list all
keys that are about to expire, or all keys signed by X, or whatever.

(In case anyone's interested, I did a paper on using relational databases as
 key stores for ACSAC 2000, you can get it from
 http://www.acsac.org/2000/thu.html.  A longer version is available from my
 home page, the ACSAC page limit was 10 pages so I had to cut some bits out).

>This is very efficient compared to the alternatives:
>  - You search the only the part of the data associated with the query.
>  - Intertable links are indexed using hashs or btrees.
>  - Records are dense.

You forgot:

   - Maintaining 10 tables at once is entertaining for the software developer.

Peter :-).

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Trust Packets
Date: Fri, 30 Jan 2004 12:31:16 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Fri, 30 Jan 2004 12:31:16 +0000 (UTC)
Sender: [email-masked]

* Werner Koch wrote:
> But these are the real cool things you can do with SQL. 

Example: Give me all keys whose trust level might be changed by updateing
this keyid. So --check-trust does scale.

Date: Fri, 30 Jan 2004 09:01:25 -0800 (PST)
From: Len Sassaman <[email-masked]>
To: Ian Grigg <[email-masked]>
Cc: "Weins, Thorsten" <[email-masked]>, [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

On Thu, 29 Jan 2004, Ian Grigg wrote:

> Some random comments.
>
> One of the most perceptive decisions that the early PGP
> designers made was to not define trust.  This was a good
> decision because trust defies definition.  Trust is too
> much wrapped up in context of the user and her companion
> users, and the programmer can't really narrow that down
> usefully ahead of time.

I wouldn't say that they didn't define trust. PGP has internal trust
calculation algorithms, which happen not to be documented within the IETF.
I have always thought this unfortunate. I agree that trust calculation
should be orthogonal to the OpenPGP message format specification, but I do
wish that it were documented.

To: [email-masked] (Peter Gutmann)
Cc: [email-masked]
Subject: Re: Trust Packets
From: Greg Troxel <[email-masked]>
Date: 30 Jan 2004 11:02:26 -0500
Lines: 50
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:

> Since we're getting a bit philosphical here, I don't know if what X.509
> enforces is really "trust".  PGP's web of trust is a reasonably accurate use
> of the term "trust", but with X.509 you need to read "trust" as "dependency"
> (in the sense of "is forced to depend upon").  For example if I make a CC
> purchase from foo.com, I don't trust them because of their Verisign cert, but
> I have no choice but to depend upon them because if I don't I can't make my
> purchase.  So PGP's mechanisms propagate trust, X.509's propagate dependency.

You of course do have a choice - whether or not to make the purchase.
I have declined to buy things because I don't trust people, and I'd
hope everyone else is in the same boat.

With pgp, you choose whether to believe a message or use a key for
encryption.  If you "have to" send the message, you "don't have a
choice".

The ultimate trust model is really no different; it's the kinds of
decisions that you can make easily that get encoded into software that
differ (and this is important).

With foo.com, you choose

1) whether foo.com is actually reputable and you are willing to deal
   with them (same in PGP and x509 case)

and

2) whether you believe that the key you have for foo.com really
   belongs to foo.com (by choosing to believe that verisign is
   adequately careful in issuing certs and protecting the CA key), or
   via some essentially equivalent operation wtih a PGP signature.

The real difference is that x509 has a bunch of rules about which
signatures won't be believed (due to name subordination) and the
cultural (not spec) notion that 'root CAs' are inherently trustworthy,
together with the notion and practice that a specific list is included
by default.  I agree that in practice this cultural difference is
large.

I think it would be a mistake for the openpgp spec to move in the
direction of suggesting that some keys be preconfigured as trusted
(where trusted specifically means that name/key bindings signed by
those keys are believed).  But I don't think anyone is suggesting
that.

-- 
        Greg Troxel <[email-masked]>

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: Trust Packets
Date: Fri, 30 Jan 2004 13:22:57 +0100
Lines: 60
Gmane-NNTP-Posting-Host: h213n3c1o299.bredband.skanova.com
Cancel-Lock: sha1:jVgWlMtaph5sjz8hOE7PQMAlzFU=
Sender: [email-masked]

[email-masked] (Peter Gutmann) writes:

> Werner Koch <[email-masked]> writes:
>
>>The concept of a keyring is PGP specific, other implementations may use an
>>SQL DB or use a mixed approach, where the trust information is kept separate
>>from the keys.
>
> Just out of interest, is there anyone using an SQL DB to store PGP keys?

I am, in a DNS-based OpenPGP key server.  It separates key
fingerprints with uid like this:

create table cks_key_id_table
(
        key_id          char(8) NOT NULL,
        fkey_id         char(16) NOT NULL,
        fp              varchar(40) NOT NULL,
        PRIMARY KEY(fp)
);

create table cks_uid_table
(
        fkey_id         varchar(16) NOT NULL,
        p_uid           int2 NOT NULL,
        fp              varchar(40) NOT NULL,
        uid             varchar(6000) NOT NULL
);

> I've thought about this a bit in the past (I use databases to store
> other types of keys) but because of the free-form association of
> different bits and pieces of keys with identifying information I
> can't think of any easy way to do it unless you use a multi-level
> lookup.  That is, you can't do a:
>
>   SELECT key FROM table WHERE email = foo
>
> because there could be an arbitrary number of email addresses attached to a
> key, and there could be an arbitrary number of keys associated with an email
> address.  So you need something like:
>
>   SELECT keyID FROM indexTable WHERE email = foo 
>   SELECT key FROM sigKeyTable WHERE keyID = foo
>
> which isn't very efficient (multiple tables, multi-level lookups, etc etc).

Have you tried this and found that performance is the most performance
critical area?  I am often surprised how efficient modern databases
are.  When I measured, the network related delays was about five times
longer than the database query delay (I'm using multiple tables, two
SQL queries per DNS query), even on local network.  I admit most of
the delays was in the Perl DNS server implementation, or in my use of
it, which appear to be rather inefficient, but anyway it suggested to
me that I shouldn't worry much about database performance.  (The
database contained the equivalent of ~2GB PGP keyrings worth of data,
although the machine had enough memory to store the entire database in
RAM.)

Regards,
Simon

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
Subject: Re: Trust Packets
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Fri, 30 Jan 2004 12:12:25 +0100
Sender: [email-masked]

On Fri, 30 Jan 2004 22:54:29 +1300, Peter Gutmann said:

> Just out of interest, is there anyone using an SQL DB to store PGP keys?  I've

I don't know.  From the discussions on the GnuPG MLs I surmised that a
some folks are trying to do it.

> which isn't very efficient (multiple tables, multi-level lookups, etc etc).

But these are the real cool things you can do with SQL. 

  Werner

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Trust Packets
Date: Fri, 30 Jan 2004 10:30:28 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 40
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Fri, 30 Jan 2004 10:30:28 +0000 (UTC)
Sender: [email-masked]

* Peter Gutmann wrote:
> Just out of interest, is there anyone using an SQL DB to store PGP keys?

Yes, here. Keyserver on DB.

> I've thought about this a bit in the past (I use databases to store other
> types of keys) but because of the free-form association of different bits
> and pieces of keys with identifying information I can't think of any easy
> way to do it unless you use a multi-level lookup.

I distribute the keys over a bunch of tables.
pgp=# \dt
 List of relations
 Schema |         Name          | Type  | Owner 
--------+-----------------------+-------+-------
 public | asymmetric_algorithm  | table | lutz
 public | compression_algorithm | table | lutz
 public | hash_algorithm        | table | lutz
 public | pubkey                | table | lutz
 public | revocation            | table | lutz
 public | revocation_class      | table | lutz
 public | sig                   | table | lutz
 public | sigtype               | table | lutz
 public | symmetric_algorithm   | table | lutz
 public | userid                | table | lutz
(10 rows)

>   SELECT keyID FROM indexTable WHERE email = foo 
>   SELECT key FROM sigKeyTable WHERE keyID = foo

Yes.

> which isn't very efficient (multiple tables, multi-level lookups, etc etc).

This is very efficient compared to the alternatives:
  - You search the only the part of the data associated with the query.
  - Intertable links are indexed using hashs or btrees.
  - Records are dense.

Date: Fri, 30 Jan 2004 23:09:59 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Trust Packets
Cc: [email-masked]
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:

>An example of this is the x.509 PKI in use in HTTPS - they define trust as
>being a CA-signed cert that includes, for example, some notion of what
>country you are in (? from?).

Since we're getting a bit philosphical here, I don't know if what X.509
enforces is really "trust".  PGP's web of trust is a reasonably accurate use
of the term "trust", but with X.509 you need to read "trust" as "dependency"
(in the sense of "is forced to depend upon").  For example if I make a CC
purchase from foo.com, I don't trust them because of their Verisign cert, but
I have no choice but to depend upon them because if I don't I can't make my
purchase.  So PGP's mechanisms propagate trust, X.509's propagate dependency.

Peter.

Date: Fri, 30 Jan 2004 22:54:29 +1300
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Trust Packets
Cc: [email-masked]
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

>The concept of a keyring is PGP specific, other implementations may use an
>SQL DB or use a mixed approach, where the trust information is kept separate
>from the keys.

Just out of interest, is there anyone using an SQL DB to store PGP keys?  I've
thought about this a bit in the past (I use databases to store other types of
keys) but because of the free-form association of different bits and pieces of
keys with identifying information I can't think of any easy way to do it
unless you use a multi-level lookup.  That is, you can't do a:

  SELECT key FROM table WHERE email = foo

because there could be an arbitrary number of email addresses attached to a
key, and there could be an arbitrary number of keys associated with an email
address.  So you need something like:

  SELECT keyID FROM indexTable WHERE email = foo 
  SELECT key FROM sigKeyTable WHERE keyID = foo

which isn't very efficient (multiple tables, multi-level lookups, etc etc).

Peter.

Date: Thu, 29 Jan 2004 09:09:04 -0500
From: Ian Grigg <[email-masked]>
To: "Weins, Thorsten" <[email-masked]>
CC: [email-masked]
Subject: Re: Trust Packets
Sender: [email-masked]

Weins, Thorsten wrote:
> Hello,
> 
> the implementation of Trust Packets is implementation specific.
> Does anybody know, how these packets are implemented in PGP 7.x or
> higher?
> 
> BTW, is there a reason why they are implementation specific? If somebody
> uses
> different implementations (e.g. on different platforms) of PGP, he will
> not be
> able to use his "one and only" keyring.

Some random comments.

One of the most perceptive decisions that the early PGP
designers made was to not define trust.  This was a good
decision because trust defies definition.  Trust is too
much wrapped up in context of the user and her companion
users, and the programmer can't really narrow that down
usefully ahead of time.

Encouraging an implementation to more closely define trust,
and standardising this across implementations, would break
it.  An example of this is the x.509 PKI in use in HTTPS -
they define trust as being a CA-signed cert that includes,
for example, some notion of what country you are in (? from?).

In terms of keyrings - Werner mentioned the local issues
with databases.  Trust includes lots of information that
will/should never be exported.  By not standardising the
format of the keyrings (and suggesting inter-program exports
to be done by means of ascii-armoured keys) PGP votes to
encourage experimenting with trust at the implementation
level.  This allows an implementation to add some special
notes in there, or turn it into an addressbook, or build
up signing networks.

That's much more beneficial than some committee trying to
define trust.

iang

To: "Weins, Thorsten" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Trust Packets
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 29 Jan 2004 14:08:52 +0100
Sender: [email-masked]

On Thu, 29 Jan 2004 10:19:30 +0100, Weins, Thorsten said:

> BTW, is there a reason why they are implementation specific? If somebody
> uses
> different implementations (e.g. on different platforms) of PGP, he will

OpenPGP defines message and key transport formats but not how an
application stores the key for its own purpose.  

The concept of a keyring is PGP specific, other implementations may
use an SQL DB or use a mixed approach, where the trust information is
kept separate from the keys.

Shalom-Salam,

   Werner

-- 
Werner Koch                                      <[email-masked]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe                  http://fsfeurope.org

content-class: urn:content-classes:message
Subject: Trust Packets
Date: Thu, 29 Jan 2004 10:19:30 +0100
From: "Weins, Thorsten" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hello,

the implementation of Trust Packets is implementation specific.
Does anybody know, how these packets are implemented in PGP 7.x or
higher?

BTW, is there a reason why they are implementation specific? If somebody
uses
different implementations (e.g. on different platforms) of PGP, he will
not be
able to use his "one and only" keyring.

Thanks in advance,

Thorsten

Date: Wed, 28 Jan 2004 17:29:09 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Minor MDC inconsistency in bis-09
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In bis-09, section 5.13 says in regards to what gets hashed into the
MDC: "The input to the hash function includes the prefix data
described above".

The next section, 5.14, says in regards to the body of the MDC packet:
"...NOT including prefix data...". (my emphasis)

Given the evidence of working code, I suspect section 5.14 is
incorrect.

David

Date: Sat, 24 Jan 2004 15:00:56 -0800
To: (various IETF lists)
From: Paul Hoffman / IMC <[email-masked]>
Subject: New mail-ng mailing list open for sign-ups
Sender: [email-masked]

Greetings again. There seems to be more discussion these days about 
replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of 
reasons. The discussion seems to pop up on a few different lists and 
in a few different hallways, and it might be good to have a single 
list where folks can congregate. Thus, I have set up a mail-ng 
mailing list.

The first task probably is to determine what the next generation of 
mail should do, and how that is different than what 
SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say 
that we can ignore actual protocol proposals for many months (if not 
years) until we figure out what is needed. Once we do that, there are 
plenty of protocol people who can attack the decided-on requirements.

There is no expectation that there will be significant agreement on 
the list. It is likely that over time the discussion will split into 
camps of like-minded design goals. The list might then spawn 
different lists for the folks of the different camps (mail-ng-shoe, 
mail-ng-sandal, ...). The list is explicitly not yet meant to be an 
IETF working group yet (if at all), and is probably more akin to the 
IRTF. But at the beginning, it will most likely be talking, not 
research.

See <http://www.imc.org/mail-ng/> for information on how to 
subscribe. The list is taking subscriptions now, and will probably go 
live for discussions within a week. Having some discussion on a 
mailing list now should make the dinners and bar gatherings at Seoul 
more interesting.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 22 Jan 2004 14:43:37 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked]
Subject: Reason for V4 signature postscript
Sender: [email-masked]

I got some email from Peter Gutmann asking why we do the bizarre
"postscript" in the hashing of V4 signatures.  I didn't remember, but
some digging into the code shed light on it, and gradually the reasons
came back.  Here is the mail I sent to him, which may be useful for
future software archaeologists.

The general concern we had was "aliasing", meaning that a specific set of
bytes which were hashed could mean different things in different contexts.
Specifically, we were worried that a V3 sig could have the same bytes
hashed as a V4.  The problem is that V3 sigs don't hash the sig version.
They hash the body of the data, which could be anything, and then they
hash the sig type and then 4 bytes of sig creation time.

We wanted to make certain that you couldn't conjure up a document and
get someone to put a V3 sig on it, and then turn that into a V4 sig on
something else.  So we wanted to make sure the last 5 hashed bytes for
a V4 sig could never look like the last 5 hashed bytes for a V3 sig.

The oldest version of the code I could find reads like this:

            /* Add hash "postscript", ensure hashed data not alias anything */
            postscript[0] = PGPVERSION_4;  /* Hash-convention version */
            postscript[1] = 0xff;   /* 5th from end, != any sig type value */
            postscript[2] = (PGPByte)(l >> 24);
            postscript[3] = (PGPByte)(l >> 16);
            postscript[4] = (PGPByte)(l >>  8);
            postscript[5] = (PGPByte)(l >>  0);
            PGPContinueHash (temp_hc, postscript, sizeof(postscript));

The 4 is the hash-convention version, which I guess we meant to
distinguish from the signature version.

The FF is there as that is never a value found in the 5th from the end
(or 4th from the end if you count differently) of the data hashed for
a V3 sig.  This assures that no V4 and V3 sigs will ever have the same
bytes hashed.

I remember now why the length was there.  It allows for unambiguous
parsing of the fields of the signature packet, counting from the far
end.  Without that, there may be ambiguity about how to parse it out,
because there is no way, starting from the front, to know where the
signed-document's data ends and the data from the signature begins.
The signed-document's data is hashed with no headers, just the content
of the document, so you don't know where it ends.

As long as the hashed data can be unambiguously parsed from one end or the
other, there is no danger of border-shifting, where data that is supposed
to be part of one field can be interpreted as being part of another.
Without this length field, that is a problem.

So that explains the length, and the FF.  The 4 still seems a little
redundant, but by the end of one of these exercises, you get sort of
paranoid about both making sure no ambiguities are possible, and also
leaving yourself an escape so that the next version of the software
won't suffer from this.  Since we were relying on parsing from the end
to prevent aliasing, it felt a little safer to put a version field right
near that end.  That way if we ever went to a V5 signature we could do
so without worry that it could be aliased with a V4 sig.

Hal Finney

content-class: urn:content-classes:message
Subject: RE: check for complementary keys
Date: Tue, 13 Jan 2004 18:02:19 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Thanks. This will make it easier for me to read the public key from the
private key and then do a match on the fingerprints of the two public
keys.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of David Shaw
Sent: Tuesday, January 13, 2004 4:00 PM
To: [email-masked]
Subject: Re: check for complementary keys

On Tue, Jan 13, 2004 at 02:34:06PM -0500, Hasnain Mujtaba wrote:
> 
> Hi all,
> 
> What is a good way to check whether an openpgp public and private key
> pair is complementary? One way I can think of is to do an
> encrypt/decrypt test with the keypair. But is there another way to
> determine this just by looking at the key material of the two keys? 

The OpenPGP packet format for private keys contains a complete copy of
the corresponding public key.  If you are not concerned about
manipulation of the secret key packet, you could simply compare this
embedded public key to the public key in question.

David

Date: Tue, 13 Jan 2004 16:00:06 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: check for complementary keys
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Jan 13, 2004 at 02:34:06PM -0500, Hasnain Mujtaba wrote:
> 
> Hi all,
> 
> What is a good way to check whether an openpgp public and private key
> pair is complementary? One way I can think of is to do an
> encrypt/decrypt test with the keypair. But is there another way to
> determine this just by looking at the key material of the two keys? 

The OpenPGP packet format for private keys contains a complete copy of
the corresponding public key.  If you are not concerned about
manipulation of the secret key packet, you could simply compare this
embedded public key to the public key in question.

David

content-class: urn:content-classes:message
Subject: check for complementary keys
Date: Tue, 13 Jan 2004 14:34:06 -0500
From: "Hasnain Mujtaba" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi all,

What is a good way to check whether an openpgp public and private key
pair is complementary? One way I can think of is to do an
encrypt/decrypt test with the keypair. But is there another way to
determine this just by looking at the key material of the two keys? 

Thanks
Hasnain.

Date: Tue, 13 Jan 2004 13:21:12 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: The last word (hopefully) on back-signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Jan 13, 2004 at 09:24:43AM +0100, Adrian von Bidder wrote:
Content-Description: signed data
> On Monday 12 January 2004 20:58, David Shaw wrote:
> > I have
> > code for GnuPG that follows this basic design, and it works well.
> 
> Will it be possible to convert existing subkeys? AFAICT, putting the 0x19 
> signature in an unhashed packet, this should be relatively painless. (Will 
> keyservers properly deal with subkeys with the additional packet suddenly 
> appearing?)

Yes, it is possible to convert existing subkeys.  One of the reasons I
advocated using a subpacket was for this ability.  Based on a number
of tests, and a conversation with the author of SKS, I don't see any
problem with updating existing subkeys on the PKSD or SKS servers.  I
haven't looked at the LDAP server yet.

David

From: Adrian von Bidder <[email-masked]>
To: [email-masked]
Subject: Re: The last word (hopefully) on back-signatures
Date: Tue, 13 Jan 2004 09:24:43 +0100
Sender: [email-masked]

--Boundary-02=_Lt6AAZ+FoIhfEfo
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 12 January 2004 20:58, David Shaw wrote:
> I have
> code for GnuPG that follows this basic design, and it works well.

Will it be possible to convert existing subkeys? AFAICT, putting the 0x19=20
signature in an unhashed packet, this should be relatively painless. (Will=
=20
keyservers properly deal with subkeys with the additional packet suddenly=20
appearing?)

cheers
=2D- vbi

=2D-=20
featured product: vim - http://vim.org

--Boundary-02=_Lt6AAZ+FoIhfEfo
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_Lt6AAZ+FoIhfEfo--

Date: Mon, 12 Jan 2004 14:58:11 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: The last word (hopefully) on back-signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Apologies for the delay in this.  I've had a lot on my plate recently.
In November, I posted two proposals for comment on the "stolen
signature"/back-signatures problem.  Here now is my final proposal
with the various comments taken into account:

First to briefly recap the purpose for this, there is a minor problem
in the current subkey design where a signing subkey can be taken from
an existing key, and bound to the attacker's primary key with a
binding signature issued by the attacker's key.  The attacker cannot
use this stolen key to issue a signature of course, but can claim that
an existing signature was issued by him.

The proposed fix is to add an additional signature into the mix -
currently we have only a binding signature issued by the primary key
on the signing subkey.  I suggest we add a signature (the
"back-signature") issued by the subkey on the primary key.  This
prevents the attack as the attacker cannot issue this signature, and
thus cannot claim ownership of an existing signature.  The
back-signature design seemed to enjoy greater approval than the other,
as well as having the nice detail that it could automatically protect
signatures issued before the back-signature was added.

The specifics (suggestions - I'm not wedded to this particular
language):

1) Define a new type of signature subpacket that consists of a regular
   signature contained in a subpacket.

    Add to section 5.2.3.1 ("Signature Subpacket Specification"):

         32 = embedded signature

    Add a new section to 5.2.3.x:

        5.2.3.26. Embedded Signature

         (1 signature packet body)

         This subpacket contains a complete signature packet body as
	 specified in section 5.2 above.  It is useful when one
	 signature needs to refer to, or be incorporated in, another
	 signature.

2) Define a new signature class (Hal suggested 0x19), that is defined
   as a subkey signature on a primary key.

    Add to section 5.2.1 ("Signature Types"):

       0x19: Primary key Binding Signature

         This signature is a statement by a signing subkey,
         indicating that it is owned by the primary key.  This
	 signature is calculated directly on the primary key itself,
	 and not on any User ID or other packets.

3) At (sub)key generation time (or later, for existing keys) create
   this 0x19 signature and store it as a subpacket on the subkey
   binding signature.  It does not matter whether it is a hashed
   subpacket or not.  The hashing rules for 0x19 are the same as a
   0x18 signature - we hash the primary key, then the subkey, and
   issue a signature from the subkey over this hash.

    In section 5.2.1, add to the description of the 0x18 signature:

        Signing subkeys have an embedded signature subpacket on this
        signature which contains a 0x19 signature by the signing
	subkey on the primary key.

    In section 5.2.4, change the sentence:

        A subkey signature (type 0x18) then hashes the subkey, using
	the same format as the main key (also using 0x99 as the first
	octet).

     to:

        A subkey binding signature (type 0x18), or primary key binding
	signature (0x19) then hashes the subkey, using the same format
	as the main key (also using 0x99 as the first octet).

    In section 10.1, change the sentence:

        Each Subkey packet must be followed by one Signature packet,
	which should be a subkey binding signature issued by the top
	level key.

    to:

        Each Subkey packet must be followed by one Signature packet,
	which should be a subkey binding signature issued by the top
	level key.  For subkeys that can issue signatures, the subkey
	binding signature must contain an embedded signature subpacket
	with a primary key binding signature (0x19) issued by the
	subkey on the top level key.

That should do it.  I've tried to keep the number of changes to a
minimum, so this may seem somewhat terse.  I do think it is sufficient
to explain the proper way to write the additional signature.  I have
code for GnuPG that follows this basic design, and it works well.

David

Date: Tue, 06 Jan 2004 12:29:22 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
Cc: [email-masked]
Subject: Re: cleartext signed messages - UTF-8 - stripping the whitespace
Sender: [email-masked]

Adrian 'Dagurashibanipal' von Bidder wrote:
> 
> On Monday 05 January 2004 16:24, Ian Grigg wrote:

...
> > 3.  What was the original deep dark motivation
> >     for stripping whitespace from the end of lines
> >     anyway?
> >
> > 4.  Do we care if UTF-8 has some weird whitespace/
> >     line endings?
> 
> IIRC from previous discussions (I wasn't around for years when PGP was
> introduced to the world...): some mailers (MUAs and MTAs) used to strip
> whitespace occasionally or do other weird things.

Thinking about it, I've come across editors and
desktops that do something similar, they add spaces
to the end of lines in arbitrary fashions, and
sometimes modify newlines (take away, add) at the
end of files (but newlines are adequately protected
already in the draft).

> Those old mailers would probably either treat all non-ASCII whitespace and
> line-endings as normal characters, or not be 8-bit clean anyway and so cause
> problems in any case. So the answer to (4) is probably a clear no.

So, the upshot is that only the defined US-ASCII
whitespace chars should be included in the
canonicalisation:

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

In which case it might be worth adding a comment
to that effect.  Because of the difficulties of
predicting the future here, I'd suggest the following:

    Also, any trailing whitespace (0x20, 0x09) at the end of
    any line is ignored when the cleartext signature is calculated.
    Implementations MAY elect to clean line endings of whitespace
    in the final signed form of the document, including UTF-8 forms.

Thus, when we hit upon some troublesome mailer that
mangles non-english language Word-prepared UTF-8 documents,
the OpenPGP plugin can pre-emptively clean it up and
still be in accord with the standard.

If applications start adding UTF-8 whitespace afterwards,
then we have more of a problem.  I guess at that point,
implementations can agree to add additional characters
to the "ignore" list.

iang

From: "Adrian 'Dagurashibanipal' von Bidder" <[email-masked]>
To: [email-masked]
Subject: Re: cleartext signed messages - UTF-8 - stripping the whitespace
Date: Mon, 5 Jan 2004 20:57:18 +0100
Sender: [email-masked]

--Boundary-02=_hGc+/fRzPla9c3B
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 05 January 2004 16:24, Ian Grigg wrote:

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

> 2.  Are there UTF-8 whitespace encodings that
>     are not in the definitions above?
>
>     I.e., not in "spaces, and tabs, 0x09" .
>
> 3.  What was the original deep dark motivation
>     for stripping whitespace from the end of lines
>     anyway?
>
> 4.  Do we care if UTF-8 has some weird whitespace/
>     line endings?

IIRC from previous discussions (I wasn't around for years when PGP was=20
introduced to the world...): some mailers (MUAs and MTAs) used to strip=20
whitespace occasionally or do other weird things.

Those old mailers would probably either treat all non-ASCII whitespace and=
=20
line-endings as normal characters, or not be 8-bit clean anyway and so caus=
e=20
problems in any case. So the answer to (4) is probably a clear no.

cheers
=2D- vbi

=2D-=20
featured product: PostgreSQL - http://postgresql.org

--Boundary-02=_hGc+/fRzPla9c3B
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_hGc+/fRzPla9c3B--

Date: Mon, 05 Jan 2004 10:24:34 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: cleartext signed messages - UTF-8 - stripping the whitespace
Sender: [email-masked]

I'm working on some code that deals with cleartext
signed messages over UTF-8 [1].

In debugging the treatment of UTF-8, I looked at
the definition of mods that OpenPGP does to the
cleartext (paras 3,5) for signature treatment [2]:

    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.

Here are the questions:

1.  In UTF-8, are there such things as line
    endings that are not of <CR> and/or <LF> form?

2.  Are there UTF-8 whitespace encodings that
    are not in the definitions above?

    I.e., not in "spaces, and tabs, 0x09" .

3.  What was the original deep dark motivation
    for stripping whitespace from the end of lines
    anyway?

4.  Do we care if UTF-8 has some weird whitespace/
    line endings?

5.  Are we explicitly ignoring these?

    Hence the question 3, perhaps the answer can
    guide us....

It seems the easiest thing is to say that we
explicitly do not include any UTF-8 characters
in the above discussion.  And add a clarifying
comment to that effect.

Perhaps also something to the effect of:

  Implementations
  MAY strip whitespace (including any UTF-8 whitespace
  that is recognised) from line endings before signing,
  so that the resultant cleartext signed message will
  not include any complex lines.

(That's essentially what I try and do in my code,
but I recognise that this goes beyond the standard....)

Alternatively, if someone can nail what UTF-8 does
in whitespace, it might be possible to put in more
consideration.

iang

[1] Code is based on Edwin Woudt's OpenPGP in Java
as found at
http://www.cryptix.org/products/openpgp/index.html
The application is Ricardian Contracts in Spanish.

[2] Looking at at section 7.1, Dash-Escaped Text, of the
current draft: draft-ietf-openpgp-rfc2440bis-09.txt
http://carmen.cselt.it/internet-drafts/draft-ietf-openpgp-rfc2440bis-09.txt

Date: Mon, 05 Jan 2004 09:55:44 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: cleartext signatures - consistent naming 
Sender: [email-masked]

Searching on the draft 2440bis-09.txt, I find
several variations of the cleartext signature
naming:

    signatures following clearsigned messages.  p48
    particularly important when computing a cleartext signature
    This is used only in clear-signed messages. p49
    7. cleartext signature framework
    another way to clear sign messages ...
    The cleartext signed message consists of:
    ...

It seems that the word "cleartext" is the dominant
form, followed by signing in some appropriate verb
form.

It would be nice if the parts outside section 7
(lines 1,3 above) also used that convention, to
make searching easier.

iang

Date: Mon,  5 Jan 2004 06:10:28 -0800
To: [email-masked], [email-masked]
Cc: 
Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide?
From: <[email-masked]>
Sender: [email-masked]

On Mon, 05 Jan 2004 05:06:54 -0800 Ralf Hauser <[email-masked]> wrote:
>
>To my understanding,
>
>If I send a message with attachments, the attachment filename is
>visible
>without cryptanalysis.
>Would it be hard to give the encrypted file a random name and only
>upon
>decryption, give it back its real name?

there is a simple workaround you might be interested in:

armor the attachment (without encryption) and include the armored attachment
as part of the plaintext of the message, and then encrypt the entire
message

not only the filename, but even the fact that you are sending an attachment,

will not be apparent
(although it may be guessed at by the size of the message)

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Mon, 5 Jan 2004 07:40:49 -0600 (CST)
Subject: Re: filenames of encrypted attachments visible ? How hard would it  be to hide?
From: "Brian G. Peterson" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Importance: Normal
Sender: [email-masked]

Ralf Hauser said:
>
> To my understanding,
>
> If I send a message with attachments, the attachment filename is visible
> without cryptanalysis.
> Would it be hard to give the encrypted file a random name and only upon
> decryption, give it back its real name?
>
> http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this
> issue.
>
> Isn't that kind of giving away information that could be easily protected
> -
> or did I miss something?
>
> Rgds
> 	Ralf

Ralf,

This is totally an implementation detail.

Many mail programs that integrate PGP or GnuPG already *do* obfuscate the
filename, calling it encrypted.dat.asc or data.asc or
somerandomstring.asc.  If the asc file has an embedded filename, any
OpenPGP compatible client should be able to retrieve the file name upon
decryption.

There are times when knowing the filenmae may be more important than
obfuscating it for security reasons.  The reverse is most certainly true
as well.

In my opinion, it should probably be left as an implementation detail for
each OpenPGP compatible mail client to decide on.

Regards,

   - Brian

From: Adrian von Bidder <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide?
Date: Mon, 5 Jan 2004 14:31:50 +0100
Sender: [email-masked]

--Boundary-02=_GdW+/lK0Ha2Hbm9
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

[sorry. ralf, of course I meant to answer to the lists]

On Monday 05 January 2004 14:06, Ralf Hauser wrote:
> To my understanding,
>
> If I send a message with attachments, the attachment filename is visible
> without cryptanalysis.
> Would it be hard to give the encrypted file a random name and only upon
> decryption, give it back its real name?
>
> http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this
> issue.
>
> Isn't that kind of giving away information that could be easily protected=
 -
> or did I miss something?

Hi,

You did miss rfc3156 (PGP/MIME). The structure of these (encrypted) emails =
is:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
=46rom: whatever
To: whatever
Subject: whatever
Date: whatever
Content-Type: multipart/encrypted;
  protocol=3D"application/pgp-encrypted";
  boundary=3D"Boundary-02=3D_5Plx/pJ9Yq8C9E0"

=2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0
Content-Type: application/pgp-encrypted

Version: 1

=2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0
Content-Type: application/octet-stream

=2D----BEGIN PGP MESSAGE-----
Version: GnuPG v1.2.3 (GNU/Linux)

hQEOAzLIxTMIwnnYEAP....
=2E...
AFWzv4cn5IDmQ5A93JaApgQg6g=3D=3D
=3DpVu5
=2D----END PGP MESSAGE-----
=2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

And the encrypted part is again a full MIME message, with attachments and a=
ll.=20
So the only relevant bits that go over the wire unencrypted are From/To=20
(unavoidable to the extent of the email addresses) and the Subject (I have =
a=20
proposal that could address this cooking slowly, I think I posted it in som=
e=20
places a few months ago).

Greetings
=2D- vbi

=2D-=20
<Knghtbrd> joeyh now has a terminal at the couch?
<Knghtbrd> That guy is wired, I swear  =3D3D>
<doogie> Knghtbrd: laptop
<doogie> and I don't mean the cats.

--Boundary-02=_GdW+/lK0Ha2Hbm9
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_GdW+/lK0Ha2Hbm9--

Reply-To: <[email-masked]>
From: "Ralf Hauser" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: filenames of encrypted attachments visible ? How hard would it be to hide?
Date: Mon, 5 Jan 2004 14:06:54 +0100
Importance: Normal
Sender: [email-masked]

To my understanding,

If I send a message with attachments, the attachment filename is visible
without cryptanalysis.
Would it be hard to give the encrypted file a random name and only upon
decryption, give it back its real name?

http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this
issue.

Isn't that kind of giving away information that could be easily protected -
or did I miss something?

Rgds
	Ralf

Sample use case: Some investment banker uses PGP and sends around an
attachment with the name "UnfriendlyTakeoverOfListedCorpXYZ.doc.asc" - isn't
that kind of an invitation to insiders?
Sure, it wouldn't be hard to rename the file before sending, but this kind
of negligence is happening all over... and I hope applications like gpg/pgp
could eventually become fool-proof/fail-safe to this level?