Subject: Email Handling Opinion Needed

From: <[email-masked]>
Date: Sat, 28 Feb 2009 19:05:56 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!

To unsubscribe from this mailing list, please log in to www.prizemover.com, click on "My Account",
click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.

Or unsubscribe at
http://prizemover.com/faq.php

Privacy Statement |
Terms & Conditions |
Contact

KEYWORD Ltd.

Tower Bridge Business Complex. Unit 7, B222. 358 Clements Road. London. SE96 5DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13D0MUY013369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 06:00:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13D0MhS013368; Tue, 3 Feb 2009 06:00:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from netscalibur-outbound-smtp04.uk.clara.net (netscalibur-outbound-smtp04.uk.clara.net [213.253.59.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13D0Bfm013343 for ; Tue, 3 Feb 2009 06:00:21 -0700 (MST) (envelope-from [email-masked])
Received: from skaro.afraid.org ([212.169.1.61]:26510) by relay04.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.44]:1325) with esmtp id 1LUKsq-00027G-Es (Exim 4.69) (return-path ); Tue, 03 Feb 2009 13:00:08 +0000
Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 2F3A05D22; Tue, 3 Feb 2009 13:00:04 +0000 (GMT/BST)
Message-ID: <[email-masked]>
Date: Tue, 03 Feb 2009 14:00:03 +0100
From: Ian G
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
To: "gerry_lowry (alliston ontario canada)"
Cc: [email-masked]
Subject: Re: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
References: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
In-Reply-To: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 1/2/09 20:14, gerry_lowry (alliston ontario canada) wrote:

> QUESTION # 1: There seems to currently exist TWO forces in the PGP universe:
>
> (a) GPG -- GnuPG (OpenPGP initiative)
> (b) PGP -- PGP Corporation.
>
> To what extent are their goals aligned?

To the extent agreed in the OpenPGP RFC. They both produce working code
to that document, and it seems to happily exchange messages. That is
the point of the document.

> More specifically, since (b) is a corporation
> which is driven by the profit motive and (a) would like to make a reasonable living
> but is likely more open than the average corporate culture, it's likely more in the
> interested of (b) to succeed in being universal but not too universal, i.e., to some
> degree, (b) could grab more market share by being somewhat proprietary.
> OTOH, it's possible AFAIK that (a) could not succeed without being 100%
> compatible with (b).

I think it is a reasonable question to ask about the structure of the
OpenPGP microindustry, although rather hard to voice without appearing
insensitive :)

The thing is, the market for OpenPGP (both paid and FLOSS) is very very
small. In such a market, the competitors can actually do far better by
working together. They can grow the market more easily that way.

If this were a "saturated market" and no growth were possible, then
stealing a client from the competitor would represent the only growth
possibility, so then we would expect to see some mutual canibalisation
and hence what you might think of as bad behaviour.

To perhaps put a controversial spin on it, the question can be turned
around. To what extent can we trust the various players to stick to
their stated goals? Without talking about say GnuPG (which I know
little about) I can suggest that it is pretty easy to pervert an open
source organisation. Here's two common ways:

* cut a secret deal with them.

* pay your developers to work on their project.

For both of those, a corporation has an easier time with the attack
(which is balanced by other things of course).

If one were to do a scorecard on how aligned the stated goals were with
the actual events and work done by the players, OpenPGP security
community would score quite highly. Other security projects would score
far more badly, and are a cause for serious concern.

iang

PS: which reminds me, I did that a few years back, and PGP Inc did score
pretty highly:
http://iang.org/ssl/security_metrics.html

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1392AF2001631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 02:02:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1392ALp001630; Tue, 3 Feb 2009 02:02:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1391wJt001309 for ; Tue, 3 Feb 2009 02:02:09 -0700 (MST) (envelope-from [email-masked])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.63 #1 (Debian)) id 1LUHAK-0004yT-Dq for ; Tue, 03 Feb 2009 10:01:56 +0100
Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1LUH4Q-0007RO-Kt; Tue, 03 Feb 2009 09:55:50 +0100
From: Werner Koch
To: gerry_lowry (alliston ontario canada)
Subject: Re: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
References: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan> <[email-masked]>
cc:
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 03 Feb 2009 09:55:50 +0100
In-Reply-To: <[email-masked]> (Jon Callas's message of "Mon, 2 Feb 2009 10:50:09 -0800")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.110007 (No Gnus v0.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 2 Feb 2009 19:50, [email-masked] said:

> Now then, let me go on to some other things. We think that the GnuPG
> guys are friends and allies who make things that we *can't* make.

I concur.

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13205D6082772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 19:00:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13205Og082771; Mon, 2 Feb 2009 19:00:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp126.rog.mail.re2.yahoo.com (smtp126.rog.mail.re2.yahoo.com [206.190.53.31]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n131xsKE082718 for ; Mon, 2 Feb 2009 19:00:05 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 44624 invoked from network); 3 Feb 2009 01:59:54 -0000
Received: from unknown (HELO zentrumvegan) ([email-masked] with login) by smtp126.rog.mail.re2.yahoo.com with SMTP; 3 Feb 2009 01:59:53 -0000
X-YMail-OSG: x6X_2fIVM1n0b1AOa2_8x96oezen5GEgVQ2TIxnxzkqSUQyTjuvFJ2JsGC06A5VHlA--
X-Yahoo-Newman-Property: ymail-3
Message-ID:
From: "gerry_lowry \(alliston ontario canada\)"
To:
References: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan> <[email-masked]>
Subject: Re: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
Date: Mon, 2 Feb 2009 20:59:34 -0500
Organization: ability business computer services
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Jon,

I regret that you took the nature of my question as an insult. None, per se, was intended.

My first question imho is fair. This forum consists of the meta experts likely best suited
to answer that question.

In no way am I talking about individuals when I ask about PGP Corporation.
I'm guessing that PGP Corporation may be a good place to be and that you
work for them. I was semi-correct about you ... from http://www.merrymeet.com/jon/
I see that you used to work for PGP Corporation. Of course, your page reads
"Last Updated: 8 April 2001" so perhaps you're back with PGP Corporation.
[BTW, http://www.merrymeet.com/jon/FGuru.JPG shows a very chilled you.]
___________________________________________________________

OTOH, that corporations can be psychopathic is well documented.

E.g.: http://www.thecorporation.com/
http://www.thecorporation.com/index.cfm?page_id=2
Above is a film based on this book:
"The Corporation: The Pathological Pursuit of Profit and Power",
Free Press (February 2004), ISBN-10: 0743247442, ISBN-13: 978-0743247443

from http://www.penguin.ca/nf/Book/BookDisplay/0,,9780140290042,00.html :
"Joel Bakan's new book is a brilliantly argued account of the
corporation's pathological pursuit of profit and power. An eminent law professor
and legal theorist, Bakan contends that the corporation is created by law to function
much like a psychopathic personality whose destructive behavior, if left unchecked,
leads to scandal and ruin."

We've recently seen the horror corporations have brought about to the economy
of the entire planet. Of course, a few humans were complicit too.

So, even if today some corporation is 100% altruistic, a change in its governance
can turn it into a demon overnight. Example: search "Google layoffs". Google
was that company that brought in a chef for its staff in the early days.

I, myself, have had my corporate loyalty rewarded more than once with a
kick in the groin.

So "making a living" does not necessarily make an individual corrupt
although this is not always the case. There are some alledged/convicted
"bad apples" that come to mind (Bernard Madoff, Ken Lay, Bernard Ebbers,
Jeffrey Skilling, et al).

Jon, *I* write code and consult, et cetera, although presently I can
not call it a living. Unfortunately, most of my eggs were in one basket
whose market sector is trucking. Consultants are usually the first to
be shown the door. While a few of my customers may disagree,
I've never had to stop cheating *them* because I've never started.
Not even the few that actually deserve to be cheated.

I envy you that you "love it" and also "happen to be good enough at it
to also make a living".

Before you make judgements about my personal morals, I suggest
that you get to know me.

Jon, as I said I'm a newbie ... I'm not here to trash anyone.
Thank you for sharing answers to my questions also.

Happy levitating!

Regards,
Gerry (Lowry)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n130rxBC079925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 17:54:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n130rxLU079924; Mon, 2 Feb 2009 17:53:59 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n130rlBw079904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2009 17:53:59 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-93-104-55-149.dynamic.mnet-online.de [93.104.55.149]) by mailgw02.dd24.net (Postfix) with ESMTPA id 307C135558F for ; Tue, 3 Feb 2009 00:53:47 +0000 (GMT)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer
To: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-Ee3mStivzu/ahJV32ijO"
Date: Tue, 03 Feb 2009 01:53:46 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-Ee3mStivzu/ahJV32ijO
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 2009-02-02 at 11:11 -0800, Jon Callas wrote:
> I believe that the problem you're describing is that your connection =20
> to a keyserver is passing through some evil router that rewrites your =20
> connection. Am I right?
Correct.

> Why isn't the solution to this "use SSL/TLS"?
Well it is =3D) ...

I'd just prefer something using OpenPGP for securing the data. It would
be somehow embarrassing to depend on X.509 based SSL/TLS in order to get
OpenPGP keys, wouldn't it ;-)
Of course RFC 5081 is a possible solution.

And I'm not sure if the keyservers (sks) and the OpenPGP clients would
already support SSL/TLS.

Happy wishes,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-Ee3mStivzu/ahJV32ijO
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMzAwNTM0NlowIwYJKoZIhvcNAQkEMRYEFJYvcRJfI3kD65xTkyIoswq95lzOMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
ACJZRkv6C2B5q9ZdvIwPj8DxU++yH51Kv6+cMu5Q84s8DJr82Y6CuNTtyk9rv1Kd0QZ54pIB6pVw
hrJfr2BzzsEEED0YT7fLJO1djTXGWXcgLH7kgitg9/h0aaBi2k73VTqoUTl+g9MGLXmQwSSgoO7K
PeGrCVbMd7cloWi5IlPhaTj7Q51NVTUOYqAgEF0uIURQVPMaF6ATNnaf7GSPsHbN+Z8Ws7bGKxd3
wsmDzbE/+LhKcY5ol/E3c8kcsBPR7DUqcOtaIL9y+b5Pn0SSbiVJ7eQ8lkvWJ+39HIiKUkL7W8s8
ASrurVBDx+AQdsOr52CujCmLassD7iMS4lx0Xl0AAAAAAAA=

--=-Ee3mStivzu/ahJV32ijO--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n130i4AI079564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 17:44:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n130i4nI079563; Mon, 2 Feb 2009 17:44:04 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp12.hushmail.com (smtp12.hushmail.com [65.39.178.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n130hq3x079538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Feb 2009 17:44:03 -0700 (MST) (envelope-from [email-masked])
Received: from smtp12.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp12.hushmail.com (Postfix) with SMTP id B3A73700E0 for ; Tue, 3 Feb 2009 00:43:51 +0000 (UTC)
Received: from smtp.hushmail.com (mailserver6.hushmail.com [65.39.178.56]) by smtp12.hushmail.com (Postfix) with ESMTP for ; Tue, 3 Feb 2009 00:43:51 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 2236B158045; Tue, 3 Feb 2009 00:43:51 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 02 Feb 2009 19:43:50 -0500
To: [email-masked]
Subject: Re: how close is OpenPGP tied to SHA1
From: [email-masked]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <[email-masked]>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, 02 Feb 2009 17:38:00 -0500 Ian G wrote:

>Pole Two is "the one true cipher suite." PGP 2 and so forth. The
>
>notion here is that you design it well, you design it balanced,
>and you
>plan on it lasting at least 10 years. If not 20 or 30. Then, you
>throw
>the whole lot out in 10 years.
>
>For my money, Pole Two delivers much more bang for buck. There
>has
>never been in modern history a complete collapse of a well-
>designed
>suite.

well,
be ready to say goodbye to pgp 2 ;-(

it won't work on 64 bit systems
(even Disastry's last version,
http://www.spywarewarrior.com/uiuc/disastry/263multi.htm
where he compiled 3 different versions, one of which was a 32 bit
version,
but doesn't work on 32 bit system
(not on windows anyway,
if anyone can get it to work on linux, please post, thanx)

the 16 bit version works on a 32 bit system,
but the 32 bit does not work on 64 or even 32 bit windows systems

(unless anyone wants to take a look at Disastry's 32 bit version of
pgp.exe and suggest a patch ...)

otherwise,
i would say that there is a place for 'both' poles,
and while many users would like to be able to use both of them,
it may be too much to try to maintain backward capability with
older systems that aren't being updated anymore

vedaal

any ads or links below this message are added by hushmail without
my endorsement or awareness of the nature of the link

--
Earn your accounting degree online. Free info. Click Now!
http://tagline.hushmail.com/fc/PnY6qxsY9yVITQjiDrgd0TQAhLD9BFnjlvPfUmZM9WuUPShOGKlmz/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Nor3u076835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 16:50:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12NorF0076834; Mon, 2 Feb 2009 16:50:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12NopRw076826 for ; Mon, 2 Feb 2009 16:50:52 -0700 (MST) (envelope-from [email-masked])
Received: by bwz5 with SMTP id 5so1698102bwz.10 for ; Mon, 02 Feb 2009 15:50:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Twr7V7HVkRvMN0JGG4om6CX4QAglhZI9WzM7F6vu7n4=; b=J1ZP5VFnGOGBQPouI9T8+C3umbCIsVmb+lJVa2obbxGorAeFu7dFD5g5bcRSQ4XvtF FM6lGMB9MMJmE6crUfARybjBhroRo1vbo9EQy4UGKfS1dqFFDLR0MwF61jefAaM6MSY0 sECHHBc+Dnp+3umt6nRQLVZinpBtt/Gdukl0w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=nRHFV03CMoF5UU9mXhc/aeYcrFBXrZ1mECCZDBGkO/ivNXXJ4A1/BsBoRVe81CQPxB zNWIxYwt6A2BOKR7fF+FkWTo1xiJUwLRhUYadYhCneL1zCqvQp6mFFsyw3bFZlYytuvT T7s6Rnl1YGuNk4l6S3dDXGkhVry/TMyuuVk9c=
MIME-Version: 1.0
Received: by 10.181.205.9 with SMTP id h9mr1847212bkq.196.1233618649958; Mon, 02 Feb 2009 15:50:49 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Tue, 3 Feb 2009 00:50:49 +0100
Message-ID: <[email-masked]>
Subject: Re: how close is OpenPGP tied to SHA1
From: Peter Thomas
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

If this WG finds a solution to this issue, e.g. by switching
everything to SHA3. What will happen to already existing keys?
I mean would it become necessary to create new keys in order to fully
benefit from the swtich?

Could there be problems with the already existing signatures using
(probably) SHA1 and downgrade attacks or similar things?

Greetings,
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Mtcxo074550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 15:55:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12MtcWD074549; Mon, 2 Feb 2009 15:55:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12MtQtN074536 for ; Mon, 2 Feb 2009 15:55:37 -0700 (MST) (envelope-from [email-masked])
Received: by fg-out-1718.google.com with SMTP id d23so702400fga.26 for ; Mon, 02 Feb 2009 14:55:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=VZgmf1iJzgg0QUZOBV+e3z/n+neFw32WU/ca5gzepbY=; b=RjPZ6W+8cXEGNM6soNPJwJihAf2vJehJSCWPe0l2fmeB8e8t7fxKsVoAnerngOmknf ZCmje8OrHz060clCbHYxCOpbeF4H2BQtoTSp2Qy2tnH75sUn+Fb1JAk7l0gsOoHTiov3 9hCEETDAlB3DpOOEmoNdMjob3ptHo5nL2I6F8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=uvDTkGzf219t1rzGs3T7L3fpUCZnaSX5xfZ33IrQVfwSe5weBH84U1faAzD2NNxS9L DV6s19kbSLW+Cs2bizVsiUN5It4tdnaivb2f7AZUX06awHTheK/wArcPFFVjY6sVxphN 4B5FUlUJIUSzj72v0k/yi2RYJ2UvDR43EdIqw=
MIME-Version: 1.0
Received: by 10.86.4.2 with SMTP id 2mr2539253fgd.49.1233615325536; Mon, 02 Feb 2009 14:55:25 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 2 Feb 2009 22:55:25 +0000
Message-ID: <[email-masked]>
Subject: Re: how close is OpenPGP tied to SHA1
From: David Crick
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, Feb 2, 2009 at 10:38 PM, Ian G wrote:
>
> On 2/2/09 22:43, Peter Thomas wrote:
>>
>> On Mon, Feb 2, 2009 at 4:58 PM, Daniel Kahn Gillmor
>> wrote:
>>>
>>> I think the answer is not to pick a "new, better" hash function for a
>>> revised spec, but to make the spec flexible enough to actually use
>>> whatever "new, better" hash function comes along (and to be able to
>>> deprecate the ones implementors/users feel are untrustworthy).
>>
>> Of course :-)
>
>
>
> There are two poles of thought.
>
> Pole One is "agility" which involves being able to switch between different
> algorithms within packets and protocols. So if an algorithm goes belly up,
> the market migrates by switching over that algorithm.
>
> Pole Two is "the one true cipher suite." PGP 2 and so forth. The notion
> here is that you design it well, you design it balanced, and you plan on it
> lasting at least 10 years. If not 20 or 30. Then, you throw the whole lot
> out in 10 years.
>
> Whether you gravitate around Pole One or Pole Two depends on a whole host of
> factors: economics, business, distributions, compatibility, structure of
> players, law & barriers, engineers & polemicists, cryptoreligion, etc.
>
> For my money, Pole Two delivers much more bang for buck. There has never
> been in modern history a complete collapse of a well-designed suite. But
> there have been huge, monstrous, embarrassing efforts spent and lost in
> maintaining "agile" suites; if the OSS's sabotage manual were updated
> today, it would almost certainly include a section suggesting much attention
> paid to perfect agility.
>
>
>
> iang

or we do a compromise of both approaches:

agility but with a few MUSTs

(of course, this leads to a few backwards-compatibility
overheads / undesirables, such as 3DES ending up as
a MUST with ECC)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12McACW073943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 15:38:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12McAxS073942; Mon, 2 Feb 2009 15:38:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from netscalibur-outbound-smtp03.uk.clara.net (netscalibur-outbound-smtp03.uk.clara.net [213.253.59.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Mc9FF073936 for ; Mon, 2 Feb 2009 15:38:09 -0700 (MST) (envelope-from [email-masked])
Received: from skaro.afraid.org ([212.169.1.61]:37005) by relay03.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.43]:1325) with esmtp id 1LU7Qd-0006kf-Ay (Exim 4.69) (return-path ); Mon, 02 Feb 2009 22:38:07 +0000
Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 1049C5D22; Mon, 2 Feb 2009 22:37:59 +0000 (GMT/BST)
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 23:38:00 +0100
From: Ian G
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
Cc: IETF OpenPGP Working Group
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 2/2/09 22:43, Peter Thomas wrote:
> On Mon, Feb 2, 2009 at 4:58 PM, Daniel Kahn Gillmor
> wrote:
>> I think the answer is not to pick a "new, better" hash function for a
>> revised spec, but to make the spec flexible enough to actually use
>> whatever "new, better" hash function comes along (and to be able to
>> deprecate the ones implementors/users feel are untrustworthy).
>
> Of course :-)

There are two poles of thought.

Pole One is "agility" which involves being able to switch between
different algorithms within packets and protocols. So if an algorithm
goes belly up, the market migrates by switching over that algorithm.

Pole Two is "the one true cipher suite." PGP 2 and so forth. The
notion here is that you design it well, you design it balanced, and you
plan on it lasting at least 10 years. If not 20 or 30. Then, you throw
the whole lot out in 10 years.

Whether you gravitate around Pole One or Pole Two depends on a whole
host of factors: economics, business, distributions, compatibility,
structure of players, law & barriers, engineers & polemicists,
cryptoreligion, etc.

For my money, Pole Two delivers much more bang for buck. There has
never been in modern history a complete collapse of a well-designed
suite. But there have been huge, monstrous, embarrassing efforts spent
and lost in maintaining "agile" suites; if the OSS's sabotage manual
were updated today, it would almost certainly include a section
suggesting much attention paid to perfect agility.

iang

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12MNdZx073307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 15:23:39 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12MNc9x073306; Mon, 2 Feb 2009 15:23:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from netscalibur-outbound-smtp03.uk.clara.net (netscalibur-outbound-smtp03.uk.clara.net [213.253.59.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12MNRkf073300 for ; Mon, 2 Feb 2009 15:23:38 -0700 (MST) (envelope-from [email-masked])
Received: from skaro.afraid.org ([212.169.1.61]:35213) by relay03.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.43]:1325) with esmtp id 1LU7CQ-0002vs-Ab (Exim 4.69) (return-path ); Mon, 02 Feb 2009 22:23:26 +0000
Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 291715D22; Mon, 2 Feb 2009 22:23:19 +0000 (GMT/BST)
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 23:23:20 +0100
From: Ian G
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
Cc: IETF OpenPGP Working Group
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 2/2/09 20:04, Jon Callas wrote:

>> Or even wait for SHA3.
>
> This is likely the best answer.

For this group, it is, I agree.

iang

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12MILIe073117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 15:18:21 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12MIL8p073116; Mon, 2 Feb 2009 15:18:21 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12MIAbI073109 for ; Mon, 2 Feb 2009 15:18:21 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (really [72.190.107.50]) by cdptpa-omta05.mail.rr.com with ESMTP id <20090202221810.JPLP21987.cdptpa-omta05.mail.rr.com@[127.0.0.1]>; Mon, 2 Feb 2009 22:18:10 +0000
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 16:18:07 -0600
From: John Clizbe
Organization: GingerBear Conspiracy Theories To Go
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11
MIME-Version: 1.0
To: Peter Thomas
CC: IETF OpenPGP Working Group
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP:
X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS)
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Thomas wrote:
> Does anyone know the state on SHA3?

"GoogleÃ¢Â„Â¢ Is Your FriendÃ‚Â®"

http://www.google.com/search?q=nist+hash+competition

http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/index.html

"The selection process will take around four years. I've previously called
this sort of thing a cryptographic demolition derby -- last one left
standing wins -- but that's only half true. Certainly all the groups will
spend the next couple of years trying to cryptanalyze each other, but in
the end there will be a bunch of unbroken algorithms; NIST will select one
based on performance and features." -Schneier
http://www.schneier.com/blog/archives/2008/10/the_skein_hash.html

- --
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:[email-masked]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn4907-2008-12-21 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the Â£33Â† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey - http://enigmail.mozdev.org

iJwEAQECAAYFAkmHcR0ACgkQvh+YERi7NzqjwAQAjDFNiAr+xJnIbjWIIh4USxBn
YskbldsTNuVxlnvIZdYnMz59nUP41doshLtbpOjGjP8a+PRlJrA3C8ywqY5yoHp9
8YS2sLCJbTfngRuqQ1jPpI4+r2w27rsjPV0i3ynd9yLkBSOd53btOpLBkonGyszq
PmG4lBygHlVm3zSsrtCIRgQBEQIABgUCSYdxHQAKCRAdBKxKYI0qEG4wAJ48R7W7
3veSUHOGuYMxgda3ZldE6gCfSo9Vw+5lbcbNI5927BpW7DFqePs=
=L1WH
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12M0mHO072345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 15:00:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12M0mZ0072344; Mon, 2 Feb 2009 15:00:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n12M0bxk072334 for ; Mon, 2 Feb 2009 15:00:48 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 63375 invoked from network); 2 Feb 2009 22:00:36 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 2 Feb 2009 22:00:36 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 17:03:20 -0500
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Peter Thomas
CC: IETF OpenPGP Working Group
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF5E4AC2CFFFA3E64EB49407"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDF5E4AC2CFFFA3E64EB49407
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 02/02/2009 04:42 PM, Peter Thomas wrote:
> Does anyone know the state on SHA3?

http://csrc.nist.gov/groups/ST/hash/timeline.html

Note that agencies of the US federal gov't are required to have fully
phased out SHA-1 by the end of 2010:

http://csrc.nist.gov/groups/ST/hash/statement.html

--dkg

--------------enigDF5E4AC2CFFFA3E64EB49407
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSYdtrczS7ZTSFznpAQJccQ//X5Ulc88gVYDi253VC2ZMdP0cZPOMerty
DeYYzjVKpOOqY601ViiUeYDwTmXzTJ8GHp6yRQupCDr5Pp2W1E8U5j9EkMgYIK86
qiX3L/HyfQd+gfNOv73EwErhZjVO/TL5Cx8zmLax5VbmR/o9210g/WYSXDLB59Uc
yNyzrgNB6J4A6cQlDLJQOu6QX0nyGjPDKxKiRQ5v+KcpmXPobtJiFBT2k0unws2e
zfEm0JihKBxRMJMd5uEKiFdiJDuNxRPqdzSXFCn8gTP0gXDazqQFIr75j9pa0JAI
exaQib4V6KvTUpBG9ZKcZa58FetO5Nb3tEtRaaH6wb+HniZv4BZcwezM3cteOMrk
b1AkXo1jBaxdNJ63H5isiQJSF3xzVUas2aXuuGTzBPyX0Hh1kxK5Oy2e0y88LUsj
FC+V42w69x+ZdTkAv41497KeyeuAEohUMNarahSGe+oXoCg7igwBCai0anL1X9xR
K2u4NMwHm7LXif2SpVuRT7lD6X/UmL+n9Zz3XQa6ohNKrxvk4sf1zx1gq5U77Oai
N6yVUudBwD1JwWc25Su4oHnuyX6csH5oj3H4NFBNfET3StXrylcONmURdS6KRgNE
5Og87t0jdDktVKz0tamIHVsSMJhX2NtBEyoxkp5tV45u6HMdB/HfIrYxeNe94ArK
oxD5+aBzoec=
=4o+R
-----END PGP SIGNATURE-----

--------------enigDF5E4AC2CFFFA3E64EB49407--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12LigFl071724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 14:44:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12Lig4v071723; Mon, 2 Feb 2009 14:44:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Liebp071717 for ; Mon, 2 Feb 2009 14:44:41 -0700 (MST) (envelope-from [email-masked])
Received: by bwz5 with SMTP id 5so1647402bwz.10 for ; Mon, 02 Feb 2009 13:44:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xQi9n9uTds+WeKqSkZOd3qHsKtigIg2KB5kT9KyTOcQ=; b=xkwHZM5NNv7Zz/8im+bkHRQo2OSQ09HVvyBBNiP09YhZD6rN/e3CfrxvWrNJOZZTky YyhcwcJMEUW5z2fn3JxWqNtLxlYWaDoef6IWQxZ3bSMo/7ZKkWsIGWpO2UVpOcdOgPtM 2xHBEGWg4pu/2K/Ybh/39asAJ7Tc1j63M8/7o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PhGJIVjaZxXbb5gDGsX3IX72+22KhY8Z4AeQAalCoX93zALGX3rdFh1MF2nVg2vUH0 l+YxScmXlXQ0z67oweuqzvwjOrd4SqzF6MmZ3+Q9OHCNUwIjzEfpB/JleEPp3C08FHdw oz7d36+bdl5lE2w+6us3YuHvfh+5SV6xEKPfk=
MIME-Version: 1.0
Received: by 10.181.209.5 with SMTP id l5mr1818420bkq.86.1233611022879; Mon, 02 Feb 2009 13:43:42 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 2 Feb 2009 22:43:42 +0100
Message-ID: <[email-masked]>
Subject: Re: how close is OpenPGP tied to SHA1
From: Peter Thomas
To: IETF OpenPGP Working Group
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, Feb 2, 2009 at 4:58 PM, Daniel Kahn Gillmor
wrote:
> I think the answer is not to pick a "new, better" hash function for a
> revised spec, but to make the spec flexible enough to actually use
> whatever "new, better" hash function comes along (and to be able to
> deprecate the ones implementors/users feel are untrustworthy).

Of course :-)

Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12LiFhc071696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 14:44:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12LiFQf071695; Mon, 2 Feb 2009 14:44:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Li30I071687 for ; Mon, 2 Feb 2009 14:44:14 -0700 (MST) (envelope-from [email-masked])
Received: by bwz5 with SMTP id 5so1646957bwz.10 for ; Mon, 02 Feb 2009 13:44:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3EvZEWof8Y/OK0qDoYtCsFnhGcZ5+SsST879ojzypC4=; b=a/DZKHPaR1ZxPkgXsk6jDy/4Tzpxh8myKQCvetNLSDsqVWCQncLDXQFTQAe5VgLH4Q GEWoyWw6Zk+t+pep3e8cCf8P84273JjfhP8P7a6P7wyT7k6gFPVyQ2P/fzf2ZC6+3Xg4 t+PfD2Kn2UfgYlYIauA0PrGDrwpyTAirMr7ck=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=s7aLl1ekrWnMos/1L6CeSrz5MlWFnh1lNG+SAPZiZ52z0uYtZiaZpiKZj7G31oz9iO Zq9ul+ESzA50znYTOHDhmBwaD6KyxPJ6qGH0sWL+paLiRFRkWj/Fm+aHMCorrn2m+6+O oc/iwc0A9GlNO7AcdyqnECEQfq/paY3zXnJ+U=
MIME-Version: 1.0
Received: by 10.181.21.2 with SMTP id y2mr1815418bki.144.1233610964168; Mon, 02 Feb 2009 13:42:44 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Mon, 2 Feb 2009 22:42:44 +0100
Message-ID: <[email-masked]>
Subject: Re: how close is OpenPGP tied to SHA1
From: Peter Thomas
To: IETF OpenPGP Working Group
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, Feb 2, 2009 at 8:04 PM, Jon Callas wrote:
>> The first question would be: Are SHA2 algorithms really more secure
>> than SHA1?
> Yes.

Does it protect against the attacks recently found in SHA1?
Or is it "just" better, because the larger hash size?

>> If so one could think to switch for example to SHA512.
>
> You could. This is what most people are doing.

Ok,.. but you cannot fully leave SHA1,.. you can only switch you
signature hash algorithm, as far as I know.
Right?

>> Or even wait for SHA3.
>
> This is likely the best answer.

Does anyone know the state on SHA3?

Best wishes,
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Jc9Xi065474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 12:38:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12Jc9kt065473; Mon, 2 Feb 2009 12:38:09 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Jc8ml065467 for ; Mon, 2 Feb 2009 12:38:09 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 4BE992E08B for ; Mon, 2 Feb 2009 11:39:04 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63289-09 for ; Mon, 2 Feb 2009 11:38:59 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 02B852E089 for ; Mon, 2 Feb 2009 11:38:59 -0800 (PST)
Received: from [192.168.1.121] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 02 Feb 2009 10:39:04 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 02 Feb 2009 10:39:04 -0800
Cc: [email-masked]
Message-Id:
From: Jon Callas
To: Christoph Anton Mitterer
In-Reply-To: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Series of minor questions about OpenPGP 6
Date: Mon, 2 Feb 2009 11:37:54 -0800
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
X-Virus-Scanned: Maia Mailguard
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 6:44 PM, Christoph Anton Mitterer wrote:

> * PGP Signed by an unverified key: 02/01/2009 at 06:44:23 PM
>
> On Fri, 2009-01-30 at 17:02 -0800, Jon Callas wrote:
>>> 3) key expiration time (9)
>>> I've probably asked this before. But, what happens if different key
>>> expiration times are specified in the self-signatures? Is it left to
>>> the implementation to decide what to do?
>> Yes. There are plenty of obvious right things to do. Let's suppose I
>> am moving from example.com to foobar.com next Monday, but I quit
>> example.com effective today (and set an expiration time that reflects
>> that). From now until Monday, neither user name is valid.
> This is a little bit strange, isn't it? Wouldn't one use signature
> expiration times on the User ID self-signatures for such move?

What's the difference?

Key expiration is expressed as a part of the self-signature. Yes, you
could time-limit the self signature and thus when the self-signature
expires you have a UID with no self-signature. But that strikes me as
an eccentric way to do the same thing. The question was not about
signature expirations, it was about key expiry.

>> It makes sense to me to have two preferred keyservers. I don't have
>> an
>> opinion about policy URIs, but I wouldn't discount it automatically
>> out of hand.
> Doesn't the RFC say that only the last subpacket of a give type of the
> same signature must be used? Or was this just a "should"?

I believe that it is guidance not a mandate.

Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJhz3IsTedWZOD3gYRApQOAJ4jpEc6kXSmxJ6XqjPDb7LSDauSHQCdGZ6P
5mScLGI8utg7++gHPgIFHXw=
=BPfz
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12JFoVv063871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 12:15:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12JFoE8063870; Mon, 2 Feb 2009 12:15:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12JFoLh063863 for ; Mon, 2 Feb 2009 12:15:50 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id A8BE92E08A for ; Mon, 2 Feb 2009 11:16:45 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63157-01 for ; Mon, 2 Feb 2009 11:16:42 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 91E622E022 for ; Mon, 2 Feb 2009 11:16:42 -0800 (PST)
Received: from [192.168.1.121] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 02 Feb 2009 10:16:48 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 02 Feb 2009 10:16:48 -0800
Cc: [email-masked]
Message-Id:
From: Jon Callas
To: Peter Thomas
In-Reply-To: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Series of minor questions about OpenPGP 6
Date: Mon, 2 Feb 2009 11:15:42 -0800
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
X-Virus-Scanned: Maia Mailguard
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 1, 2009, at 4:04 PM, Peter Thomas wrote:

>
> Hi Jon,..
>
> Thanks for your answers :-)
>
> On Sat, Jan 31, 2009 at 2:02 AM, Jon Callas wrote:
>>> 5) Is it allowed that more than on subpackets of the same type exist
>>> in the same signature?
>>> E.g. Two policy URIs in on 0x13, or two preferred key servers. And
>>> what would it mean?
>>
>> It makes sense to me to have two preferred keyservers. I don't have
>> an
>> opinion about policy URIs, but I wouldn't discount it automatically
>> out of
>> hand.
> Uhm, may I propose for a future RFC that all this is clarified a
> little bit and perhaps tightened up?
> I think right now the RFC suggests that in case of multiple subpackets
> per signature the last on in the signature takes priority?
> But again that's was just a suggestion if I recall correctly and thus
> may left space for ambiguities.

Why isn't the solution then what the RFC says -- that the last one
takes precedence?

If you find this unsatisfying, then why not start an I-D to clarify?

>
>
>
>> I'm not going to comment further, but only because I'm in a hurry and
>> haven't memorized the hex values.
> If you'd find time to do so later I'd still welcome it :-)
> David made only a few comments (this is definitely not a complaint ;-)
> and I'm still not fully sure how this works, or whether it's
> completely up to the implementation.

I apologize for not having the time to be an RFC lawyer, but if the
RFC says that the last one takes precedence, I think we're done.

Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJhziQsTedWZOD3gYRAleSAJ94MJu1Sew3vfVYcKxAEWAV1lSGLwCdGsI3
oPH7ADrFw5rClkyr3y177pg=
=UmiV
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12JBjCq063521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 12:11:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12JBjWC063520; Mon, 2 Feb 2009 12:11:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12JBird063514 for ; Mon, 2 Feb 2009 12:11:45 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 4878B2E08B for ; Mon, 2 Feb 2009 11:12:40 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63059-05 for ; Mon, 2 Feb 2009 11:12:37 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 8EA2F2E089 for ; Mon, 2 Feb 2009 11:12:37 -0800 (PST)
Received: from [192.168.1.121] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 02 Feb 2009 10:12:43 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 02 Feb 2009 10:12:43 -0800
Cc: [email-masked]
Message-Id: <[email-masked]>
From: Jon Callas
To: Christoph Anton Mitterer
In-Reply-To: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
Date: Mon, 2 Feb 2009 11:11:38 -0800
References: <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
X-Virus-Scanned: Maia Mailguard
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 31, 2009, at 2:54 PM, Christoph Anton Mitterer wrote:

> * PGP Signed by an unverified key: 01/31/2009 at 02:54:48 PM
>
> Hi.
>
> I having the following issue on my OpenPGP "TODO" list for some very
> long time now, and David just remembered me on it.

I do not understand either the problem you're trying to solve or the
solution.

Let's start with a problem description.

I believe that the problem you're describing is that your connection
to a keyserver is passing through some evil router that rewrites your
connection. Am I right?

Why isn't the solution to this "use SSL/TLS"?

Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJhzebsTedWZOD3gYRAq5YAJ9nzgbGAtYEbv6d0BnjfHV7kmchVACgkqWJ
XzLG73TvDATkidZFOnDgbdk=
=ytlY
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12J7FFv063114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 12:07:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12J7FWG063113; Mon, 2 Feb 2009 12:07:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12J7Eeu063105 for ; Mon, 2 Feb 2009 12:07:14 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 5D3142E089 for ; Mon, 2 Feb 2009 11:08:10 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63059-01 for ; Mon, 2 Feb 2009 11:08:04 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 622B52E088 for ; Mon, 2 Feb 2009 11:08:04 -0800 (PST)
Received: from [192.168.1.121] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 02 Feb 2009 10:08:10 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 02 Feb 2009 10:08:10 -0800
Cc: OpenPGP
Message-Id:
From: Jon Callas
To: Christoph Anton Mitterer
In-Reply-To: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Series of minor questions about OpenPGP 4
Date: Mon, 2 Feb 2009 11:07:00 -0800
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
X-Virus-Scanned: Maia Mailguard
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>
> Ok I got your point,.. and the following is probably a little bit
> pedantic and quibbling. The point I was trying to make is:
> As this "use the most recent" is "only" a RECOMMENDS, an
> implementation
> might not follow this advice, and would be still conforming, right?
> As you've said, it's only an advice.

Yes, but if an implementation both does not interoperate and does not
follow a recommendation that would make it interoperate, then while
that implementation is conforming, it has *chosen* not to interoperate.

Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJhzaJsTedWZOD3gYRAsUGAKCGreKNt7vhUcl+8zwM8mPSXQhjjwCgjKO7
z+NhcHug/PFH9Y45/5562mM=
=7H4K
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12J49Du062864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 12:04:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12J494q062863; Mon, 2 Feb 2009 12:04:09 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12J48QE062854 for ; Mon, 2 Feb 2009 12:04:08 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 057262E08B for ; Mon, 2 Feb 2009 11:05:04 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 62814-08 for ; Mon, 2 Feb 2009 11:05:00 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id B08AA2E088 for ; Mon, 2 Feb 2009 11:05:00 -0800 (PST)
Received: from [192.168.1.121] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 02 Feb 2009 10:05:06 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 02 Feb 2009 10:05:06 -0800
Cc: IETF OpenPGP Working Group
Message-Id: <[email-masked]>
From: Jon Callas
To: Peter Thomas
In-Reply-To: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: how close is OpenPGP tied to SHA1
Date: Mon, 2 Feb 2009 11:04:00 -0800
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
X-Virus-Scanned: Maia Mailguard
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 2, 2009, at 5:14 AM, Peter Thomas wrote:

>
> Hi Daniel.
>
> On Mon, Feb 2, 2009 at 2:59 AM, Daniel Kahn Gillmor
> wrote:
>> This was just discussed on the list last month in a thread titled "A
>> review of hash function brittleness in OpenPGP":
> Thanks for that pointer.
>
>> Proposals?
> Well,.. not really ;-)
> The first question would be: Are SHA2 algorithms really more secure
> than SHA1?

Yes.

> If so one could think to switch for example to SHA512.

You could. This is what most people are doing.

> Or even wait for SHA3.

This is likely the best answer.

>
> Or are there any other promising hash functions? Whirlpool?

Whirlpool is in my opinion a 2005 answer, not a 2009 answer. The
problem with Whirlpool is that it's slow, and still not as well
examined as SHA2.

Nonetheless, I've heard tell that someone is working on a Whirlpool I-
D, which isn't a bad thing, but is arguably unneeded presently.

Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJhzXSsTedWZOD3gYRAtnjAJ4jMDgb4Mo8IvmwrDm2/6VoErPDRQCePy0H
iVfu1LkaNDzGbiQG3tJR6Ss=
=45R0
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Ip7Rh061837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 11:51:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12Ip7xT061836; Mon, 2 Feb 2009 11:51:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12IouPd061818 for ; Mon, 2 Feb 2009 11:51:06 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 293652E08A for ; Mon, 2 Feb 2009 10:51:51 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 62712-10 for ; Mon, 2 Feb 2009 10:51:45 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 888042E089 for ; Mon, 2 Feb 2009 10:51:45 -0800 (PST)
Received: from [192.168.1.121] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 02 Feb 2009 09:51:51 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 02 Feb 2009 09:51:51 -0800
From: Jon Callas
To: gerry_lowry (alliston ontario canada)
In-Reply-To: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
Subject: Re: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
X-Priority: 3
References: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
Message-Id: <[email-masked]>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 2 Feb 2009 10:50:09 -0800
Cc:
X-Mailer: Apple Mail (2.930.3)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7BIT
X-Virus-Scanned: Maia Mailguard
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> QUESTION # 1: There seems to currently exist TWO forces in the PGP
> universe:
>
> (a) GPG -- GnuPG (OpenPGP initiative)
> (b) PGP -- PGP Corporation.
>
> To what extent are their goals aligned?
> More specifically, since (b) is a corporation
> which is driven by the profit motive and
> (a) would like to make a reasonable living
> but is likely more open than the average
> corporate culture, it's likely more in the
> interested of (b) to succeed in being
> universal but not too universal, i.e., to some
> degree, (b) could grab more market share
> by being somewhat proprietary.
> OTOH, it's possible AFAIK that (a) could
> not succeed without being 100%
> compatible with (b).

Frankly, this is an insult. The suggestion that because we make a
living at this we must therefore be corrupt ticks me off.

What do *you* do for a living, and when did you stop cheating *your*
customers?

We do this because we think it's a way to make the world a better
place, that we can also make a living at it as well. Hal was one of
the major developers of PGP 2 and was one of the people who risked
going to jail for it. I was still heavily involved in OpenPGP during
the years when it wasn't my job, as well. We are doing this because we
love it. We happen to be good enough at it to also make a living. The
suggestion that because we are making a living we must therefore be
shafting the community says a lot more about your personal morals than
ours.

That doesn't mean we're perfect, it means our hearts are in the right
place. If you think we're doing the community wrong, send me an email
and let me know.

Now then, let me go on to some other things. We think that the GnuPG
guys are friends and allies who make things that we *can't* make.
Ditto for the new library that Ben and Rachel did. We applaud them.
The world needs more OpenPGP, and the best way to get it is to have
more Open Source.

There are differences between GnuPG and PGP, and that's somewhere
between irrelevant and a good thing. As John Clizbe pointed out, the
success of the standard is interoperability. It's actually a good
thing to have two implementations that aren't completely in lock-step,
but have a "friends can disagree" attitude about some things. We also
as a community put that into the standard itself, that there are many
things that gentlepersons can disagree on.

For example, in the days we first created the OpenPGP standard, there
was a lot of debate about symmetric ciphers. Two major ones were CAST5
and Blowfish. To avoid an endless, useless debate about it, they were
both put in. In the post-AES that debate is almost entirely historic.
But PGP didn't implement Blowfish because Phil Zimmermann hates it --
he was a huge CAST5 proponent. His opinion carries on to this day
because no one is screaming for us to put Blowfish in (it's mostly
historic, as I said). When PGP Corporation was formed, we put in
decryption of Blowfish because it aids interoperability and wouldn't
require UI and documentation changes. Odds are, this is probably all
news to you and that shows how well the standard works.

We consider interop bugs to be serious. Whenever we find some rough
edge, you'll likely find me, Hal, David, and Werner huddling in the
back room to figure out what to do. Sometimes that turns into a note
on this list. Sometimes one or the other or both of us fix the
problem. We're friends with common goals and different user bases.

Jon

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFJhzK3sTedWZOD3gYRAqEoAJsEbBkiatdZzdTybmjtrGc5cHiI3gCeNRL0
Y+qFadhwSTy/Lw8C+KH5ipg=
=SVKb
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12FtWpW052180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 08:55:32 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12FtWtk052179; Mon, 2 Feb 2009 08:55:32 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n12FtLjs052163 for ; Mon, 2 Feb 2009 08:55:31 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 58301 invoked from network); 2 Feb 2009 15:55:19 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 2 Feb 2009 15:55:19 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 10:58:04 -0500
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Peter Thomas
CC: IETF OpenPGP Working Group
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig32493423E6B52C862989C50B"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig32493423E6B52C862989C50B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 02/02/2009 08:14 AM, Peter Thomas wrote:
> The first question would be: Are SHA2 algorithms really more secure
> than SHA1? If so one could think to switch for example to SHA512.
> Or even wait for SHA3.
> Or are there any other promising hash functions? Whirlpool?

I think the answer is not to pick a "new, better" hash function for a
revised spec, but to make the spec flexible enough to actually use
whatever "new, better" hash function comes along (and to be able to
deprecate the ones implementors/users feel are untrustworthy).

So for the RFC it's more a question of making sure that everything is
parameterized than it is to say specific things like "no more MD5",
which may rapidly become out-of-date.

--dkg

--------------enig32493423E6B52C862989C50B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSYcYEczS7ZTSFznpAQJ2fg/8CYTStrMAvF20vPJWe9ciUEkkROGcIl+u
8x1Yj0p3facSKZAUuNty8UCeab0D5skMnEXxVF4S6URnN1H4ymLDbzuWV/pEJRld
T4KulDJJqgLhW/KkF84LpEPC//RU5xORTRBXcjn0UVswak0OUEcLdW86e5QYyT+r
ImYBz/J8579qNKvdgX6Tv+kxulvq8x9UMUa/zL8mdTYU1wku5mQo9mdrnuSYAAsT
kF+QmFHwE24LULle94RODNuLbHrH+SqUTRieqMSDYawvjbke9c3ZDWK1TZZULwvA
2irZOnBk4rh/8SQhN18wX8VVHkknCTd8rgpmJLAJO3nLasMGFcceAc9qNeI1nLH1
qe3aB5vOnULTdM8q8WMe3+CiIIvPQXEHn9ssnVpKLCl/BRIs++nQlvI4UW0nlOux
Lj6LecbJgiFHZ65IWTpdtcxL6We4LnQK0TgJnXHb0Uoq1eMzpmsFa9eB48i4u+1K
yfAhuWEe9AsxeByy07xbwA0y+x9VapG5yMR3Gh6yHS90RJYeOMWy4VZ5o7oZT0ry
IG3Kb5yNwzFltFC2hm8LR8MQNKYC56JjmdLZokOv5s212FouFfEPpXPXJGcsxVsd
/OqfMiRdDmH46fXgEP95OXxJbdbJItJMqCQ2AW1B+8XiZc4fr8C7wlHq7tM3ZusI
8l0Ddqod4fk=
=Ibit
-----END PGP SIGNATURE-----

--------------enig32493423E6B52C862989C50B--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12FFo0h049286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 08:15:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12FFoFI049285; Mon, 2 Feb 2009 08:15:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12FFmPC049278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2009 08:15:49 -0700 (MST) (envelope-from [email-masked])
Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n12FFmiq021805 for ; Mon, 2 Feb 2009 10:15:48 -0500
Message-Id:
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Series of minor questions about OpenPGP 6
Date: Mon, 2 Feb 2009 10:15:47 -0500
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Feb 2, 2009, at 9:54 AM, Christoph Anton Mitterer wrote:

> On Sun, 2009-02-01 at 22:23 -0500, David Shaw wrote:
>> For example you can certainly have multiple keyservers: there are
>> multiple places to store a key.
> I've tried this with gpg, but at least it seems that you can only
> set one keyserver.
> Would it parse and query more keyservers if they'd be set in the
> subpackets?

Nope. There are places where multiple subpackets are reasonable.
That doesn't mean that a given implementation will actually act on them.

If you want a better example, look at designated revoker subpackets.
GPG will only generate a single designated revoker subpacket per
signature. If, however, there are multiple designated revoker
subpackets in a given 0x1F, GPG will act on all of them. This implies
properly handling the "sensitive" flag in the designated revoker as
well, and dealing with the potential conflict when one revoker is
sensitive and one is not, but they are located on the same subpacket
so they cannot be separated.

David

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Esfjp047572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 07:54:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12EsfFK047571; Mon, 2 Feb 2009 07:54:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Esdpa047563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2009 07:54:40 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-62-216-211-227.dynamic.mnet-online.de [62.216.211.227]) by mailgw02.dd24.net (Postfix) with ESMTPA id 5FA4A35436A for ; Mon, 2 Feb 2009 14:54:38 +0000 (GMT)
Subject: Re: Series of minor questions about OpenPGP 6
From: Christoph Anton Mitterer
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-YUoRB6A/cWXkz/QAqwxn"
Date: Mon, 02 Feb 2009 15:54:37 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-YUoRB6A/cWXkz/QAqwxn
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 2009-02-01 at 22:23 -0500, David Shaw wrote:=20
> For example you can certainly have multiple keyservers: there are =20
> multiple places to store a key.
I've tried this with gpg, but at least it seems that you can only set one k=
eyserver.
Would it parse and query more keyservers if they'd be set in the subpackets=
?

Bye
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-YUoRB6A/cWXkz/QAqwxn
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMjE0NTQzNVowIwYJKoZIhvcNAQkEMRYEFGIffYQS45foSq5KkpM+GDdQOYlhMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
ADEkZuJ02BEyIlTB4QwQtvzPcXDHdbyfIQaMy8wuXbQXJPtqInOvh9vKpZqpy2FlTvMyf40dw4eo
H4vSS2cNQX3XWDZnWseWbOS3owU4xMtH9fX4B/psdHEva/+W94wYN/NA5ppmjI9PNeNLhkdzPkPA
4O9IfkkMtmXCfGJKufRwIwaVLvaVaAlgHY2pqu3eVJqtBAJbUYIsb9euWxPAWMydmTvBjrXPPiOe
vMGeO4fedXDOMEJi6HFbgp0fhPBWzB6mXt2g0QgTzJMITlksrhYo5tu5PZXXg7djMKknQm0OfQnj
CLO5GwnLtC9gbvib5hPfZhz9gA8z5PsrzS3FnzwAAAAAAAA=

--=-YUoRB6A/cWXkz/QAqwxn--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Ejmbq047110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 07:45:48 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12Ejm6c047109; Mon, 2 Feb 2009 07:45:48 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Ejal5047091 for ; Mon, 2 Feb 2009 07:45:47 -0700 (MST) (envelope-from [email-masked])
Received: by fxm13 with SMTP id 13so1628592fxm.10 for ; Mon, 02 Feb 2009 06:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iA3Jw8kJvISuQnZFJAbIUBWuLYa5NgIW+PhOGZH49qQ=; b=Ksk5t9QXYhm1gSwHgjIkXQgzOdUX+50JsAxnU4XNWu2b74RFa1k92YASjd6yS60sr5 8eNxN02dC06Tila2+xdbN95uU4PjUedrUsmsYpHMzyEm3EslmMvYmZIta/LzB2qKBXYt ZWZtLWrNQL1f+uwme3kBPJ5dre5dtjDNwEtnM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Df1MyBCuiWR9AJZGR3uqfqrUSY4+L9fKHknvjn6pdM/BW3Xu5t1emQxKhfvjSk7VzP kMcIs/xfuV8sx2RylyoSkRw7YDySm4O6xTTNx1yddsPgwUsh8D6LJKHvL4E06N4rnw0o XptYzm0612svbrm+A+70/G9cXkHjXwkPWKphg=
MIME-Version: 1.0
Received: by 10.181.33.8 with SMTP id l8mr1693790bkj.155.1233585935238; Mon, 02 Feb 2009 06:45:35 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]>
Date: Mon, 2 Feb 2009 15:45:35 +0100
Message-ID: <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 6
From: Peter Thomas
To: IETF OpenPGP Working Group
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Mon, Feb 2, 2009 at 4:12 AM, David Shaw wrote:
> Many of the questions you are asking are of that sort, hence the difficulty
> answering them. At one point, there was discussion about writing a second
> document to cover these sorts of questions. Possibly it is time to restart
> that.
Yes I see, and fully understand ;-)
I hope I didn't get to much on your nerves,... but I think it showed
that there's really an interest in such kind of a document :-)

> The
> RFC also doesn't stop you from doing foolish things (which is a feature, not
> a bug).
Well I'm not sure about this ;-)
>From a cryptosystem I'd expect that nearly everything is as strictly
defined as possible, in order to avoid ambiguities or conflicts
between implementations, which could lead to security issues.
But of course this is just my opinion, and it's not my intention to
offend the way it's handled right now :)

> I would advise against changing the expiration time of the key depending on
> how it is selected. A key should have one expiration time, or you're in for
> a lot of pain when a user sending to one user ID sees the key as expired,
> but a user sending to a different user ID on the same key does not. If that
> is the goal, you should be expiring the user IDs differently. Not the key.
Of course,.. but this is just the problem I want to show. An
implementation could call itself conforming to the RFC (and actually
it would be), but it could do all these stupid an bad things.

> The shorter answer is that GPG will take an expiration, a revocation key
> ("designated revoker"), or key flags from an 0x1F.
Thanks.

Thanks,
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12EaNHl046570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 07:36:23 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12EaNP0046569; Mon, 2 Feb 2009 07:36:23 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12EaCTO046554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2009 07:36:23 -0700 (MST) (envelope-from [email-masked])
Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n12EaB60021475 for ; Mon, 2 Feb 2009 09:36:11 -0500
Message-Id: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
Date: Mon, 2 Feb 2009 09:36:11 -0500
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Feb 2, 2009, at 7:56 AM, Christoph Anton Mitterer wrote:

> On Sun, 2009-02-01 at 22:33 -0500, David Shaw wrote:
>> There are other ways to store keys. There is even an RFC (4398) for
>> storing OpenPGP keys in DNS.
> Hey this is really nice,... I wasn't aware of it =)

It's pretty interesting. GPG supports it (both in the "PGP" variant
where the whole key is stored in a very large DNS blob, and in the
more useful "IPGP" variant where the DNS returns a URL pointing to the
regular key) but I don't think it gets particularly wide use. Not all
that many people control their own DNS, so that's an additional
barrier on top of all of the usual barriers.

One thing that DNS is very good for is fast, lightweight, queries.
You could see how building something like a revocation server would be
ideal over DNS: revocations are small, and the queries over DNS are
fast and cheap.

David

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12DErjr040109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 06:14:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12DErE5040108; Mon, 2 Feb 2009 06:14:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12DEgYX040091 for ; Mon, 2 Feb 2009 06:14:53 -0700 (MST) (envelope-from [email-masked])
Received: by bwz5 with SMTP id 5so1333681bwz.10 for ; Mon, 02 Feb 2009 05:14:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=MCWftUHyvIwbm7ZhOhXIV1tgQET7YxkleiUx2ed11x0=; b=aOpxPm+MPzmtZNWs3A+ENJ1A03dqblK/5VbTu05SbKMDl1h/q/ZgjZ7/jIffxcs1Bi HSAtcJ87ypsItifgBOXMBYnozgRFpNXIfd1LlIIN/oFn6J9BV+k0O4begjVuoLRAeVVe FbpDNxP5Sa8hRFu7DYf01CtZ7L/BQD1FcyXaM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mLdUuqfCE4y2FCAjkrrkGTPGCecMiN6VYqzMcJVIDjytHIviQCNxkIYCnGSkSIZcpc URffjbieVH3K/YE74A0nRwNny38pR+VTg4ZTczZk2KgXSu/EZ7uv3AiRUFRN3EboxVLw kZAhtjrS2MtSvSzKjcL8OKmpwDDH+UNl0NiQc=
MIME-Version: 1.0
Received: by 10.181.226.19 with SMTP id d19mr507074bkr.38.1233580480139; Mon, 02 Feb 2009 05:14:40 -0800 (PST)
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Date: Mon, 2 Feb 2009 14:14:40 +0100
Message-ID: <[email-masked]>
Subject: Re: how close is OpenPGP tied to SHA1
From: Peter Thomas
To: IETF OpenPGP Working Group
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Daniel.

On Mon, Feb 2, 2009 at 2:59 AM, Daniel Kahn Gillmor
wrote:
> This was just discussed on the list last month in a thread titled "A
> review of hash function brittleness in OpenPGP":
Thanks for that pointer.

> Proposals?
Well,.. not really ;-)
The first question would be: Are SHA2 algorithms really more secure
than SHA1? If so one could think to switch for example to SHA512.
Or even wait for SHA3.
Or are there any other promising hash functions? Whirlpool?

Greetings,
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12Cv6cu039161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 05:57:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12Cv6FI039160; Mon, 2 Feb 2009 05:57:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12CusjZ039143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2009 05:57:05 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-62-216-211-227.dynamic.mnet-online.de [62.216.211.227]) by mailgw01.dd24.net (Postfix) with ESMTPA id AE3FF7CC364 for ; Mon, 2 Feb 2009 12:56:53 +0000 (GMT)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer
To: IETF OpenPGP Working Group
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-j7d8B53J1gDrYAqCnyNZ"
Date: Mon, 02 Feb 2009 13:56:52 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-j7d8B53J1gDrYAqCnyNZ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 2009-02-01 at 22:33 -0500, David Shaw wrote:
> There are other ways to store keys. There is even an RFC (4398) for =20
> storing OpenPGP keys in DNS.
Hey this is really nice,... I wasn't aware of it =3D)

Thanks,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-j7d8B53J1gDrYAqCnyNZ
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMjEyNTY1MlowIwYJKoZIhvcNAQkEMRYEFL7tqlF3CDsC7JJpJmLmWV/R9VM+MGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AEOtvpJp/0z0GAREC6MbmMdpocZsC7IFpBBJEYEy4ehXUJCIxaaqGlR+Sg7GTlcbNDYBC4Wa2PG5
fBzt8wT87syO8R8e0iH7R+8BYD4rs/Etlc8U1jSD0bvtl5uLk98Ez6P5ujssTD0KTZYDJsuAcSuQ
WSdiZn/29eVhsd2lDHgboH0OlL5k8F96epNEW59N8ltfIXvVN60mis37+oh79iespflmZeEVutZO
skqRSmVRS+izz5E5mTYWCTwIWQD5CENUrEM7fOJYU9ggik9GOssQ+MWaoqO2dWUV+0Nw8MEdAmI4
MoFKv8qtmc5wKW2N/S/J2atzaOMK+N7y1uasgAgAAAAAAAA=

--=-j7d8B53J1gDrYAqCnyNZ--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12CpbkV038859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 05:51:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12CpbG0038858; Mon, 2 Feb 2009 05:51:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12CpOwW038850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Feb 2009 05:51:36 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-62-216-211-227.dynamic.mnet-online.de [62.216.211.227]) by mailgw02.dd24.net (Postfix) with ESMTPA id C34A2355570 for ; Mon, 2 Feb 2009 12:51:23 +0000 (GMT)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-hpL7YNd5fUV8zzWYfDs9"
Date: Mon, 02 Feb 2009 13:51:22 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-hpL7YNd5fUV8zzWYfDs9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 2009-02-01 at 21:19 -0600, John Clizbe wrote:
> PKS, SKS, LDAP, ONAK, OpenPKSD, CKS are the keyserver implementations I k=
now of.
Ok I kenw about LDAP and OpenPKSD,... but I thought the later was
dead,... last entry on their website seems to be from 2005.

Regards,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-hpL7YNd5fUV8zzWYfDs9
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMjEyNTEyMFowIwYJKoZIhvcNAQkEMRYEFGHm6vD0c0+FMtEkKfIc98GYBwXBMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AC9tIGrBv4Z+tqBTYLN9v4nJ07JhZ3V4WACnerjXkrqt/J5k+qMsj0QmvRO0jkaLgPsig8DR9QRT
J7ogvOh66LYMIR7GPoploUmFUFeNbMyKRZSfDAimwGgZvQEUnkVwiVsx26CaRrBaT/im68nFz0U2
zxq7D12r7SwM92ohirKGRfQuRzzt/s65t5FLFNhlOTKf6jaHJX0JoOKD5RonQ5HyNq/45n1VNooY
dxc70CTSN1ZKS0VsPJW9FEq9WPKqsv2czDVWk2SQ+pBWLbc6YwP9xN0KIR578Id434PmVj4I9VZa
vs06thdy5qA981xvtNiAy1RSyBu1K3eUKRMTqTgAAAAAAAA=

--=-hpL7YNd5fUV8zzWYfDs9--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12C0ZrO036462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Feb 2009 05:00:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n12C0ZMM036461; Mon, 2 Feb 2009 05:00:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from netscalibur-outbound-smtp05.uk.clara.net (netscalibur-outbound-smtp05.uk.clara.net [213.253.59.86]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n12C0NLL036450 for ; Mon, 2 Feb 2009 05:00:34 -0700 (MST) (envelope-from [email-masked])
Received: from skaro.afraid.org ([212.169.1.61]:57996) by relay05.mail.eu.clara.net (smtp-vh.dircon.co.uk [213.253.3.45]:1325) with esmtp id 1LTxTR-0007Z5-J7 (Exim 4.69) (return-path ); Mon, 02 Feb 2009 12:00:22 +0000
Received: from viento.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id E7A175D22; Mon, 2 Feb 2009 12:00:14 +0000 (GMT/BST)
Message-ID: <[email-masked]>
Date: Mon, 02 Feb 2009 13:00:16 +0100
From: Ian G
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Cc: Peter Thomas
Subject: Re: Series of minor questions about OpenPGP 4
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On 1/2/09 21:55, Daniel Kahn Gillmor wrote:

> Hrm, thinking about this now, i'm not sure why it would necessarily need
> to be machine-readable. I think i was thinking that there would be ways
> to mechanize your interpretations of various signatures based on the
> policy decisions.
>
> This would require some good work sorting out common policies that could
> then be referred to by URL, sort of like how Creative Commons has sorted
> out some common licensing arrangements which can be identified by URL:
>
> http://creativecommons.org/licenses/by-sa/3.0
>
> uniquely identifies a well-known license, and people are building tools
> to automatically assemble indexes of content that's been licensed that way.

Yes, that works because the tech supports the document, which is primary
and the rest is secondary.

However if you look at it from the OpenPGP context, the tech now has to
support more things; a signature, a document and a "CPS" or statement
of legal semantics. This starts to get complex. For example, if a
signature over a document has a complicated meaning, dependent on a CPS,
and the CPS disappears from view after a few years, the tech will have
trouble explaining it to the reader.

For a view of how this was addressed in machine-readable financial
contracts, have a look at the Ricardian Contract. It basically
re-combined the three elements back into one document. Any "CPS" was
within the document or left unsaid, as were all the keys, and the
clear-text OpenPGP signature was used. We called this the rule of one
document.

> If a group did the same type of work for certification policies that CC
> has done in regard to content licensing, then you could begin to build
> similar sorts of tools to interpret human-centered policy preferences
> through the web of trust.
>
> This is a more ambitious project, though, and you're right to question
> the need for every policy to be machine-interpretable.

It's also about other disciplines, so one should be careful to bring in
the elements of those disciplines that can be trusted to understand and
help the project. One of the reasons CC succeeds is that it was done by
lawyers from universities copying a thing called open source. One of
the reasons CPSs "failed" or turned out to do something other than what
"we expected" was that they weren't done that way.

iang

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1251c8q020519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 22:01:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1251c5M020518; Sun, 1 Feb 2009 22:01:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1251Ra2020512 for ; Sun, 1 Feb 2009 22:01:37 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (really [72.190.107.50]) by cdptpa-omta01.mail.rr.com with ESMTP id <20090202050126.ECGC6485.cdptpa-omta01.mail.rr.com@[127.0.0.1]>; Mon, 2 Feb 2009 05:01:26 +0000
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 23:01:22 -0600
From: John Clizbe
Organization: GingerBear Conspiracy Theories To Go
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11
MIME-Version: 1.0
To: IETF OpenPGP Working Group
CC: Gerry Lowry
Subject: Re: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
References: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
In-Reply-To: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
X-Enigmail-Version: 0.95.7
OpenPGP:
X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS)
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gerry_lowry (alliston ontario canada) wrote:
> Hello,
>
> I'm calling myself a "newbie" with regards to PGP/GPG even though I've
> through my own ignorance and incompetence orphaned keys back as far as
> September 1997. One day my brain may, if I am lucky, reconnect with their
> corresponding passphrases so that I can revoke them. I'm guessing there is a
> very large number of orphaned keys in the PGP universe.
>
> I've read about PGP in Chey Cobb's "Cryptography for Dummies" and PGP/GPG in
> Michael W. Lucas' "PGP & GPG: email for the practical paranoid". Also, I've
> used gnupg.pdf as a reference but have yet to digest all of its 148 pages.

I remember Cobb's book as being more weighted to X.509 and PKCS. Not read Lucas,
so I can't comment on it other than I recall it having a cover blurb by Len
Sassaman, who also posts here. I guess gnupg.pdf is fine if the v2.0
specifics are filtered out.

> I live under the cloud of the virus a.k.a. Windows [XP, Vista, Server 2003,
> Server 2008].

At one time, 70-75% of Enigmail downloads were Windows users.

I'm not one for Windows-bashing - I consider it "So-o-o-o-o-o Last Century" ;-)

> gpg (GnuPG) 1.4.9
> Supported algorithms:
> Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
> Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
> AES256 (S9), TWOFISH (S10)
> Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
> SHA512 (H10), SHA224 (H11)
> Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)
>
> Although there are GUI environments available, for the present, I am sticking
> with GnuPG and its various command line tools until I understand them
> sufficiently to warrant investigating GUI tools. The former MIT GUI
> distribution never integrated very well with Outlook Express, at least,
> that was my experience. This is a second reason why I prefer command line
> tools.

You're missing out on some good work and the chance to help push that work
by submitting user feedback.

The GPGshell front-end to GnuPG seems to be preferred by folks moving over from
or familiar with PGP Desktop.

Are you only interested in integration with OE? The PGP plugin, as I recall,
worked well with both Outlook and OE (PGP 8.1). GnuPG integration with Outlook
2003 is possible with the GPGol plugin bundled in GPG4Win. If switching mail
clients is an option, Thunderbird+Enigmail & GnuPG may work well for you (but
I'm biased).

> QUESTION # 1: There seems to currently exist TWO forces in the PGP universe:
>
> (a) GPG -- GnuPG (OpenPGP initiative)
> (b) PGP -- PGP Corporation.
>
> To what extent are their goals aligned? More specifically, since (b) is a
> corporation which is driven by the profit motive and (a) would like to make a
> reasonable living but is likely more open than the average corporate culture,
> it's likely more in the interested of (b) to succeed in being universal but not
> too universal, i.e., to some degree, (b) could grab more market share by being
> somewhat proprietary. OTOH, it's possible AFAIK that (a) could not succeed
> without being 100% compatible with (b).

Two _major_ forces. I think there are something around fifteen different
implementations of the OpenPGP RFC. GnuPG and PGP just seem to have the largest
share of user awareness.

GnuPG succeeds quite well without being 100% compatible with PGP, and vice
versa. They each have differences.

An implementation is only required to implement the MUST portions of the
standard. What optional features or extensions they package is their choice.

> QUESTION # 2: I have looked at http://www.biglumber.com/ ...
> http://biglumber.com/x/web?va=1: "Total of 3190 listings (3107 people [442
> with images], 83 events) in 79 countries and 1144 cities."
> 613 listings are expired; even if the 613 listings are NOT part of the 3190
> listings, "biglumber" is not very much in use. http://pgp.mit.edu/ has been
> around for many years. It's possibly a better indicator of how many keys
> their are ... sadly, it does not appear to offer much in the way of
> statistics.

2662848 on the SKS keyservers as of 14:45 today (1-Feb-2009 US/Central)

Sadly, the server code on pgp.mit.edu is way out of date. I don't believe it is
even being maintained. The PKS code is known to behave badly with certain
features of newer V4 keys. I've never heard that this was reliably fixed - some
servers were patched to not do damage, but I don't believe the patches were
well-distributed.

> OTOH, I almost never receive even PGP signed e-mails. I spoke
> with a senior I.T. person recently who was not even aware of PGP technology.

I'm never surprised by what Sr IT folks don't know. Never. Ever.

> To what extent is GPG/PGP technology being used by e-mail users?
> I'm guessing it must be less than 1% based on the many 1000's of
> e-mails that I have received each month over the last decade.

A friend just posted this anecdote a couple days ago to the [GnuPG-Users] list:
+> At last year's USENIX, in a panel discussion, Dan Wallach of Rice
+> declared Enigmail the best thing going in terms of OpenPGP integration.
+> That's high praise coming from a very well-respected guy in computer
+> security.
+>
+> This was said as part of a sidebar he made about the difficulty in
+> getting 30+ Ph.Ds in computer science to all use PGP for a particular
+> mailing list. Some were using Evolution, some were using ancient PGP,
+> some were using modern PGP, some were using plugins, others were C&Ping
+> into a Microsoft Word document then using some weird Word PGP plugin,
+> some were using Enigmail, etc. He capped it off with an exasperated
+> sigh, then recommended Enigmail to people who needed OpenPGP
+> integration, as Enigmail gave the least troubles.

If CS professors with interest in computer security can't get OpenPGP working
within their own group, what do _you_ think are the chances for the "Average User"?

> I'll have more questions and I hope comments that you'll find useful later.

Could you please format them in a more friendly manner. Most folks seem to limit
line lengths to < 80 characters. It was a bit of a chore to rewrap your message.

You may also find the GnuPG-Users list (gnupg-users[AT]gnupg.org) and the Yahoo!
PGP-Basics group (PGP-Basics[AT]yahoogroups.com) helpful. In fact, both of those
are probably great places to continue this discussion.

> Thank you for your opinions.

Thank you for your questions.

- --
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:[email-masked]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn4907-2008-12-21 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the £33† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey - http://enigmail.mozdev.org

iJwEAQECAAYFAkmGfh8ACgkQvh+YERi7NzqlFQP/RnpMd+EWwCV8iVfFZrwNmJGD
lV3HUSNE5htUCuCgWRkZnb/A8a3bd9obo6Cnn8T9h+eaK8qZ40mBbva+VkUrDvd/
yf7fz117I4eqz+e9hxnsmUxkX+/s79DTZ5HMNvuAKoc8avZiSdpheNoQB7sFnFj6
AT+mAsLfIGMxaRz7yLWIRgQBEQIABgUCSYZ+HwAKCRAdBKxKYI0qEDPmAJ4pD9zR
dEhyjUEDk8X9C3S6au42uwCgxEfC8f498iAzRnDeihb5FBdCgz0=
=MeVo
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123Xlhu017743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 20:33:47 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n123XlZt017742; Sun, 1 Feb 2009 20:33:47 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123XjbW017736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 20:33:46 -0700 (MST) (envelope-from [email-masked])
Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n123XiI2016683 for ; Sun, 1 Feb 2009 22:33:44 -0500
Message-Id:
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
Date: Sun, 1 Feb 2009 22:33:44 -0500
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Feb 1, 2009, at 9:44 PM, Christoph Anton Mitterer wrote:

> Hi John.
>
>
> On Sun, 2009-02-01 at 19:37 -0600, John Clizbe wrote:
>> sks-devel[AT]nongnu.org
>>
>> Yaron Minsky did the development work, but doesn't have time for
>> new development
>> only maintenance.
> Thanks for that info :-)
>
> Hmm,.. what are our main keyserver implementations? sks and pks are
> the only ones I know about...

PKS is dead at this point. It more or less works, but cannot handle
keys with more than one subkey, or are uncommon in some ways.

SKS replaces PKS. It speaks the same access protocol as PKS (called
"HKP" - it's basically a subset of HTTP, so you can use any handy HTTP
software to access a keyserver), so any software written to talk to
PKS can talk to SKS without changes.

The other protocols that are commonly used are HTTP (just fetching a
regular file on a regular web server), and LDAP. LDAP is particularly
well suited for keyservers, as what is a keyserver if not a
directory? The PGP folks developed a LDAP schema that both PGP and
GPG use when talking to a LDAP server.

There are other ways to store keys. There is even an RFC (4398) for
storing OpenPGP keys in DNS.

David

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123N5jU017438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 20:23:05 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n123N5go017437; Sun, 1 Feb 2009 20:23:05 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123N4xA017431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 20:23:05 -0700 (MST) (envelope-from [email-masked])
Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n123N3ba016614; Sun, 1 Feb 2009 22:23:03 -0500
Message-Id: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group , Christoph Anton Mitterer
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Series of minor questions about OpenPGP 6
Date: Sun, 1 Feb 2009 22:23:02 -0500
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Feb 1, 2009, at 9:44 PM, Christoph Anton Mitterer wrote:

>>> 4) exportable certification (4)
>>> Does this have a meaning on subkey binding signatures (0x18)? E.g.
>>> something like don't import the signature itself and neither the
>>> subkey?
>> I have applications for this, myself. Yes.
> Uhm @David (if you read this), does gnupg support creating non
> exportable subkey binding signatures? And if so I assume that it
> doesn't
> export the subkey either?!

No, it does not support this. I like Jon's idea though. It's a
clever way to special-case a particular subkey.

>> It makes sense to me to have two preferred keyservers. I don't have
>> an
>> opinion about policy URIs, but I wouldn't discount it automatically
>> out of hand.
> Doesn't the RFC say that only the last subpacket of a give type of the
> same signature must be used? Or was this just a "should"?

No. This is only in case of conflict. The RFC has a lot of language
(in section 5.2.4.1) about how people should not automatically take
the last subpacket without thinking. Having multiples of certain
subpackets is correct and reasonable, and does not imply conflict.
For example you can certainly have multiple keyservers: there are
multiple places to store a key.

David

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123JPji017138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 20:19:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n123JPow017137; Sun, 1 Feb 2009 20:19:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123JOwb017130 for ; Sun, 1 Feb 2009 20:19:24 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (really [72.190.107.50]) by cdptpa-omta01.mail.rr.com with ESMTP id <20090202031924.CSNI6485.cdptpa-omta01.mail.rr.com@[127.0.0.1]> for ; Mon, 2 Feb 2009 03:19:24 +0000
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 21:19:23 -0600
From: John Clizbe
Organization: GingerBear Conspiracy Theories To Go
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP:
X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS)
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Anton Mitterer wrote:

> Hmm,.. what are our main keyserver implementations? sks and pks are the only
> ones I know about...

PKS, SKS, LDAP, ONAK, OpenPKSD, CKS are the keyserver implementations I know of.

PKS used to be dominant, but I believe SKS now is. Many of the old PKS servers
have moved to SKS or gone offline.

- --
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:[email-masked]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn4907-2008-12-21 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the Â£33Â† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey - http://enigmail.mozdev.org

iJwEAQECAAYFAkmGZjkACgkQvh+YERi7Nzog4QQA0CHUmMvaPKQ+hesqQT2UeiRq
Jm9NckngsyTlUCtf0wV56WQF/I0DMQEHsW4MbwVSZzEdWp9AJ29RHkMOgcBkm9Pu
45L+svgnaMr+y6zdYYHn3z2T37A+3gupS7W5v9oPCkhplCWpZxtyGBIl5G4V0805
3jqCeob/hmcsHSXe4XaIRgQBEQIABgUCSYZmOQAKCRAdBKxKYI0qEGYiAKD0+Hnz
LGVPuFSk3tOIY1nJYzIFHwCfbuLSKDs0BVYhz0f/dLseuhuSZrE=
=OYB+
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123CGMg016791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 20:12:16 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n123CG0S016790; Sun, 1 Feb 2009 20:12:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n123C45h016757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 20:12:15 -0700 (MST) (envelope-from [email-masked])
Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n123C4ef016543 for ; Sun, 1 Feb 2009 22:12:04 -0500
Message-Id:
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Series of minor questions about OpenPGP 6
Date: Sun, 1 Feb 2009 22:12:04 -0500
References: <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.930.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Feb 1, 2009, at 7:25 PM, Peter Thomas wrote:

> On Sat, Jan 31, 2009 at 5:04 AM, David Shaw
> wrote:
>> Use the shortest expiration time. If the 0x1F says you have 10
>> days, and
>> the 0x13 says you have 5 days, you have 5 days.
> Ok,.. but basically this means,... it's left to the implementation by
> the RFC, as Jon said, right?

Yes. A lot of the problem and confusion that seems to be coming out
of this thread is that people expect the RFC to specify everything
about OpenPGP semantics.

RFC-4880 (like 2440 before it) is really a format document. Even the
title is telling: "OpenPGP Message Format". The document contains
enough information to understand the message format, and a lot of the
semantics follows directly from that, but you won't really find a lot
of these "what happens if" sort of answers there. It's not that the
OpenPGP community doesn't have an answer for them (the existence of
multiple interoperating implementations shows that), but there is no
RFC that can be pointed to.

Many of the questions you are asking are of that sort, hence the
difficulty answering them. At one point, there was discussion about
writing a second document to cover these sorts of questions. Possibly
it is time to restart that.

Note that the answers I'm giving you are what implementations do, or
what I would advise if someone wanted to do something different. This
is always within the scope what the RFC requires/allows, but may not
be specifically mandated behavior. In other words, it's RFC-4880
compliant, but another implementation could do something else and also
be RFC-4880 compliant. The RFC also doesn't stop you from doing
foolish things (which is a feature, not a bug).

> So an implementation could also use the key expiration of the 0x1F
> when the key was selected via key ID for example,.. or one of my other
> examples from above.

I would advise against changing the expiration time of the key
depending on how it is selected. A key should have one expiration
time, or you're in for a lot of pain when a user sending to one user
ID sees the key as expired, but a user sending to a different user ID
on the same key does not. If that is the goal, you should be expiring
the user IDs differently. Not the key.

> But in any case,... if the selected expiration time is reached,.. the
> WHOLE key is expired, right?

If you are expiring the whole key, then the whole key - all user IDs,
all subkeys go with it.

>> If you have preferred algorithms in both the 0x1F and a 0x13, then
>> you use
>> the one with the narrowest scope. So, if the key was chosen by a
>> particular
>> user ID, you use the preferred algorithms from that user ID's
>> selfsig. If
>> that selfsig does not have preferred algorithms, use the one in the
>> 0x1F.
>> If the key was chosen by key ID (so there is no one particular user
>> ID) you
>> use the preferred algorithm from the primary user ID. As before,
>> if there
>> is no preferred algorithm there, use the one from the 0x1F. If
>> there is
>> preferred algorithms on a 0x18, I think I'd take the union of those
>> algorithms with the ones from the user ID or 0x1F.
> Ok but again,.. this handling is _not_ enforced by the RFC, and an
> implementation could also choose to do it by one of my examples,
> right? Of course what you've explained here above is probably the most
> reasonable :-)

Yes.

> Does gnupg do it like that? I mean that you can set kind of a "global"
> default via the 0x1F, expect you re-set it on the 0x13s?

No. GPG ignores preferences on a 0x1F. In practice, no
implementation generates 0x1F signatures for anything other than
designated revokers.

>>> - key server preferences / preferred key server / key flags /
>>> features
> For them it's also up to the implementation right?
> Where can I find how gnupg would choose if I'd have them
> a) only in the 0x1F but not the 0x13s
> b) in both
>
> "Read the sources!"?! xD

Sure: you want the getkey.c file, in the merge_selfsigs_main() function.

The shorter answer is that GPG will take an expiration, a revocation
key ("designated revoker"), or key flags from an 0x1F.

>>> II) Subpackets on any of the 0x10-0x13 certification signatures:
>>> III) Subpackets on the 0x18 subkey binding signature:
> Were my assumptions here correct?
>
> Does it make any sense to have keyserverprefs/preferred
> keyserver/features on 0x18 subkey binding signatures?

Features, maybe, but we don't currently have any flags that would be
relevant for subkeys. In any event, not all of the possible
subpackets are meaningful in all possible signature types.

> Can anyone here of an example or a semantical meaning, that a
> self-signature is a trust-signature?

By definition a self-signature is ultimate trust ("this is me, and I
trust myself always"). A trust signature is a way of limiting trust,
which is not appropriate for a self-signature.

David

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n122iboU015534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 19:44:37 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n122ib1X015533; Sun, 1 Feb 2009 19:44:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n122iOm7015514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 19:44:36 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw01.dd24.net (Postfix) with ESMTPA id 194697CC1AC for ; Mon, 2 Feb 2009 02:44:24 +0000 (GMT)
Subject: Re: Series of minor questions about OpenPGP 6
From: Christoph Anton Mitterer
To: [email-masked]
In-Reply-To:
References: <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-j2VmlQ1PEgLIJO5MQN6U"
Date: Mon, 02 Feb 2009 03:44:23 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-j2VmlQ1PEgLIJO5MQN6U
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 2009-01-30 at 17:02 -0800, Jon Callas wrote:
> > 3) key expiration time (9)
> > I've probably asked this before. But, what happens if different key
> > expiration times are specified in the self-signatures? Is it left to
> > the implementation to decide what to do?
> Yes. There are plenty of obvious right things to do. Let's suppose I =20
> am moving from example.com to foobar.com next Monday, but I quit =20
> example.com effective today (and set an expiration time that reflects =20
> that). From now until Monday, neither user name is valid.
This is a little bit strange, isn't it? Wouldn't one use signature
expiration times on the User ID self-signatures for such move?

> > 4) exportable certification (4)
> > Does this have a meaning on subkey binding signatures (0x18)? E.g.
> > something like don't import the signature itself and neither the
> > subkey?
> I have applications for this, myself. Yes.
Uhm @David (if you read this), does gnupg support creating non
exportable subkey binding signatures? And if so I assume that it doesn't
export the subkey either?!

> It makes sense to me to have two preferred keyservers. I don't have an =20
> opinion about policy URIs, but I wouldn't discount it automatically =20
> out of hand.
Doesn't the RFC say that only the last subpacket of a give type of the
same signature must be used? Or was this just a "should"?

Greetings,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-j2VmlQ1PEgLIJO5MQN6U
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMjAyNDQyM1owIwYJKoZIhvcNAQkEMRYEFJnqil6bYCXVLtcw3KL9oZHxqEtaMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AGU76/T1JM/s52N9bpiC+oySvgZOTfMZPoGE67AVCSiuDuCNHFv4mbhjFZs36APhDJCOQqUTOG6F
VQiGFdCqtQp6vcHh15VeCgep6J1ZgtpF1xbu6G1jdOrnUMa3JiRRDjYsRcL0M4QppYd77k+yPESq
sO4VtrXEI3v+MNM1w9PpRFQooPGelbWMIeaFQfTwYl+cDWh13/Z4uomlDzWvxk15jRVs/c8AC7il
jqNT0Ph9lrniwXlW7yVr1GG0y1neBiC06r4j9Wr8kZ+TtK3hyiKdM8XVXWYwFe/yRHm6c9YZBw1h
GG2i/F9nrxLwEq8hdr5VavlKjz/4C2ocIF6XIRcAAAAAAAA=

--=-j2VmlQ1PEgLIJO5MQN6U--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n122iS0D015522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 19:44:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n122iS6L015521; Sun, 1 Feb 2009 19:44:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n122iFZY015513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 19:44:27 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw02.dd24.net (Postfix) with ESMTPA id 919B63554C4 for ; Mon, 2 Feb 2009 02:44:14 +0000 (GMT)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer
To: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-yNkpSItU0mq1+oAQBymb"
Date: Mon, 02 Feb 2009 03:44:13 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-yNkpSItU0mq1+oAQBymb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi John.

On Sun, 2009-02-01 at 19:37 -0600, John Clizbe wrote:
> sks-devel[AT]nongnu.org
>=20
> Yaron Minsky did the development work, but doesn't have time for new deve=
lopment
> only maintenance.
Thanks for that info :-)

Hmm,.. what are our main keyserver implementations? sks and pks are the onl=
y ones I know about...

> Under SKS, it will get that data from another keyserver. To forge a key w=
ould
> require co-opting and taking simultaneous control of all the SKS keyserve=
rs.
Of course,.. I've already that,.. that this part is more a theoretical
point ;-)

> > And as you've said, one important point would be client support...
> > The average user probably don't want to set up socat or any similar
> > proxy.
> No, it would have to be done in the client.
That's what I meant ;)

Best wishes,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-yNkpSItU0mq1+oAQBymb
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMjAyNDQxM1owIwYJKoZIhvcNAQkEMRYEFFkM7OUEy9ldyxkP26SLEKLeV17qMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
ANBbV4splPSRfsnYuhWxfi8a6ckJ3IRZ/ZremdZWGRLyXwLATAXnwht2BiisUkJ4TlgfywMnhsPR
KLPSkcg6m9gYcSzxkCIYe63pEnCLzSWDsfHDW0MfEMPg5cTZjbgf9YCQrgZS/P1s7KlsVXN1Inaf
XDPbvP4WAyG3eRm/V1CoeSgMRpGvhWDTQoOO2bN0lSzKa6m9POoZBs2dtlCZhHNO5HCWIlnX/DZB
SFGd2zRTuV82aS4LuyoUu+/a1jzNFUhI91mE0qdajhrKdpMnT3xyXs8m+CA61BXDuMvfpMDxowox
4DwC2CafNo598XdVxylMQa6gcqDFf/aqG8zqdtAAAAAAAAA=

--=-yNkpSItU0mq1+oAQBymb--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n122RTC4015240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 19:27:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n122RT2K015239; Sun, 1 Feb 2009 19:27:29 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n122RSgq015233 for ; Sun, 1 Feb 2009 19:27:28 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (really [72.190.107.50]) by cdptpa-omta02.mail.rr.com with ESMTP id <20090202022728.RQTG5582.cdptpa-omta02.mail.rr.com@[127.0.0.1]> for ; Mon, 2 Feb 2009 02:27:28 +0000
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 20:27:27 -0600
From: John Clizbe
Organization: GingerBear Conspiracy Theories To Go
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP:
X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS)
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Kahn Gillmor wrote:
> On 02/01/2009 08:24 PM, Peter Thomas wrote:
>> After reading the whole RFC I've found several places where SHA1 is
>> given as the only possible algorithm,
>
> This was just discussed on the list last month in a thread titled "A
> review of hash function brittleness in OpenPGP":
>
> http://www.imc.org/ietf-openpgp/mail-archive/msg30323.html
>
> It would be worth reviewing that thread because it contains relevant
> discussion.

http://www.imc.org/ietf-openpgp/ has links to the indexed archive as well as how
to obtain the entire archive in mbox format

- --
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:[email-masked]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn4907-2008-12-21 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the Â£33Â† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey - http://enigmail.mozdev.org

iJwEAQECAAYFAkmGWgwACgkQvh+YERi7NzqwlQP9HyFNw/9YKjGgelaUD1SRMSid
huWosy5a01+mHC4SY49RSKe3ygmC8KY349azBjsu9K3sc/O5rJyGKBUHkJ3FzsVl
7svhw5DRtrAndHjwTphngWVbsvtTFdmleUoJLDUVsd/WN/I02rNAkwyoOU7YcdTX
JUO7OsH8GResDZMmRmyIRgQBEQIABgUCSYZaDAAKCRAdBKxKYI0qEJw2AKCUAPMU
iaDYZFtpRJ83D6nc1EHzeACfZL/1N/FjFmbaCv+I+18dYur/mCo=
=w1Jj
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121vP1F014346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 18:57:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n121vOvM014345; Sun, 1 Feb 2009 18:57:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n121vDCq014338 for ; Sun, 1 Feb 2009 18:57:24 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 66979 invoked from network); 2 Feb 2009 01:57:13 -0000
Received: from 166.84.167.89 (HELO ?10.156.156.130?) (166.84.167.89) by relay00.pair.com with SMTP; 2 Feb 2009 01:57:13 -0000
X-pair-Authenticated: 166.84.167.89
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 20:59:56 -0500
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Peter Thomas
CC: [email-masked]
Subject: Re: how close is OpenPGP tied to SHA1
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3E0CAAA4AA0A671519471DCD"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3E0CAAA4AA0A671519471DCD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 02/01/2009 08:24 PM, Peter Thomas wrote:
> After reading the whole RFC I've found several places where SHA1 is
> given as the only possible algorithm,

This was just discussed on the list last month in a thread titled "A
review of hash function brittleness in OpenPGP":

http://www.imc.org/ietf-openpgp/mail-archive/msg30323.html

It would be worth reviewing that thread because it contains relevant
discussion. In short: the fingerprints seem to be the most worrisome
part, and we probably need to think about how to move forward.

Proposals?

--dkg

--------------enig3E0CAAA4AA0A671519471DCD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSYZToMzS7ZTSFznpAQKyoA//YMhqrLHW2J26fh62gFOtI+WyrD8T6wiU
ys+nX/a/KBuvCZd7nk3wxSbwEuCuxMhktSjvKy4BdQtfGsdlcAN72ucY2cW8DuRt
dzl105BFJk9kyQWAdFl61C62JJ6LcZFYdWwj7yV0pI9FogwJRv1WokcyxEdz7k30
THHt0ia+VVBVoSymoW7r6RjquZ744k4OZ8hMdgPc23HxYWjoAEcBQXTRVJ8JKHDX
a2oIDjQR/FjtYoCaBXyzPEpcxrds9QcSHYlapvIS/x0ek6Y/w6Q/ddZCV0vB4229
QEi2sPIZb4Bm0TGJXjAlMe5Q/TEKHuARIt15Nbu1qGCvnVqRStdwT4QtuF2FfOjl
xx1hUj/5Nkvz0RU7dp4qJxjd0iS46opZ5lFCFJFEQVIM69zqA5I1icXw1svSBRcz
Q4vD8/fGbWLRJQUDRyGZ/mFGKWFtG9VHq/V0qkjEhMSJ4NF3jnprDe9Tm838rAux
RgYMbbMMiqvy2I4FyQ3bYYg+FZJzhbXcvyIIUzd/kfKQvCJ0PXJZaN/hOCoZ5R3b
cmAIdQU+EThzVtdJ0+Hm/qtbD58usQBCyLEAPintqjLB6r77rSXjDGGMtsMBMHyE
O5D6D82u+fOhTMIU4c3QzPhwpZ7kgfLdvHVDXHtFjjCPlROD0ySUXG6QbdcjqDmv
TND2xBces00=
=niE1
-----END PGP SIGNATURE-----

--------------enig3E0CAAA4AA0A671519471DCD--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121bYXq013835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 18:37:34 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n121bYjL013834; Sun, 1 Feb 2009 18:37:34 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121bNxD013826 for ; Sun, 1 Feb 2009 18:37:34 -0700 (MST) (envelope-from [email-masked])
Received: from [127.0.0.1] (really [72.190.107.50]) by cdptpa-omta04.mail.rr.com with ESMTP id <20090202013722.PIDX23506.cdptpa-omta04.mail.rr.com@[127.0.0.1]> for ; Mon, 2 Feb 2009 01:37:22 +0000
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 19:37:21 -0600
From: John Clizbe
Organization: GingerBear Conspiracy Theories To Go
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
MIME-Version: 1.0
To: [email-masked]
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP:
X-Face: &KOqPhy&\S+}^~xEHZGEs'8mps-5a4E=`i>2c!PuesSM7lpv}^Yfn<6?y=BF@X+N!n&!L&# .m>o,xH$v%{I8Gmf/Z'.qB|U;][A5$#c;u%(rJ\S"2NotGhXF@~cM4'Q!/E\9cP{1M;J8A0e>-&xN, hQ>[CjNA{+~zDNk1'jz@|yeaCJX*M1;(Tb_7(.WCK:)}W?d.Nl<8&W{]/T-+gG?\lS)
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Anton Mitterer wrote:
> On Sun, 2009-02-01 at 16:25 -0500, Daniel Kahn Gillmor wrote:
>> So: Is this scheme fully implemented and easy-to-use yet? No. But
>> the pieces are there, and it's already been assembled piecemeal with
>> currently-available tools. If you are interested, or manage to push
>> it further, i'd be very happy to hear about your progress.

> Well my time's limited ^^...
> I had hoped to get somehow in contact with the keyserver software
> developers,..

sks-devel[AT]nongnu.org

Yaron Minsky did the development work, but doesn't have time for new development
only maintenance.

The other keyserver list, pgp-keyserver-folk[AT]alt.org, seems to have gone missing.

> The keyservers should also communicate secured with each other,.. in you
> setup there's still the (of course very small) chance that the secure
> keyserver (e.g. your's) is already attacked and doesn't get the full
> data during its synchronisation with the others,...

Under SKS, it will get that data from another keyserver. To forge a key would
require co-opting and taking simultaneous control of all the SKS keyservers.

To fool a keyserver would require being able to fake hashes of the database
contents on-the-fly.

> and I suppose most people use one of the "big/wellknown" keyservers when
> submitting their keys.

Yeah, even when the code the keyserver runs is broken/orphaned.

> And as you've said, one important point would be client support...
> The average user probably don't want to set up socat or any similar
> proxy.

No, it would have to be done in the client.

- --
John P. Clizbe Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or
mailto:[email-masked]?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn4907-2008-12-21 (Windows XP)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the Â£33Â† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey - http://enigmail.mozdev.org

iJwEAQECAAYFAkmGTk4ACgkQvh+YERi7Nzp22QP/TeruwklRnyW0M4K0fpLJursc
cHQYb52ma0BhADsZW0YbU/YX4R2303gIrNkg0XDmrVZZ4v7//D2Qod6PCKvXRlrg
XCWASWmECorNe/cE+7REu4NZD8TxHAVexzwEAGIEJsOmdzyWllU3hBgzFA1F1E5j
AsDmH9Rk3npVJRtu4+uIRgQBEQIABgUCSYZOTgAKCRAdBKxKYI0qECUTAJ44dzIM
d0wDJnN62gmUzxhU8QWYdgCfeKeWjZvv6nQ3LS8N65zp7s4Nq5o=
=ZBt6
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121PClx013438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 18:25:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n121PC1E013437; Sun, 1 Feb 2009 18:25:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n121P0A3013418 for ; Sun, 1 Feb 2009 18:25:11 -0700 (MST) (envelope-from [email-masked])
Received: by fk-out-0910.google.com with SMTP id 19so1062492fkr.10 for ; Sun, 01 Feb 2009 17:24:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=HE53CnS+353n/Dm1EV4gZeYwpWWVpVpNwy0pSmUFGKA=; b=Zpks7HHLl7/4MjjlyDWjth4YvY11HHj9NgrAN5wvDFde/hUJlLwrQ+PqvLQUtA7FmS +XE3L8kZfVPLDeUE8py0GzdMnAkeJeZ6s+5W9DXD61Y+eojazR8vAgXN4eOXpAFAjcvl FPYhSTcRYNZN+N74sdIl/JMoHaWJlRxGbiNBo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=AKLu3TLNwLB4L30GV0OPnj3Z7tOvrAp7YOIQ2WPaHMU6ZVLI7IiSD3Na+CgAMcV66p SaCQQ6fZj90Kj/h5srjNsNKj1arWPxbV/5q6CJNz9558CbFVyGBTwBIOmwzGykiflPX7 BQm/A9S2LKiERL/hk6yrhA1XlB87Fkl08W48Y=
MIME-Version: 1.0
Received: by 10.181.218.14 with SMTP id v14mr1473867bkq.48.1233537899394; Sun, 01 Feb 2009 17:24:59 -0800 (PST)
Date: Mon, 2 Feb 2009 02:24:59 +0100
Message-ID: <[email-masked]>
Subject: how close is OpenPGP tied to SHA1
From: Peter Thomas
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi WG.

After reading the whole RFC I've found several places where SHA1 is
given as the only possible algorithm, e.g. the whole MDC stuff, or the
revocation key signature subpacket (it has these 20 octets of the
fingerprint).
In addition to that we depend very much on SHA1 as our fingerprints
uses it, and if I understand correct the whole web of trust uses them
at keysigning parties, etc.

Now how close are the two tied?

I mean the signatures are completely independent of SHA1 (one can use
a different hash algo for them), and the signatures are not calculated
over fingerprints but over data, right?
So in principle one could say, that it would be better not to use
fingerprints when two people sign their keys, but the should better
really exchange secured copies of their public keys, ok?

I still remember the first papers about possible attacks on SHA1
(though I don't know the current state on this),... and we've already
seen how fast MD5 was completely hacked.
So what would happen if the same happens to SHA1? Would the existing
web of trust (I mean the existing keys and their relationships) blow
up?

Bye,
Peter

btw: Is there a difference between OpenPGP's MDC and MAC's?

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n120PeIL011501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 17:25:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n120PerE011500; Sun, 1 Feb 2009 17:25:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n120PcNm011494 for ; Sun, 1 Feb 2009 17:25:39 -0700 (MST) (envelope-from [email-masked])
Received: by bwz5 with SMTP id 5so1061385bwz.10 for ; Sun, 01 Feb 2009 16:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=pG9xScDKkBrr+iPURDNn9b+6jwAz18/t5x1IoSzt6Sc=; b=Grj1737s5b3L2E3HUKZe1nSIipzjccnK7dGozAG0rLURCbv69I7kDv+Iu+4N5+/74W PCkzgvamxbNIzmQOsyAGHZuxTdLpJe3jql+XkhPNsQdEsYcbiSQzBlPQLuzBThNRQam1 JBpNOhpC0ZequvPil2f8mm/PA81ULJrj2/LqU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dN6ucscJPlVaobvkp5sWjaHZp1jk3wyMlQc12v8lz/h6++hFo+idHGCr7DK9PmKcFj AyCPMa75gqGwh23HkxihAQo5PdBAi8NgI/wvJry9H8cITf5cCqO5GcYX84mED/BgRBXL nSGYiYvYIhH1QVGDu+5vYHgpWFFWGoTwVdJp8=
MIME-Version: 1.0
Received: by 10.181.31.16 with SMTP id i16mr115095bkj.129.1233534337666; Sun, 01 Feb 2009 16:25:37 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Mon, 2 Feb 2009 01:25:37 +0100
Message-ID: <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 6
From: Peter Thomas
To: OpenPGP
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hello.

On Sat, Jan 31, 2009 at 5:04 AM, David Shaw wrote:
> Use the shortest expiration time. If the 0x1F says you have 10 days, and
> the 0x13 says you have 5 days, you have 5 days.
Ok,.. but basically this means,... it's left to the implementation by
the RFC, as Jon said, right?
So an implementation could also use the key expiration of the 0x1F
when the key was selected via key ID for example,.. or one of my other
examples from above.
And your answer here is "just" the probably most reasonable advice?!
But in any case,... if the selected expiration time is reached,.. the
WHOLE key is expired, right?

> As you note, the subkeys
> have their own expiration time - but not if they exceed the whole key
> expiration time. You can't have a subkey that lives beyond its primary key.
Of course :)

> If you have preferred algorithms in both the 0x1F and a 0x13, then you use
> the one with the narrowest scope. So, if the key was chosen by a particular
> user ID, you use the preferred algorithms from that user ID's selfsig. If
> that selfsig does not have preferred algorithms, use the one in the 0x1F.
> If the key was chosen by key ID (so there is no one particular user ID) you
> use the preferred algorithm from the primary user ID. As before, if there
> is no preferred algorithm there, use the one from the 0x1F. If there is
> preferred algorithms on a 0x18, I think I'd take the union of those
> algorithms with the ones from the user ID or 0x1F.
Ok but again,.. this handling is _not_ enforced by the RFC, and an
implementation could also choose to do it by one of my examples,
right? Of course what you've explained here above is probably the most
reasonable :-)

Ah and did I understand this correct:
When the symmetric/hash/compression algorithm is set on a 0x1F but not
any of the 0x13, the ones from the 0x1F are used? But if the 0x13s
have them _too_ these are used?!
Does gnupg do it like that? I mean that you can set kind of a "global"
default via the 0x1F, expect you re-set it on the 0x13s?

>> - key server preferences / preferred key server / key flags / features
For them it's also up to the implementation right?
Where can I find how gnupg would choose if I'd have them
a) only in the 0x1F but not the 0x13s
b) in both

"Read the sources!"?! xD

>> II) Subpackets on any of the 0x10-0x13 certification signatures:
>> III) Subpackets on the 0x18 subkey binding signature:
Were my assumptions here correct?

Does it make any sense to have keyserverprefs/preferred
keyserver/features on 0x18 subkey binding signatures?

Can anyone here of an example or a semantical meaning, that a
self-signature is a trust-signature?

Wow,... I think I'm going to run out of questions ^^

Thanks,
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1204eg7010954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 17:04:40 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n1204eUM010953; Sun, 1 Feb 2009 17:04:40 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n1204c3c010946 for ; Sun, 1 Feb 2009 17:04:39 -0700 (MST) (envelope-from [email-masked])
Received: by bwz5 with SMTP id 5so1056811bwz.10 for ; Sun, 01 Feb 2009 16:04:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=97sPNEtrwXTUz7cj1/+GaIYlcuIYLPxR66C79U+UVoQ=; b=mib37Ww1kJifaixPxIbbgKttLD/e7I0bd7bLRB821kTlGpEd8uRosKZsLwpsvx3ait wJIfA4QGGoi4jW/oEoIOZuj9qB90MSqQuOMfYCu+Q3FlPZK3Td+vlvTydFDQEC/9YOkd 1DvtMTyd/2aDo2qICSfTBWGWZgzg6qrEqu72k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=sZHyL3aQ2pLy587Xa0AQMD6lBS+PWtze3FXOaULN6+ZvdQh30L82EY+3pcTqY6T5Kx Gze8iMxsMVALxX02syvHQvPORRQvtop0ENTdYz3dk+HtUaGMpX7qkcDNOGaZnbmXW1yK xshiIx9kh2xJ2NWQIsYuS1L+wVBpMCkOwbU1A=
MIME-Version: 1.0
Received: by 10.181.134.11 with SMTP id l11mr1450535bkn.18.1233533077942; Sun, 01 Feb 2009 16:04:37 -0800 (PST)
In-Reply-To:
References: <[email-masked]>
Date: Mon, 2 Feb 2009 01:04:37 +0100
Message-ID: <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 6
From: Peter Thomas
To: [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Jon,..

Thanks for your answers :-)

On Sat, Jan 31, 2009 at 2:02 AM, Jon Callas wrote:
>> 5) Is it allowed that more than on subpackets of the same type exist
>> in the same signature?
>> E.g. Two policy URIs in on 0x13, or two preferred key servers. And
>> what would it mean?
>
> It makes sense to me to have two preferred keyservers. I don't have an
> opinion about policy URIs, but I wouldn't discount it automatically out of
> hand.
Uhm, may I propose for a future RFC that all this is clarified a
little bit and perhaps tightened up?
I think right now the RFC suggests that in case of multiple subpackets
per signature the last on in the signature takes priority?
But again that's was just a suggestion if I recall correctly and thus
may left space for ambiguities.

> I'm not going to comment further, but only because I'm in a hurry and
> haven't memorized the hex values.
If you'd find time to do so later I'd still welcome it :-)
David made only a few comments (this is definitely not a complaint ;-)
and I'm still not fully sure how this works, or whether it's
completely up to the implementation.

Thanks for your help so far :-)
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11N7MVe009430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 16:07:22 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11N7Mq5009429; Sun, 1 Feb 2009 16:07:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11N78OB009420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 16:07:20 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw02.dd24.net (Postfix) with ESMTPA id 3CF21355479 for ; Sun, 1 Feb 2009 23:07:08 +0000 (GMT)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-SS+8yItyoYXbTOzL48PV"
Date: Mon, 02 Feb 2009 00:07:07 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-SS+8yItyoYXbTOzL48PV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Daniel.

On Sun, 2009-02-01 at 16:25 -0500, Daniel Kahn Gillmor wrote:
> In addition to an active attacker modifying the communication, queries
> to keyservers are also potentially information leaks -- anyone simply
> observing the query knows something about who your contacts are.
Excellent point.

> > Are there currently working means to prevent this?
> Yes there are! Back in November i set up nginx on
> zimmermann.mayfirst.org (a member of the sks-keyservers pool) to
> provide
> an HTTPS link to the keyserver. Access to that keyserver can then be
> done by running hkp over TLS. While the OpenPGP tool i was using
> (gpg)
> didn't seem to be able to handle such a TLS-wrapped link natively, i
> was
> able to approximate it with a client-side proxy using socat:
>=20
> https://lists.riseup.net/www/arc/monkeysphere/2008-11/msg00046.html
This sounds nice =3D)

> Because TLS offers mutual authentication, message integrity, and
> privacy, this can potentially defend against every kind of active
> attack
> except for a full DoS (which an active attacker who can modify your
> network traffic can execute no matter what anyway) (and could also be
> used to limit queries to your keyserver to particular users, if you so
> desired).
Of course,...

> But wait, you say, I don't want to have to use X.509 certificates
> along
> with TLS! Well, i don't either. RFC 5081 provides for TLS to use
> OpenPGP certificates for either party in the communication. This
> removes the need for X.509, while retaining all the benefits of TLS.
Even better :-) Which RFC5018 have you used?

> So: Is this scheme fully implemented and easy-to-use yet? No. But
> the
> pieces are there, and it's already been assembled piecemeal with
> currently-available tools. If you are interested, or manage to push
> it
> further, i'd be very happy to hear about your progress.
Well my time's limited ^^...
I had hoped to get somehow in contact with the keyserver software
developers,..

The keyservers should also communicate secured with each other,.. in you
setup there's still the (of course very small) chance that the secure
keyserver (e.g. your's) is already attacked and doesn't get the full
data during its synchronisation with the others,... and I suppose most
people use one of the "big/wellknown" keyservers when submitting their
keys.

And as you've said, one important point would be client support...
The average user probably don't want to set up socat or any similar
proxy.

Best wishes,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-SS+8yItyoYXbTOzL48PV
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTIzMDcwN1owIwYJKoZIhvcNAQkEMRYEFK7jhZzIYsqoOsI+g7Lqe/Cso2DJMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AGVr9XJcF9+BviIQAngP7r//EBo9YFtKQqTCbRDMKx1xoanPZAlB5oJhdEQnwu5iboe65vT4pB1i
TMK4DBgdT3RmHiAd+zpDfKtbL3uOErlIyyKVFgrcsZwyW95yCeuoAzPwhXWuz3Wg5GIk7/NjRgm5
j7lts3I35+Ga2847v8JXsaDM5/TWUjVw55c3AFuSo19fw0JSa7Dz0T3tNdGRkY/RvajVS5Kfgr3p
91/aLpG9mh0QSSz3gH9iHwktBlCLOjyQxJM/VehJs4LxL5kEPdbTTjBFSi0x8wMQ7wx/takRjg6u
xpo/4VpKY02oFWpZJa1zQOABMCA1VQOf+uwJ40UAAAAAAAA=

--=-SS+8yItyoYXbTOzL48PV--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11LMoNY006446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 14:22:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11LMoAt006445; Sun, 1 Feb 2009 14:22:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n11LMmhL006439 for ; Sun, 1 Feb 2009 14:22:49 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 1221 invoked from network); 1 Feb 2009 21:22:47 -0000
Received: from 166.84.167.89 (HELO ?10.156.156.130?) (166.84.167.89) by relay02.pair.com with SMTP; 1 Feb 2009 21:22:47 -0000
X-pair-Authenticated: 166.84.167.89
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 16:25:28 -0500
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Christoph Anton Mitterer
CC: [email-masked]
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig006E853F3C9A7B56962918E4"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig006E853F3C9A7B56962918E4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Christoph--

I think the issue you're raising about secured access to keyservers is
important.

In addition to an active attacker modifying the communication, queries
to keyservers are also potentially information leaks -- anyone simply
observing the query knows something about who your contacts are.

On 01/31/2009 05:54 PM, Christoph Anton Mitterer wrote:
> Imagine that my ISP is evil, tracks my connections and always removes
> some revocation signatures when I get the data.
>
> Are there currently working means to prevent this?

Yes there are! Back in November i set up nginx on
zimmermann.mayfirst.org (a member of the sks-keyservers pool) to provide
an HTTPS link to the keyserver. Access to that keyserver can then be
done by running hkp over TLS. While the OpenPGP tool i was using (gpg)
didn't seem to be able to handle such a TLS-wrapped link natively, i was
able to approximate it with a client-side proxy using socat:

https://lists.riseup.net/www/arc/monkeysphere/2008-11/msg00046.html

Because TLS offers mutual authentication, message integrity, and
privacy, this can potentially defend against every kind of active attack
except for a full DoS (which an active attacker who can modify your
network traffic can execute no matter what anyway) (and could also be
used to limit queries to your keyserver to particular users, if you so
desired).

But wait, you say, I don't want to have to use X.509 certificates along
with TLS! Well, i don't either. RFC 5081 provides for TLS to use
OpenPGP certificates for either party in the communication. This
removes the need for X.509, while retaining all the benefits of TLS.

So: Is this scheme fully implemented and easy-to-use yet? No. But the
pieces are there, and it's already been assembled piecemeal with
currently-available tools. If you are interested, or manage to push it
further, i'd be very happy to hear about your progress.

hth,

--dkg

--------------enig006E853F3C9A7B56962918E4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSYYTTszS7ZTSFznpAQLp7g//d2psASBPIx1NnTqwz8kgcFqWC5A4sl4G
Stnv+3C4Agoh5E5zC9Y6fi889q082apSZTKhlfbt965Q2O9KXpCoAI8MdcW7SyLS
KdrjPUqJBJOzW8KwOmFQbct8se5T4hM2GXMx90EzGduzzWqE4QKVadDIRIdNR74c
2MEkCVBUfrjxvqwg+ItEYtPekqyzKnqHGihWqsoC7T+3Gc4m1seeLfvXEX1m4MO/
zv53/yKYF5xm3znDXJyVDcviqo+yj404pnOElFj4C64F7dHYdOoW8H+zfH0uve+f
QeNncpkleYSYu6G9dHj0TJs9Wdc/eCCoAu7jpMwpdMwwm40AwIkSYh6HPMEEP9Uk
WSrWBZTQ+3fb1/ZozmlZNJNXCi7L5FX39hXb4Q27fkumxwK39+2I4aqvEXKg+bPA
SvCs6O3YBUBwwNHRCBzfz8D1TxUdqZjSyVKTRLy7uRCWdtUP/NYnt5LUaATB4LCk
htDh5yN6Ir2p0DEYTGlqZ7j6VvJxpZJSrjNe0wPAdOyeUiL+zF7jnIi9ECRxAY5r
2DPadXjBEd1sg/noigScVVT6SHuQ3Nz4kx4vZULvL9gxy0tcDOEBxmmbSDy1FWH3
DOibus1fd+/4p5dMyZ+3GOXD19zYsh5bCAySvkZ7HS7aFW3Rk7ZDyGSDnRT9NHWQ
L/fONLFGZXE=
=xDjL
-----END PGP SIGNATURE-----

--------------enig006E853F3C9A7B56962918E4--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11KrSUP005249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 13:53:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11KrSxq005248; Sun, 1 Feb 2009 13:53:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n11KrGu0005236 for ; Sun, 1 Feb 2009 13:53:27 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 97784 invoked from network); 1 Feb 2009 20:53:15 -0000
Received: from 166.84.167.89 (HELO ?10.156.156.130?) (166.84.167.89) by relay02.pair.com with SMTP; 1 Feb 2009 20:53:15 -0000
X-pair-Authenticated: 166.84.167.89
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 15:55:57 -0500
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Peter Thomas
CC: IETF OpenPGP Working Group
Subject: Re: Series of minor questions about OpenPGP 4
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FCE153C1AFBAEC24EE43D18"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3FCE153C1AFBAEC24EE43D18
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 01/30/2009 06:39 PM, Peter Thomas wrote:
> On Fri, Jan 30, 2009 at 9:06 PM, Daniel Kahn Gillmor
>> this assumes that the policies are machine-parseable in a form that
>> includes conflict resolution, no?
> Why? All policies might have a human readable chapter "X. In case of
> policy conflicts", where they explain what should happen.
>=20
>> what form are you proposing? my
>> reading of the RFC is that there is no restriction on what can be
>> contained in the policy URI.
> I don't see that point why this would have to be machine-readable.

Hrm, thinking about this now, i'm not sure why it would necessarily need
to be machine-readable. I think i was thinking that there would be ways
to mechanize your interpretations of various signatures based on the
policy decisions.

This would require some good work sorting out common policies that could
then be referred to by URL, sort of like how Creative Commons has sorted
out some common licensing arrangements which can be identified by URL:

http://creativecommons.org/licenses/by-sa/3.0

uniquely identifies a well-known license, and people are building tools
to automatically assemble indexes of content that's been licensed that wa=
y.

If a group did the same type of work for certification policies that CC
has done in regard to content licensing, then you could begin to build
similar sorts of tools to interpret human-centered policy preferences
through the web of trust.

This is a more ambitious project, though, and you're right to question
the need for every policy to be machine-interpretable.

--dkg

--------------enig3FCE153C1AFBAEC24EE43D18
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSYYMYszS7ZTSFznpAQI+Zw//Vlf88GkbSTN+eS8ziaNgP+SAFTGsLWLR
olZGvXszw2LY2Pw46bPxsRJ1TSMGRA6TrnIBVxNR7trWaMSyecyDaPd4EtkCHWja
gFCCj7w8H/vIS/ZWrN0wNOkyvi3NQCPhf51cmA8QfBTw+f2POHVK/7+q74pt1MNM
d/erJ2RTetRKRqRoNbQWbuhbONc10flZb1b/4RNCLa4QmWb5ck//AH4tDkZw2b32
/t/QVK4Dh5KtlugmLhZIS5zZuqwQzUNucaU+NhpkwPpwxTv7V9WnNQcKOuAes113
jOw9DdC5s7kwsbNpevefbJMvDvUUdOIyLRQK1nr6xMPM3jsUPwnku430a0VzeIxG
XQxcH4hPQZkR017r+wrDBb0OXpgEGwjfr/uiAtjitTU66PQdl+5waSIK3hVvYOBt
QzDctgCr+ErIqL0R7+4OpTG5xJFHP8MDcVoU76+vebwolDasBWKAVnX5pMd2F/WW
N0bxyBF9MUirW3U3TaPfTYSxu+GopgKXw4aLLlRIpnMzGRoppsV1AJCVRWA++qHh
ndITKe2tmAJ7DBFpQ3nKoanzzm1QOwvKhwutVIGdwouYCZugotW6Fwvnqegt5mUZ
hM9PzQGKI5qZQFdlnIlo9UJVqjBstM9edzG1xNfzuPioqIG4hwHqLoxWFAsr1M+o
FXGnzR39nWE=
=E+zS
-----END PGP SIGNATURE-----

--------------enig3FCE153C1AFBAEC24EE43D18--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11K5gmU003562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 13:05:42 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11K5gIN003561; Sun, 1 Feb 2009 13:05:42 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11K5exv003554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 13:05:42 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw01.dd24.net (Postfix) with ESMTPA id 1AB527CC11C for ; Sun, 1 Feb 2009 20:05:40 +0000 (GMT)
Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer
To: OpenPGP
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-2GPpdv9303FocfTLoXiX"
Date: Sun, 01 Feb 2009 21:05:39 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-2GPpdv9303FocfTLoXiX
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, 2009-01-31 at 22:36 -0500, David Shaw wrote:
> > To conclude:
> >
> > Public Key
> > 0x1F (timestamp 1)
> > 0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1
> > 0x1F (timestamp 3)
> > 0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3
> > 0x1F (timestamp 5)
> > UID
> > 0x13 (timestamp 1)
> > 0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1
> > 0x13 (timestamp 3)
> > 0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3
> > 0x13 (timestamp 5)
> >
> > would work as I described in the example, and ONLY:
> > 0x1F (timestamp 5)
> > 0x13 (timestamp 5)
> > would be usable, right?
> >
> > But something like:
> > Subkey
> > 0x18 (timestamp 1)
> > 0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1
> > 0x18 (timestamp 3)
> > doesn't work, and the subkey will still be revoked.

> No, because that implementation, completely in accordance with the =20
> RFC, does not have to regard that user ID as valid after seeing a =20
> single revocation. An implementation is free to treat any user ID =20
> with a revocation on it as permanently dead.
Oh my god :-O
Surely? I thought that the 0x30 says it only applies to _earlier_
sigs...

Hmm,.. that's bad ^^ such applications should be forbidden,.. and their
programmers be imprisoned xD
Well seriously,.. that's a point.

So if an implementation doesn't behave like this,.. the above would work
(expect it behaves in some other very obscure way) and would be in
accordance with the RFC?
I just ask to see whether my understanding of the revocations and so on
is now "correct".
Or at least, the above is the way it would work in gnupg, as you've said
before.

> I understand what you're trying to accomplish, I really do. =20
> Unfortunately, the RFC doesn't give you the tools to do what you =20
> want. Luckily, the problem you're trying to solve isn't actually a =20
> problem with any known implementation of OpenPGP.
Of course, the whole thing (at least from my point of view) was more a
theoretical discussion, in the sense if this would give us the tools to
handle implementations which don't follow the RFC's advice.

> If you want to generate extra revocations, go right ahead (it should =20
> work fine), but understand it is not a "RFC safe" way of doing things.
Actually I don't intend to use this revocation-trick....
I've already thought about doing so, but now that you've said, an
_conforming_ implementation might treat a UID invalid forever after a
single revocation,... I'm not so sure anymore ;)

Ok,.. thanks for the enormous effort you spend on this,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-2GPpdv9303FocfTLoXiX
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTIwMDUzOVowIwYJKoZIhvcNAQkEMRYEFDCU77e+TVCqB0lLINk4+KkcTx6ZMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
ABH8QJOGyfzYgSNZpJYHdHyhPv3uiF/m0a+iwVjvIqBE97H4GnSQA0BFz1aMXgb3mUwAvaEOk3bK
S00SS2q5WCElKqLjW9X+2c9K7Sih5RPtXKhfKG0afk14ybNquRAGl7T3sMiymOM5PfdYYDXDjHMN
U1i7OqXx0RVr0/YPXc1Ld+VP92ZrT7az8TSQ876tIK5xn26hA0AqQDPCGyqB/5G6C18iWpfDOuWL
BPtpmrqtXKuPUjMSB0MG1k4k6q0Om2N9UG7XpOkw4zUnXXECeQIGo9OnagmGsFPPNMxfhMxHA53H
T6yLvrjDxi33LKHPS0dPpsM51CLFt/jQ2IS3FF0AAAAAAAA=

--=-2GPpdv9303FocfTLoXiX--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11JrDJg003029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 12:53:13 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11JrDaS003028; Sun, 1 Feb 2009 12:53:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11JrBOc003019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 12:53:12 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw02.dd24.net (Postfix) with ESMTPA id C9AA33551D0; Sun, 1 Feb 2009 19:53:10 +0000 (GMT)
Subject: Re: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
From: Christoph Anton Mitterer
To: "gerry_lowry (alliston ontario canada)"
Cc: [email-masked]
In-Reply-To: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
References: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-vh8VVxvS6NtZ9Eqp+lq4"
Date: Sun, 01 Feb 2009 20:53:10 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-vh8VVxvS6NtZ9Eqp+lq4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 2009-02-01 at 14:14 -0500, gerry_lowry (alliston ontario canada)
wrote:
> I live under the cloud of the virus a.k.a. Windows [XP, Vista, Server 200=
3, Server 2008].
Ok let me just skip a possibly flame war triggering comment on how
windows and cryptologic security can go hand in hand ;-)

I do not like your indenting :P

> QUESTION # 1: There seems to currently exist TWO forces in the PGP unive=
rse:
>=20
> (a) GPG -- GnuPG (OpenPGP initiative)
> (b) PGP -- PGP Corporation.
These are probably THE main players, but we have quite some other
implementations.

>=20
> To what extent are their goals aligned? Mor=
e specifically, since (b) is a corporation
> which is driven by the profit motive and (a)=
would like to make a reasonable living
> but is likely more open than the average cor=
porate culture, it's likely more in the
> interested of (b) to succeed in being univer=
sal but not too universal, i.e., to some
> degree, (b) could grab more market share by =
being somewhat proprietary.
Well at least they've managed to work together on the standard so I'd
say that there's a good relationship.
But David, Hal, Jon and Werner could answer this probably better =3D)

> OTOH, it's possible AFAIK that (a) could not=
succeed without being 100%
> compatible with (b).
I don't think so,.. as especially in the Linux/OpenSource community
nearly everybody use gnupg. Please don't interpret this as if I wouldn't
like PGP or its staff). Is there a Linux version of pgp, at all?

> http://pgp.mit.edu/ has been around for many=
years.
This is only one of many keyersers.

> OTOH, I almost never receive even PGP
> signed e-mails. I spoke with a senior I.T. =
person recently who was
> not even aware of PGP technology.
Well,... I won't comment on this...

> To what extent is GPG/PGP technology being u=
sed by e-mail users?
> I'm guessing it must be less than 1% based o=
n the many 1000's of
> e-mails that I have received each month over=
the last decade.
It's quite widespread in the OpenSource community, and you should not
forget that OpenPGP is far more than just email.
Look e.g. at the Debian project which signs all its packages via
OpenPGP.

Of course the usage depends on the community which you're part of.

In the last time X.509 advanced more and more, and especially stuff like
Thawte's wot or CACert.
But these provide by far less security IMHO.
In general they depend on a single root with their limited strict
hierarchical PKI.
Which means effectively, everything depends on the root cert.
If this is somehow compromised,... game's over.
It's even worse, as most people have never received the root cert in a
secure way (just downloaded it from the web, or shipped with the
browser, et cetera)

And to come back to these two, CACert and thawte, already two people
(two assurers with the necessary points) can forge an identity.

So apart from military solutions, proprietary standards or rarely-used
PKIs you can right now only choose between:
-OpenPGP
-something X.509 based (e.g. CMS, S/MIME)

And IMHO it's clear, which one of the two provides (or can provide)
security and which one not (that much).
(I think this has the potential to start a flame war ^^)

Just my 0.02=E2=82=AC,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-vh8VVxvS6NtZ9Eqp+lq4
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTE5NTMxMFowIwYJKoZIhvcNAQkEMRYEFLvEKwlGpo2dXxEDkX8wffg9REi3MGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AOPgHiYXc4IzlvKCvTd0BS/k36SoGfkS1v9qcZYYrCm0YYcxPoR5Emrqb40aZrLpGlY+u7mYioRV
DGOhLNRO90p78KJmL1qCQnTQA3bOfNT0O5NX7rTteDuY0mq1/6hNtNeZszok68nBJQoQv5bVoQOi
+KeUvBSn9PhaYxlN8Jc3m1VP4DpvLeuweUKck71w9n0BaZ8mdWLtcA+ZODannv0XUgMPCfWkDP6U
61Y90ZI6K8FMzN2sGldZnL6z4mw5M/b1T3eYh27BNpErF+Hae3cxtHpmiyKXx88rHL17J23nu9vO
SZQ7J72uRFLdj9wn4jOsG+RgXbLwmFL1+N+RLyIAAAAAAAA=

--=-vh8VVxvS6NtZ9Eqp+lq4--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11JQJo3002239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 12:26:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11JQJw7002238; Sun, 1 Feb 2009 12:26:19 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11JQGOk002232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 12:26:18 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw02.dd24.net (Postfix) with ESMTPA id A9D79354F12 for ; Sun, 1 Feb 2009 19:26:15 +0000 (GMT)
Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer
To: OpenPGP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-GSnsBUe0sRY7Ps2M4u9D"
Date: Sun, 01 Feb 2009 20:26:14 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-GSnsBUe0sRY7Ps2M4u9D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, 2009-01-31 at 22:36 -0500, David Shaw wrote:
> > I've seen you other mail that for subkeys this isn't possible at =20
> > all, as
> > only one 0x18 and corresponding revocation is allowed.
> Unless you strip off the old 0x18 and revocation.
Ok,.. but this is not really possible due to the keyservers,... they'd
bring it back, correct?
Now what would e.g. gnupg do if it enounters:
Subkey
0x18 subkey binding (timestamp 1)
0x28 subkey revocation (timestamp 2)
0x18 subkey binding (timestamp 3)
?

Or what if it for example has:
Subkey
0x18 subkey binding (timestamp 3)

And with via an update from the keyservers it gets:
0x18 subkey binding (timestamp 1)
0x28 subkey revocation (timestamp 2)
in addition.

> If an implementation doesn't follow the recommendation, then most of =20
> the bets are off. You can't really predict what it will do. Will it =20
> decide that signature 2 is revoked, and thus act on signature 1? =20
> Maybe. Will it decide that signature 1 is revoked, and thus act on =20
> signature 2? Maybe.
Ok I see. While I don't consider this to be a big problem in practice, I
think that this is an aesthetic problem with the spec as even an, in the
strict sense, conforming application could run into this problem.
I think this underlines Peter's and my point of view, that some future
RFC should clarify all this:
1. What MUST an implementation do with multiple self-sigs (and not what
is it RECOMMENDED to do).
2. Revocations SHOULD contain signature target subpackets.
3. And specifying the a revocation signature always applies to the
signature most recently to its own timestamp

(Of course 3. would be implied by 1.)
=20

> Again, though, I have to stress that this is RFC pedantic nitpickery. =20
> In the real world, no implementation does this, as it would make =20
> little sense.
Yea, of course,.. I fully know and agree with you! Please don't think
that I want to be annoying or offend your something like this :-)
I'm just a perfectionist ;-)

> > But on more thing: What I wrote above, with the "classes" and that it
> > applies only to the specific UID,.. this is actually true, right?
> I'm not sure I understand the question here.
I meant:
If I do a 0x30 certification revocation it _either_ applies only to
0x10s and 0x11s and 0x12s and 0x13s ... _or_ to 0x1Fs.
These two groups cannot be mixed, as they're calculated over different
data, and thus the revocation signature too.

Ok,... I think we have the same opinion now (ok, one of us is a little
bit more pedantic,.. don't wanna say names,..let's call him "Christoph
M." ;-) ) so we can stop this discussion here ^^.

Greets,

--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-GSnsBUe0sRY7Ps2M4u9D
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTE5MjYxNFowIwYJKoZIhvcNAQkEMRYEFESpI54qnbxV5Wj3vdj1dtSV8ClXMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AHD+/z40HQYQEhEpHkJyfcFDWDEa6EQnwHEPFI6AJLzo9OmDtqAZF0/s5UB4PeI3EZzg5ATtlR2E
Cb8zihTRd6UUB3OaMNT01tfJSxEvB935oqRE+10dttxjvHIO45bMAdFnSdne7Fu1RLH/tLk49LRd
ETZ9m+EGsQbNgBZlPOjwJ2I0tmGmBZBfmaC5S85seWfmZD/vJiEpCfAGaWuWKbf/ZM+znfSsB6yk
TLLqBkrD5C376hZfLG7LX33XzX10q2XSrMg5naO04YttwfebWQyTo5fGgoYHO5ZIpFLbOcjmjVlD
FWwjMuBtKmtPrO2/y0az/74S8fdCqOfEYWLRKBEAAAAAAAA=

--=-GSnsBUe0sRY7Ps2M4u9D--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11JF3b0001904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 12:15:03 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11JF3jB001903; Sun, 1 Feb 2009 12:15:03 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp132.rog.mail.re2.yahoo.com (smtp132.rog.mail.re2.yahoo.com [206.190.53.37]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n11JEp2t001887 for ; Sun, 1 Feb 2009 12:15:02 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 7382 invoked from network); 1 Feb 2009 19:14:51 -0000
Received: from unknown (HELO zentrumvegan) ([email-masked] with login) by smtp132.rog.mail.re2.yahoo.com with SMTP; 1 Feb 2009 19:14:51 -0000
X-YMail-OSG: Yim6seIVM1kJapqOJfHbtnchNC8zKK9Qg0DRafbM3.v11hrfDBMc8NG5qYsDh8IVXQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <7B23DB0E8D3F4ED0ACBB2F85987120C6@zentrumvegan>
From: "gerry_lowry \(alliston ontario canada\)"
To:
Subject: "newbie" questions: GPG a.k.a. GnuPG versus PGP corporation's products ... ; et cetera
Date: Sun, 1 Feb 2009 14:14:50 -0500
Organization: ability business computer services
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hello,

I'm calling myself a "newbie" with regards to PGP/GPG even though I've through my own
ignorance and incompetence orphaned keys back as far as September 1997. One day
my brain may, if I am lucky, reconnect with their corresponding passphrases so that
I can revoke them. I'm guessing there is a very large number of orphaned keys in the PGP universe.

I've read about PGP in Chey Cobb's "Cryptography for Dummies" and PGP/GPG in Michael W. Lucas'
"PGP & GPG: email for the practical paranoid". Also, I've used gnupg.pdf as a reference but have
yet to digest all of its 148 pages.

I live under the cloud of the virus a.k.a. Windows [XP, Vista, Server 2003, Server 2008].

gpg (GnuPG) 1.4.9
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), TWOFISH (S10)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10), SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)

Although there are GUI environments available, for the present, I am sticking with GnuPG and its
various command line tools until I understand them sufficiently to warrant investigating GUI tools.
The former MIT GUI distribution never integrated very well with Outlook Express, at least,
that was my experience. This is a second reason why I prefer command line tools.

QUESTION # 1: There seems to currently exist TWO forces in the PGP universe:

(a) GPG -- GnuPG (OpenPGP initiative)
(b) PGP -- PGP Corporation.

To what extent are their goals aligned? More specifically, since (b) is a corporation
which is driven by the profit motive and (a) would like to make a reasonable living
but is likely more open than the average corporate culture, it's likely more in the
interested of (b) to succeed in being universal but not too universal, i.e., to some
degree, (b) could grab more market share by being somewhat proprietary.
OTOH, it's possible AFAIK that (a) could not succeed without being 100%
compatible with (b).

QUESTION # 2: I have looked at http://www.biglumber.com/ ... http://biglumber.com/x/web?va=1:
"Total of 3190 listings (3107 people [442 with images], 83 events) in 79 countries and 1144 cities."
613 listings are expired; even if the 613 listings are NOT part
of the 3190 listings, "biglumber" is not very much in use.
http://pgp.mit.edu/ has been around for many years. It's possibly a better
indicator of how many keys their are ... sadly, it does not appear to offer
much in the way of statistics. OTOH, I almost never receive even PGP
signed e-mails. I spoke with a senior I.T. person recently who was
not even aware of PGP technology.

To what extent is GPG/PGP technology being used by e-mail users?
I'm guessing it must be less than 1% based on the many 1000's of
e-mails that I have received each month over the last decade.

I'll have more questions and I hope comments that you'll find useful later.

Thank you for your opinions.

Regards,
Gerry (Lowry)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11IG6od099961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 11:16:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11IG6Fw099960; Sun, 1 Feb 2009 11:16:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11IFsuP099951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 11:16:05 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw01.dd24.net (Postfix) with ESMTPA id 65CB07CC056; Sun, 1 Feb 2009 18:15:53 +0000 (GMT)
Subject: Re: Series of minor questions about OpenPGP 4
From: Christoph Anton Mitterer
To: Peter Thomas
Cc: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-LrNshLcOgTMz/B6AvVZO"
Date: Sun, 01 Feb 2009 19:15:51 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-LrNshLcOgTMz/B6AvVZO
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, 2009-02-01 at 00:41 +0100, Peter Thomas wrote:
> > Thus you cannot resign a subkey to un-revoke it.
> Uhm what do you mean with this?
He probably meant re-sign ;-)

> > In fact, there was a proposal for
> > perfect forward security in OpenPGP a few years ago that involved
> > generating new subkeys very frequently (even to the point of a new subk=
ey per message)
> Wouldn't this actually create new security problems? I'm by no means a
> crypto-expert, but AFAIK the more one uses a key to sign/encrypt data,
> the more it is likely that someone can use all this data for
> statistical attacks.
> And this would be especially bad for the primary key, as far as I underst=
and?
Personally I'm using my primary key just for signing other keys...

> I must apologize myself,.. but I don't understand this.
> The RFC must somehow specify which of the earlier self-signatures is
> revoked by it, or not? Or does it always revoke the MOST RECENT found
> signature BEFORE its own timestamp? If so where is this specified (I'm
> just curious, not that I wouldn't believe you ;-) )?
> And if that's the case we must remember that an implementation is
> allowed to use any self-signature, it's just RECOMMENDED to use the
> most recent.
Well I'm actually a little bit surprised about how revocation actually
works. This was not clear to me before, and without signature targets I
consider it somewhat wishy-washy.

> > This will work in GPG, but I don't think it is necessary -
> Sorry when I'm nasty, but just think of the example directly above
> this text? Or the other examples I gave (with the older self-signature
> using MD5 and the new SHAsomething, or other differing subpackets).
> Of course probably any reasonable implementation will follow the
> recommendation and just use the most recent self-sig like gnupg does
> (sig+sig+revoc), but others might not.
>=20
> What's the opinion on the others on this?
Well my opinion is - don't forget that I'm by no means an expert - that
this issue is not very dangerous at least in practice.
But on the other hand, I agree that _without_ signature targets there is
a chance for problems, especially when applications have their own
mechanism how to resolve ambiguities with multiple-self-sigs.

Even if an implementation follows the RFC RECOMMENDATION it could be
stupid:
Public Key
time 1: 0x1F on that key
time 2: 0x1F on that key
time 3: 0x30 on that key/0x1F's

In that order,.. the application might perhaps work (even then it could
be very stupid ^^) but consider the following order that an attacker
might give you:
Public Key
time 2: 0x1F on that key
time 1: 0x1F on that key
time 3: 0x30 on that key/0x1F's

Isn't this what Daniel had in mind?

But again, the practical impact is probably little as most
implementations behave reasonable (I assume gpg always orders all
signatures by time, before it looks at them?).
And that's probably why David sees not much of a problem here :-)
However I'd be curious what the other experts are thinking ;-)

So when will we see Signature Targets support in PGP and gnupg?! XD
Any voluntary to code? *G*

--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-LrNshLcOgTMz/B6AvVZO
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTE4MTU1MVowIwYJKoZIhvcNAQkEMRYEFP9KRNNCH9DAUBlI8cKS/VWPcn6eMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AH2uCT++k1LnLl51J/5MRNhmVZ+tvSakqHhDHuLXdPGogZDq9IjFvgSuJDxiiQVU+tgHZPUiAKs+
KxXEMJMNfQBqlzy0qDzmUce8T8UZDSBT1dTsHS5fjeeEp3rfK7wN84qGbue0eEOQK/1gwzFjGuIo
ama9kQDLjkbH/PXuKFk3m3tAKEt+1BJ+K/6QNhaztmhGQ90rFUlK3x+dbgBLoX8QfOu5AQ2x+otq
fd7yhxE5GSAYk62ne2/WcFVIgbZrLYm3fdAIO3qgJdtPoc3llIPqytU+syEbwQU8e8OO+/un5dcx
KT2EHHQmZ5LjcSlRQnjVHdCdB1pD426+CjTKD/4AAAAAAAA=

--=-LrNshLcOgTMz/B6AvVZO--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11IFqhl099947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 11:15:52 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11IFqiQ099946; Sun, 1 Feb 2009 11:15:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11IFnpQ099939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 11:15:51 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw02.dd24.net (Postfix) with ESMTPA id CE7FE354EB1 for ; Sun, 1 Feb 2009 18:15:48 +0000 (GMT)
Subject: Re: "Roles" for subkeys?!
From: Christoph Anton Mitterer
To: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-i//SKeBMXrNO7i/bzYdv"
Date: Sun, 01 Feb 2009 19:15:48 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-i//SKeBMXrNO7i/bzYdv
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Daniel.

On Sun, 2009-02-01 at 18:49 +0100, Daniel A. Nagy wrote:
> As far as I know, this is the primary use case for subkeys. I have a diff=
erent
> signature subkey on every computer that I use and the same encryption sub=
key.
> The primary key is not installed anywhere.
That's what I do, but additionally I have multiple encryption subkeys.

> I think that having different encryption subkeys is pointless.
Why? If I'd only have one single encryption subkey and if I'd store it
(including the private key) at work. Klaus our evil sysadmin (just
kidding ;) ) would not only be able to read my business mail, but also
encrypted data sent to my home-address. Or am I messing something up?

> While it is not
> in the standard (maybe it should), all OpenPGP implementations encrypt to=
the
> most recent valid encryption subkey.
I think that's the default (even with signing subkeys),... but e.g. in
gnupg you can simply specify the key you want to use, if I recall
correctly.

> > 2. When I make signatures with my different subkeys, I'd like that
> > people see it when I used my not-so-secure work signing subkey (perhaps
> > something that the user agent adds like + "(this is my
> > unsecury work signing key)".
> Not a bad idea. I think using the user id with your work email address in=
the
> corresponding subpacket would accomplish this.
Yes, but this wouldn't tell anybody which subkey to use in case of
encryption or to expect in case of signing.

Regards,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-i//SKeBMXrNO7i/bzYdv
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTE4MTU0OFowIwYJKoZIhvcNAQkEMRYEFAUuliwJQBeipaZyNTAvk6hTwikeMGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
ALAO2oRtW/QcVwDZ+MDbPj48o/uMf3J1o8Iy7SVFQ5uX9HjoYmGQDOvCFZg6ZwhJRGjM1smXa8H9
XMC0nZCPd/yHiINmmQQnVAZe2MqNt9FdGFbxCKhV7WWzVypOLdP1NPqg2fb2vRae9IThOngp38Js
5wwMWfb4TKow4DL9JISuLsTYdtgcW/fGmoNJZAiyCvd2KaL5m3MKU9Q9d6q8U2kq2QGV8rIPs8Jw
PuHzGAZb/jBh1sEg2qdsUmS2/x4dsaBwRDnd8ZlHeIfT4emVvD2ZffVwgOmlJVCCiOKhNEKmRXvO
m2EnIxiOMlTzHU6QtxRyvxH2pgUWOm4L1kzAbngAAAAAAAA=

--=-i//SKeBMXrNO7i/bzYdv--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11I6w6Z099322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 11:06:58 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11I6wKr099321; Sun, 1 Feb 2009 11:06:58 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11I6jAL099312 for ; Sun, 1 Feb 2009 11:06:57 -0700 (MST) (envelope-from [email-masked])
Received: by fxm13 with SMTP id 13so1151579fxm.10 for ; Sun, 01 Feb 2009 10:06:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=q+t0syNGIxF3uw89tNICaqxmBoHl71RHHJKB4jFPe6U=; b=b07yGhwRZlqliPP9YJgNyi5hF4flF3qFOxEIZ3mT6+Ilv+QhScx13u9CYR6HAcInKo yvXPJ5JFRI8NtQUgQO3WNiKwtTdx5SI4IhXqJC2EAjDIYbjFJQu8yxdKlZg5abh3g0ux HYRJhpiXvhqaqdmUvPSW2zRfLEg78qxMXl9Q4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Pr+shO8k4i3RkpDivejtXGTJ2AaONxl/2kG73h0TyEtyuWUrrLlNtqS9oJrOc/BCfH kV9hEdpMvKQX4LORZoI9lo/S5Z1ENh6OcfaOpfjTWfmnqpGhD1Rdb5sAAYF1noOqb3Kp c22xykUqAepD9ew0nusclC6gqbrd2OMbrS7q0=
MIME-Version: 1.0
Received: by 10.181.205.3 with SMTP id h3mr1343330bkq.91.1233511604719; Sun, 01 Feb 2009 10:06:44 -0800 (PST)
In-Reply-To:
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Sun, 1 Feb 2009 19:06:44 +0100
Message-ID: <[email-masked]>
Subject: Re: Series of minor questions about OpenPGP 4
From: Peter Thomas
To: OpenPGP
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Sun, Feb 1, 2009 at 4:17 AM, David Shaw wrote:
>>> That's a good question. The RFC specifies that a subkey may have one
>>> (and only one) binding signature, and zero or one revocations.
>> Wow,.. uhm could you please point me to the location that mandates this?
> Section 11.1. But notice what that section is: Transferable Public Keys.
> This doesn't really mean you *can't* re-sign a subkey. It just means that
> once you *have* re-signed a subkey, you need to remove the old signature
> (and revocation, if any) before you give the key to anyone else.
Uhm,.. ok I think I don't fully understand the whole issue.
As you've said, section 11.1 is just about transportation, and nothing more:
So in principle the following would be ok and allowed (AND they key
would be valid and ussable) by the standard:
Subkey
0x18 timestamp 1
0x28 timestamp 2 => revokes 0x18 from timestamp 1
0x18 timestamp 3
Right?
You just wouldn't be allowed to transport it.
But what does this actually mean? Would it follow from this, that if
an implementation or keyserver deletes the whole subkey, or just the
unrevoked part?
I must admit that I consider the standard to be a little bit unclear
in this issue, (don't take this personally of course ;-) ).

>>> Not exactly - it revokes one signature. However if there is more than
>>> one signature, the earlier signature should be superseded by the later
>>> one.
>> I must apologize myself,.. but I don't understand this.
>> The RFC must somehow specify which of the earlier self-signatures is
>> revoked by it, or not? Or does it always revoke the MOST RECENT found
>> signature BEFORE its own timestamp? If so where is this specified (I'm
>> just curious, not that I wouldn't believe you ;-) )?
> The RFC specifies the signature target which lets a revocation indicate
> which signature is being revoked.
Ok with signature targets it's clear.... but we talk when having no
signature targets, which seems to be currently the case in all
implementations, right?

> Aside from that, there is no indication
> at all beyond that the revocation is issued over the same data as the
> signature being revoked, and that it is dated after the original signature.
Ok,. but it MUST be an earlier one?

> It's not most recent, it's not least recent, it's simply not specified.
Wow... this means in principle,... that there is a "hole" in the RFC,
for those cases where an implementation doesn't follow the
recommendation to use the most recent self-signature, or am I wrong?

I mean if an implementation follows the advice to only use the most
recent self-signature the following example would be ok:
UserID
0x13 timestamp 1
0x13 timestamp 2
0x30 timestamp 3

The key holder wants obviously that both is revoked and it works the following:
1st: the timestamp 1 sig is replaced ("revoked") by the timestamp 2 sig
2nd: no there's only one left (the timestamp2 sig) which is than
revoked by the timestamp 3 sig

Right so far?

Even with reordering the packets an attacker could do nothign, e.g.:
UserID
0x13 timestamp 1
0x30 timestamp 3
0x13 timestamp 2
This could still be resolved as above.

But if an implementation doesn't follow that advice we could end up
with the following:
UserID
0x13 timestamp 1
0x13 timestamp 2
0x30 timestamp 3
No which one is revoked by the timestamp 3 sig? #1 or #2?

Even in such a case an implementation could do stupid things:
UserID
0x13 timestamp 1
0x30 timestamp 2
0x13 timestamp 3
0x30 timestamp 4

It could think that #4 revokes #1 (it is an earlier signature), then
#2 would be ineffective and #3 would remain.

I think I'm a little bit confused now xD

Cheers and thanks in advance,
Peter

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11Ho8Hc098805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 10:50:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11Ho8RV098804; Sun, 1 Feb 2009 10:50:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11Hnue4098786 for ; Sun, 1 Feb 2009 10:50:07 -0700 (MST) (envelope-from [email-masked])
Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 9983411A333; Sun, 1 Feb 2009 18:49:54 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 67FB2598099; Sun, 1 Feb 2009 19:48:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at mail.agileight.com
Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4prqv-aYyRX1; Sun, 1 Feb 2009 19:48:52 +0100 (CET)
Received: from [10.0.0.164] (unknown [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id 14142598092; Sun, 1 Feb 2009 19:48:51 +0100 (CET)
Message-ID: <[email-masked]>
Date: Sun, 01 Feb 2009 18:49:47 +0100
From: "Daniel A. Nagy"
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Christoph Anton Mitterer
CC: [email-masked]
Subject: Re: "Roles" for subkeys?!
References: <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigFA07B9848E836EF896D16436"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFA07B9848E836EF896D16436
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Christoph Anton Mitterer wrote:
> On advantage of subkeys is that one can use them independently from the=

> primaries, I mean you don't need a copy of the primary private key to
> decrypt data encrypted with a public encryption subkey, or you don't
> need it to sign data with the secret signing subkey.
> gnupg even has some options to create such crippled keys, and they're
> good to use in e.g. less secure like my work PC where every sysadmin
> have access to (Klaus, if you read this, it's not that I wouldn't trust=

> you ;) )...

As far as I know, this is the primary use case for subkeys. I have a diff=
erent
signature subkey on every computer that I use and the same encryption sub=
key.
The primary key is not installed anywhere.

> So far I don't need subkey roles,... but the problem now is,...
>=20
> 1. When some of my LHC/LCG/Grid/etc contacts sends me encrypted data,..=
=2E
> he doesn't know which encryption subkey to choose, as you've said.
> And thus I'll be probably unable to decrypt the message (at least at
> work).

I think that having different encryption subkeys is pointless. While it i=
s not
in the standard (maybe it should), all OpenPGP implementations encrypt to=
the
most recent valid encryption subkey.

> 2. When I make signatures with my different subkeys, I'd like that
> people see it when I used my not-so-secure work signing subkey (perhaps=

> something that the user agent adds like + "(this is my
> unsecury work signing key)".

Not a bad idea. I think using the user id with your work email address in=
the
corresponding subpacket would accomplish this.

> I know that this is currently not possibly to do this,.. but is there
> any interest for such things?

I think it is possible. See above.

--=20
Daniel

--------------enigFA07B9848E836EF896D16436
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkmF4MAACgkQi+vAY9cJzcLP6QCgobvZvK5tauKv366QJgilpA55
XZIAn2HPMNddFERChIjssdSYGkblzaSN
=bdNK
-----END PGP SIGNATURE-----

--------------enigFA07B9848E836EF896D16436--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11HLcr1098020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 10:21:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11HLbLq098019; Sun, 1 Feb 2009 10:21:37 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11HLPk4098005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 10:21:37 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw02.dd24.net (Postfix) with ESMTPA id 9188C354B68 for ; Sun, 1 Feb 2009 17:21:24 +0000 (GMT)
Subject: "Roles" for subkeys?!
From: Christoph Anton Mitterer
To: [email-masked]
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-LvY8W8jhbTfygc6AIHAj"
Date: Sun, 01 Feb 2009 18:21:23 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-LvY8W8jhbTfygc6AIHAj
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi WG!

Let me just pick the following from another thread up and fork it here:

On Sat, 2009-01-31 at 22:17 -0500, David Shaw wrote:
Subkeys aren't really usable for roles.
> I've always missed that,...

User IDs make great roles. =20
> Subkeys can be used by anyone who cares to, so if you have two =20
> encryption keys, even though you intend one for "home" and one for =20
> "work", you have no way to tell me which one you want me to use, and =20
> even if you did, I could use the other one if I wanted to.
On advantage of subkeys is that one can use them independently from the
primaries, I mean you don't need a copy of the primary private key to
decrypt data encrypted with a public encryption subkey, or you don't
need it to sign data with the secret signing subkey.
gnupg even has some options to create such crippled keys, and they're
good to use in e.g. less secure like my work PC where every sysadmin
have access to (Klaus, if you read this, it's not that I wouldn't trust
you ;) )...
So far I don't need subkey roles,... but the problem now is,...

1. When some of my LHC/LCG/Grid/etc contacts sends me encrypted data,...
he doesn't know which encryption subkey to choose, as you've said.
And thus I'll be probably unable to decrypt the message (at least at
work).

2. When I make signatures with my different subkeys, I'd like that
people see it when I used my not-so-secure work signing subkey (perhaps
something that the user agent adds like + "(this is my
unsecury work signing key)".

I know that this is currently not possibly to do this,.. but is there
any interest for such things?

Regards,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-LvY8W8jhbTfygc6AIHAj
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTE3MjEyM1owIwYJKoZIhvcNAQkEMRYEFLqqwKTUBa25BvOteuqLoRgxCJN3MGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AGFpkhLNgmdE7mrvF/0T0TKN3B0Q+kU/lEowMhRPihesCg01gAoT00h2wh/q//Sc8ycJDrd67n8T
gHjS6fslBqC2LKRDwFiESgwypMeARHyWs1ApbFF9KPIawGKkr06PGzvV6rmrt3UJENIabpaM3d04
1gdk+wG/h0ZzYdB3twVYDs4EAG3GZIsMHIYdWjowUF5UM8u4KmDqk6O4lg+bKt5q2xaQwlgnLsoP
b2oZWhDgqjREBRYY+3mrqKmwi2H8jxRt36f+tfVU9KcBzOYln5hf6XGXSSHvyKTOTCPnIVfU6tkX
eA4rUc4evqDZ/odAoj55CGv8gRDPEvKxRqZT84MAAAAAAAA=

--=-LvY8W8jhbTfygc6AIHAj--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11F4Cp5093078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 08:04:12 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n11F4CJ9093077; Sun, 1 Feb 2009 08:04:12 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11F3xNK093063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Feb 2009 08:04:11 -0700 (MST) (envelope-from [email-masked])
Received: from [192.168.0.101] (ppp-88-217-48-249.dynamic.mnet-online.de [88.217.48.249]) by mailgw01.dd24.net (Postfix) with ESMTPA id A11217CC0B6 for ; Sun, 1 Feb 2009 15:03:58 +0000 (GMT)
Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks
From: Christoph Anton Mitterer
To: [email-masked]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-CS8wATJdE90WL2LxdJ1i"
Date: Sun, 01 Feb 2009 16:03:57 +0100
Message-Id: <[email-masked]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--=-CS8wATJdE90WL2LxdJ1i
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, 2009-01-31 at 16:30 -0800, Wim Lewis wrote:
> One of the =20
> strengths of the PGP setup, I think, is that you don't have to trust =20
> the keyserver;
Well I think you already do this or better said, the whole PKI does it.
It's just not yet secured.

> An end-to-end approach is better, IMHO. (It also protects against the =20
> opposite side of the equation: is Mallory secretly stripping the =20
> revocation certificate out of your friend's uploads to the keyserver? =20
> Also, I don't want to have to make trust/policy decisions based on =20
> how much I trust the people running the keyserver, how strong my =20
> trust path is to their key, and so on. That way lies X.509...) =20
Yeah but again,.. I think you're already doing this, otherwise you'd
have to retrieve all you key updates manually from the key owners (e.g.
every day or so). Even worse, you'd also have to retrieve updates by the
signers to the keys of your keyrings, and their signers and so on..

> Notionally, I want some sort of periodic, signed communication from =20
> other keyholders, saying, "The official state of my key-and-=20
> subpackets is X. Expect another message before date Y".
But this is very difficult, as it's probably not enough to only get the
official state of the key of your direct contacts (see above)

> However, not =20
> all of the subpackets are really important: if I'm missing a =20
> signature from someone else,
But what if this signature is part of the trust path?

> or an alternate user ID, I'm not going =20
> to trust you any *more* than if I have it. So this thing only needs =20
> to cover packets which reduce trust --- revocations, I guess. (Am I =20
> missing a scenario here?)
I think you miss the case of keys, that you didn't sign yourself, but
have some indirect trust path to it.

> But is this actually any different from periodically renewing a set =20
> of expiring signatures? (I don't think so, but I could easily be =20
> missing stuff.) In which case, OpenPGP already supplies everything =20
> needed to prevent this sort of denial-of-key-distribution attack.
How?

> Of course I think securing the keyserver communication is *also* =20
> good, as long as the trust model doesn't depend on it. :)
I think it actually DOES depend on it. Even if you'd completely forget
keyservers and imagine that you directly exchange the keys with your
direct contacts (I mean that official most recent state of the key), you
could "loose" their revocation certs when an attacker strips them of.
So even in that case, your direct contact would have to sign the whole
key as if it would be casual data.

Or am I wrong?

Best wishes,
--=20
Christoph Anton Mitterer
Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

[email-masked]
[email-masked]

--=-CS8wATJdE90WL2LxdJ1i
Content-Type: application/x-pkcs7-signature; name=smime.p7s
Content-Disposition: attachment; filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw
ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD
VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw
HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50
b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG
SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I
al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp
KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE
bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep
GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw
ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp
Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5
MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB
MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV
HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl
cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16
hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE
cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY
laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW
kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe
UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+
8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY
NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov
Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ
rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF
BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y
ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx
OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ
ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h
bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc
1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni
X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp
F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV
APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA
GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB
hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0
byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor
BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF
BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh
Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC
AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG
SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC
ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/
5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU
GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2
11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP
zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY
HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/
5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT
cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1
dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1
NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6
Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI
hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty
kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo
qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+
lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV
O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD
rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq
Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/
KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6
JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ
92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF
BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC
hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx
BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG
9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR
wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT
uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf
HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi
qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK
bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX
pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW
YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj
oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS
bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL
ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/
MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTA5MDIwMTE1MDM1N1owIwYJKoZIhvcNAQkEMRYEFOUTpJi38/MfNisl9qFrRpi39v85MGkGCSsG
AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu
Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ
AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy
dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB
AGTPNL8m9cdJ+37V9b1FsTWPYarlWAKzYSvv0PlF4QQ6iVn+awkCTk8jTkhu91I7acR7zvTWsIvG
cfdsEVijtsYGw1X3alO+xKhVjcR6YH6AHJphDqgDdjbkWiX03UDlVuSZ/xetJiT+sLLXevMtZUpe
xhO0jIBV43d41UpWPXUGJW5bG01ypKnE1gZQrOYO34RqyNX7T1iz3+eBQSX0KdV79ZeOWT33uUAd
XFkC8lR4lpCZEhGpgMrwxszVKFEYRIKy9oJVmVlnce42J529ad6g+hzPZyiIwN4jcGAsqFdGB+ez
nYhW8OUfVFifi5ixX1nxuohp7hQomFVOKiHFvYkAAAAAAAA=

--=-CS8wATJdE90WL2LxdJ1i--