PGP Partitioned Encoding Format
hal@finney.org ("Hal Finney") Mon, 28 February 2005 23:58 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23239 for <openpgp-archive@lists.ietf.org>; Mon, 28 Feb 2005 18:58:15 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SNNUil016922; Mon, 28 Feb 2005 15:23:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SNNU9f016921; Mon, 28 Feb 2005 15:23:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SNNSIH016911 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 15:23:28 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 2E5DC57EBA; Mon, 28 Feb 2005 15:35:57 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: PGP Partitioned Encoding Format
Message-Id: <20050228233557.2E5DC57EBA@finney.org>
Date: Mon, 28 Feb 2005 15:35:57 -0800
From: hal@finney.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
A few weeks ago I sent a message describing PGP Corporation's new
notation packet, used to distinguish PGP-MIME support from the legacy
"partitioned" format. I got some feedback from that, but I need to make
it clear that this is an informative comment and that PGP is using its
own private namespace for notation packets. PGP is trying to "play nice"
by using this namespace and not the global namespace which the working
group manages.
PGP-MIME is well documented but the partitioned format used by earlier
versions of PGP has not been clearly described. I am providing more
detailed documentation of the partitioned format which has been used by
previous and current versions of PGP software in this message. The new
notation packet can be used to indicate support for this partitioned
format and/or for PGP-MIME.
Hal Finney
PGP Corporation
======================================================================
PGP Partitioned Encoding Format Technote
Copyright 2004-2005 PGP Corporation
All Rights Reserved
Introduction
"Partitioned Encoding" refers generally to the way PGP software
encrypted email in the days before the PGP/MIME specification. No
equivalent specification exists for messages encoded with PGP software
from that era. Partitioned Encoding is a term given to the evolved form
of this method of encoding. The primary goals of all additions to the
Partitioned Encoding format are backwards compatibility and email client
compatibility. Whereas PGP/MIME represents "correct" Internet standard
behavior resulting in efficient but potentially incompatible behavior,
Partitioned Encoding holds as its only goal the ability for all that
came before to decrypt the format either automatically or manually. This
document describes the general format of such messages and details a
few special cases.
Although the preferred encoding for new messages is PGP/MIME, Partitioned
Encoding is still in use, and in some scenarios is the most desirable
format. Because all PGP software can decrypt Partitioned Encoding
messages, this format is the best choice when backward compatibility is
important. Partitioned encoding has evolved over the years, the dialect
described here is the format used by current PGP products (PGP Universal).
One other example where Partitioned Encoding is often the best encoding to
use is when sending PGP email to mobile devices. Because the two primary
standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
body of an email including attachments as one part, a mobile device is
prevented from downloading only specific segments of the message which
can be very desirable in low-bandwidth scenarios.
Partitioned Encoding Overview
Each MIME part of a message is processed individually resulting in an
encoded MIME message much like the original but with encrypted/signed
content. The overall structure of a message is generally retained. A
text message with three attachments encrypts to an encrypted text message
with three encrypted attachments. An email follows Partitioned Encoding
via the following algorithm:
For every MIME part in a message, starting with the first:
If the part is a multipart container:
recursively encode the sub-parts.
For all other part types>
If the part is text/plain
encrypt/sign the part.
If the part is binary or a text type other than plain:
encrypt/sign the part as an attachment
when encrypting, headers are X- prefixed to prevent mail clients from interpreting them
when clear signing, corresponding <filename>.sig attachments are created
Each of these steps is further described below, with examples. For sake
of simplicity, not shown above is the special handling for the "Outlook
Plugin" dialect of Partitioned Encoding. This format is covered in a
separate section, below.
Example 1 shows a simple RFC-822 message and the resulting messages
after signing and encrypting. The straight-forward method used to encode
the email should be apparent. In both instances, the message content is
replaced by the PGP SDK output.
Example 1. A simple message
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> Soylent Green is PEOPLE!
Signed
> To: dcokenias@pgp.com.com
> From: Damon Cokenias <dcokenias@pgp.com.com>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Soylent Green is PEOPLE!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQYwc3wNUXR15SGMCEQJQfACfYFtobpQgt7/U2FTsHyiLOVQB6tgAni3T
> +Es5k0Bz4RGryRpM7CqxLqnw
> =LC7J
> -----END PGP SIGNATURE-----
Signed and Encrypted
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP MESSAGE-----
> Version: PGP Universal 1.2.2
>
> qANQR1DBwU4DjrZ+IglRIpQQB/4gPDVMliQnlJDeQmCiYe1iP56nZ476z0MB9vbI
> OP3z0lypOxJ871vh2EXf3EGITSkay+KdEY2CpSV2alqiBf21S5GS0llZ61IvDGo1
> gDyGiNGBkfNazAyNGYAYYkvNvjamPLmHfyqZqHEfCDDhqiIfXEIykUMImrFEHMsH
> UIvc1aPKxoaFsmzsSinIRYYSOZ/Gx29xXhrJhxJMXaSsnMp2Np/cOqcH6gK8wDrN
> FuurFRnW+up/O9iAw2moeOUqR2DocvRI7MJMkxArLCaGJL2zUxpIzRtedYlI8lRu
> ZE5ROP2rdinDnNf4JoI+2TMigA1R8GZiEKNcWIko+dQlMBqdB/4nghxYYW/PMm/B
> K47yrAqza8GxQEtzGDaOTsDioiH7bQThGG5qlna7odUTY4elHjNiT0qCHg0FCGZN
> iE+uIMBOBFFmZFzDOnmMtp9vuPLmI1+YpaHDfbwX3tQV3hdj2RFC2ofHB5Eh5Mzm
> 9T+5QPV9iUQDcDkus0/+3P/TPmtvAL/QB5WPUuNX7piZbsp7pvQn9BvT2i/ulZDn
> wPSoREhllnRjs3aTg5XrWkHFQ8I3QFfFhIVam9jHITwlAGkMmV7oK4flllAyK4Ui
> vJ+PsCVejuC1ZmSBbb97sw26+jSvr+PLO5ftvAi0FFb6Q2Dx1nYaE9UbAHX9JbC2
> 0qneMzIS0lYBjO7LVgoBDD4ayRqwAuu3RXqAzm02/JSpsIbD5Gr3bcLdvdKVCrCT
> IsCV2QEMYx4wiy3HjarYEO+z5Pztwcdx7PiTF8GAvMyfhmVxBpdqROM+Y6Jx0w==
> =JZf0
> -----END PGP MESSAGE-----
The second example, below, is more complex, showing a multipart message
composed of a text part and two binary attachments. Each MIME part
in the message is signed/encrypted separately. The text portion is
signed/encrypted exactly as in the first example. The binary attachments
get special treatment, however.
Signing/Encrypting Binary Parts
If the binary attachment being signed/encrypted does not have a filename,
it is given one. The attachment's name is "Attachment" + a number +
an extension. The number is a simple counter, starting at one, used to
ensure uniqueness. The extension is a three letter code inferred from
the part's MIME type. An anonymous binary attachment with Content-Type
of image/jpeg might be named "Attachment1.jpg", for example.
When a binary part is encrypted, the part's file name is hidden in
the encrypted data. The publicly-viewable name of an encrypted binary
part is always a generic name. Encrypted binary have a MIME type of
application/octet-stream. An encrypted part's headers are prefixed with
"X-Content-PGP-Universal-Saved-" to prevent them from being interpreted
by mail clients. When the part is decrypted, the process is reversed
and the original headers are reunited with the content. PGP products
before PGP Universal do not preserve these headers, but also generally
required manual opening of the attachments to decrypt them and thus no
functionality is lost for those scenarios.
When a binary part is clear-signed, a new attachment is created
to hold the signature. The MIME type of this attachment is
application/octet-stream. The signature attachment has the same name
as the signed part with ".sig" appended. These "detached signatures"
are base64 encoded.
Example 2. A more complex message
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-beige.gif"
> Content-Disposition: inline;
> filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
> . . . (cut) . . .
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-taupe.gif"
> Content-Disposition: inline;
> filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
> . . . (cut) . . .
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234--
Signed
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQZEXQmMQlGdKg9VZEQLl6QCgwFM2xtYzN0mJWcK9eYkU0ejiUqsAoOr6esBx8e1X
> mGBERfNK9ff0adY7
> -----END PGP SIGNATURE-----
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-beige.gif"
> Content-Disposition: attachment;
> filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
> . . . (cut) . . .
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-taupe.gif"
> Content-Disposition: attachment;
> filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
>
> . . . (cut) . . .
>
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> name="soylent-beige.gif.sig"
> Content-Disposition: attachment;
> filename="soylent-beige.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5dMjmJEnqAHpUrCKP/Xu8pB8JCgAn2shn2AKp913
> HAJt+LwN0AdtSDn3
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> name="soylent-taupe.gif.sig"
> Content-Disposition: attachment;
> filename="soylent-taupe.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5BusKlATEhfNiRbGhSlrUYlbPg4AnRLoX03Vo48H
> NoWukVfqSGyiQFV+
> --BOUNDARY-0000-1234--
Signed and Encrypted
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/wKGj60HNiMWCFZckprmNCIFSkfD0ZpRyYg0L65
> bbydP5KnPo266C5CEy4T11E2Xp11tMh6WjvRqalV8FDONpFLhV89k2JvX+rQ6W+o
> nbd5cW5XiflO2+5t/IlMdzSrdpr2Wn9GgZss0T/5FA7E1ayj2SNjffIVfKuXHDEk
>
> . . . (cut) . . .
>
> Td3A+VZ7VWkJPQKruA+IMnShEUsaFcfVSkpylSzwrcL1g5M7We1LGHgtGXT/ejJ0
> H3FeNtDw97dsmcc9oNFOHqwvQPt+h5dQfi3fGsT8Lw45VAePRjezZOn1zfVlf3Rc
> idkUaO2aW9A=
> =RqCL
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
> filename="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
> x-unix-mode=0644;
> name="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
> name="Attachment1.pgp"
> Content-Disposition: attachment;
> filename="Attachment1.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9yRpLW7rIulg2VxJTZps+MghHEaBptaYfA24Rf
> RvGv0y0xQDEpFYB5BY4BBbgUK+124K4c4ulaMGRMqsbqwTtzedUvqzuWEIqLdrhE
> 437c3hev2b3MiG/gVLz07O9S0FgZ1GxzTywWiCJSNIO1pKSRXN1BwDD2Yy7MLh9m
> 4uxYZzMMr0QTonzf1RoDCWm0tPL8n2sSR4D96yw+c0+FaFmPUEWtdHl43D1n752Y
>
> . . . (cut) . . .
>
> 1p5271ir9IBuQnHGd9azBhAxV+MndAcwhW006FF0H2Aw1DUWwJGA8ebXyVs8/Lp+
> nQYVAc88tl6seKo3dPCMGlTaBbVbmSHoqJadhqf6zl5+6nnFAlT31UmPlfOz
> =h4y5
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
> filename="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
> x-unix-mode=0644;
> name="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
> name="Attachment2.pgp"
> Content-Disposition: attachment;
> filename="Attachment2.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/0bA0TCswweIaDGLJXpTsrlMpEhCmNjGh53qeek
> /4r1XEwYPRVho/lUAaxtDNJ3mcAXekdlLxAtxdDRpypdRUz7yjPtcEB7P9wN8uWf
> 7AylCYd7ABvFmerenRZZ7Bc9TjHJWxnuoUWDsKlfeaOxqNgeiSZY4Q20HY0YZnTI
>
> . . . (cut) . . .
>
> D0urDVE2fFlpxjLPrPBrKf7wbo1+3ZUHjOgeElQTgChMOF5SgizEJlk2OLZoq/IO
> Ktu7v7jcQGPsKEyOC0Dzzhn33AeB06cU1sJV7gha6vrn0qfIXZQmGk3mzf4=
> =N7Wi
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--
HTML and RTF Encoding
PGP messages created by the PGP Plugin for Outlook (Windows) originally
defined a special attachment for storing HTML and RTF content for
compatibility purposes. PGP Universal has adopted this same formatting
for all HTML and RTF messages when using Partitioned Encoding. These
messages are readily identified by the presence of an attachment
called "PGPexch.htm.pgp", "PGPexch.htm.asc", "PGPexch.rtf.pgp" or
"PGPexch.rtf.asc". The attachment contains the encrypted RTF or HTML
portion of a multipart/alternative message.
This encoding should be used when signing/encrypting a
multipart/alternative message composed of exactly one plain text part and
one HTML part. Doing so ensures maximum compatibility for Windows users
with older PGP software. A multipart/alternative part with plain/html
subparts will become a multipart/mixed with an encrypted plain subpart
and an encrypted HTML attachment. A special header ("X-PGP-MIME-Structure:
alternative") is added to indicate this transformation was performed. This
header is not required for proper decoding.
When decrypting such messages, the "PGPexch.htm.pgp" or "PGPexch.htm.asc"
attachment will become the HTML alternative for the main body
text. Because RTF is not used for Internet mail, do not make RTF
attachments part of the message body. The RTF should be decrypted, but
should remain an attachment. The RTF attachment is useful only to Outlook.
Example 3. A multipart/alternative message with html and text parts
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/alternative;
> boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain
>
> Soylent Green is PEOPLE!
>
> --BOUNDARY-0000-1234
> Content-Type: text/html;
> charset=US-ASCII
>
> <html><body bgcolor="black" text="green">
> Soylent Green is <b>PEOPLE!</b>
> </body></html>
>
> --BOUNDARY-0000-1234--
Signed and Encrypted
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9KEBufHfz139ZuQCBushTxOenNzF5QzgqLkfTB
> h1a6y9XOfp1lox0Unx2s0cDcD1Vq2Ca/1kJvpYuPdnKyhwHSUZK9sE1RMSLM9sj/
> ng1FMHemyNb5NN+8T5jYFEE8KQlrNwpJfHXTgOkmeBrH749I2oHV/yhezYI9YqKI
>
> . . . (cut) . . .
>
> yIbvwHvS6HJeLjUylmRX+hplo2k/31JVg4b52z9Od3XEPptMYpvEKkpJUve6b3P2
> uLdxaT3vKep15UcdqitsbVVISxr6XZ+DZq4NKkrR73tt4eLhQlTWgZoYgac6QLuM
> Cg==
> =NOiI
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Type: text/html;
> charset=US-ASCII
> Content-Type: application/octet-stream;
> name="PGPexch.htm.pgp"
> Content-Disposition: attachment
> X-PGP-MIME-Structure: alternative
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/467rWcjfuimgRk44ifIqog/CpjSlitDbv/T+Kr
> JZqgEBP5CxwiO8G/Bgf2PpYOz2iiTDRycfFgwOktmkBvAYSatipSCwAWJ/UPcXXA
> uqQEnKyq+tZIibE9fDrbzObvgIHbe2M7HofiobQ0UAVb3/KaQphRM2sJ0ATotIbp
>
> . . . (cut) . . .
>
> TjQiuNqJfYlyWUrPUg7dTeSdSOnIm/zqLVQxm/+NB9SWaY+G3eqqBg6M/ytNaUwd
> jjBHOHh+6wPfkegmWP/8wxI58n6SV9d5OQ==
> =aD+v
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--
References
RFC 2440 OpenPGP Message Format
RFC 3156 MIME Security with Pretty Good Privacy
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SNNUil016922; Mon, 28 Feb 2005 15:23:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SNNU9f016921; Mon, 28 Feb 2005 15:23:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SNNSIH016911 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 15:23:28 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 2E5DC57EBA; Mon, 28 Feb 2005 15:35:57 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: PGP Partitioned Encoding Format
Message-Id: <20050228233557.2E5DC57EBA@finney.org>
Date: Mon, 28 Feb 2005 15:35:57 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
A few weeks ago I sent a message describing PGP Corporation's new
notation packet, used to distinguish PGP-MIME support from the legacy
"partitioned" format. I got some feedback from that, but I need to make
it clear that this is an informative comment and that PGP is using its
own private namespace for notation packets. PGP is trying to "play nice"
by using this namespace and not the global namespace which the working
group manages.
PGP-MIME is well documented but the partitioned format used by earlier
versions of PGP has not been clearly described. I am providing more
detailed documentation of the partitioned format which has been used by
previous and current versions of PGP software in this message. The new
notation packet can be used to indicate support for this partitioned
format and/or for PGP-MIME.
Hal Finney
PGP Corporation
======================================================================
PGP Partitioned Encoding Format Technote
Copyright 2004-2005 PGP Corporation
All Rights Reserved
Introduction
"Partitioned Encoding" refers generally to the way PGP software
encrypted email in the days before the PGP/MIME specification. No
equivalent specification exists for messages encoded with PGP software
from that era. Partitioned Encoding is a term given to the evolved form
of this method of encoding. The primary goals of all additions to the
Partitioned Encoding format are backwards compatibility and email client
compatibility. Whereas PGP/MIME represents "correct" Internet standard
behavior resulting in efficient but potentially incompatible behavior,
Partitioned Encoding holds as its only goal the ability for all that
came before to decrypt the format either automatically or manually. This
document describes the general format of such messages and details a
few special cases.
Although the preferred encoding for new messages is PGP/MIME, Partitioned
Encoding is still in use, and in some scenarios is the most desirable
format. Because all PGP software can decrypt Partitioned Encoding
messages, this format is the best choice when backward compatibility is
important. Partitioned encoding has evolved over the years, the dialect
described here is the format used by current PGP products (PGP Universal).
One other example where Partitioned Encoding is often the best encoding to
use is when sending PGP email to mobile devices. Because the two primary
standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
body of an email including attachments as one part, a mobile device is
prevented from downloading only specific segments of the message which
can be very desirable in low-bandwidth scenarios.
Partitioned Encoding Overview
Each MIME part of a message is processed individually resulting in an
encoded MIME message much like the original but with encrypted/signed
content. The overall structure of a message is generally retained. A
text message with three attachments encrypts to an encrypted text message
with three encrypted attachments. An email follows Partitioned Encoding
via the following algorithm:
For every MIME part in a message, starting with the first:
If the part is a multipart container:
recursively encode the sub-parts.
For all other part types>
If the part is text/plain
encrypt/sign the part.
If the part is binary or a text type other than plain:
encrypt/sign the part as an attachment
when encrypting, headers are X- prefixed to prevent mail clients from interpreting them
when clear signing, corresponding <filename>.sig attachments are created
Each of these steps is further described below, with examples. For sake
of simplicity, not shown above is the special handling for the "Outlook
Plugin" dialect of Partitioned Encoding. This format is covered in a
separate section, below.
Example 1 shows a simple RFC-822 message and the resulting messages
after signing and encrypting. The straight-forward method used to encode
the email should be apparent. In both instances, the message content is
replaced by the PGP SDK output.
Example 1. A simple message
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> Soylent Green is PEOPLE!
Signed
> To: dcokenias@pgp.com.com
> From: Damon Cokenias <dcokenias@pgp.com.com>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Soylent Green is PEOPLE!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQYwc3wNUXR15SGMCEQJQfACfYFtobpQgt7/U2FTsHyiLOVQB6tgAni3T
> +Es5k0Bz4RGryRpM7CqxLqnw
> =LC7J
> -----END PGP SIGNATURE-----
Signed and Encrypted
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Simple Message
> Date: Mon, 1 Nov 2004 16:21:00 -0800
>
> -----BEGIN PGP MESSAGE-----
> Version: PGP Universal 1.2.2
>
> qANQR1DBwU4DjrZ+IglRIpQQB/4gPDVMliQnlJDeQmCiYe1iP56nZ476z0MB9vbI
> OP3z0lypOxJ871vh2EXf3EGITSkay+KdEY2CpSV2alqiBf21S5GS0llZ61IvDGo1
> gDyGiNGBkfNazAyNGYAYYkvNvjamPLmHfyqZqHEfCDDhqiIfXEIykUMImrFEHMsH
> UIvc1aPKxoaFsmzsSinIRYYSOZ/Gx29xXhrJhxJMXaSsnMp2Np/cOqcH6gK8wDrN
> FuurFRnW+up/O9iAw2moeOUqR2DocvRI7MJMkxArLCaGJL2zUxpIzRtedYlI8lRu
> ZE5ROP2rdinDnNf4JoI+2TMigA1R8GZiEKNcWIko+dQlMBqdB/4nghxYYW/PMm/B
> K47yrAqza8GxQEtzGDaOTsDioiH7bQThGG5qlna7odUTY4elHjNiT0qCHg0FCGZN
> iE+uIMBOBFFmZFzDOnmMtp9vuPLmI1+YpaHDfbwX3tQV3hdj2RFC2ofHB5Eh5Mzm
> 9T+5QPV9iUQDcDkus0/+3P/TPmtvAL/QB5WPUuNX7piZbsp7pvQn9BvT2i/ulZDn
> wPSoREhllnRjs3aTg5XrWkHFQ8I3QFfFhIVam9jHITwlAGkMmV7oK4flllAyK4Ui
> vJ+PsCVejuC1ZmSBbb97sw26+jSvr+PLO5ftvAi0FFb6Q2Dx1nYaE9UbAHX9JbC2
> 0qneMzIS0lYBjO7LVgoBDD4ayRqwAuu3RXqAzm02/JSpsIbD5Gr3bcLdvdKVCrCT
> IsCV2QEMYx4wiy3HjarYEO+z5Pztwcdx7PiTF8GAvMyfhmVxBpdqROM+Y6Jx0w==
> =JZf0
> -----END PGP MESSAGE-----
The second example, below, is more complex, showing a multipart message
composed of a text part and two binary attachments. Each MIME part
in the message is signed/encrypted separately. The text portion is
signed/encrypted exactly as in the first example. The binary attachments
get special treatment, however.
Signing/Encrypting Binary Parts
If the binary attachment being signed/encrypted does not have a filename,
it is given one. The attachment's name is "Attachment" + a number +
an extension. The number is a simple counter, starting at one, used to
ensure uniqueness. The extension is a three letter code inferred from
the part's MIME type. An anonymous binary attachment with Content-Type
of image/jpeg might be named "Attachment1.jpg", for example.
When a binary part is encrypted, the part's file name is hidden in
the encrypted data. The publicly-viewable name of an encrypted binary
part is always a generic name. Encrypted binary have a MIME type of
application/octet-stream. An encrypted part's headers are prefixed with
"X-Content-PGP-Universal-Saved-" to prevent them from being interpreted
by mail clients. When the part is decrypted, the process is reversed
and the original headers are reunited with the content. PGP products
before PGP Universal do not preserve these headers, but also generally
required manual opening of the attachments to decrypt them and thus no
functionality is lost for those scenarios.
When a binary part is clear-signed, a new attachment is created
to hold the signature. The MIME type of this attachment is
application/octet-stream. The signature attachment has the same name
as the signed part with ".sig" appended. These "detached signatures"
are base64 encoded.
Example 2. A more complex message
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-beige.gif"
> Content-Disposition: inline;
> filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
> . . . (cut) . . .
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-taupe.gif"
> Content-Disposition: inline;
> filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
> . . . (cut) . . .
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234--
Signed
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All,
>
> Marketing materials for our new product line are enclosed. Please have
> feedback ready by Thursday lunch!
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 1.2.2
>
> iQA/AwUBQZEXQmMQlGdKg9VZEQLl6QCgwFM2xtYzN0mJWcK9eYkU0ejiUqsAoOr6esBx8e1X
> mGBERfNK9ff0adY7
> -----END PGP SIGNATURE-----
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-beige.gif"
> Content-Disposition: attachment;
> filename=soylent-beige.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
> 1InA23i31luozkmeyGiv0czk8KTP5NDm8VqnzXO11fb6/PX6/HK01aDM4vL4+8Le7I7D3UugyaPO
>
> . . . (cut) . . .
>
> a40HBBk0LIYtewYMTllgQxU+hCIXGAZwT1JBfHZkgwMfZhtbQHNpOEU8gxYQL18bXDo9Am1hxgBe
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: base64
> Content-Type: image/gif;
> x-unix-mode=0644;
> name="soylent-taupe.gif"
> Content-Disposition: attachment;
> filename=soylent-taupe.gif
>
> R0lGODlhDgAZAOZ9AF6pzm2x02yx02Ks0GOs0Gqw0kadx7LW6HCz1HS11Weu0dvs9EGaxrTX6dLn
> 8ValzFmnzVemzE6hylimzXe31kedx12pzk+hykufyW+y01Kjy0ygydTo8t3t9XK01FSky9jq83G0
>
> . . . (cut) . . .
>
> Dz9JJXUIUTuDCgRWVw8aEkwJDCmDAiYHRiQRchcUBkeDlgRoIKYLngkflMxwMIhDDgcFmoiYdscN
> mkJVMhQgMgAAog4JENhQ93HEFCH2EIEIMOJMiACIOKgoACWOB0Q1KkSQwYYCojF5UMRooKZRo0AA
> Ow==
>
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> name="soylent-beige.gif.sig"
> Content-Disposition: attachment;
> filename="soylent-beige.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5dMjmJEnqAHpUrCKP/Xu8pB8JCgAn2shn2AKp913
> HAJt+LwN0AdtSDn3
> --BOUNDARY-0000-1234
> Content-Type: application/octet-stream;
> name="soylent-taupe.gif.sig"
> Content-Disposition: attachment;
> filename="soylent-taupe.gif.sig"
> Content-Transfer-Encoding: base64
>
> iQA/AwUAQZEXQmMQlGdKg9VZEQKnbgCg5BusKlATEhfNiRbGhSlrUYlbPg4AnRLoX03Vo48H
> NoWukVfqSGyiQFV+
> --BOUNDARY-0000-1234--
Signed and Encrypted
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: New Products
> Date: Mon, 1 Nov 2004 16:01:00 -0700
>
> --BOUNDARY-0000-1234
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain;
> charset=US-ASCII
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/wKGj60HNiMWCFZckprmNCIFSkfD0ZpRyYg0L65
> bbydP5KnPo266C5CEy4T11E2Xp11tMh6WjvRqalV8FDONpFLhV89k2JvX+rQ6W+o
> nbd5cW5XiflO2+5t/IlMdzSrdpr2Wn9GgZss0T/5FA7E1ayj2SNjffIVfKuXHDEk
>
> . . . (cut) . . .
>
> Td3A+VZ7VWkJPQKruA+IMnShEUsaFcfVSkpylSzwrcL1g5M7We1LGHgtGXT/ejJ0
> H3FeNtDw97dsmcc9oNFOHqwvQPt+h5dQfi3fGsT8Lw45VAePRjezZOn1zfVlf3Rc
> idkUaO2aW9A=
> =RqCL
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
> filename="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
> x-unix-mode=0644;
> name="Attachment1.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
> name="Attachment1.pgp"
> Content-Disposition: attachment;
> filename="Attachment1.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9yRpLW7rIulg2VxJTZps+MghHEaBptaYfA24Rf
> RvGv0y0xQDEpFYB5BY4BBbgUK+124K4c4ulaMGRMqsbqwTtzedUvqzuWEIqLdrhE
> 437c3hev2b3MiG/gVLz07O9S0FgZ1GxzTywWiCJSNIO1pKSRXN1BwDD2Yy7MLh9m
> 4uxYZzMMr0QTonzf1RoDCWm0tPL8n2sSR4D96yw+c0+FaFmPUEWtdHl43D1n752Y
>
> . . . (cut) . . .
>
> 1p5271ir9IBuQnHGd9azBhAxV+MndAcwhW006FF0H2Aw1DUWwJGA8ebXyVs8/Lp+
> nQYVAc88tl6seKo3dPCMGlTaBbVbmSHoqJadhqf6zl5+6nnFAlT31UmPlfOz
> =h4y5
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Disposition: inline;
> filename="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Type: image/gif;
> x-unix-mode=0644;
> name="Attachment2.pgp"
> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64
> Content-Type: application/octet-stream;
> name="Attachment2.pgp"
> Content-Disposition: attachment;
> filename="Attachment2.pgp"
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/0bA0TCswweIaDGLJXpTsrlMpEhCmNjGh53qeek
> /4r1XEwYPRVho/lUAaxtDNJ3mcAXekdlLxAtxdDRpypdRUz7yjPtcEB7P9wN8uWf
> 7AylCYd7ABvFmerenRZZ7Bc9TjHJWxnuoUWDsKlfeaOxqNgeiSZY4Q20HY0YZnTI
>
> . . . (cut) . . .
>
> D0urDVE2fFlpxjLPrPBrKf7wbo1+3ZUHjOgeElQTgChMOF5SgizEJlk2OLZoq/IO
> Ktu7v7jcQGPsKEyOC0Dzzhn33AeB06cU1sJV7gha6vrn0qfIXZQmGk3mzf4=
> =N7Wi
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--
HTML and RTF Encoding
PGP messages created by the PGP Plugin for Outlook (Windows) originally
defined a special attachment for storing HTML and RTF content for
compatibility purposes. PGP Universal has adopted this same formatting
for all HTML and RTF messages when using Partitioned Encoding. These
messages are readily identified by the presence of an attachment
called "PGPexch.htm.pgp", "PGPexch.htm.asc", "PGPexch.rtf.pgp" or
"PGPexch.rtf.asc". The attachment contains the encrypted RTF or HTML
portion of a multipart/alternative message.
This encoding should be used when signing/encrypting a
multipart/alternative message composed of exactly one plain text part and
one HTML part. Doing so ensures maximum compatibility for Windows users
with older PGP software. A multipart/alternative part with plain/html
subparts will become a multipart/mixed with an encrypted plain subpart
and an encrypted HTML attachment. A special header ("X-PGP-MIME-Structure:
alternative") is added to indicate this transformation was performed. This
header is not required for proper decoding.
When decrypting such messages, the "PGPexch.htm.pgp" or "PGPexch.htm.asc"
attachment will become the HTML alternative for the main body
text. Because RTF is not used for Internet mail, do not make RTF
attachments part of the message body. The RTF should be decrypted, but
should remain an attachment. The RTF attachment is useful only to Outlook.
Example 3. A multipart/alternative message with html and text parts
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/alternative;
> boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain
>
> Soylent Green is PEOPLE!
>
> --BOUNDARY-0000-1234
> Content-Type: text/html;
> charset=US-ASCII
>
> <html><body bgcolor="black" text="green">
> Soylent Green is <b>PEOPLE!</b>
> </body></html>
>
> --BOUNDARY-0000-1234--
Signed and Encrypted
> Mime-Version: 1.0
> To: dcokenias@pgp.com
> From: Damon Cokenias <dcokenias@pgp.com>
> Subject: Outlook Encoding
> Date: Mon, 1 Nov 2004 16:21:00 -0800
> Content-Type: multipart/mixed;
> boundary="BOUNDARY-0000-1234"
>
> This is a multipart message in MIME format.
>
> --BOUNDARY-0000-1234
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/9KEBufHfz139ZuQCBushTxOenNzF5QzgqLkfTB
> h1a6y9XOfp1lox0Unx2s0cDcD1Vq2Ca/1kJvpYuPdnKyhwHSUZK9sE1RMSLM9sj/
> ng1FMHemyNb5NN+8T5jYFEE8KQlrNwpJfHXTgOkmeBrH749I2oHV/yhezYI9YqKI
>
> . . . (cut) . . .
>
> yIbvwHvS6HJeLjUylmRX+hplo2k/31JVg4b52z9Od3XEPptMYpvEKkpJUve6b3P2
> uLdxaT3vKep15UcdqitsbVVISxr6XZ+DZq4NKkrR73tt4eLhQlTWgZoYgac6QLuM
> Cg==
> =NOiI
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234
> X-Content-PGP-Universal-Saved-Content-Type: text/html;
> charset=US-ASCII
> Content-Type: application/octet-stream;
> name="PGPexch.htm.pgp"
> Content-Disposition: attachment
> X-PGP-MIME-Structure: alternative
>
> -----BEGIN PGP MESSAGE-----
> Version: 0
>
> qANQR1DBwEwD42FWyEinTuQBB/467rWcjfuimgRk44ifIqog/CpjSlitDbv/T+Kr
> JZqgEBP5CxwiO8G/Bgf2PpYOz2iiTDRycfFgwOktmkBvAYSatipSCwAWJ/UPcXXA
> uqQEnKyq+tZIibE9fDrbzObvgIHbe2M7HofiobQ0UAVb3/KaQphRM2sJ0ATotIbp
>
> . . . (cut) . . .
>
> TjQiuNqJfYlyWUrPUg7dTeSdSOnIm/zqLVQxm/+NB9SWaY+G3eqqBg6M/ytNaUwd
> jjBHOHh+6wPfkegmWP/8wxI58n6SV9d5OQ==
> =aD+v
> -----END PGP MESSAGE-----
>
> --BOUNDARY-0000-1234--
References
RFC 2440 OpenPGP Message Format
RFC 3156 MIME Security with Pretty Good Privacy
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SJoV2i001316; Mon, 28 Feb 2005 11:50:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SJoVKZ001314; Mon, 28 Feb 2005 11:50:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SJoTj0001295 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 11:50:30 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1SKnra04767 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 20:50:09 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <42237702.50604@systemics.com>
Date: Mon, 28 Feb 2005 19:54:42 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
Subject: Re: Forward Secrecy
References: <20050228184109.2C6BA57EBA@finney.org>
In-Reply-To: <20050228184109.2C6BA57EBA@finney.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hal Finney wrote:
>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.
>
> Using a series of encryption keys, each with a short lifetime,
> reduces the information revealed by the compromise of any one private
> key because each key protects less data. If expired keys are
> securely deleted, attackers will never be able to retrieve them to
> decrypt captured ciphertext. Therefore when a public encryption key
> expires, an OpenPGP client MUST securely wipe the corresponding
> private key [4].
>
>I don't agree that OpenPGP clients MUST always securely wipe expired
>private keys. In the context of a user who wants PFS, this makes sense.
>But for a user who wants to be sure he can decrypt his messages, this
>is a bad policy. For example, some mail systems may store the messages
>in encrypted form, and he needs to keep the key around in order to read
>those messages in the future.
>
>
I'm inclined to think that this would be bad
practice. If a mail system were to want to
keep mail around for encryption purposes,
I'd say it should re-encrypt the packet using
a local key.
The alternate - saving the encrypted message
in the form as it was sent over the network -
leads to all sorts of key management trouble
later on. It means that keys have to be kept
around for as long as the oldest email, which
isn't really likely to please anyone.
>But this leads to a larger concern, which is that much of this draft
>specifies client behavior in a manner which has traditionally been out
>of scope for our working group. We would not normally propose to give
>guidelines for UI such as the existence of a panic mode, and how clients
>should respond to it. For example, we do not attempt to prescribe how
>client software should display signed messages, what information should
>be shown from a signature, or how to depict messages which are partially
>signed and partially unsigned.
>
>
I'd agree with that. Although, if PFS is to
be achieved, a certain amount of guidance
would be required ... to explain things like
"must wipe the transport key after re-encrypting."
>I won't try to go through the rest of the draft at this time. As I said,
>I support the goal of PFS, but I am skeptical about whether it makes
>sense for our WG to promulgate such detailed advice on a relatively
>narrow aspect of security.
>
>
One comment - the URL points to an ID, a draft
presumably heading for standards track. Would
it make more sense to specify a more client-oriented
document if it was informational track?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SISfTu094779; Mon, 28 Feb 2005 10:28:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SISfX0094778; Mon, 28 Feb 2005 10:28:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SISe0k094761 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 10:28:41 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 2C6BA57EBA; Mon, 28 Feb 2005 10:41:09 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: Re: Forward Secrecy
Message-Id: <20050228184109.2C6BA57EBA@finney.org>
Date: Mon, 28 Feb 2005 10:41:09 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I think we had some discussion of this a few years ago, but I don't
have my records handy. I do like the idea of forward secrecy but I
think there are a few problems with the proposals in the draft
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.
Using a series of encryption keys, each with a short lifetime,
reduces the information revealed by the compromise of any one private
key because each key protects less data. If expired keys are
securely deleted, attackers will never be able to retrieve them to
decrypt captured ciphertext. Therefore when a public encryption key
expires, an OpenPGP client MUST securely wipe the corresponding
private key [4].
I don't agree that OpenPGP clients MUST always securely wipe expired
private keys. In the context of a user who wants PFS, this makes sense.
But for a user who wants to be sure he can decrypt his messages, this
is a bad policy. For example, some mail systems may store the messages
in encrypted form, and he needs to keep the key around in order to read
those messages in the future.
We would need to make the wording clear that this is only for clients
operating in "PFS mode".
Deletion should take place once all messages that could have been
sent before expiry have been received and decrypted. For example, as
a user logs on, their mail client SHOULD retrieve and decrypt all
messages from their mail server before deleting any newly-expired
private keys. A "panic mode" MAY bypass this step.
I guess that "panic mode" means some command the user could give to
immediately delete all expired decryption keys.
But this leads to a larger concern, which is that much of this draft
specifies client behavior in a manner which has traditionally been out
of scope for our working group. We would not normally propose to give
guidelines for UI such as the existence of a panic mode, and how clients
should respond to it. For example, we do not attempt to prescribe how
client software should display signed messages, what information should
be shown from a signature, or how to depict messages which are partially
signed and partially unsigned.
The PFS draft is full of detailed recommendations about client behavior.
Here, it describes how and when clients should access the mail server.
Later, it talks about clients sending various warnings to each other,
generating keys in the background, and revoking keys before exporting
the private part. The main thrust of the draft is towards specifying
client behavior.
My principle concern is that since we have eschewed such specifications
even for the more fundamental task of communicating securely via email,
does it make sense to go into such detail for a rather more specialized
sub-task, of achieving PFS in the process? Here is another example:
Clients receiving messages encrypted with a revoked key MUST warn the
sender that they should not use that public key again. Any relevant
key revocation certificates MUST be included in the warning.
This is not really PFS specific, and it may be a good idea, but it is
exactly the kind of thing which we have left out of the OpenPGP spec.
There are too many issues involved in the design of a mail user agent
for a secure email system, for us to try to capture them in a spec.
I won't try to go through the rest of the draft at this time. As I said,
I support the goal of PFS, but I am skeptical about whether it makes
sense for our WG to promulgate such detailed advice on a relatively
narrow aspect of security.
Hal Finney
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SH1vwF086236; Mon, 28 Feb 2005 09:01:57 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SH1viX086235; Mon, 28 Feb 2005 09:01:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SH1m5Z086170 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 09:01:49 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A251A33C33; Mon, 28 Feb 2005 17:01:35 +0000 (GMT)
Message-ID: <42234DF9.7040803@algroup.co.uk>
Date: Mon, 28 Feb 2005 16:59:37 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Derek Atkins <derek@ihtfp.com>
Cc: agenda@ietf.org, ietf-openpgp@imc.org
Subject: Re: OpenPGP Agenda for IETF-62
References: <sjmk6os1vql.fsf@dogbert.ihtfp.org>
In-Reply-To: <sjmk6os1vql.fsf@dogbert.ihtfp.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Derek Atkins wrote:
> OpenPGP is scheduled to meet at IETF-62 in Minneapolis:
>
> TUESDAY, March 8, 2005
> 0900-1130 Morning Sessions
> SEC openpgp An Open Specification for Pretty Good Privacy WG
>
>
> The Agenda for this meeting:
>
> ?? - ?? PFS (Ben Laurie?)
Sure thing.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGh1Ib084904; Mon, 28 Feb 2005 08:43:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SGh1Vx084903; Mon, 28 Feb 2005 08:43:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGh0vM084897 for <ietf-openpgp@imc.org>; Mon, 28 Feb 2005 08:43:01 -0800 (PST) (envelope-from warlord@MIT.EDU)
Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id j1SGgwIT006381; Mon, 28 Feb 2005 11:42:58 -0500
From: Derek Atkins <derek@ihtfp.com>
To: agenda@ietf.org
Cc: ietf-openpgp@imc.org
Subject: OpenPGP Agenda for IETF-62
Date: Mon, 28 Feb 2005 11:42:58 -0500
Message-ID: <sjmk6os1vql.fsf@dogbert.ihtfp.org>
User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
OpenPGP is scheduled to meet at IETF-62 in Minneapolis:
TUESDAY, March 8, 2005
0900-1130 Morning Sessions
SEC openpgp An Open Specification for Pretty Good Privacy WG
The Agenda for this meeting:
:00 - :05 Agenda Bashing
Find Secretary / Jabber Scribe
:05 - :35 draft-ietf-openpgp-rfc2440bis editorial status (Jon Callas?)
:35 - ?? Discussion of Open Issues (Jon?)
?? - ?? PFS (Ben Laurie?)
Proposed names are suggested presenters and may be changed.
-derek
--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RNSPNQ071580; Sun, 27 Feb 2005 15:28:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RNSPXl071579; Sun, 27 Feb 2005 15:28:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RNSJa6071570 for <ietf-openpgp@imc.org>; Sun, 27 Feb 2005 15:28:20 -0800 (PST) (envelope-from fw@deneb.enyo.de)
Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1D5WnN-0004kz-Ha; Sun, 27 Feb 2005 23:21:49 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.50) id 1D5WnL-00012d-Eo; Sun, 27 Feb 2005 23:21:47 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Jon Callas <jon@callas.org>
Cc: Rick van Rein <rick@openfortress.nl>, ietf-openpgp@imc.org
Subject: Re: Tighter MPI spec
References: <20050224093032.GA98866@phantom.vanrein.org> <0a5ed6016f5c7d1ecd1ef3e4c1dad620@callas.org> <20050225195202.GA29679@phantom.vanrein.org> <078d807c80e952b628b386fa0c33061a@callas.org>
Date: Sun, 27 Feb 2005 23:21:47 +0100
In-Reply-To: <078d807c80e952b628b386fa0c33061a@callas.org> (Jon Callas's message of "Fri, 25 Feb 2005 18:12:04 -0800")
Message-ID: <87k6otfxtw.fsf@deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
* Jon Callas:
> This language has been sitting in 2440 and followons since '97. No one
> has ever had a problem implementing it, no one has had an
> interoperability issue with bignums. Not PGP, nor GnuPG, nor Hushmail,
> nor Cryptix, nor Forum, nor Bouncy Castle, nor anyone else.
Not true. GnuPG had a bug in MPI handling because it followed the
language in RFC 2440 too verbatim. 8-)
(You added a hint to 2440bis a few years ago, so others hopefully
won't make the same mistake.)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1QClTA5079156; Sat, 26 Feb 2005 04:47:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1QClT9q079155; Sat, 26 Feb 2005 04:47:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1QClR1u079146 for <ietf-openpgp@imc.org>; Sat, 26 Feb 2005 04:47:28 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id B1F2333C2E; Sat, 26 Feb 2005 12:47:16 +0000 (GMT)
Message-ID: <42206F5C.2030004@algroup.co.uk>
Date: Sat, 26 Feb 2005 12:45:16 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <jon@callas.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: More questions and comments on rfc2440bis-12
References: <421C6AEF.5030608@algroup.co.uk> <20050225162716.GA1778@jabberwocky.com> <421F5DD6.1090204@algroup.co.uk> <20050225181128.GB1778@jabberwocky.com> <d2bf815aed39698a385baccc0f2de121@callas.org>
In-Reply-To: <d2bf815aed39698a385baccc0f2de121@callas.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Jon Callas wrote:
>
> On other certification types:
>
> Apart from what David said about GnuPG, no one has ever done any sort of
> certification other than the 0x10 certification signatures. (By that I
> mean that there's never been a program that actually went to the trouble
> of creating a UI that effectively said, "How good do you think this
> certification is?")
>
> At one point, we removed them from OpenPGP because no one used them.
> They were put in because the working group liked the expressiveness of
> the language even if no one was expressing themselves that way. I think
> that discussion is still valid and don't see a reason to change it. The
> different degrees of certification are in the OpenPGP language because
> we as a group think they should be there.
OK, then the explanation could perhaps be improved.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1Q2BaBx038168; Fri, 25 Feb 2005 18:11:36 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1Q2BaFR038167; Fri, 25 Feb 2005 18:11:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1Q2BV9j038144 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 18:11:31 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Fri, 25 Feb 2005 18:11:21 -0800
Received: from [172.16.1.2] ([66.46.153.63]) by keys.merrymeet.com (PGP Universal service); Fri, 25 Feb 2005 18:11:21 -0800
X-PGP-Universal: processed
In-Reply-To: <20050225195202.GA29679@phantom.vanrein.org>
References: <20050224093032.GA98866@phantom.vanrein.org> <0a5ed6016f5c7d1ecd1ef3e4c1dad620@callas.org> <20050225195202.GA29679@phantom.vanrein.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <078d807c80e952b628b386fa0c33061a@callas.org>
Content-Transfer-Encoding: 7bit
Cc: ietf-openpgp@imc.org
From: Jon Callas <jon@callas.org>
Subject: Re: Tighter MPI spec
Date: Fri, 25 Feb 2005 18:12:04 -0800
To: Rick van Rein <rick@openfortress.nl>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On 25 Feb 2005, at 11:52 AM, Rick van Rein wrote:
> The specification of the MPI format has a *flaw* that forces compliant
> implementations to do more work than desired or intended. This is
> outright embarassing in a standard.
>
Perhaps I'm just stupid, but I don't see what the ambiguity is, or what
needs to be fixed, other than that you've changed the explanatory
example. Especially with Ben Laurie's comment that unused bits MBZ, I
don't see any any room for even willful error in it.
This language has been sitting in 2440 and followons since '97. No one
has ever had a problem implementing it, no one has had an
interoperability issue with bignums. Not PGP, nor GnuPG, nor Hushmail,
nor Cryptix, nor Forum, nor Bouncy Castle, nor anyone else.
I know I'm in the fog of jetlag and flu, but I don't see how your
example of [00 05 22] could possibly be interpreted as a decimal 17. I
can see how you might think it 0x22 (decimal 34) with a bad length, or
a 2 with a bad length and garbage in the unused bits (now clarified by
Ben Laurie). I think that the point you're trying to make is that is is
conceivable that [00 05 31] a 17.
However, the existing text says:
These octets form a big-endian number; a big-endian number can be
made into an MPI by prefixing it with the appropriate length.
and
The length field of an MPI describes the length starting from its
most significant non-zero bit. Thus, the MPI [00 02 01] is not
formed correctly. It should be [00 01 01].
Even without the MBZ clarification, I think this tells us that the
*natural* formation of a 17 as an MPI to be [00 05 11]. The second
paragraph says that [00 06 11] is not legal because the sixth bit of
0x11 is zero, and that [00 05 31] is not legal because that sixth bit
is now the most significant non-zero bit. Bis13 (which presently only I
have) adds in:
Unused bits of an MPI MUST be zero.
which seems to me to remove all realms for misinterpretation.
The first paragraph shows that the natural way to form an MPI would
bring you to [00 05 11]. The second shows that [00 05 i] where i > 0x1f
is not legal. Please help me understand how I would evaluate [00 05
22], [00 05 44], and [00 05 88] to be a 17. Without the MBZ
clarification, I can see how they might be naively be seen to be 2, 4,
and 8 respectively, but I think that the MBZ clarification removes even
the naive misunderstanding. I just don't see how they're 17. Let me
know and I'll fix it, really I will.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1Q07emn026680; Fri, 25 Feb 2005 16:07:40 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1Q07eOp026679; Fri, 25 Feb 2005 16:07:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1Q07eJP026665 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 16:07:40 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 16:07:32 -0800
Received: from [172.16.1.2] ([66.46.153.63]) by keys.merrymeet.com (PGP Universal service); Fri, 25 Feb 2005 16:07:31 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <20050225181128.GB1778@jabberwocky.com>
References: <421C6AEF.5030608@algroup.co.uk> <20050225162716.GA1778@jabberwocky.com> <421F5DD6.1090204@algroup.co.uk> <20050225181128.GB1778@jabberwocky.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <d2bf815aed39698a385baccc0f2de121@callas.org>
Content-Transfer-Encoding: 7bit
From: Jon Callas <jon@callas.org>
Subject: Re: More questions and comments on rfc2440bis-12
Date: Fri, 25 Feb 2005 16:08:20 -0800
To: OpenPGP <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On other certification types:
Apart from what David said about GnuPG, no one has ever done any sort
of certification other than the 0x10 certification signatures. (By that
I mean that there's never been a program that actually went to the
trouble of creating a UI that effectively said, "How good do you think
this certification is?")
At one point, we removed them from OpenPGP because no one used them.
They were put in because the working group liked the expressiveness of
the language even if no one was expressing themselves that way. I think
that discussion is still valid and don't see a reason to change it. The
different degrees of certification are in the OpenPGP language because
we as a group think they should be there.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PM658Q016058; Fri, 25 Feb 2005 14:06:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PM659d016057; Fri, 25 Feb 2005 14:06:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PM5t4i016002 for <ietf-openpgp@mail.imc.org>; Fri, 25 Feb 2005 14:05:59 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D4nWt-0006r6-Ne for <ietf-openpgp@mail.imc.org>; Fri, 25 Feb 2005 23:01:47 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D4nW5-0000Na-7e; Fri, 25 Feb 2005 23:00:57 +0100
To: Ian G <iang@systemics.com>
Cc: Hal Finney <hal@finney.org>, ietf-openpgp@mail.imc.org
Subject: Re: DSA hash algorithms
References: <20050225192221.400F257EBA@finney.org> <421F893D.5010103@systemics.com>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Fri, 25 Feb 2005 23:00:57 +0100
In-Reply-To: <421F893D.5010103@systemics.com> (Ian G.'s message of "Fri, 25 Feb 2005 20:23:25 +0000")
Message-ID: <87r7j4z4di.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Fri, 25 Feb 2005 20:23:25 +0000, Ian G said:
> I also lean to the first solution. I do not
Same here.
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PKmilJ010585; Fri, 25 Feb 2005 12:48:44 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PKmiiP010584; Fri, 25 Feb 2005 12:48:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PKmhl7010566 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 12:48:44 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005022520483601300qkvi9e>; Fri, 25 Feb 2005 20:48:36 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1PKmZ7o020950 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 15:48:35 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1PKmYUr004896 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 15:48:34 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1PKmY2k004895 for ietf-openpgp@imc.org; Fri, 25 Feb 2005 15:48:34 -0500
Date: Fri, 25 Feb 2005 15:48:34 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: [ISSUE] Minor language nits
Message-ID: <20050225204834.GA2271@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Three minor language nits:
In section 5.2.3. Version 4 Signature Packet Format:
- Two-octet scalar octet count for following hashed subpacket
data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will
skip over the hashed subpackets.
There needs to be a "the" between "for" and "following". Note also
the same problem one paragraph later for the item discussing the
unhashed subpacket data.
=============================
Throughout the document, references to RFCs are written
inconsistently. For example, there are 3 references to "RFC 1991"
(with the space), and 2 references to "RFC1991" (without the space).
I like it with the space, though I really don't care which way things
go so long as it is consistent. (It's not just 1991 - all the RFC
references in the draft are mixed between the two styles).
=============================
There are a few spots in the draft where "PGP" is used when "OpenPGP"
should have been used (when referring to the standard, rather than the
product):
Section 2.3 (Compression) has one in the second paragraph.
Section 5.2.1 (Signature Types) has one in the discussion of the 0x13
signature class.
Section 5.7 (Symmetrically Encrypted Data Packet) has one when
discussing "PGP's variant of Cipher Feedback (CFB) mode".
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PKJ6qa008446; Fri, 25 Feb 2005 12:19:06 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PKJ63Y008445; Fri, 25 Feb 2005 12:19:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PKJ53C008433 for <ietf-openpgp@mail.imc.org>; Fri, 25 Feb 2005 12:19:05 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1PLIca08782; Fri, 25 Feb 2005 21:18:43 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421F893D.5010103@systemics.com>
Date: Fri, 25 Feb 2005 20:23:25 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Hal Finney <hal@finney.org>
CC: ietf-openpgp@mail.imc.org
Subject: Re: DSA hash algorithms
References: <20050225192221.400F257EBA@finney.org>
In-Reply-To: <20050225192221.400F257EBA@finney.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hal Finney wrote:
>I suggest that we do one of two things. We could change the spec to
>require SHA-1 with DSA keys, and then when NIST comes out with DSA-2
>which uses SHA-2 (which they have been promising for years now), we will
>then support the larger hashes. Or we could change the spec to allow
>any hash >= 160 bits to be used with DSA keys. We could follow the NIST
>recommendation in http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
>and use just the left 160 bits of the larger hash.
>
>I lean towards the first solution, even though hash rollback attacks
>require the ability to completely reverse hashes and not just find
>collisions, so we really do seem safe from them. I feel uncomfortable
>going out with a spec that intentionally opens itself up to a preventable
>attack. But it's frustrating that NIST has dragged its feet and not
>come up with a DSA standard that allows other hashes. It is tempting
>to allow SHA-2 with DSA as an interim measure.
>
>
I also lean to the first solution. I do not
judge the size of the market in digital
signatures to be anywhere significant
enough to worry about, and the attacks
so far mooted are all in the theoretical,
unvalidated domain.
Secondly, if someone wants something
stronger than DSA, they can use RSA.
It's good to review the possibilities though.
(I'm sure NIST have also received their
wake up call by now ;-)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PK7GRn007609; Fri, 25 Feb 2005 12:07:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PK7Gap007608; Fri, 25 Feb 2005 12:07:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PK7ET9007593 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 12:07:15 -0800 (PST) (envelope-from news@branwen.iks-jena.de)
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.3/8.13.1) with ESMTP id j1PK78NX017609 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 21:07:10 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.3/8.13.1/Submit) id j1PK78rn017608 for ietf-openpgp@imc.org; Fri, 25 Feb 2005 21:07:08 +0100
To: ietf-openpgp@imc.org
Path: not-for-mail
From: Lutz Donnerhacke <lutz@iks-jena.de>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: DSA hash algorithms
Date: Fri, 25 Feb 2005 20:07:08 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 20
Message-ID: <slrnd1v1bc.f7i.lutz@belenus.iks-jena.de>
References: <20050225192221.400F257EBA@finney.org>
NNTP-Posting-Host: belenus.iks-jena.de
X-Trace: branwen.iks-jena.de 1109362028 17125 217.17.192.34 (25 Feb 2005 20:07:08 GMT)
X-Complaints-To: usenet@iks-jena.de
NNTP-Posting-Date: Fri, 25 Feb 2005 20:07:08 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
* "Hal Finney" wrote:
> (Although RIPEMD-160 has not been attacked, the earlier RIPEMD hash was
> broken last year, and it seems plausible that the new attacks could work
> against RIPEMD-160 as well.)
IBTD. By the same argument applies to the SHA-2 family. It is senseless.
> I suggest that we do one of two things. We could change the spec to
> require SHA-1 with DSA keys, and then when NIST comes out with DSA-2
> which uses SHA-2 (which they have been promising for years now), we will
> then support the larger hashes. Or we could change the spec to allow
> any hash >= 160 bits to be used with DSA keys. We could follow the NIST
> recommendation in http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
> and use just the left 160 bits of the larger hash.
Because every hash of 160bit will do, I'd propose to be as flexible as
possible. We can provide a general statement about hashes in all contexts:
"If the digest is larger than expected, only the leftmost bits count."
I do not know if those truncated hashes provide the same level of security ...
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PJqJZv006462; Fri, 25 Feb 2005 11:52:19 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PJqJSi006461; Fri, 25 Feb 2005 11:52:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp13.wxs.nl (smtp13.wxs.nl [195.121.6.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PJqIij006444 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 11:52:18 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp13.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ICH003B5GIQ9N@smtp13.wxs.nl> for ietf-openpgp@imc.org; Fri, 25 Feb 2005 20:52:02 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 54C582A6AD; Fri, 25 Feb 2005 20:52:02 +0100 (CET)
Date: Fri, 25 Feb 2005 20:52:02 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: Tighter MPI spec
In-reply-to: <0a5ed6016f5c7d1ecd1ef3e4c1dad620@callas.org>
To: Jon Callas <jon@callas.org>
Cc: ietf-openpgp@imc.org
Message-id: <20050225195202.GA29679@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
References: <20050224093032.GA98866@phantom.vanrein.org> <0a5ed6016f5c7d1ecd1ef3e4c1dad620@callas.org>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello Jon,
> We're attempting to get to last call on the document.
That places things in perspective, of course.
> we don't
> need small changes that add no particular value.
The specification of the MPI format has a *flaw* that forces compliant
implementations to do more work than desired or intended. This is
outright embarassing in a standard.
> While these changes
> may make things clearer for you, they're likely to irritate someone
> else.
Agreeable.
> I don't find the MPI changes to be clearer. I find them less clear,
My goal is to take away the ambguity. The exact wording is just a way
to get that done. Any other phrasing would be fine.
Hope this helps,
-Rick
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PJA1Uv003800; Fri, 25 Feb 2005 11:10:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PJA1m9003799; Fri, 25 Feb 2005 11:10:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PJ9wUl003785 for <ietf-openpgp@mail.imc.org>; Fri, 25 Feb 2005 11:10:01 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 400F257EBA; Fri, 25 Feb 2005 11:22:21 -0800 (PST)
To: ietf-openpgp@mail.imc.org
Subject: DSA hash algorithms
Message-Id: <20050225192221.400F257EBA@finney.org>
Date: Fri, 25 Feb 2005 11:22:21 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Jon and I (who both work for PGP Corp.) were looking at the situation with
DSA hash algorithms. The recent attack on SHA-1, reducing its strength
from 2^80 down to 2^69, is motivating a move towards the SHA-2 family.
PGP is migrating towards SHA-2 as the default hash algorithm for use
with RSA signatures.
We discussed the pros and cons of allowing SHA-2 with DSA signatures.
It's a complicated issue, cryptographically and technologically, which
I could write more about. But in the process we reviewed the language
in the RFC draft about the issue.
Section 5.2.2, Version 3 Signature Packet Format, says:
DSA signatures MUST use hashes with a size of 160 bits, to match q,
the size of the group generated by the DSA key's generator value.
The hash function result is treated as a 160 bit number and used
directly in the DSA signature algorithm.
Section 13, Security Considerations, says:
* The DSA algorithm will work with any 160-bit hash, but it is
sensitive to the quality of the hash algorithm, if the hash
algorithm is broken, it can leak the secret key. The Digital
Signature Standard (DSS) specifies that DSA be used with SHA-1.
RIPEMD-160 is considered by many cryptographers to be as strong.
An implementation should take care which hash algorithms are
used with DSA, as a weak hash can not only allow a signature to
be forged, but could leak the secret key.
* There is a somewhat-related potential security problem in
signatures. If an attacker can find a message that hashes to the
same hash with a different algorithm, a bogus signature
structure can be constructed that evaluates correctly.
For example, suppose Alice DSA signs message M using hash
algorithm H. Suppose that Mallet finds a message M' that has the
same hash value as M with H'. Mallet can then construct a
signature block that verifies as Alice's signature of M' with
H'. However, this would also constitute a weakness in either H
or H' or both. Should this ever occur, a revision will have to
be made to this document to revise the allowed hash algorithms.
Presently, then, we allow DSA signatures to use other hashes than SHA-1,
but they have to be exactly 160 bits. The only other 160 bit hash we
support is RIPEMD-160. The language allows this hash, but technically
disallows any of the SHA-2 family hashes from being used with our DSA
signatures.
This is unfortunate, because it makes us vulnerable to hash rollback
attacks, as described in the last paragraph above, but does not let us
move to what are thought to be the strongest hashes in the standard,
SHA-256 and SHA-512. So in a way we have the worst of both worlds: hash
rollbacks because we don't fix on SHA-1 as the DSS does; but inability
to respond flexibly to attacks on the current hashes.
(Although RIPEMD-160 has not been attacked, the earlier RIPEMD hash was
broken last year, and it seems plausible that the new attacks could work
against RIPEMD-160 as well.)
I suggest that we do one of two things. We could change the spec to
require SHA-1 with DSA keys, and then when NIST comes out with DSA-2
which uses SHA-2 (which they have been promising for years now), we will
then support the larger hashes. Or we could change the spec to allow
any hash >= 160 bits to be used with DSA keys. We could follow the NIST
recommendation in http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
and use just the left 160 bits of the larger hash.
I lean towards the first solution, even though hash rollback attacks
require the ability to completely reverse hashes and not just find
collisions, so we really do seem safe from them. I feel uncomfortable
going out with a spec that intentionally opens itself up to a preventable
attack. But it's frustrating that NIST has dragged its feet and not
come up with a DSA standard that allows other hashes. It is tempting
to allow SHA-2 with DSA as an interim measure.
BTW, I'm not sure about the comment above about weak hashes exposing
secret keys with DSA. I can't bring such an attack to mind. Does anyone
have a reference to that?
Hal Finney
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PIBo8d099284; Fri, 25 Feb 2005 10:11:50 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PIBo6m099283; Fri, 25 Feb 2005 10:11:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PIBhW8099257 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 10:11:47 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <200502251811350140030rgqe>; Fri, 25 Feb 2005 18:11:35 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1PIBY7o020245; Fri, 25 Feb 2005 13:11:34 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1PIBX3L002092; Fri, 25 Feb 2005 13:11:33 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1PIBSIP002091; Fri, 25 Feb 2005 13:11:28 -0500
Date: Fri, 25 Feb 2005 13:11:28 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: Ben Laurie <ben@algroup.co.uk>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: More questions and comments on rfc2440bis-12
Message-ID: <20050225181128.GB1778@jabberwocky.com>
Mail-Followup-To: Ben Laurie <ben@algroup.co.uk>, OpenPGP <ietf-openpgp@imc.org>
References: <421C6AEF.5030608@algroup.co.uk> <20050225162716.GA1778@jabberwocky.com> <421F5DD6.1090204@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <421F5DD6.1090204@algroup.co.uk>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Fri, Feb 25, 2005 at 05:18:14PM +0000, Ben Laurie wrote:
>
> David Shaw wrote:
> >On Wed, Feb 23, 2005 at 11:37:19AM +0000, Ben Laurie wrote:
> >
> >>In 5.2.1:
> >>
> >>"0x10: Generic certification of a User ID and Public Key packet."
> >>
> >>Does this mean that the signature is over the User ID packet and the
> >>Public Key packet, concatenated, in that order? Or what?
> >
> >
> >5.2.1 is just an overview. The nitty-gritty on how to make each type
> >is specified in 5.2.4. Computing Signatures.
> >
> >
> >>Also, what on earth does:
> >>
> >> Note that all PGP "key signatures" are this type of
> >> certification.
> >
> >
> >PGP doesn't generate 0x11, 0x12, or 0x13 signatures, and when it
> >encounters them treats them all as if they were 0x10.
>
> When you say "PGP" you mean, presumably, some version(s) of the software
> - which? I presume modern ones do generate them all?
All versions I've ever seen, including 2, 5, 6, 7, and 8, and all
sub-versions of that list.
I see 0x11, 0x12, and 0x13 as sort of a vestigal tail in OpenPGP.
They're not really useful for much, and are pretty much ignored.
Certainly 0x12 doesn't have less validity than 0x13 in the usual
definition of the web of trust.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PHKHY0093505; Fri, 25 Feb 2005 09:20:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PHKHhF093504; Fri, 25 Feb 2005 09:20:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PHKGD5093496 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 09:20:16 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id C674133C84; Fri, 25 Feb 2005 17:20:15 +0000 (GMT)
Message-ID: <421F5DD6.1090204@algroup.co.uk>
Date: Fri, 25 Feb 2005 17:18:14 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <dshaw@jabberwocky.com>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: More questions and comments on rfc2440bis-12
References: <421C6AEF.5030608@algroup.co.uk> <20050225162716.GA1778@jabberwocky.com>
In-Reply-To: <20050225162716.GA1778@jabberwocky.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
David Shaw wrote:
> On Wed, Feb 23, 2005 at 11:37:19AM +0000, Ben Laurie wrote:
>
>>In 5.2.1:
>>
>>"0x10: Generic certification of a User ID and Public Key packet."
>>
>>Does this mean that the signature is over the User ID packet and the
>>Public Key packet, concatenated, in that order? Or what?
>
>
> 5.2.1 is just an overview. The nitty-gritty on how to make each type
> is specified in 5.2.4. Computing Signatures.
>
>
>>Also, what on earth does:
>>
>> Note that all PGP "key signatures" are this type of
>> certification.
>
>
> PGP doesn't generate 0x11, 0x12, or 0x13 signatures, and when it
> encounters them treats them all as if they were 0x10.
When you say "PGP" you mean, presumably, some version(s) of the software
- which? I presume modern ones do generate them all?
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PH1IkL091702; Fri, 25 Feb 2005 09:01:18 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PH1IVn091701; Fri, 25 Feb 2005 09:01:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PH1GYq091682 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 09:01:17 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 98D6D33C9A; Fri, 25 Feb 2005 17:01:11 +0000 (GMT)
Message-ID: <421F595E.9040502@algroup.co.uk>
Date: Fri, 25 Feb 2005 16:59:10 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ian G <iang@systemics.com>
Cc: Jon Callas <jon@callas.org>, OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Forward Secrecy
References: <421DFDC3.3080404@algroup.co.uk> <150db1b4e99f6b351820cf60b96dd61d@callas.org> <421F57D7.7010201@systemics.com>
In-Reply-To: <421F57D7.7010201@systemics.com>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Ian G wrote:
>
> Jon Callas wrote:
>
>>
>> I think this is a great idea and ought to be part of the WG's scope.
>> I'd even like to see some of the OTR work brought in here.
>>
>> I don't see why this shouldn't just get a good buffing and go.
>
>
>
> As long as it doesn't hold up the draft, that
> would be fine! How about we set a deadline
> on the draft, and go to the next step on it?
It is an independent I-D.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGmiiU090377; Fri, 25 Feb 2005 08:48:44 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PGmia2090376; Fri, 25 Feb 2005 08:48:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGmfvi090340 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 08:48:42 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1PHlra07843; Fri, 25 Feb 2005 17:48:05 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421F57D7.7010201@systemics.com>
Date: Fri, 25 Feb 2005 16:52:39 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <jon@callas.org>
CC: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Forward Secrecy
References: <421DFDC3.3080404@algroup.co.uk> <150db1b4e99f6b351820cf60b96dd61d@callas.org>
In-Reply-To: <150db1b4e99f6b351820cf60b96dd61d@callas.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Jon Callas wrote:
>
> I think this is a great idea and ought to be part of the WG's scope.
> I'd even like to see some of the OTR work brought in here.
>
> I don't see why this shouldn't just get a good buffing and go.
As long as it doesn't hold up the draft, that
would be fine! How about we set a deadline
on the draft, and go to the next step on it?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGRQ4H088422; Fri, 25 Feb 2005 08:27:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PGRQsB088421; Fri, 25 Feb 2005 08:27:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGRPGf088407 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 08:27:25 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc12) with ESMTP id <2005022516271801400hlagpe>; Fri, 25 Feb 2005 16:27:18 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1PGRH7o019721 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 11:27:17 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1PGRGss001878 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 11:27:16 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1PGRGvC001877 for ietf-openpgp@imc.org; Fri, 25 Feb 2005 11:27:16 -0500
Date: Fri, 25 Feb 2005 11:27:16 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: More questions and comments on rfc2440bis-12
Message-ID: <20050225162716.GA1778@jabberwocky.com>
Mail-Followup-To: OpenPGP <ietf-openpgp@imc.org>
References: <421C6AEF.5030608@algroup.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <421C6AEF.5030608@algroup.co.uk>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Wed, Feb 23, 2005 at 11:37:19AM +0000, Ben Laurie wrote:
>
> In 5.2.1:
>
> "0x10: Generic certification of a User ID and Public Key packet."
>
> Does this mean that the signature is over the User ID packet and the
> Public Key packet, concatenated, in that order? Or what?
5.2.1 is just an overview. The nitty-gritty on how to make each type
is specified in 5.2.4. Computing Signatures.
> Also, what on earth does:
>
> Note that all PGP "key signatures" are this type of
> certification.
PGP doesn't generate 0x11, 0x12, or 0x13 signatures, and when it
encounters them treats them all as if they were 0x10.
By default GnuPG generates 0x10, but the user can request another
type. Also by default GnuPG ignores 0x11 signatures completely, but
treats treats 0x12 and 0x13 the same as 0x10.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PFxFeH086250; Fri, 25 Feb 2005 07:59:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PFxFm1086249; Fri, 25 Feb 2005 07:59:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PFxCad086233 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 07:59:12 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Fri, 25 Feb 2005 07:59:03 -0800
Received: from [172.16.1.2] ([66.46.153.98]) by keys.merrymeet.com (PGP Universal service); Fri, 25 Feb 2005 07:59:02 -0800
X-PGP-Universal: processed
In-Reply-To: <421DFDC3.3080404@algroup.co.uk>
References: <421DFDC3.3080404@algroup.co.uk>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <150db1b4e99f6b351820cf60b96dd61d@callas.org>
Content-Transfer-Encoding: 7bit
Cc: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: Re: Forward Secrecy
Date: Fri, 25 Feb 2005 07:59:26 -0800
To: Ben Laurie <ben@algroup.co.uk>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I think this is a great idea and ought to be part of the WG's scope.
I'd even like to see some of the OTR work brought in here.
I don't see why this shouldn't just get a good buffing and go.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PFc6xq084645; Fri, 25 Feb 2005 07:38:06 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PFc6nX084644; Fri, 25 Feb 2005 07:38:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PFc1IX084633 for <ietf-openpgp@imc.org>; Fri, 25 Feb 2005 07:38:01 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Fri, 25 Feb 2005 07:37:49 -0800
Received: from [172.16.1.2] ([66.46.153.98]) by keys.merrymeet.com (PGP Universal service); Fri, 25 Feb 2005 07:37:48 -0800
X-PGP-Universal: processed
In-Reply-To: <20050224093032.GA98866@phantom.vanrein.org>
References: <20050224093032.GA98866@phantom.vanrein.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <0a5ed6016f5c7d1ecd1ef3e4c1dad620@callas.org>
Content-Transfer-Encoding: 7bit
Cc: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: Re: Tighter MPI spec (and on keychains)
Date: Fri, 25 Feb 2005 07:38:09 -0800
To: Rick van Rein <rick@openfortress.nl>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I don't see any reason we need to change either of these.
We're attempting to get to last call on the document. While there's at
least one open discussion (which I'll try to get to soon), we don't
need small changes that add no particular value. While these changes
may make things clearer for you, they're likely to irritate someone
else. Whatever you may think about the present wordings, they are the
devil we know and the devil that we've agreed on.
I don't find the MPI changes to be clearer. I find them less clear, but
that could be a combination of the hour of the day and that I
understand the way things are. And as Ian said, keyrings are out of
scope. The reason they are that way is so that someone can store keys
however they want and still call it a keyring.
This document shows how the data structures are laid out. There are
many higher-level things you can do with them.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OJNAdO059478; Thu, 24 Feb 2005 11:23:10 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OJNAth059477; Thu, 24 Feb 2005 11:23:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OJN90o059469 for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 11:23:09 -0800 (PST) (envelope-from vedaal@hush.com)
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 58912A329A for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 11:23:09 -0800 (PST)
Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 11:23:08 -0800 (PST)
Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j1OJN8ah086808 for ietf-openpgp@imc.org; Thu, 24 Feb 2005 11:23:08 -0800 (PST) (envelope-from vedaal@hush.com)
Message-Id: <200502241923.j1OJN8ah086808@mailserver3.hushmail.com>
Date: Thu, 24 Feb 2005 11:23:06 -0800
To: ietf-openpgp@imc.org
Cc:
Subject: Re: Forward Secrecy // sorry, ignore my previous message //
From: <vedaal@hush.com>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
sorry,
i didn't read it through carefully,
as long as the private key is revoked and no backups made,
it does provide a 'lot' of extra security
sorry,
vedaal
Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434
Promote security and make money with the Hushmail Affiliate Program:
http://www.hushmail.com/about-affiliate?l=427
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OJ1hkE057118; Thu, 24 Feb 2005 11:01:43 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OJ1hLp057117; Thu, 24 Feb 2005 11:01:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OJ1c71057101 for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 11:01:43 -0800 (PST) (envelope-from vedaal@hush.com)
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 92B72A32FB for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 11:01:32 -0800 (PST)
Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 11:01:32 -0800 (PST)
Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j1OJ1WMn083642 for ietf-openpgp@imc.org; Thu, 24 Feb 2005 11:01:32 -0800 (PST) (envelope-from vedaal@hush.com)
Message-Id: <200502241901.j1OJ1WMn083642@mailserver3.hushmail.com>
Date: Thu, 24 Feb 2005 11:01:28 -0800
To: ietf-openpgp@imc.org
Cc:
Subject: Re: Forward Secrecy
From: <vedaal@hush.com>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, 24 Feb 2005 08:16:03 -0800 Ben Laurie <ben@algroup.co.uk>
wrote:
>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.html
>http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt
>
>Forward Secrecy Extensions for OpenPGP
>Comments, please!
the site lists the following statement:
"If expired keys are securely deleted, attackers will never be able
to retrieve them to decrypt captured ciphertext. Therefore when a
public encryption key expires, an OpenPGP client MUST securely wipe
the corresponding private key"
it would also need the suggestion/requirement that the OpenPGP
client
NOT be allowed to make a 'backup' of the private key,
something now routinely done by default
but even if it does so, and does not make any backups,
it is still not foolproof,
it just requires the adversary to do 'more work'
assuming the sender corresponds with 'n' different recipients,
and sends a new subkey packet to each of them for each encryption,
if the adversary can intercept each e-mail message, and stores
them,
then the adversary now needs the 'n' long-term private keys of the
recipients, and can then recover the subkeys and the messages
so, the security still depends on the recipient's long term
private keys not being compromised, as it did without the use of
the subkeys
but if the sender doesn't encrypt to self, and encrypts only to the
receiver,
how is the security improved by having different subkeys each time
for that receiver?
vedaal
Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434
Promote security and make money with the Hushmail Affiliate Program:
http://www.hushmail.com/about-affiliate?l=427
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OGIKLh044445; Thu, 24 Feb 2005 08:18:20 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OGIKKG044444; Thu, 24 Feb 2005 08:18:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OGII2e044424 for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 08:18:19 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 7F22733C9A for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 16:18:05 +0000 (GMT)
Message-ID: <421DFDC3.3080404@algroup.co.uk>
Date: Thu, 24 Feb 2005 16:16:03 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <ietf-openpgp@imc.org>
Subject: Forward Secrecy
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
This I-D has been through WG last call back in 2001 or so. At that
point, something went wrong and it got sat on. Unfortunately, I didn't
have time before the deadline to convert it to the new format, but it
now is, and I'd like to try to introduce it as a work item for the WG.
I'll send it to the I-D editor, but in the meantime, its available here:
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.html
http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt
Forward Secrecy Extensions for OpenPGP
"The confidentiality of encrypted data depends on the secrecy of the key
needed to decrypt it. If one key is able to decrypt large quantities of
data, its compromise will be disastrous. This memo describes three
methods for limiting this vulnerability for OpenPGP messages: reducing
the lifetime of confidentiality keys; one-time keys; and the additional
use of lower-layer security services."
Comments, please!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OCVdov004553; Thu, 24 Feb 2005 04:31:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OCVdCo004552; Thu, 24 Feb 2005 04:31:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OCVXh2004479 for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 04:31:38 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1ODV5a32341 for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 13:31:21 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421DCA27.4090009@systemics.com>
Date: Thu, 24 Feb 2005 12:35:51 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Tighter MPI spec (and on keychains)
References: <20050224093032.GA98866@phantom.vanrein.org>
In-Reply-To: <20050224093032.GA98866@phantom.vanrein.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
(on the keyrings only)
Rick van Rein wrote:
>Another thing. In 3.6 on Keyrings, I was confused whether it described a
>message format or a storage format. Only the former seems interesting in
>the scope of this spec. I therefore propose the following.
>
>CHANGE
> A keyring is a collection of one or more keys in a file or database.
> Traditionally, a keyring is simply a sequential list of keys, but
> may be any suitable database. It is beyond the scope of this
> standard to discuss the details of keyrings or other databases.
>INTO
> A keyring is conceptually a set of at least one public key. To put
> a keyring in an OpenPGP message, it is represented as the concatenation
> of the keys in the ring.
>
>
Are you trying to make it into a message?
I never heard of a 'keyring message' ... if it isn't
defined and nobody has wanted it until now, I'd
have thought there was no value in complicating
things by adding it now.
The reason that the comment is there at all is because
even though it is out of scope, there needs to be a
signal that tells people that. There have always
been lots of discussions about 'what about the
keyring, it isn't defined!' and this is meant to
clearly indicated that ... it isn't defined.
>Note: The original statement speaks of "one or more" keys. I therefore
> said "at least one" but models are often complicated by treating the
> zero case differently -- could the "one or more" be strikken? Or
> would this cause unacceptable backward compatibility problems?
>
>
If this is about keyrings, then it is a potential tightening
in something that is agreed as out of scope. As it is out
of scope, it can't be authoritive!
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1O9VJIu048128; Thu, 24 Feb 2005 01:31:19 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1O9VJ55048127; Thu, 24 Feb 2005 01:31:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp18.wxs.nl (smtp18.wxs.nl [195.121.6.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1O9VEom047997 for <ietf-openpgp@imc.org>; Thu, 24 Feb 2005 01:31:19 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp18.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ICE00HTHT2W9U@smtp18.wxs.nl> for ietf-openpgp@imc.org; Thu, 24 Feb 2005 10:30:32 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 4C7ED2A6AD; Thu, 24 Feb 2005 10:30:32 +0100 (CET)
Date: Thu, 24 Feb 2005 10:30:32 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Tighter MPI spec (and on keychains)
To: OpenPGP <ietf-openpgp@imc.org>
Message-id: <20050224093032.GA98866@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello Jon and others,
According to bis-12, the following MPI values are acceptable encodings
of decimal 17: [00 05 11], [00 05 22], [00 05 44] and [00 05 88]
I bet this is unintentional. I therefore propose these changes:
CHANGE
An MPI consists of two pieces: a two-octet scalar that is the length
of the MPI in bits followed by a string of octets that contain the
actual integer.
INTO
An MPI consists of two pieces: a two-octet scalar that is the length
of the MPI in bits followed by a string of octets that contain the
actual integer. The second part is prefixed with (8-MPI.length) mod 8
zero-valued bits.
CHANGE
These octets form a big-endian number; a big-endian number can be
made into an MPI by prefixing it with the appropriate length.
INTO
These octets form a big-endian number; a big-endian number can be
made into an MPI by prefixing it with the appropriate bit length.
AFTER
The length field of an MPI describes the length starting from its
most significant non-zero bit. Thus, the MPI [00 02 01] is not
formed correctly. It should be [00 01 01].
APPEND
The bits of the MPI end in the last bit of the last octet. Thus,
the MPI [00 05 44] is not formed correctly. It should be [00 05 11].
Another thing. In 3.6 on Keyrings, I was confused whether it described a
message format or a storage format. Only the former seems interesting in
the scope of this spec. I therefore propose the following.
CHANGE
A keyring is a collection of one or more keys in a file or database.
Traditionally, a keyring is simply a sequential list of keys, but
may be any suitable database. It is beyond the scope of this
standard to discuss the details of keyrings or other databases.
INTO
A keyring is conceptually a set of at least one public key. To put
a keyring in an OpenPGP message, it is represented as the concatenation
of the keys in the ring.
Note: The original statement speaks of "one or more" keys. I therefore
said "at least one" but models are often complicated by treating the
zero case differently -- could the "one or more" be strikken? Or
would this cause unacceptable backward compatibility problems?
Cheers,
-Rick
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1NBbRWK054476; Wed, 23 Feb 2005 03:37:27 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1NBbRGR054475; Wed, 23 Feb 2005 03:37:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1NBbQ1S054390 for <ietf-openpgp@imc.org>; Wed, 23 Feb 2005 03:37:27 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id ED5FC33C8B for <ietf-openpgp@imc.org>; Wed, 23 Feb 2005 11:37:12 +0000 (GMT)
Message-ID: <421C6AEF.5030608@algroup.co.uk>
Date: Wed, 23 Feb 2005 11:37:19 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OpenPGP <ietf-openpgp@imc.org>
Subject: More questions and comments on rfc2440bis-12
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
In 5.2.1:
"0x10: Generic certification of a User ID and Public Key packet."
Does this mean that the signature is over the User ID packet and the
Public Key packet, concatenated, in that order? Or what?
Also, what on earth does:
Note that all PGP "key signatures" are this type of
certification.
mean?
In 5.2.2:
"The data being signed is hashed, and then the signature type and
creation time from the signature packet are hashed (5 additional
octets)."
is unclear, suggest:
"The concatenation of the data to be signed, the signature type and
creation time from the signature packet (5 additional octets) is hashed."
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LMZusN055534; Mon, 21 Feb 2005 14:35:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LMZuKB055533; Mon, 21 Feb 2005 14:35:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from TREVOR (ip30.post-street-towers.sfo.ygnition.net [66.199.92.30] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LMZoJA055523 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 14:35:55 -0800 (PST) (envelope-from trevp@trevp.net)
Message-Id: <5.2.0.9.0.20050221135210.028ec430@mail.iqmail.net>
X-Sender: trevp@mail.iqmail.net
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 21 Feb 2005 14:35:32 -0800
To: <ietf-openpgp@imc.org>
From: Trevor Perrin <trevp@trevp.net>
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
In-Reply-To: <20050221171131.GA30510@jabberwocky.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
At 12:11 PM 2/21/2005 -0500, David Shaw wrote:
>[...]
>A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78
>9A BC DE F0 ...(etc).
One neat thing you could do with this sort of typed, variable-length
fingerprint format is try out different 'algos' for shorter, more friendly
fingerprints:
Example 1: base32 the first 125 bits of a hash output, for a 25-character
fingerprint.
Example 2: search for a hash output beginning with 20 zero bits (< 1 sec on
a modern machine; search is done by placing random values in a subpacket),
then base32 the subsequent 100 bits for a 20-character fingerprint (with
120-bit security level).
Maybe that's too weird to be standardized, but at least it could be grafted
on easily. I.e., a key could be known by a standard 40 or 64-character
fingerprint, as well as a 20-character fingerprint in communities that
support that extension.
Trevor
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LLCmQt050054; Mon, 21 Feb 2005 13:12:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LLCmZQ050053; Mon, 21 Feb 2005 13:12:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LLCiOF050042 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 13:12:47 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1LMCEa13473 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 22:12:24 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421A4FCB.9080700@systemics.com>
Date: Mon, 21 Feb 2005 21:16:59 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
References: <200502211852.j1LIq8J1032313@mailserver2.hushmail.com> <20050221194405.GA30523@jabberwocky.com>
In-Reply-To: <20050221194405.GA30523@jabberwocky.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
David Shaw wrote:
>>as long as it's a new key type anyway,
>>can it be made to somehow work-around the 160 limit of the DSA,
>>for DH/DSA keys ?
>>
>>
>
>No. This would break compatibility with v4 keys where the 160-bit
>limit still exists.
>
>If/when a new DSA is defined with different semantics, OpenPGP can
>support that in addition to the current DSA, but the new DSA cannot
>replace the old one. Either way, it's not really a v5 specific thing,
>as a new DSA can just as easily be used in v4 (again, without
>replacing the current DSA).
>
>
Yes, I agree. DSA is quite highly defined, better
to leave it alone and suffer its shortfalls for now.
Some time in the future, NIST will design a DSA-2,
and that can be added. For now, if DSA is considered
too dodgy then RSA could be used.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LJvSXH046611; Mon, 21 Feb 2005 11:57:28 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LJvSiC046610; Mon, 21 Feb 2005 11:57:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LJvRTk046601 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 11:57:27 -0800 (PST) (envelope-from konrad@silmor.de)
Received: from pd9e1f864.dip.t-dialin.net ([217.225.248.100] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1D3Jg7-0005z8-00 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 20:57:11 +0100
From: Konrad Rosenbaum <konrad@silmor.de>
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Date: Mon, 21 Feb 2005 20:57:07 +0100
User-Agent: KMail/1.7.2
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de>
In-Reply-To: <87vf8rlbbm.fsf@wheatstone.g10code.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart5843842.TODgaey7Pn"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200502212057.10496@zaphod.konrad.silmor.de>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
--nextPart5843842.TODgaey7Pn
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday 17 February 2005 11:39, Werner Koch wrote:
> We should really start thinking on how to switch to a different hash
> algorithm. The question is whether sha-256 is really that much more
> secure. From my understanding it has not been developed as a
> replacement for SHA-1 but to meet the requirements of AES and to
> extend DSA.
How would SHA-256 extend DSA? DSA uses a q of 160 bit(*), which limits the=
=20
implementation to any hash that delivers 160 bits or cutting the hash back=
=20
to 160 bit.
As long as we still allow any hash to be used with DSA one can attempt a=20
downgrade attack by altering the signature to use SHA-1 and then try to=20
find a fitting text(**).
Or would that create a DSA-2 which uses a q of 256 bit?=20
How large would p be then?
Would that DSA-2 get a new Algorithm-ID or is the q of 256 bit indicator=20
enough?
(*)apart from the p of 1024 bit
(**)yes, I know 2^69 is still a lot of computation and the attack wasn't=20
about finding a duplicate for a specific message, but....
Konrad
--nextPart5843842.TODgaey7Pn
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCGj0WClt766LaIH0RAsDvAJ0VfYwx7HmAEoyzuhBu3eXYWUI+cACfXUSN
JQY0ZJfIzHEBcdN6SjmHUo8=
=D8we
-----END PGP SIGNATURE-----
--nextPart5843842.TODgaey7Pn--
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LJmNGk046011; Mon, 21 Feb 2005 11:48:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LJmNp9046010; Mon, 21 Feb 2005 11:48:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LJmLc2045998 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 11:48:22 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1LKlka13147; Mon, 21 Feb 2005 20:47:57 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421A3BFF.2020806@systemics.com>
Date: Mon, 21 Feb 2005 19:52:31 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050219)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <dshaw@jabberwocky.com>
CC: ietf-openpgp@imc.org
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
References: <20050221171131.GA30510@jabberwocky.com>
In-Reply-To: <20050221171131.GA30510@jabberwocky.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
David Shaw wrote:
>I also suggest that this not be a part of 2440bis. The v5 discussions
>will undoubtedly take a while, and delaying 2440bis for an unknown
>(but probably long) period of time seems a shame.
>
>
As long as we are all agreed on that, I'm quite
keen to support a parallel track on new cleaned
up layouts.
What is the current status of 2440bis, BTW?
Is there a list of "things that must be complete" ?
It seems that every time we go around in a review
phase, another dozen minor fixes get proposed,
adopted, and then we start again!
At what point do we declare diminishing returns
to reviews?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LJiGnt045766; Mon, 21 Feb 2005 11:44:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LJiGu3045765; Mon, 21 Feb 2005 11:44:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LJiFlH045753 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 11:44:15 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005022119440801300qim0de>; Mon, 21 Feb 2005 19:44:08 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1LJi67o030514 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 14:44:06 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1LJi5kY030697 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 14:44:05 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1LJi5VS030696 for ietf-openpgp@imc.org; Mon, 21 Feb 2005 14:44:05 -0500
Date: Mon, 21 Feb 2005 14:44:05 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
Message-ID: <20050221194405.GA30523@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <200502211852.j1LIq8J1032313@mailserver2.hushmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200502211852.j1LIq8J1032313@mailserver2.hushmail.com>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Mon, Feb 21, 2005 at 10:52:05AM -0800, vedaal@hush.com wrote:
>
>
>
> On Mon, 21 Feb 2005 09:11:31 -0800 David Shaw
> <dshaw@jabberwocky.com> wrote:
>
> [...]
>
> > the v5 key idea.
>
> >It's
> >more of a "design v5 in 2005, because we need it a few years from
> >now".
>
> [...]
>
> >Anyway, this is a starting point.
>
> >suggestions
>
>
> as long as it's a new key type anyway,
> can it be made to somehow work-around the 160 limit of the DSA,
> for DH/DSA keys ?
No. This would break compatibility with v4 keys where the 160-bit
limit still exists.
If/when a new DSA is defined with different semantics, OpenPGP can
support that in addition to the current DSA, but the new DSA cannot
replace the old one. Either way, it's not really a v5 specific thing,
as a new DSA can just as easily be used in v4 (again, without
replacing the current DSA).
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LIqK4M042667; Mon, 21 Feb 2005 10:52:20 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LIqKwM042666; Mon, 21 Feb 2005 10:52:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LIqFWN042657 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 10:52:20 -0800 (PST) (envelope-from vedaal@hush.com)
Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 2FAFBA3351 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 10:52:09 -0800 (PST)
Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 10:52:08 -0800 (PST)
Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id j1LIq8DE032314 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 10:52:08 -0800 (PST) (envelope-from vedaal@hush.com)
Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id j1LIq8J1032313 for ietf-openpgp@imc.org; Mon, 21 Feb 2005 10:52:08 -0800 (PST)
Message-Id: <200502211852.j1LIq8J1032313@mailserver2.hushmail.com>
Date: Mon, 21 Feb 2005 10:52:05 -0800
To: ietf-openpgp@imc.org
Cc:
Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess
From: <vedaal@hush.com>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Mon, 21 Feb 2005 09:11:31 -0800 David Shaw
<dshaw@jabberwocky.com> wrote:
[...]
> the v5 key idea.
>It's
>more of a "design v5 in 2005, because we need it a few years from
>now".
[...]
>Anyway, this is a starting point.
>suggestions
as long as it's a new key type anyway,
can it be made to somehow work-around the 160 limit of the DSA,
for DH/DSA keys ?
vedaal
Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2
Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434
Promote security and make money with the Hushmail Affiliate Program:
http://www.hushmail.com/about-affiliate?l=427
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LHBjDh035522; Mon, 21 Feb 2005 09:11:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LHBjkM035521; Mon, 21 Feb 2005 09:11:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LHBeXm035499 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 09:11:45 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005022117113301100t50dse>; Mon, 21 Feb 2005 17:11:33 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1LHBW7o029975 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 12:11:32 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1LHBVAt030520 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 12:11:31 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1LHBVpZ030519 for ietf-openpgp@imc.org; Mon, 21 Feb 2005 12:11:31 -0500
Date: Mon, 21 Feb 2005 12:11:31 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Some thoughts on a v5 key and why it shouldn't be a mess
Message-ID: <20050221171131.GA30510@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I had around 10 hours in a car this weekend, which gave me a good bit
of time to think some more about the v5 key idea.
I don't see this as a "drop everything and do v5" suggestion. It's
more of a "design v5 in 2005, because we need it a few years from
now". Attacks only get better, and if we want to be able to shrug off
a future SHA-1 break like we were able to shrug off the MD5 break, we
need to start the process. While this is prompted by the SHA-1
problems, note that NIST was already replacing SHA-1 with the SHA-2
family by 2010 for size reasons. Even if the recent SHA-1 problems
hadn't happened, I'd still think it was time to start designing a v5
key.
I don't think there needs to be a lot of fear over a version number
bump. To be sure, the change from v3 to v4 was disruptive. In one
step, the packet format, the default symmetric cipher, and the
public-key algorithm was changed. Even the concept of a key was
altered by adding subkeys. I'm not criticizing - the changes were
necessary for many reasons, but unfortunately they also split the user
base into "before" and "after", with interoperability problems between
the two groups. In some (occasionally frustrating) corners, the
change hasn't even happened yet.
I don't see the change from v4 to v5 being nearly as disruptive as the
v3 to v4 change. The straw proposal I'm putting forth here is an
incremental change over v4, large enough to be worth doing, small
enough that if the change is done carefully, it should be painless.
v4 and the proposed v5 can also quite happily co-exist without anyone
noticing or caring. Note that I'm not talking about making a v5
signature at this point.
Here is a proposed packet format for a v5 key, interspersed with
comments. Obviously, not every detail is given, but the general ideas
should be clear:
- A one-octet version number (5).
- A one-octet hash algorithm number.
This is an attempt to balance Jon's comments about 160 bits being all
that a human user can handle for a fingerprint, and the desire to not
be locked to SHA-1 in case of future trouble. Essentially you set
this value to the fingerprint hash you want to use for this key. The
value itself is hashed into the fingerprint (and signatures on the
key), so it cannot be changed once the key is generated. Is is
possible for different v5 key fingerprints to be of different lengths.
A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78
9A BC DE F0 ...(etc). The v5 keyid concept is the same as v4: the
keyid is the lower 32 or 64 bits of the fingerprint, however long it
may be.
There are some problems with this idea, not least that any
implementation that doesn't understand the hash algorithm won't be
able to use the key. It may well be better to lock this value to
SHA-256 and be done with it.
- A two-octet scalar octet count for the following subpacket
data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will
skip over the subpackets.
- Subpacket data.
Yes, v5 keys have subpackets. It's a bit of future-proofing since it
is a lot easier to add a subpacket than it is to go to a v6 key
format. Note that there are no "unhashed" subpackets here. All
subpackets are hashed into the fingerprint, and therefore are fixed at
key generation time. The subpacket numbers do not need to be the same
as signature subpackets, but the encoding format is the same, and the
critical bit has the same meaning here as it does for signatures.
Only one subpacket comes to mind at the moment, and that is:
Expiration time
(4 octet time field)
The validity period limit of the key. This is the number of
seconds after the key creation time that the key must expire by.
If this is not present or has a value of zero, the key has no
hard expiration.
This gives a "hard" expiration time which cannot be extended, unlike
the current "soft" expiration in v4. There were a number of
disagreements over the v4 soft expirations, and while it's an
interesting discussion, at the end of the day there are good reasons
to support both. In practice, this key subpacket sets a hard limit on
the lifetime of a key, and any soft expirations can only affect the
lifetime of the key up to that hard point. No hard expiration acts
just like v4. Users can mix the two to give whatever semantics they
want.
- A four-octet number denoting the time that the key was created.
This might be better as a subpacket, but then implementers would have
to deal with the case if it was missing.
- A one-octet number denoting the public key algorithm of this
key.
- A series of multiprecision integers comprising the key
material.
Same as v4. There is no need to change MPIs around. There are only
so many ways to store large numbers in a row.
The v5 secret keys, like the v4 secret keys, are the same as the
public key with the secret material appended.
An additional change, which is not part of the key packet format is
that v5 keys have AES as both their "last resort" and "must implement"
ciphers. When encrypting to v4 and v5 keys together, the default
cipher is 3DES. One way to look at this is that cipher preferences on
a v5 key have "AES, 3DES" implicitly at the end if not explicitly used
earlier. When combined with the implicit "3DES" already at the end of
a v4 preference list, the right thing will happen automatically. Note
that while AES is the "must" cipher for v5, implementations that
support v4 keys must also implement 3DES.
To make the transition from v4 to v5 as invisible as possible, I'd
suggest having read support for this in implementations for as long as
possible (say, 1 year) before allowing users to create these keys.
This gives time for upgrading (and there will be a certain amount of
upgrading for other reasons during that time as well, which the v5
keys can be included with), and for various other processes that
interact with OpenPGP like keyservers to be updated.
I also suggest that this not be a part of 2440bis. The v5 discussions
will undoubtedly take a while, and delaying 2440bis for an unknown
(but probably long) period of time seems a shame.
Anyway, this is a starting point. Please thow darts and make
suggestions.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LEApdK021404; Mon, 21 Feb 2005 06:10:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LEApYn021403; Mon, 21 Feb 2005 06:10:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LEAge0021365 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 06:10:47 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D3EEL-0003tQ-0u for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 15:08:09 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D3EG7-0007lN-1V; Mon, 21 Feb 2005 15:09:59 +0100
To: Ben Laurie <ben@algroup.co.uk>
Cc: Jon Callas <jon@callas.org>, OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de> <420A012A.5020204@systemics.com> <39c100e92dbc54b9fcb678d904676384@callas.org> <4219A890.3000603@algroup.co.uk> <87d5uu6upb.fsf@wheatstone.g10code.de> <4219D182.3090203@algroup.co.uk>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Mon, 21 Feb 2005 15:09:59 +0100
In-Reply-To: <4219D182.3090203@algroup.co.uk> (Ben Laurie's message of "Mon, 21 Feb 2005 12:18:10 +0000")
Message-ID: <873bvq57ig.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Mon, 21 Feb 2005 12:18:10 +0000, Ben Laurie said:
> Sorry, not very well today, and it seems not thinking straight. So why
> is there an issue with compatibility?
This happens as soon as you switch your software without updating all
copies of your public key. In particular downgrading the software is
troublesome but also upgrading sometimes (e.g. Tiger/192 has been
removed). You might also have two different applications using the
same keypair.
For the average user the preferences work.
Shalom-Salam,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LCIOAV091501; Mon, 21 Feb 2005 04:18:24 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LCIOZj091500; Mon, 21 Feb 2005 04:18:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LCIIxw091396 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 04:18:19 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A283933CC4; Mon, 21 Feb 2005 12:18:05 +0000 (GMT)
Message-ID: <4219D182.3090203@algroup.co.uk>
Date: Mon, 21 Feb 2005 12:18:10 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Werner Koch <wk@gnupg.org>
Cc: Jon Callas <jon@callas.org>, OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de> <420A012A.5020204@systemics.com> <39c100e92dbc54b9fcb678d904676384@callas.org> <4219A890.3000603@algroup.co.uk> <87d5uu6upb.fsf@wheatstone.g10code.de>
In-Reply-To: <87d5uu6upb.fsf@wheatstone.g10code.de>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Werner Koch wrote:
> On Mon, 21 Feb 2005 09:23:28 +0000, Ben Laurie said:
>
>
>>Oops. What I said was that this seems like a candidate for having
>>flags in the PGP certificates that say what is supported by the
>>receiving application(s).
>
>
> Sorry, I don't understand this. We do have these preferences since
> the very beginning.
Sorry, not very well today, and it seems not thinking straight. So why
is there an issue with compatibility?
BTW, I see that 5.2.3.7. says "It is assumed that only algorithms listed
are supported by the recipient's software" but this language is not
carried forward into 5.2.3.8/9. In fact 5.2.3.9 explicitly rules out
indicating what exactly is supported ("...the key holder's software
might have no compression software").
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LB5lnm065460; Mon, 21 Feb 2005 03:05:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LB5lxj065458; Mon, 21 Feb 2005 03:05:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LB5fKM064921 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 03:05:46 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D3BLG-0000Pe-Hr for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 12:03:06 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D3BLt-0007bZ-AK; Mon, 21 Feb 2005 12:03:45 +0100
To: Ben Laurie <ben@algroup.co.uk>
Cc: Jon Callas <jon@callas.org>, OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de> <420A012A.5020204@systemics.com> <39c100e92dbc54b9fcb678d904676384@callas.org> <4219A890.3000603@algroup.co.uk>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Mon, 21 Feb 2005 12:03:44 +0100
In-Reply-To: <4219A890.3000603@algroup.co.uk> (Ben Laurie's message of "Mon, 21 Feb 2005 09:23:28 +0000")
Message-ID: <87d5uu6upb.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Mon, 21 Feb 2005 09:23:28 +0000, Ben Laurie said:
> Oops. What I said was that this seems like a candidate for having
> flags in the PGP certificates that say what is supported by the
> receiving application(s).
Sorry, I don't understand this. We do have these preferences since
the very beginning.
Salam-Shalom,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L9Ncbm031126; Mon, 21 Feb 2005 01:23:38 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1L9NcmM031124; Mon, 21 Feb 2005 01:23:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1L9NacK031022 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2005 01:23:37 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9187533CBB; Mon, 21 Feb 2005 09:23:23 +0000 (GMT)
Message-ID: <4219A890.3000603@algroup.co.uk>
Date: Mon, 21 Feb 2005 09:23:28 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <jon@callas.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de> <420A012A.5020204@systemics.com> <39c100e92dbc54b9fcb678d904676384@callas.org>
In-Reply-To: <39c100e92dbc54b9fcb678d904676384@callas.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Jon Callas wrote:
>
> Mandatory-to-implement does not mean mandatory-to-use.
>
> If we change 3DES to AES, things don't instantly stop working. If we do
> that, 3DES would be a SHOULD, of course, and there will be a note that
> says that if you don't implement 3DES there could be interoperability
> issues.
>
> I don't think that any reasonable implementor is going to run right out
> and code stupidly. It will obviously take a couple of years before
> someone can safely assume, for example, that the
> algorithm-of-last-resort would be AES.
>
> However, if we ever want to roll 3DES over to AES, we have to start
> sometime. The couple of years of bake-in doesn't start until a change is
> made. Why not now?
>
> I'm willing to concede the point on SHA-256, I wouldn't have brought it
> up at all if NIST hadn't said a couple days ago they're phasing out
> SHA-1 and rolling to SHA-256.
Oops. What I said was that this seems like a candidate for having flags
in the PGP certificates that say what is supported by the receiving
application(s).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1KIio0j002249; Sun, 20 Feb 2005 10:44:50 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1KIio4x002248; Sun, 20 Feb 2005 10:44:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1KIinF2002238 for <ietf-openpgp@imc.org>; Sun, 20 Feb 2005 10:44:50 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2AF2433CA6; Sun, 20 Feb 2005 18:44:38 +0000 (GMT)
Message-ID: <4218DA9A.1020404@algroup.co.uk>
Date: Sun, 20 Feb 2005 18:44:42 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jon Callas <jon@callas.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de> <420A012A.5020204@systemics.com> <39c100e92dbc54b9fcb678d904676384@callas.org>
In-Reply-To: <39c100e92dbc54b9fcb678d904676384@callas.org>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
-----BEGIN PGP MESSAGE-----
Charset: ISO-8859-1
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
hQMOA6U0CVECDD9xEAv/SrJNDiXaZAs/xsyv0oZ7WZ0au61y2C8ql+xzVXvCXjPM
KoaPsZ7jq2CGVK5fYOOiSzH8qEobBpnj0qo3F1jOSaENPCddetMKcvIIzoa/kX1P
051oxGm7l7oU+Dz5C83V95BMuvh7cMcpd/WsAwg25I9mSiv07FCoMuRyRuRAAtdP
fDsivYBQjDbXOJ062NlYjTOjXHw95Ok492ac0r6RirSeKYIbD0qbgpntLRLtDrJx
8s05+EbHETL47pEmxPC0S2E6HOdrDliFM3egFp4AjgVAjdSMSXuCbyG8Biaz2eSS
b7pAFlJfuTwa3/yQ895vKgybKL80NZjNIkfbksSpzCEcZmTX0J8q4FXjbgMyvLUi
VRfWJQOHOZKE07WkEv4Y0DtEix22qaH+XQBpA0nsZfW6IClxsCZtxa3pQBR0RBX4
K6hCdQVxorH/ZCq89PxPGvTocaYyokLjyGuCglAJ4jQp15JDY7xvAbFmhbgzH8Sc
XK+12PDsksql6MshsOdrC/sFcg83lxEc2RRibMNNbPLjYL2l3XXSR/b26CoOkIJY
jMKcONI80pJ1LUy1pko9lT7fnFiK5JArHRki0QE/4PZDa7eALUsCOX2TfQiOKfz5
gyZpxvcb4VNp2y9KlUDyiJTe4ZEIsjUBEJut7KSrBMjoAgYJXY5i6HZRtbkNNCQH
U/TM1nJB/OPetS6prBD5MuGakvflAu3N3yZxeiNP5ug3FNYsKqN81S4a4kEvFfg5
ejm8swCzWej510ng62Stsl5bD04Tik8U9ZXpxsmG4+kyvUJf4T3KlEDH7ovWZk+Q
0gow2XtImhcqhoZikYTPcvrYRc15jw2qlgAEp0/7EN6/vLQB/y+FC3+WdbtRiNx4
ebNV/skLJFMXK1+mYfli6a5nVMzioqra01xt3OS9uPX646mXwcJ+Dl7o+zqlEK37
/pXUikPnB69NPF/grJxCPFB/P5wNwuUUlvubEkjEbFbBGl1H/GRHiH2y8Gjf6npY
QAfFmj7nsL6Q6atjRosh3EPJ6Xmj9MS2msQF6F1yIZg2pmI4NmUzuapat7jl6Ewc
cMI0R4Lvh72ohq5GggaUBi6Weu/ca8aRG5Trh+Srzg7FhlgVKmcXiW3gOg5QVIbS
psHNOV8+7yLgRAkRi+jbAUWkiSTHWz9d//PNc5H0j09aJcAnzIgyC+uRn91RphaY
1Oogh/81VSbbQtY42tACshWzDcj+nOIf+t0s4Qi5V/gOE9LtrynwuoX2ELx2YhFT
yURskg9+r4rqEvFTa9hVl5t8Bj6fsX5BBF7OSFjWeWA+yi07q2TAb35hi6wVfGnQ
cVUmLKxsqQnJy91ZPMKBILRLZdVbcmaQ/FgFzj8+jQGdQu/33hhnAdSPph0GVQwu
/sjxrkjQ/7WutMH3+h2AyhTEp4Y4yn4fDTpJHDmrZmGAu722HsoFoYW9ORU26j/C
uswPkHF9Psk0PhgQbpbIQ8nxHgKNKO8uQPobCHAKTXokORkR2L1FCbmd2EtTaTvy
sLsAJv95f/WQcWRxr/T65Ka5sLX6yq7MJ4o5A5PlSc3zZYdlzexNEXTRqWJbPBsR
cw7HbVD+L+nRb1Gbqyj6vWHl5jcdJJdKDfOOqF1fMZyxn/pASGutUfE7rjTMWHzN
qY0wTowmHvD2a7yf+5p+8PNr5AhHrum8GwzKCfxbpgsD/3PB4pO6w9/UVe2tT6JV
dpo3eUmlKIl8Fw4/ZJ48T4YSKXHQOKl2H3KrfF6C7RIOZgnrDAYOrzCTPCBCTUwY
+RyhGoPGlXieMoQcDazKOd0qnMbDh17wF0sz8RBg/Drsnp0dH4DZHAJkKfOk0eUI
1e5mu1l+7GDfV9KaGZaK7ZxKD+0TDiRAyRQL+XE=
=dK0Y
-----END PGP MESSAGE-----
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IGj7nN039135; Fri, 18 Feb 2005 08:45:07 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IGj7Y6039134; Fri, 18 Feb 2005 08:45:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IGj6kb039111 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 08:45:06 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D2BET-0004RS-M5 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 17:43:57 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D2BE1-0004pU-Om; Fri, 18 Feb 2005 17:43:29 +0100
To: aboietf@redtenbacher.de
Cc: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <E1D2A24-0007Wa-00@mrelayng.kundenserver.de>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Fri, 18 Feb 2005 17:43:29 +0100
In-Reply-To: <E1D2A24-0007Wa-00@mrelayng.kundenserver.de> (aboietf@redtenbacher.de's message of "Fri, 18 Feb 2005 16:27:04 +0100")
Message-ID: <87oeehbyz2.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Fri, 18 Feb 2005 16:27:04 +0100, aboietf said:
> 3 of the newspaper mailing lists I am on (IIRC, it was on the Heise
> Newsticker, the PC WELT newslist and the "focus.de"-newsreport).
Come on, not even semi-professionals would take PC WELT or that
general new magazine (focus) seriously.
> Hmh - for GnuPG the article may not have been a problem as it clearly
> stated that end users doing manual decryption are _not_ susceptible to
> the attack.
GnuPG is used in many gateways and AFAIK you are also using it.
> So the article contains clear statements that crypto gateways
> which use OpenPGP and do automatic decryption, are susceptible to
^^^^^^^^^^^
!!!!!!!!!!!
> the attack (and thus "broken").
> Aside from costing me time to explain the facts to every concerned
> customer, this situation is not very nice for our company. We
That is what service is about; explain your clients whether this is a
problem for them or not.
> if Jon writes that the OpenPGP protocol is going to be changed due to
> a discovery, than this means to a journalist that the discovery must
> be "a really important security flaw or else no one would bother to
Better to tell people about potential weaknesses than to shift them
under the carpet. And well, from a commercial POT you get free
advertising due to such things. There is even no competitor who does
it better - so why bother?
Anyway, such political or economic discussion is IMHO out of scope for
the WG. Feel free to use gnupg-users@ or similar to continue.
Shalom-Salam,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IG1VUq034697; Fri, 18 Feb 2005 08:01:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IG1Vr8034696; Fri, 18 Feb 2005 08:01:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IG1RAs034674 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 08:01:30 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1IG0Er28503; Fri, 18 Feb 2005 16:00:20 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <42161234.9020204@systemics.com>
Date: Fri, 18 Feb 2005 16:05:08 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rick van Rein <rick@openfortress.nl>
CC: Jon Callas <jon@callas.org>, Hal Finney <hal@finney.org>, David Shaw <dshaw@jabberwocky.com>, ietf-openpgp@imc.org
Subject: Re: Hash Collision Shield (subpacket def)
References: <20050217164629.GA44839@phantom.vanrein.org> <20050217171726.GB10406@jabberwocky.com> <5543a3873c27a1dbfe192e2e16fb43be@callas.org> <20050218075600.GA38612@phantom.vanrein.org>
In-Reply-To: <20050218075600.GA38612@phantom.vanrein.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Rick van Rein wrote:
>>>I think we should not do this for several reasons, but those reasons
>>>don't matter much: we already have signature notations.
>>>
>>>
>
>Indeed, that would be the other way of doing it. The likeliness of
>implementations actually using it is less if they are not confronted with
>the technique though. Is it an idea to add a bit under the notation data
>section instead? I'm volunteering.
>
>
If there is a way to do it already, then that
would be better than any changes. We have
tried (ok, some of have tried) to take a razor
to OpenPGP and cut off many bows and frills.
Adding another little feature without a clear
need faces an uphill battle.
Adding a note that a notation packet could
be used as an anti-collision technique seems
like a fine idea. As it's somewhat forward
thinking, I'm not sure where it would go tho,
possibly in the last section of security oddments?
Also, there is a discussion going on here:
http://www.educatedguesswork.org/movabletype/archives/2005/02/next_steps_for_1.html
where Craig Hughes / Dan Simon claim that
introducting random hashing increases collision
resistence, but at the expense of decreasing
other forms of resistence.
>I could never agree to such a strong break in compatibility; also
>because it would be an optional extension and lead to less complete
>implementations breaking on it.
>
>
Yup! It's really tough adding in little quirks
at this stage.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IFRLbx031652; Fri, 18 Feb 2005 07:27:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IFRLYr031651; Fri, 18 Feb 2005 07:27:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IFRFXM031631 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 07:27:16 -0800 (PST)
Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D2A25-0003zM-00 for ietf-openpgp@imc.org; Fri, 18 Feb 2005 16:27:05 +0100
Received: from [62.134.96.180] (helo=62.134.96.180) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1D2A24-0007Wa-00 for ietf-openpgp@imc.org; Fri, 18 Feb 2005 16:27:04 +0100
Subject: Re: SHA-1 broken
From: aboietf@redtenbacher.de
To: ietf-openpgp@imc.org
Message-Id: <E1D2A24-0007Wa-00@mrelayng.kundenserver.de>
Date: Fri, 18 Feb 2005 16:27:04 +0100
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e384712ef1f129ade61e87b26279bda6
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Werner Koch <wk@gnupg.org> wrote on 18 Feb 2005:
>I only know the Heise report (ct magazine and the most known IT news
>ticker). [...]
I received articles about the alleged "security flaw in OpenPGP" on
3 of the newspaper mailing lists I am on (IIRC, it was on the Heise
Newsticker, the PC WELT newslist and the "focus.de"-newsreport).
I did not check on how many other channels similar articles were
published, as I was too busy answering phone calls and mails from
concerned customers of our crypto gateway, who wanted to know whether
our product was now "broken" or still safe.
The effect was obvious to feel: Our customers were concerned, and if
so many customers contact us, I can imagine how many potential
customers (who don't contact us) are shying away from the idea of
using automatic encryption/decryption due to those articles.
>Their article didn't talk about a practical attack or
>spread panic [...] The article was quite okay.
Hmh - for GnuPG the article may not have been a problem as it clearly
stated that end users doing manual decryption are _not_ susceptible to
the attack.
But imagine being in my position, i.e. the manufacturer of a product
that automatically encrypts/decrypts mail using the OpenPGP protocol.
Let me quote from the "quite okay" article that was published on
14 Feb 2004 at 13:17:
"Weakness in OpenPGP: Serge Mister and Robert Zuccherato ... have
detected a weakness in the open crypto protocol OpenPGP which has the
effect that on systems which automatically decrypt, the clear text can
be calculated [by an attacker]. ... At risk are those systems that
automatically decrypt encrypted messages. ... The crypto community is
considering to modify the OpenPGP protocol due to this weakness."
So the article contains clear statements that crypto gateways
which use OpenPGP and do automatic decryption, are susceptible to
the attack (and thus "broken").
Aside from costing me time to explain the facts to every concerned
customer, this situation is not very nice for our company. We
pioneered the crypto gateway idea more than 5 years ago (see e.g.
"www.redtenbacher.de/signatur/index.htm") and I personally did a lot
of lecturing and article writing to spread the idea of automatic
encryption/decryption via a gateway. Now the press writes that the
very basis of our security products is allegedly "broken".
Therefore, let us be aware that journalists are no crypto experts and
can easily misunderstand statements even if the original article (by
Jon et al.) was technically correct. If a journalist reads words like
"security weakness" or "broken", they just publish that "fact" without
bothering to differentiate who exactly is susceptible to the risk. And
if Jon writes that the OpenPGP protocol is going to be changed due to
a discovery, than this means to a journalist that the discovery must
be "a really important security flaw or else no one would bother to
change the protocol"! That is the simple mind of the press, and we
should take this into account when making public announcements.
- Wolfgang Redtenbacher
---------------------------------------------------------------------
Redtenbacher Software Tel.: +49 7159 17046
Roemerstr. 11/1 Fax: +49 7159 17047
D-71272 Renningen e-mail: wolfgang@redtenbacher.de
---------------------------------------------------------------------
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IDV56Z014626; Fri, 18 Feb 2005 05:31:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IDV5IZ014625; Fri, 18 Feb 2005 05:31:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IDV3L1014511 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 05:31:04 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1IDUBr27839; Fri, 18 Feb 2005 13:30:21 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <4215EF09.7010702@systemics.com>
Date: Fri, 18 Feb 2005 13:35:05 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ingo Luetkebohle <ingo@fargonauten.de>
CC: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <20050218004927.CB72957EBA@finney.org> <87d5uyf548.fsf@wheatstone.g10code.de> <1108729615.18605.28.camel@chagall.TechFak.Uni-Bielefeld.DE>
In-Reply-To: <1108729615.18605.28.camel@chagall.TechFak.Uni-Bielefeld.DE>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Ingo Luetkebohle wrote:
>On Fri, 2005-02-18 at 13:02 +0100, Werner Koch wrote:
>
>
>>We should however not kick out SHA-1 from all places where it is now
>>used and replace it by SHA-256 before we understand the new attack.
>>
>>
>
>Hmm, maybe this is stupid and it is definetely more effort
>computationally, but what about using several hashing methods
>simultaneously, mandating that all hashes have to check out?
>
>
Scientifically, it's very hard to show that that
is an improvement in and of itself. If the two
(or more) hashes are similar, there is no real
expectation that their security is improved.
For example, MD5 and SHA-1 are both attacked
by the same techniques, so combining them
isn't going to give any definitive advantage.
And, if one of the hashes is much stronger,
then just use that. I.e., if we were to use both
SHA-2 and SHA-1 then in almost all circumstances,
the security of SHA-2 would dominate that of
SHA-1, so there is little point in using the latter.
Also, there is one bad side: complexity. The
addition of complexity is always a 'bad' as it
introduces the possibility of wierd effects.
Think of it this way, if the algorithm delivers
TRUE if (n-1) of n hashes deliver TRUE, then
we have the possibility of implementation
bugs that muck up the checking in some way
and returning TRUE on 0.
iang
PS: there is a new cryptosystem called ciphire
(sp?) that does precisely that: it uses two
algorithms everywhere, in different ways.
Looks great on paper now, but what happens
in 3 years time when they have to replace
half the algorithms?
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ICRDp6091279; Fri, 18 Feb 2005 04:27:13 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1ICRDd9091278; Fri, 18 Feb 2005 04:27:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mailout.TechFak.Uni-Bielefeld.DE (mailout.TechFak.Uni-Bielefeld.DE [129.70.136.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ICRBGm091211 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 04:27:12 -0800 (PST) (envelope-from ingo@fargonauten.de)
Received: from chagall.TechFak.Uni-Bielefeld.DE (chagall.TechFak.Uni-Bielefeld.DE [129.70.139.44]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2004/05/05/sjaenick) with ESMTP id j1ICQtD8000280 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 18 Feb 2005 13:26:55 +0100 (MET)
Subject: Re: SHA-1 broken
From: Ingo Luetkebohle <ingo@fargonauten.de>
To: Werner Koch <wk@gnupg.org>
Cc: "\"Hal Finney\"" <hal@finney.org>, ietf-openpgp@imc.org
In-Reply-To: <87d5uyf548.fsf@wheatstone.g10code.de>
References: <20050218004927.CB72957EBA@finney.org> <87d5uyf548.fsf@wheatstone.g10code.de>
Content-Type: text/plain
Date: Fri, 18 Feb 2005 13:26:55 +0100
Message-Id: <1108729615.18605.28.camel@chagall.TechFak.Uni-Bielefeld.DE>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.0
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Fri, 2005-02-18 at 13:02 +0100, Werner Koch wrote:
> We should however not kick out SHA-1 from all places where it is now
> used and replace it by SHA-256 before we understand the new attack.
Hmm, maybe this is stupid and it is definetely more effort
computationally, but what about using several hashing methods
simultaneously, mandating that all hashes have to check out?
regards
--
Ingo
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ICLcqi089722; Fri, 18 Feb 2005 04:21:38 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1ICLbJj089720; Fri, 18 Feb 2005 04:21:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ICLa67089630 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 04:21:36 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1ICKhr27523; Fri, 18 Feb 2005 12:20:54 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <4215DEC1.3000104@systemics.com>
Date: Fri, 18 Feb 2005 12:25:37 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
CC: Jon Callas <jon@callas.org>, aboietf@redtenbacher.de, Adam Shostack <adam@homeport.org>
Subject: The oracle weakness and the art of disclosure
References: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de> <c2fb5c250787458643ca22dd4407329f@callas.org>
In-Reply-To: <c2fb5c250787458643ca22dd4407329f@callas.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Jon Callas wrote:
> I think it would have been less helpful, however, to do as a different
> organization did the previous week over a botched IV. They said that
> it wasn't worth fixing and no one needs that anyway and there was a
> storm of press over here.
I personally hated the announcement ... BUT ...
It is what we should be doing. I base this remark on
a research line in economics that I've picked up over
the last year, inspired by Adam Shostack's question
of "what is a security signal?" This has led me to
question "what is security?" Between the two of us
and with help from others, we've been gradually
forming an idea about what economics has to say
about all this.
The upshot is that the disclosure of weaknesses is
highly recommended. It turns out, and I think we can
show this in economics terms, that disclosing the
protocol's weaknesses in clear and obvious detail
is a good security signal.
Now, back in the real world, many protocols and
security systems simply don't do that. So I think
there is going to be a period of adjustment, where
those that disclose in glorious and self-flagellating
terms will be leading the others, in many senses.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IC5fvE085169; Fri, 18 Feb 2005 04:05:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IC5fjV085168; Fri, 18 Feb 2005 04:05:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IC5ZMu084897 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 04:05:40 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D26rb-0007I1-6Y for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 13:04:03 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D26q7-0004Vq-T3; Fri, 18 Feb 2005 13:02:31 +0100
To: hal@finney.org ("Hal Finney")
Cc: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <20050218004927.CB72957EBA@finney.org>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Fri, 18 Feb 2005 13:02:31 +0100
In-Reply-To: <20050218004927.CB72957EBA@finney.org> (Hal Finney's message of "Thu, 17 Feb 2005 16:49:27 -0800 (PST)")
Message-ID: <87d5uyf548.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, 17 Feb 2005 16:49:27 -0800 (PST), "Hal Finney" said:
> alternative views that SHA-1 is just fine and/or that SHA-2 is no better.
> I don't think SHA-1 is just fine and I do think that SHA-2 is better.
> Where we go with that is still open for discussion.
I agree with your reasoning.
We should however not kick out SHA-1 from all places where it is now
used and replace it by SHA-256 before we understand the new attack.
If we recall the DES development, the NSA knew techniques which got
invented in open research only years later. Hopefully that is the
case with SHA-2 too.
Shalom-Salam,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IBt16T081368; Fri, 18 Feb 2005 03:55:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IBt15j081367; Fri, 18 Feb 2005 03:55:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IBsxYD081347 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 03:55:00 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D26hx-0007D4-N0 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 12:54:05 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D26fq-0004VJ-Q0; Fri, 18 Feb 2005 12:51:54 +0100
To: aboietf@redtenbacher.de
Cc: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <E1D1vEp-0000Tl-00@mrelayng.kundenserver.de>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Fri, 18 Feb 2005 12:51:54 +0100
In-Reply-To: <E1D1vEp-0000Tl-00@mrelayng.kundenserver.de> (aboietf@redtenbacher.de's message of "Fri, 18 Feb 2005 00:39:16 +0100")
Message-ID: <87hdkaf5lx.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Fri, 18 Feb 2005 00:39:16 +0100, aboietf said:
> proper handling for the publication of the "oracle attack" would have
> been to point out that no mail application based on OpenPGP was
> susceptible to the circumstances of the attack, and that implementing
We don't know.
> an "oracle" is considered a Really Stupid Thing (TM).
The sad thing is that oracles are very common. On the positive side
you have the fact that people don't interpret error messages properly
because that is too much work and just return a Bollean value - by
that they defeat this particular attack (maybe except for LANs).
> never relevant to the reality of e-mail applications. If a recipient
> is so stupid as to send me back thousands of "I can't read your mail"
Heise clearly pointed out that the attack won't work for attended
usage.
Salam-Shalom,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IBopKL079793; Fri, 18 Feb 2005 03:50:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IBop43079792; Fri, 18 Feb 2005 03:50:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IBofE9079474 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 03:50:46 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D26d9-0007Bc-8j for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 12:49:07 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D26av-0004Uo-Ce; Fri, 18 Feb 2005 12:46:49 +0100
To: Jon Callas <jon@callas.org>
Cc: aboietf@redtenbacher.de, ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de> <c2fb5c250787458643ca22dd4407329f@callas.org>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Fri, 18 Feb 2005 12:46:49 +0100
In-Reply-To: <c2fb5c250787458643ca22dd4407329f@callas.org> (Jon Callas's message of "Thu, 17 Feb 2005 17:46:54 -0800")
Message-ID: <87ll9mf5ue.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, 17 Feb 2005 17:46:54 -0800, Jon Callas said:
> I'm sorry that the German press was so twitchy about it. I sent
I only know the Heise report (ct magazine and the most known IT news
ticker). Their article[1] didn't talk about a practical attack or
spread panic - don't known about the trolls on their forum; I don't
read that. The article was quite okay. They even didn't call me -
what they usually do if there are OpenPGP or GnuPG problems.
Shalom-Salam,
Werner
[1] http://www.heise.de/pda/newsticker/m56350.html
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I8V2QQ004828; Fri, 18 Feb 2005 00:31:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I8V2Ue004827; Fri, 18 Feb 2005 00:31:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I8V0mE004743 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 00:31:01 -0800 (PST) (envelope-from news@branwen.iks-jena.de)
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.3/8.13.1) with ESMTP id j1I8UnaU022269 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 09:30:51 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.3/8.13.1/Submit) id j1I8UnSw022268 for ietf-openpgp@imc.org; Fri, 18 Feb 2005 09:30:49 +0100
To: ietf-openpgp@imc.org
Path: not-for-mail
From: Lutz Donnerhacke <lutz@iks-jena.de>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: SHA-1 broken
Date: Fri, 18 Feb 2005 08:30:49 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 25
Message-ID: <slrnd1b9tp.oa.lutz@taranis.iks-jena.de>
References: <92a50730b469e32d19a7732981651f48@callas.org>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1108715449 19837 217.17.192.37 (18 Feb 2005 08:30:49 GMT)
X-Complaints-To: usenet@iks-jena.de
NNTP-Posting-Date: Fri, 18 Feb 2005 08:30:49 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
* Jon Callas wrote:
> A key fingerprint is little more than a hash of the key material, the
> creation time, and a few constants. There's very little place in there
> to manufacture a collision. Fingerprints need little more than
> one-way-ness.
IBTD, sorry.
The recent attack allows to construct two "random" messages differing in
some (few) bits generating the same hash.
So a possible attack might be to generate such a collision and search one of
the messages in existing key material from the key servers. If some key was
found containing one of those sequences, it can be replaced by a different
key by changing those few bits.
This manipulation does not change the fingerprint and might not change the
key signature nor the user certificates, so the modified key is a drop in
replacement for the old one.
The main advantage for the attacker is, that the modified key might be easily
factorised. Very likely. So the attacker can mount a MITM attack using the
web of trust to hide it.
Bad news.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I7uM1a091274; Thu, 17 Feb 2005 23:56:22 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I7uMcr091273; Thu, 17 Feb 2005 23:56:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp16.wxs.nl (smtp16.wxs.nl [195.121.6.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I7uL8H091160 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 23:56:21 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp16.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC300LCMKPDC5@smtp16.wxs.nl> for ietf-openpgp@imc.org; Fri, 18 Feb 2005 08:56:05 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id D3BAA2A69D; Fri, 18 Feb 2005 08:56:00 +0100 (CET)
Date: Fri, 18 Feb 2005 08:56:00 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: Hash Collision Shield (subpacket def)
In-reply-to: <5543a3873c27a1dbfe192e2e16fb43be@callas.org>
To: Jon Callas <jon@callas.org>, Hal Finney <hal@finney.org>
Cc: David Shaw <dshaw@jabberwocky.com>, ietf-openpgp@imc.org
Message-id: <20050218075600.GA38612@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
References: <20050217164629.GA44839@phantom.vanrein.org> <20050217171726.GB10406@jabberwocky.com> <5543a3873c27a1dbfe192e2e16fb43be@callas.org>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello,
Jon and David said a similar thing:
> >I think we should not do this for several reasons, but those reasons
> >don't matter much: we already have signature notations.
Indeed, that would be the other way of doing it. The likeliness of
implementations actually using it is less if they are not confronted with
the technique though. Is it an idea to add a bit under the notation data
section instead? I'm volunteering.
> However, I also think this is a very bad idea. We already have pulled
> things out of OpenPGP because they could be used for subliminal
> channels,
This is definately the weak point of this strategy, as said in the header.
It applies equally to notation data encoding, of course.
But it it does seem to be the only way to make durable signatures.
Hal liked the idea but pointed out that collisions might have occurred
before the random data was hashed, Actually that is such a strong downer
that I am now wondering what the added value of this approach would be.
> But we could specify it to work this way: we'd have a subpacket with
> the random data, and its meaning is that this stuff gets hashed first
> when we do the signature calculation. We'd be changing the rules for
> how signatures are calculated.
I could never agree to such a strong break in compatibility; also
because it would be an optional extension and lead to less complete
implementations breaking on it.
Thanks,
-Rick
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I7GkXn076063; Thu, 17 Feb 2005 23:16:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I7GkvH076062; Thu, 17 Feb 2005 23:16:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I7GjKI076032 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 23:16:45 -0800 (PST) (envelope-from konrad@silmor.de)
Received: from pd9e1fa09.dip.t-dialin.net ([217.225.250.9] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1D22NT-0003Ui-00; Fri, 18 Feb 2005 08:16:39 +0100
From: Konrad Rosenbaum <konrad@silmor.de>
To: aboietf@redtenbacher.de, ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Date: Fri, 18 Feb 2005 08:16:37 +0100
User-Agent: KMail/1.7.2
References: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
In-Reply-To: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2937758.2gYUIBvpJC"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200502180816.38822@zaphod.konrad.silmor.de>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
--nextPart2937758.2gYUIBvpJC
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday 17 February 2005 21:18, aboietf@redtenbacher.de wrote:
> The recent announcement of Jon Callas et al. was - in my eyes - not
> helpful at all. It solved a non-existing problem (not one single
> existing OpenPGP implementation suffered from the "oracle" effect),
> and the result in the media (at least in Germany) was rather
> catastrophic: Even the (normally pretty conservative) Heise Verlag
> published panic articles that "all automatic encrypt/decrypt systems
> based on OpenPGP are broken"!
Since when is the Heise Newsticker "pretty conservative"? If they can draw=
=20
attention to their website they will do it.=20
You're free to contact them and ask for an update of that article... ;-)
Konrad
--nextPart2937758.2gYUIBvpJC
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCFZZWClt766LaIH0RAnybAJ4oyX1T8C/W+tpbHwKVzqkCbMmZ9gCfeCNH
Sh23EKvtkxc7zhkM1+H7V4s=
=06t9
-----END PGP SIGNATURE-----
--nextPart2937758.2gYUIBvpJC--
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I6xmCW069799; Thu, 17 Feb 2005 22:59:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I6xmsl069798; Thu, 17 Feb 2005 22:59:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I6xlhU069643 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 22:59:47 -0800 (PST) (envelope-from konrad@silmor.de)
Received: from pd9e1fa09.dip.t-dialin.net ([217.225.250.9] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1D226p-0003T3-00 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2005 07:59:27 +0100
From: Konrad Rosenbaum <konrad@silmor.de>
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Date: Fri, 18 Feb 2005 07:59:19 +0100
User-Agent: KMail/1.7.2
References: <200502170750.53386@zaphod.konrad.silmor.de> <421494F0.3060100@systemics.com> <20050217140010.GN24504@jabberwocky.com>
In-Reply-To: <20050217140010.GN24504@jabberwocky.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2173628.TG4jFkyWuK"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200502180759.26222@zaphod.konrad.silmor.de>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
--nextPart2173628.TG4jFkyWuK
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Thursday 17 February 2005 15:00, David Shaw wrote:
> I don't think it's all that easy to just add options to the
> fingerprint. Let's say you specified a fingerprint (which is
> currently just HASH) with ALGO:HASH. So, my current (SHA-1)
> fingerprint would be:
>
> 2:7D92FD313AB6F3734CC59CA1DB698D7199242560
>
> Simple enough, but my fingerprint would also be (MD5):
>
> 1:B9E4614F2E6FACD8F5DD32010AC50AAC
>
> and even (SHA-512):
>
> =20
> 10:00C2C9BBF4AC3AD6D45275C041E1EE88AA6B0564F227AD4FBE0F7BBE845B8B47342A94
>1A88384A79CFC0858572DCDE326AC21625D7822B2102CA3857669C381B
>
> Allowing multiple representations of the fingerprint allows for all
> sorts of problems where an attacker can force a particular hash
> algorithm. There is even a warning about this attack (in the context
> of signatures) in the draft.
[cut]
> Rather than trying to jury-rig something together to allow using other
> hashes, I think I would rather just declare a V5 key format (which can
> be essentially the same as V4), which uses a different hash.
Why not do both?
If the hash ID used for the fingerprint is part of the key format and=20
consequently hashed together with the key then there shouldn't be much of=20
an attack vector left. The only one who can enforce a certain hash to be=20
used is the key owner, if anybody else tries it ultimately changes the=20
fingerprint.
Konrad
--nextPart2173628.TG4jFkyWuK
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCFZJOClt766LaIH0RAtqkAJsG1YN1IZ3mt7kh0jWyziEkWfo+pQCePsQA
iSVGTatUKFvnDbsBuB4alvU=
=+K+i
-----END PGP SIGNATURE-----
--nextPart2173628.TG4jFkyWuK--
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2bIFx025474; Thu, 17 Feb 2005 18:37:18 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I2bIFc025473; Thu, 17 Feb 2005 18:37:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2bIun025460 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 18:37:18 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Feb 2005 18:37:12 -0800
Received: from [172.16.1.3] ([199.107.157.239]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Feb 2005 18:37:12 -0800
X-PGP-Universal: processed
In-Reply-To: <41EA7B12.7090803@algroup.co.uk>
References: <41EA7B12.7090803@algroup.co.uk>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <14f2671e7e984a1aa596eacfb804e124@callas.org>
Content-Transfer-Encoding: 7bit
Cc: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: Re: draft-ietf-openpgp-rfc2440bis-12 5.2.3
Date: Thu, 17 Feb 2005 18:37:45 -0800
To: Ben Laurie <ben@algroup.co.uk>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On 16 Jan 2005, at 6:32 AM, Ben Laurie wrote:
> in 5.2.3, there was:
>
> - Hashed subpacket data set.
>
> - Unhashed subpacket data set.
>
> and in 5.2.3.1:
>
> A subpacket data set consists of zero or more signature subpackets,
> preceded by a two-octet scalar count of the length in octets of all
> the subpackets; a pointer incremented by this number will skip over
> the subpacket data set.
>
Done.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2VgDw025072; Thu, 17 Feb 2005 18:31:42 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I2Vghf025071; Thu, 17 Feb 2005 18:31:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2VfNx025055 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 18:31:41 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Feb 2005 18:31:35 -0800
Received: from [172.16.1.3] ([199.107.157.239]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Feb 2005 18:31:35 -0800
X-PGP-Universal: processed
In-Reply-To: <41E9831B.1050006@algroup.co.uk>
References: <41E9831B.1050006@algroup.co.uk>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <58424853e638b6b271d4170f5b00e140@callas.org>
Content-Transfer-Encoding: 7bit
Cc: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: Re: Comments on draft-ietf-openpgp-rfc2440bis-12
Date: Thu, 17 Feb 2005 18:32:07 -0800
To: Ben Laurie <ben@algroup.co.uk>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On 15 Jan 2005, at 12:54 PM, Ben Laurie wrote:
>
> 3.2 (MPI) doesn't specify what the unused bits should be set to. This
> may be deliberate but I think it should either say they MUST be zero
> (which I prefer) or that their content is unspecified.
>
> 4.2 refers to Content Tags, but 4.3 calls them Packet Tags.
>
Both of these are fixed.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2MhaM024382; Thu, 17 Feb 2005 18:22:43 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I2Mh7B024381; Thu, 17 Feb 2005 18:22:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I2Mg7R024370 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 18:22:43 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Feb 2005 18:22:33 -0800
Received: from [172.16.1.3] ([199.107.157.239]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Feb 2005 18:22:33 -0800
X-PGP-Universal: processed
In-Reply-To: <20050217171726.GB10406@jabberwocky.com>
References: <20050217164629.GA44839@phantom.vanrein.org> <20050217171726.GB10406@jabberwocky.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <5543a3873c27a1dbfe192e2e16fb43be@callas.org>
Content-Transfer-Encoding: 7bit
Cc: ietf-openpgp@imc.org
From: Jon Callas <jon@callas.org>
Subject: Re: Hash Collision Shield (subpacket def)
Date: Thu, 17 Feb 2005 18:23:03 -0800
To: David Shaw <dshaw@jabberwocky.com>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On 17 Feb 2005, at 9:17 AM, David Shaw wrote:
> I think we should not do this for several reasons, but those reasons
> don't matter much: we already have signature notations. If someone
> wants to add arbitrary stuff in the middle of their signatures, they
> can do that now.
>
I agree completely. Notations are the way to do this.
However, I also think this is a very bad idea. We already have pulled
things out of OpenPGP because they could be used for subliminal
channels, and there are a lot of people who think that DSA is the work
of Satan because it has random data and thus subliminal channels.
However, if someone wishes to add in extra random data, then a notation
is a fine way to do it.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1pXfd020547; Thu, 17 Feb 2005 17:51:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I1pX2l020546; Thu, 17 Feb 2005 17:51:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1pWOo020540 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 17:51:33 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 5D52357EBA; Thu, 17 Feb 2005 17:51:11 -0800 (PST)
To: ietf-openpgp@imc.org, rick@openfortress.nl
Subject: Re: Hash Collision Shield (subpacket def)
Message-Id: <20050218015111.5D52357EBA@finney.org>
Date: Thu, 17 Feb 2005 17:51:11 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
This hash collision shield is an interesting idea, but to work the random
data has to be hashed first, before the other data that is signed.
Otherwise if the data being signed is hashed first, and it has a
collision, the collision will still be valid when the random data is
hashed later. That's because of how these hash functions work.
But we could specify it to work this way: we'd have a subpacket with
the random data, and its meaning is that this stuff gets hashed first
when we do the signature calculation. We'd be changing the rules for
how signatures are calculated. We could set the critical bit on the
subpacket to indicate that the sig won't be verifiable by software which
doesn't recognize that subpacket type. We could even put the subpacket
into the unhashed region since there is no reason to hash it again.
OTOH it doesn't hurt to do so.
There are some down sides to putting random data into signatures. See
http://www.educatedguesswork.org/movabletype/archives/2005/02/next_steps_for_1.html
for some discussion of the pros and cons.
Hal Finney
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1kTJF020210; Thu, 17 Feb 2005 17:46:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I1kTnC020209; Thu, 17 Feb 2005 17:46:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1kSN4020196 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 17:46:28 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Thu, 17 Feb 2005 17:46:19 -0800
Received: from [172.16.1.3] ([199.107.157.239]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Feb 2005 17:46:18 -0800
X-PGP-Universal: processed
In-Reply-To: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
References: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <c2fb5c250787458643ca22dd4407329f@callas.org>
Content-Transfer-Encoding: 7bit
Cc: ietf-openpgp@imc.org
From: Jon Callas <jon@callas.org>
Subject: Re: SHA-1 broken
Date: Thu, 17 Feb 2005 17:46:54 -0800
To: aboietf@redtenbacher.de
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On 17 Feb 2005, at 12:18 PM, aboietf@redtenbacher.de wrote:
> The recent announcement of Jon Callas et al. was - in my eyes - not
> helpful at all. It solved a non-existing problem (not one single
> existing OpenPGP implementation suffered from the "oracle" effect),
> and the result in the media (at least in Germany) was rather
> catastrophic: Even the (normally pretty conservative) Heise Verlag
> published panic articles that "all automatic encrypt/decrypt systems
> based on OpenPGP are broken"!
>
I'm sorry that the German press was so twitchy about it. I sent
releases to both Reuters and UPI here, and got a polite response back
from Reuters thanking me for being so humble about it. There's not been
a further peep on it, and I've been waiting for it. Should this ever
happen again, I'll try to make sure that the German press isn't silly.
I know people who can do German translations -- not that I'm expecting
to ever have to do that again, mind you.
I think it would have been less helpful, however, to do as a different
organization did the previous week over a botched IV. They said that it
wasn't worth fixing and no one needs that anyway and there was a storm
of press over here.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I0non9013712; Thu, 17 Feb 2005 16:49:50 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I0noEO013711; Thu, 17 Feb 2005 16:49:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I0nnbI013702 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 16:49:49 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id CB72957EBA; Thu, 17 Feb 2005 16:49:27 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Message-Id: <20050218004927.CB72957EBA@finney.org>
Date: Thu, 17 Feb 2005 16:49:27 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I have a little different perspective on the new attacks, which I will
throw into the mix. Of course everything is still very mmuch uncertain
and up in the air and we are all digesting the information.
Many people are saying, this is nothing to worry about, 2^69 is still
plenty strong, and there is no reason to stop using SHA-1. I am not
comfortable with this. 2^69 is in a gray area. It's not small enough
to say we absolutely have to stop using it, but it's not big enough
to say that the hash is basically as strong as before.
A reduction in strength by a factor of 2048 is the difference between
1 day and 5 years. It's the difference between 1 month and 170 years.
Depending on how much money you have to spend, this could definitely
make the difference between a practical and an impractical attack.
And remember that the birthday attack of 2^80 also requires 2^80 memory,
which would probably dominate the costs. We don't know the details
of the new attack but I haven't seen any indication that it requires
enormous amounts of memory.
This makes me feel pretty uncomfortable sticking with SHA-1, especially
when we do have a replacement hash that NIST (which is backed by the
NSA in these issues) was already encouraging people to transition to,
the SHA-2 family: SHA-256, SHA-384 and SHA-512. These hashes are newer,
and they were designed with an eye to experience with SHA-1 and its
related hashes, MD5 and MD4. They are intended to provide much greater
strength: 128 to 256 bits, compared to 80 bits for SHA-1.
This leads to another claim I'm seeing a lot of, which is that SHA-256
is just about the same as SHA-1 and will probably be just as unsafe.
I don't agree that we are in a position to make this conclusion. MD4, MD5
and SHA-1 are a very similar family of hash functions, each one adding
a few twists and extensions to the one before. SHA-2 is not nearly
so similar. I don't think anyone who has studied or implemented these
functions would disagree with the claim that SHA-1 is much closer to MD5
than it is to SHA-256. This suggests to me that you can't generalize
from the older hash functions to SHA-2.
Now, it's true that in its broad structure, SHA-2 does share commonalities
with the others. It is basically an unbalanced feistel network structure.
But it handles the nonlinearities differently, it updates two words
each round, one in the middle and one at the end, using two sources of
nonlinearities, it mixes the bits up much more with rotates, it avoids
the use of the 16 round block structure of MD4, MD5 and SHA-1, and there
are many more differences.
We can also look at the fact that in a way, the attack just barely works
against SHA-1. As I said, it puts us in a gray area. SHA-1 almost
retained its full designed strength against the attack. The additional
complexity in SHA-2 should give us even more confidence. And SHA-2, with
a minimum strength of 128 bits, has a much greater margin against attacks.
If we took 11 bits off SHA-2 it wouldn't matter a bit. We could lose
30 bits and it wouldn't matter.
Some people are concerned that SHA-2 hasn't received enough attention.
But don't get the impression that this is some little-known hash function
which has suddenly found itself thrust into the limelight. These hashes
have been around for four years. The are being put forward by the most
powerful and prominent source of cryptographic standards in the world.
People haven't ignored SHA-2. If there is a dearth of published
attacks, it's not because nobody paid attention. Finding a flaw in the
new standard hash algorithm of the United States government would be a
major accomplishment for a cryptographer.
Now, I'm not arguing here that we should drop all support for SHA-1 and
switch over to SHA-2. But in my opinion, given the information presently
available, SHA-2 is a better choice for a hash function than SHA-1.
I wanted to give my reasoning because I'm seeing people promoting the
alternative views that SHA-1 is just fine and/or that SHA-2 is no better.
I don't think SHA-1 is just fine and I do think that SHA-2 is better.
Where we go with that is still open for discussion.
Hal Finney
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HNdSw5006810; Thu, 17 Feb 2005 15:39:28 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HNdSXW006809; Thu, 17 Feb 2005 15:39:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HNdRmm006791 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 15:39:27 -0800 (PST) (envelope-from aboietf@redtenbacher.de)
Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D1vEq-0005q8-00 for ietf-openpgp@imc.org; Fri, 18 Feb 2005 00:39:16 +0100
Received: from [62.134.96.43] (helo=62.134.96.43) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1D1vEp-0000Tl-00 for ietf-openpgp@imc.org; Fri, 18 Feb 2005 00:39:16 +0100
Subject: Re: SHA-1 broken
From: aboietf@redtenbacher.de
To: ietf-openpgp@imc.org
Message-Id: <E1D1vEp-0000Tl-00@mrelayng.kundenserver.de>
Date: Fri, 18 Feb 2005 00:39:16 +0100
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e384712ef1f129ade61e87b26279bda6
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Ian G <iang@systemics.com> wrote on 17 Feb 2005:
>>Please, let us stop making any "change announcements" to the public if
>>there is not an actual security problem to be solved!
>
>Well, I'm not sure anyone has made any
>"change announcements" unless you mean
>that recent minor oracle attack.
That is exactly what I meant: the announcement of Jon et al.
regarding the "minor oracle attack".
>It seems that we have to go through a
>period of actually revealing these things
>and encouraging people not to panic.
>
>Elsewise we go back to the bad old days
>where we keep all quiet.
I was not suggesting to "keep quiet" any real weaknesses. But the
proper handling for the publication of the "oracle attack" would have
been to point out that no mail application based on OpenPGP was
susceptible to the circumstances of the attack, and that implementing
an "oracle" is considered a Really Stupid Thing (TM).
The short mention in the announcement that the OpenPGP group would be
changing the protocol due to the "oracle attack publication", was
interpreted by the media as a "proof" of the fact that a serious
problem had been found - which was not the case at all. The "attack"
may have been interesting from a mathematical viewpoint, but it was
never relevant to the reality of e-mail applications. If a recipient
is so stupid as to send me back thousands of "I can't read your mail"
answers, this same user will surely be stupid enough to send me his
private PGP key + passphrase if I devise a proper social engineering
or phishing attack. So the problem here is the fact of having an
"oracle" (implemented as a stupid user or a stupid programmer) in the
first place, and lies _not_ with the protocol.
Therefore, let us solve the problem where it is, and not at some other
place!
- Wolfgang Redtenbacher
---------------------------------------------------------------------
Redtenbacher Software Tel.: +49 7159 17046
Roemerstr. 11/1 Fax: +49 7159 17047
D-71272 Renningen e-mail: wolfgang@redtenbacher.de
---------------------------------------------------------------------
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HM6jFn098897; Thu, 17 Feb 2005 14:06:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HM6jXi098896; Thu, 17 Feb 2005 14:06:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HM6iWh098887 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 14:06:44 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 14:06:31 -0800
Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Feb 2005 14:06:30 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <421508E4.2040702@systemics.com>
References: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de> <421508E4.2040702@systemics.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <92a50730b469e32d19a7732981651f48@callas.org>
Content-Transfer-Encoding: 7bit
From: Jon Callas <jon@callas.org>
Subject: Re: SHA-1 broken
Date: Thu, 17 Feb 2005 14:07:10 -0800
To: OpenPGP <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
My feeling is that a key fingerprint is the *least* of the things that
are in danger from a SHA-1 break.
A key fingerprint is little more than a hash of the key material, the
creation time, and a few constants. There's very little place in there
to manufacture a collision. Fingerprints need little more than
one-way-ness.
Furthermore, it is imperative that a fingerprint be short. The whole
reason for having them is that they are short. All the things you want
a fingerprint for require it being short. Twenty bytes is plenty long
enough for one. Otherwise just get rid of the fingerprint and just
write down the key.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HL8t1j094054; Thu, 17 Feb 2005 13:08:55 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HL8tmx094053; Thu, 17 Feb 2005 13:08:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HL8nj2094030 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 13:08:54 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1HL8Fr22862; Thu, 17 Feb 2005 21:08:25 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421508E4.2040702@systemics.com>
Date: Thu, 17 Feb 2005 21:13:08 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aboietf@redtenbacher.de
CC: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
In-Reply-To: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
aboietf@redtenbacher.de wrote:
>What are the actual facts behind these "SHA-1 is broken" rumours?
>Someone found a way to reduce the SHA-1 strenght by 11 binary digits.
>This has the exact same effect as if someone boosted the current
>processor speeds by a factor of 2096.
>
>
Right now, that's about it. It looks like
the 'padding' issue is unimportant and
the only issue is the number of bits
of reduced strength. So I don't think
we have to change SHA-1...
>The recent announcement of Jon Callas et al. was - in my eyes - not
>helpful at all. It solved a non-existing problem (not one single
>existing OpenPGP implementation suffered from the "oracle" effect),
>and the result in the media (at least in Germany) was rather
>catastrophic: Even the (normally pretty conservative) Heise Verlag
>published panic articles that "all automatic encrypt/decrypt systems
>based on OpenPGP are broken"!
>
>So the actual effect of the announcement was that, while not fixing
>any real security problem, it seriously caused a Public Relations
>damage for crypto gateways like our "KT Mail gateway"
>(www.redtenbacher.de/info/gateway.htm) or "PGP Universal" (from PGP
>Inc.).
>
>Please, let us stop making any "change announcements" to the public if
>there is not an actual security problem to be solved!
>
>
Well, I'm not sure anyone has made any
"change announcements" unless you mean
that recent minor oracle attack.
(off topic for the draft group...)
I would disagree in the question of making
announcements. Recent research and
thinking has led to the notion that we have
to be very aggressive about announcing
our weaknesses and going OTT (over the
top) in how we present these weaknesses.
It seems that we have to go through a
period of actually revealing these things
and encouraging people not to panic.
Elsewise we go back to the bad old days
where we keep all quiet.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HKIOeY088994; Thu, 17 Feb 2005 12:18:24 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HKIOEL088993; Thu, 17 Feb 2005 12:18:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HKILI8088981 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 12:18:24 -0800 (PST) (envelope-from aboietf@redtenbacher.de)
Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1D1s6M-0006OX-00 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 21:18:18 +0100
Received: from [62.134.100.69] (helo=62.134.100.69) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1D1s6L-0000OH-00 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 21:18:18 +0100
Subject: Re: SHA-1 broken
From: aboietf@redtenbacher.de
To: ietf-openpgp@imc.org
Message-Id: <E1D1s6L-0000OH-00@mrelayng.kundenserver.de>
Date: Thu, 17 Feb 2005 21:18:18 +0100
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e384712ef1f129ade61e87b26279bda6
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Werner Koch <wk@gnupg.org> wrote on 17 Feb 2005:
>We should really start thinking on how to switch to a different hash
>algorithm. The question is whether sha-256 is really that much more
>secure. From my understanding it has not been developed as a
>replacement for SHA-1 but to meet the requirements of AES and to
>extend DSA.
While not being opposed to David's suggestion of a potential V5 key
with AES/SHA-256, I still can't see any real need for replacing SHA-1
in the near future.
What are the actual facts behind these "SHA-1 is broken" rumours?
Someone found a way to reduce the SHA-1 strenght by 11 binary digits.
This has the exact same effect as if someone boosted the current
processor speeds by a factor of 2096.
Does this mean that any 128 bit hash gets "broken" by building a
cluster of 2096 PCs?
Let us be realistic and avoid any panic mode. Quickly announcing
changes to the OpenPGP protocol is doing us a bad service as it
undermines public trust for no good reason at all.
The recent announcement of Jon Callas et al. was - in my eyes - not
helpful at all. It solved a non-existing problem (not one single
existing OpenPGP implementation suffered from the "oracle" effect),
and the result in the media (at least in Germany) was rather
catastrophic: Even the (normally pretty conservative) Heise Verlag
published panic articles that "all automatic encrypt/decrypt systems
based on OpenPGP are broken"!
So the actual effect of the announcement was that, while not fixing
any real security problem, it seriously caused a Public Relations
damage for crypto gateways like our "KT Mail gateway"
(www.redtenbacher.de/info/gateway.htm) or "PGP Universal" (from PGP
Inc.).
Please, let us stop making any "change announcements" to the public if
there is not an actual security problem to be solved!
- Wolfgang Redtenbacher
---------------------------------------------------------------------
Redtenbacher Software Tel.: +49 7159 17046
Roemerstr. 11/1 Fax: +49 7159 17047
D-71272 Renningen e-mail: wolfgang@redtenbacher.de
---------------------------------------------------------------------
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJgFMv085422; Thu, 17 Feb 2005 11:42:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HJgFns085421; Thu, 17 Feb 2005 11:42:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJgF54085409 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 11:42:15 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <200502171942070120042jc9e>; Thu, 17 Feb 2005 19:42:07 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1HJg77o003242 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 14:42:07 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1HJg5sd018923 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 14:42:05 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1HJg5ol018922 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 14:42:05 -0500
Date: Thu, 17 Feb 2005 14:42:05 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Message-ID: <20050217194205.GB18817@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de> <421494F0.3060100@systemics.com> <20050217140010.GN24504@jabberwocky.com> <4214B1C9.9070101@systemics.com> <20050217183638.GC10406@jabberwocky.com> <4214F130.7020207@systemics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4214F130.7020207@systemics.com>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, Feb 17, 2005 at 07:32:00PM +0000, Ian G wrote:
> David Shaw wrote:
>
> >My main argument for a V5 key is that doing patch work on V4 has the
> >potential to split the installed base into "old V4" and "new V4".
> >Rather than end up like that, just call "new V4" "V5" instead. It is
> >also an opportunity to fix the handful of little details that bug
> >people about V4: the default cipher can be AES instead of 3DES. The
> >key expiration dates can be hard or soft (not just soft as in V4).
> >And so on.
> >
> >
>
> OK, so you would propose an intermediate
> "fixes lots of little things" V5. I don't know
> what the balance between these future
> paths would be ...
What I'm trying to get at is there is no "intermediate". The word
intermediate implies that there is some ultimate goal and this would
be a step towards it. My argument is that there is no ultimate goal,
and shooting for one is something we can spend a lot of time arguing
over to no avail. Without a time machine, we don't know what
cryptography will become in the future. We can just do the best we
can with the knowledge we have, ponder where we think things are going
over the next 10 years, build in as much future proofing as we can
think of - and even then expect that eventually there will need to be
a V6.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJRWTN084046; Thu, 17 Feb 2005 11:27:32 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HJRWfV084045; Thu, 17 Feb 2005 11:27:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJRUiv084029 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 11:27:31 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1HJR6r22228; Thu, 17 Feb 2005 19:27:11 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <4214F130.7020207@systemics.com>
Date: Thu, 17 Feb 2005 19:32:00 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <dshaw@jabberwocky.com>
CC: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de> <421494F0.3060100@systemics.com> <20050217140010.GN24504@jabberwocky.com> <4214B1C9.9070101@systemics.com> <20050217183638.GC10406@jabberwocky.com>
In-Reply-To: <20050217183638.GC10406@jabberwocky.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
David Shaw wrote:
>My main argument for a V5 key is that doing patch work on V4 has the
>potential to split the installed base into "old V4" and "new V4".
>Rather than end up like that, just call "new V4" "V5" instead. It is
>also an opportunity to fix the handful of little details that bug
>people about V4: the default cipher can be AES instead of 3DES. The
>key expiration dates can be hard or soft (not just soft as in V4).
>And so on.
>
>
OK, so you would propose an intermediate
"fixes lots of little things" V5. I don't know
what the balance between these future
paths would be ...
>I don't know that this should necessarily be in 2440bis, though, or
>2440bis may never be released.
>
>
I think if we can make an assessment that
SHA-1 is still good for another couple of
years, then we should go for it. Sure, shove
a note in there that it's a worry, but life is
full of worries...
(Which is to say that seeing as there are
some major difficulties in replacing SHA-1
in the current structures, then we should
just shrug and move on. No removal unless
it is absolutely necessary.)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJPMfY083861; Thu, 17 Feb 2005 11:25:22 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HJPM9l083860; Thu, 17 Feb 2005 11:25:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJPGXI083842 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 11:25:21 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D1rG9-0005yP-6Y for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 20:24:21 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D1rDd-0003kP-BL for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 20:21:45 +0100
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de> <421494F0.3060100@systemics.com> <20050217140010.GN24504@jabberwocky.com> <4214B1C9.9070101@systemics.com> <20050217183638.GC10406@jabberwocky.com>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Thu, 17 Feb 2005 20:21:44 +0100
In-Reply-To: <20050217183638.GC10406@jabberwocky.com> (David Shaw's message of "Thu, 17 Feb 2005 13:36:38 -0500")
Message-ID: <87u0obgfg7.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, 17 Feb 2005 13:36:38 -0500, David Shaw said:
> Rather than end up like that, just call "new V4" "V5" instead. It is
> also an opportunity to fix the handful of little details that bug
> people about V4: the default cipher can be AES instead of 3DES. The
> key expiration dates can be hard or soft (not just soft as in V4).
I am all in favor of this. Some time ago we even discussed that a v5
signature format would be a good idea so solve some things. We could
even addres the back signature thing better with a new format.
> I don't know that this should necessarily be in 2440bis, though, or
> 2440bis may never be released.
More than 6 years since the last RFC so it is indeed time to have a
new one, defining what the current standard is and showing a warning
that a v5 format is being worked own. This will give enough time to
work out the problems and analyze what's up with the hash algorithms.
Salam-Shalom,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HIam03079765; Thu, 17 Feb 2005 10:36:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HIamPp079764; Thu, 17 Feb 2005 10:36:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HIal0X079755 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 10:36:47 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005021718364001600fmtffe>; Thu, 17 Feb 2005 18:36:40 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1HIad7o002932 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 13:36:39 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1HIacFH010572 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 13:36:38 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1HIacwk010571 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 13:36:38 -0500
Date: Thu, 17 Feb 2005 13:36:38 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Message-ID: <20050217183638.GC10406@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de> <421494F0.3060100@systemics.com> <20050217140010.GN24504@jabberwocky.com> <4214B1C9.9070101@systemics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4214B1C9.9070101@systemics.com>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, Feb 17, 2005 at 03:01:29PM +0000, Ian G wrote:
>
> David Shaw wrote:
>
> >Rather than trying to jury-rig something together to allow using other
> >hashes, I think I would rather just declare a V5 key format (which can
> >be essentially the same as V4), which uses a different hash. Users
> >can continue using V4 keys as long as they desire, and developers will
> >have time to add support for V5 so it's ready when it is needed. This
> >ties in neatly with other things recently discussed here : for
> >example, a V5 key could be said to have AES as the default algorithm.
> >
> >
>
> Having now read the "note" that the Shandong
> team distributed, I'm less inclined to think this
> is the end of the world. See my blog for some
> snippets.
>
> Declaring a need for a V5 key makes a lot of
> sense, if we believe that we can survive that
> long. However, the first thing would be that
> I'd say a redesign of the key structure would
> be better than just a minor change to one
> element. I don't think it's worth carring the
> costs of an entire new key structure in code
> without making it worth carrying on for the
> next N decades.
We're much in agreement, though I don't forsee any key version making
it much beyond 10-15 years. The technology changes, and there is no
easy way to get around that. V4 keys have lasted for around 7-8 years
now, and will likely hang on for years to come; that's a pretty good
run. I think designing a V5 key that will last much longer than that
is not possible without a crystal ball. The best we can do is to
design it to last as long as possible, and know that someday we'll be
making a V6 key.
My main argument for a V5 key is that doing patch work on V4 has the
potential to split the installed base into "old V4" and "new V4".
Rather than end up like that, just call "new V4" "V5" instead. It is
also an opportunity to fix the handful of little details that bug
people about V4: the default cipher can be AES instead of 3DES. The
key expiration dates can be hard or soft (not just soft as in V4).
And so on.
I don't know that this should necessarily be in 2440bis, though, or
2440bis may never be released.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HHHbeN071696; Thu, 17 Feb 2005 09:17:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HHHb13071695; Thu, 17 Feb 2005 09:17:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HHHaNG071657 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 09:17:36 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20050217171728015007e14me>; Thu, 17 Feb 2005 17:17:28 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1HHHR7o002590 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 12:17:28 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1HHHQG3010470 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 12:17:26 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1HHHQFh010469 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 12:17:26 -0500
Date: Thu, 17 Feb 2005 12:17:26 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: Hash Collision Shield (subpacket def)
Message-ID: <20050217171726.GB10406@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <20050217164629.GA44839@phantom.vanrein.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050217164629.GA44839@phantom.vanrein.org>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, Feb 17, 2005 at 05:46:29PM +0100, Rick van Rein wrote:
>
> Hello,
>
> It's a bit of a long stretch perhaps... but it is probably the simplest
> thing we can do, and it is completely backward compatible. Suggested
> text fragments follow.
>
> The problem of the fingerprints and other hard-coded SHA1 apps are not
> solved by this, of course.
>
> Should we add a remark about subliminal channels caused by incorporating
> random bytes?
I think we should not do this for several reasons, but those reasons
don't matter much: we already have signature notations. If someone
wants to add arbitrary stuff in the middle of their signatures, they
can do that now.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HGkpJu068565; Thu, 17 Feb 2005 08:46:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HGkpKG068564; Thu, 17 Feb 2005 08:46:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp17.wxs.nl (smtp17.wxs.nl [195.121.6.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HGkk3C068533 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 08:46:50 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC200F33ELI9I@smtp17.wxs.nl> for ietf-openpgp@imc.org; Thu, 17 Feb 2005 17:46:30 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 02BD72A69B; Thu, 17 Feb 2005 17:46:29 +0100 (CET)
Date: Thu, 17 Feb 2005 17:46:29 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Hash Collision Shield (subpacket def)
To: ietf-openpgp@imc.org
Message-id: <20050217164629.GA44839@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello,
It's a bit of a long stretch perhaps... but it is probably the simplest
thing we can do, and it is completely backward compatible. Suggested
text fragments follow.
The problem of the fingerprints and other hard-coded SHA1 apps are not
solved by this, of course.
Should we add a remark about subliminal channels caused by incorporating
random bytes?
Cheers,
-Rick
------------ 8< ------------ 8< ------------ 8< ------------ 8< ------------
The value of the subpacket type octet may be:
2 = signature creation time
...
32 = embedded signature
33 = hash collision shield
...
4.2.3.27. Hash Collision Shield
(N random octets)
Hash functions are important to digital signatures, and breaking them
means breaking a signature schema. The first collision against hashes
is usually the collision attack, because these are computationally the
least expensive form of attack.
After a collision attack to a hash algorithm, the time to come up with
an attack that can completely reverse a given hash value is incredibly
long. This means that shielding against collision attacks is a very
practical method of prolonging the secure use of hash functions. This
is useful for applications such as timestamps and non-revocable
signatures, because these may have to be valid for very long periods.
An attacker could mount a collision attack by predicting the signature
calculation and preparing two documents with colliding hash values.
One document would be signed by someone other than the attacker, the
other document would be exploited with that signature attached.
Such attacks can be avoided if the signer makes the signing process
unpredictable to the attacker. The simples way to do that is to
generate random octets per signature, under full control of the signer,
and include them in the hashed subpackets of a signature packet.
The number of random octets SHOULD match the length of the hash used in
the signature. This subpacket MUST NOT be flagged as critical and MAY
remain without interpretation in the verification process.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HEv4ZD057890; Thu, 17 Feb 2005 06:57:04 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HEv44S057888; Thu, 17 Feb 2005 06:57:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HEv39R057872 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 06:57:03 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1HEuar20938; Thu, 17 Feb 2005 14:56:42 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <4214B1C9.9070101@systemics.com>
Date: Thu, 17 Feb 2005 15:01:29 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Shaw <dshaw@jabberwocky.com>
CC: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de> <421494F0.3060100@systemics.com> <20050217140010.GN24504@jabberwocky.com>
In-Reply-To: <20050217140010.GN24504@jabberwocky.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
David Shaw wrote:
>Rather than trying to jury-rig something together to allow using other
>hashes, I think I would rather just declare a V5 key format (which can
>be essentially the same as V4), which uses a different hash. Users
>can continue using V4 keys as long as they desire, and developers will
>have time to add support for V5 so it's ready when it is needed. This
>ties in neatly with other things recently discussed here : for
>example, a V5 key could be said to have AES as the default algorithm.
>
>
Having now read the "note" that the Shandong
team distributed, I'm less inclined to think this
is the end of the world. See my blog for some
snippets.
Declaring a need for a V5 key makes a lot of
sense, if we believe that we can survive that
long. However, the first thing would be that
I'd say a redesign of the key structure would
be better than just a minor change to one
element. I don't think it's worth carring the
costs of an entire new key structure in code
without making it worth carrying on for the
next N decades.
But, yes, V4 keys are old too. A good point.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HE0Pk5052926; Thu, 17 Feb 2005 06:00:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HE0ObM052925; Thu, 17 Feb 2005 06:00:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HE0K90052907 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 06:00:24 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20050217140012015007hgb7e>; Thu, 17 Feb 2005 14:00:12 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j1HE0B7o001708 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 09:00:11 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j1HE0ACH009575 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 09:00:10 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j1HE0Aau009574 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 09:00:10 -0500
Date: Thu, 17 Feb 2005 09:00:10 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
Message-ID: <20050217140010.GN24504@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de> <421494F0.3060100@systemics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <421494F0.3060100@systemics.com>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.8i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, Feb 17, 2005 at 12:58:24PM +0000, Ian G wrote:
>
> Werner Koch wrote:
>
> >On Thu, 17 Feb 2005 09:36:08 +0000 (UTC), Lutz Donnerhacke said:
> >
> >
> >
> >>Don't panic. This problem is already solved by allowing different
> >>hash-algorithms in the packet format. As long as no detailed examination
> >>of
> >>
> >>
> >
> >The fingerprint and the MDC both use SHA-1 hardwired.
> >
> >
>
> It would seem an easy matter to add some options
> on fingerprint. That's something that could be
> added to the standard as a MAY and people can
> switch across if the weaknesses in SHA1 move
> across to economically exploitable status.
I don't think it's all that easy to just add options to the
fingerprint. Let's say you specified a fingerprint (which is
currently just HASH) with ALGO:HASH. So, my current (SHA-1)
fingerprint would be:
2:7D92FD313AB6F3734CC59CA1DB698D7199242560
Simple enough, but my fingerprint would also be (MD5):
1:B9E4614F2E6FACD8F5DD32010AC50AAC
and even (SHA-512):
10:00C2C9BBF4AC3AD6D45275C041E1EE88AA6B0564F227AD4FBE0F7BBE845B8B47342A941A88384A79CFC0858572DCDE326AC21625D7822B2102CA3857669C381B
Allowing multiple representations of the fingerprint allows for all
sorts of problems where an attacker can force a particular hash
algorithm. There is even a warning about this attack (in the context
of signatures) in the draft.
If SHA-1 is showing its age, well, that's to be expected. It's had a
good run, but even before this new attack came to light, it was
already being phased out by NIST.
Rather than trying to jury-rig something together to allow using other
hashes, I think I would rather just declare a V5 key format (which can
be essentially the same as V4), which uses a different hash. Users
can continue using V4 keys as long as they desire, and developers will
have time to add support for V5 so it's ready when it is needed. This
ties in neatly with other things recently discussed here : for
example, a V5 key could be said to have AES as the default algorithm.
Note that keyservers and other programs that use OpenPGP will need to
understand whatever we do. Not messing about with the well-understood
and widely implemented definition of V4 keys will make this easier.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HCro8v031773; Thu, 17 Feb 2005 04:53:50 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HCro5O031772; Thu, 17 Feb 2005 04:53:50 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HCriA3031714 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 04:53:48 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j1HCrUr20083 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 12:53:36 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <421494F0.3060100@systemics.com>
Date: Thu, 17 Feb 2005 12:58:24 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de> <87vf8rlbbm.fsf@wheatstone.g10code.de>
In-Reply-To: <87vf8rlbbm.fsf@wheatstone.g10code.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Werner Koch wrote:
>On Thu, 17 Feb 2005 09:36:08 +0000 (UTC), Lutz Donnerhacke said:
>
>
>
>>Don't panic. This problem is already solved by allowing different
>>hash-algorithms in the packet format. As long as no detailed examination of
>>
>>
>
>The fingerprint and the MDC both use SHA-1 hardwired.
>
>
It would seem an easy matter to add some options
on fingerprint. That's something that could be
added to the standard as a MAY and people can
switch across if the weaknesses in SHA1 move
across to economically exploitable status.
For the MDC, that sounds more of a challenge. I
would suspect that the call is now on for a change to
the draft to allow alternate algorithms there! Are
there any easy ways? Or is this a deal breaker?
Given the rapid advance of the attack by the Shandong
team we should basically expect SHA-1 to be broken
within the year. So, I would guess within the time
frame of completing the draft, we may have to set
it up so that it is prepared for that event.
Which would mean that all uses of SHA-1 would have
an alternate. It doesn't necessarily mean that SHA-1
changes from MUST to SHOULD.
>We should really start thinking on how to switch to a different hash
>algorithm. The question is whether sha-256 is really that much more
>secure. From my understanding it has not been developed as a
>replacement for SHA-1 but to meet the requirements of AES and to
>extend DSA.
>
>
I think if all attacks are still limited by the fundamental
birthday principle, SHA-256 is likely to be safe. What is
worrying to the academic world is the fact that the
foundation of SHA-256 is as an extended SHA-1 (which
was an extended MD5, which was....) and this entire
approach is now being subjected to reduced rounds
attacks. Note that SHA-1 in unpadded form has lost
11 of its 80 bits. Even if SHA-256 lost 80 of 160 bits it
would still be good!
Academic elegance does not concern us here.
If SHA-256 is big-and-ugly enough to overcome all but
the most ridiculous of birthday attacks then it will serve
our purposes .... perhaps at least for the five year interim
required for the academics to come up with the next
generation.
(Quick question - how long was it from the start of the
AES competition to the announcement? About 4 years?)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HBKQFR000415; Thu, 17 Feb 2005 03:20:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HBKPIh000414; Thu, 17 Feb 2005 03:20:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from server.myhostnet.net (server.myhostnet.net [69.28.242.87] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HBKOPh000354 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 03:20:24 -0800 (PST) (envelope-from sattva@pgpru.com)
Received: from nskfw1.beelinegprs.com ([217.118.79.9] helo=[127.0.0.1]) by server.myhostnet.net with esmtpa (Exim 4.44) id 1D1jhU-0006M0-0Q; Thu, 17 Feb 2005 14:19:48 +0300
Message-ID: <42147DA5.1070003@pgpru.com>
Date: Thu, 17 Feb 2005 17:19:01 +0600
From: "Vlad \"SATtva\" Miller" <sattva@pgpru.com>
Organization: PGP in Russia (www.pgpru.com)
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Lutz Donnerhacke <lutz@iks-jena.de>
CC: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de>
In-Reply-To: <slrnd18pc8.q9.lutz@taranis.iks-jena.de>
X-Enigmail-Version: 0.90.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myhostnet.net
X-AntiAbuse: Original Domain - imc.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - pgpru.com
X-Source:
X-Source-Args:
X-Source-Dir:
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On 17.02.05 15:36, Lutz Donnerhacke wrote:
> * Konrad Rosenbaum wrote:
>
>> While this attack reduces SHA-1 from strength 2^80 to 2^69 and
>> 2^69 operations is still unreachably much, likelihood seems high
>> that someone will improve this attack once the paper has been
>> released.
>>
>> Should we phase out SHA-1? But in favour of what?
>
> Don't panic. This problem is already solved by allowing different
> hash-algorithms in the packet format. As long as no detailed
> examination of other algorithms is available, OpenPGP should not
> change MAYs and MUSTs.
Although I agree that we must not rush, but make weighted decisions,
there is a ground for some misgivings. For instance, v4 key format
relies solely on SHA-1 for fingerprints and MDC calculation, and when
(and if) the attack in question will become more useful in practical
sense, may lead to bad results.
--
Respectfully yours,
__________________________________
Vladislav "SATtva" Miller
"PGP in Russia" project leader
http://www.pgpru.com
PGP public key ID: 0x4D8BB49E
http://www.pgpru.com/contacts/
Email encryption and digital signing
is highly desired. Preferred method
is OpenPGP, otherwise S/MIME.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HAeU5s086241; Thu, 17 Feb 2005 02:40:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HAeUNZ086240; Thu, 17 Feb 2005 02:40:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HAeKqq086142 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 02:40:29 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D1j4B-00046Z-Ef for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 11:39:27 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D1j4P-0003F0-IN; Thu, 17 Feb 2005 11:39:41 +0100
To: Lutz Donnerhacke <lutz@iks-jena.de>
Cc: ietf-openpgp@imc.org
Subject: Re: SHA-1 broken
References: <200502170750.53386@zaphod.konrad.silmor.de> <slrnd18pc8.q9.lutz@taranis.iks-jena.de>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Thu, 17 Feb 2005 11:39:41 +0100
In-Reply-To: <slrnd18pc8.q9.lutz@taranis.iks-jena.de> (Lutz Donnerhacke's message of "Thu, 17 Feb 2005 09:36:08 +0000 (UTC)")
Message-ID: <87vf8rlbbm.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, 17 Feb 2005 09:36:08 +0000 (UTC), Lutz Donnerhacke said:
> Don't panic. This problem is already solved by allowing different
> hash-algorithms in the packet format. As long as no detailed examination of
The fingerprint and the MDC both use SHA-1 hardwired.
We should really start thinking on how to switch to a different hash
algorithm. The question is whether sha-256 is really that much more
secure. From my understanding it has not been developed as a
replacement for SHA-1 but to meet the requirements of AES and to
extend DSA.
Salam-Shalom,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H9aMwo065622; Thu, 17 Feb 2005 01:36:22 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1H9aMJk065620; Thu, 17 Feb 2005 01:36:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H9aKUG065545 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 01:36:21 -0800 (PST) (envelope-from news@branwen.iks-jena.de)
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.13.3/8.13.1) with ESMTP id j1H9a8gB009887 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 10:36:10 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.13.3/8.13.1/Submit) id j1H9a8aW009886 for ietf-openpgp@imc.org; Thu, 17 Feb 2005 10:36:08 +0100
To: ietf-openpgp@imc.org
Path: not-for-mail
From: Lutz Donnerhacke <lutz@iks-jena.de>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: SHA-1 broken
Date: Thu, 17 Feb 2005 09:36:08 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 10
Message-ID: <slrnd18pc8.q9.lutz@taranis.iks-jena.de>
References: <200502170750.53386@zaphod.konrad.silmor.de>
NNTP-Posting-Host: taranis.iks-jena.de
X-Trace: branwen.iks-jena.de 1108632968 8644 217.17.192.37 (17 Feb 2005 09:36:08 GMT)
X-Complaints-To: usenet@iks-jena.de
NNTP-Posting-Date: Thu, 17 Feb 2005 09:36:08 +0000 (UTC)
User-Agent: slrn/0.9.8.0 (Linux)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
* Konrad Rosenbaum wrote:
> While this attack reduces SHA-1 from strength 2^80 to 2^69 and 2^69
> operations is still unreachably much, likelihood seems high that someone
> will improve this attack once the paper has been released.
>
> Should we phase out SHA-1? But in favour of what?
Don't panic. This problem is already solved by allowing different
hash-algorithms in the packet format. As long as no detailed examination of
other algorithms is available, OpenPGP should not change MAYs and MUSTs.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H7UUlp021428; Wed, 16 Feb 2005 23:30:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1H7UUTP021427; Wed, 16 Feb 2005 23:30:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H7UL9s021290 for <ietf-openpgp@imc.org>; Wed, 16 Feb 2005 23:30:29 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1D1g6P-0000Mz-MM for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 08:29:33 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1D1g6K-00033x-Rj; Thu, 17 Feb 2005 08:29:28 +0100
To: Rick van Rein <rick@openfortress.nl>
Cc: ietf-openpgp@imc.org
Subject: Re: Timestamp and 3rd party sig
References: <20050216231251.GA30630@phantom.vanrein.org>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Thu, 17 Feb 2005 08:29:28 +0100
In-Reply-To: <20050216231251.GA30630@phantom.vanrein.org> (Rick van Rein's message of "Thu, 17 Feb 2005 00:12:51 +0100")
Message-ID: <87is4rwso7.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Thu, 17 Feb 2005 00:12:51 +0100, Rick van Rein said:
> A topic open for debate would be whether it may be assumed that "extra" or
> "sufficient" effort has been taken to guard and/or synchronise the time
> encapsulated. In line with the intention of 0x10..0x13 I left this out
That would again put definitions of trust into the protocol. OpenPGP
has always abstained from defining what trust is.
> The term 'notary seal' is a bit confusing because the strength and
> implications of such seals differ strongly between countries.
Ditto.
> The term Third Party is used a lot for key escrow parties. Is it an idea
> to rename this to an "Independent Confirmation signature"?
Fine with me.
> In 5.2.3.25, the definition of "Signature Target" is not very accurate.
> Notably, it is not very strict about the contents being hashed.
I recall that we discussed this a long time ago but can't remember the
details anymore.
Shalom-Salam,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H6pGUt007422; Wed, 16 Feb 2005 22:51:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1H6pGrM007421; Wed, 16 Feb 2005 22:51:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H6pFTT007150 for <ietf-openpgp@imc.org>; Wed, 16 Feb 2005 22:51:15 -0800 (PST) (envelope-from konrad@silmor.de)
Received: from pd9e1f876.dip.t-dialin.net ([217.225.248.118] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1D1fV0-0000GI-00 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2005 07:50:54 +0100
From: Konrad Rosenbaum <konrad@silmor.de>
To: ietf-openpgp@imc.org
Subject: SHA-1 broken
Date: Thu, 17 Feb 2005 07:50:49 +0100
User-Agent: KMail/1.7.2
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1162879.5N5eC6Krpi"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200502170750.53386@zaphod.konrad.silmor.de>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
--nextPart1162879.5N5eC6Krpi
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi,
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
While this attack reduces SHA-1 from strength 2^80 to 2^69 and 2^69=20
operations is still unreachably much, likelihood seems high that someone=20
will improve this attack once the paper has been released.
Should we phase out SHA-1? But in favour of what?
This also means that DSA/DSS is broken (a downgrade attack becomes=20
possible). Should we return to suggesting RSA as signature algorithm?
Konrad
--nextPart1162879.5N5eC6Krpi
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCFD7NClt766LaIH0RAsfFAKCfXV7nqM3XR1ZkSQUyLr/cfIby/gCgpglB
yMqLHwYP99JzpUl6b/TQAdU=
=uAgt
-----END PGP SIGNATURE-----
--nextPart1162879.5N5eC6Krpi--
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GNDDdk057261; Wed, 16 Feb 2005 15:13:13 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GNDDWc057260; Wed, 16 Feb 2005 15:13:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp19.wxs.nl (smtp19.wxs.nl [195.121.6.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GND7vQ057237 for <ietf-openpgp@imc.org>; Wed, 16 Feb 2005 15:13:12 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp19.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC1001D91TGYI@smtp19.wxs.nl> for ietf-openpgp@imc.org; Thu, 17 Feb 2005 00:12:52 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id D14142A697; Thu, 17 Feb 2005 00:12:51 +0100 (CET)
Date: Thu, 17 Feb 2005 00:12:51 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Timestamp and 3rd party sig
To: ietf-openpgp@imc.org
Message-id: <20050216231251.GA30630@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello,
Dare I suggest a rephrasing of the 0x40 and 0x50 definitions?
0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in
it.
This can be read as if the document signed and the signing key don't matter.
The point of a timestamp is a matter of emphasising what its intention is,
but not much more.
A topic open for debate would be whether it may be assumed that "extra" or
"sufficient" effort has been taken to guard and/or synchronise the time
encapsulated. In line with the intention of 0x10..0x13 I left this out
in the text that follows, to avoid pinning down something that is open
to debate.
I therefore propose either this text...
0x40: Timestamp signature.
The intention of this signature is to accurately record the time
at which the timestamped data was seen by the timestamp-signing
party.
...then I tried to add a definition of what was being timestamped...
If the timestamped data is an OpenPGP signature, it MUST
be referenced with a Signature Target [or Signature Reference,
see below] subpacket. In all other cases, the timestamped data MUST
be constructed as a normal signature on data.
This is much clearer to an implementer, I think.
-> Is the distinction between sig-on-sig and sig-on-data desirable?
-> The MUSTs are intended to avoid multiple formats which mean the same.
-> Given this definition, should one use 0x40 or 0x50 to confirm revocations?
Another issue:
0x50: Third-Party Confirmation signature.
This signature is a signature over some other OpenPGP signature
packet(s). It is analogous to a notary seal on the signed data.
A third-party signature SHOULD include Signature Target
subpacket(s) to give easy identification. Note that we really do
mean SHOULD. There are plausible uses for this (such as a blind
party that only sees the signature, not the key nor source
document) that cannot include a target subpacket.
The term 'notary seal' is a bit confusing because the strength and
implications of such seals differ strongly between countries.
Since the Signature Target subpacket(s) are hashes, they convey the
signature subpacket that is being signed -- is that not sufficient for
blind signing purposes? If the signature target is not provided, what
would then be the subpackets determining what is being confirmed?
The term Third Party is used a lot for key escrow parties. Is it an idea
to rename this to an "Independent Confirmation signature"?
In 5.2.3.25, the definition of "Signature Target" is not very accurate.
Notably, it is not very strict about the contents being hashed. Also,
I (as a non-native English speaker) am tempted to call it a "Signature
Reference". Dare I rephrase?
CURRENT:
5.2.3.25. Signature Target
(1 octet PK algorithm, 1 octet hash algorithm, N octets hash)
This subpacket identifies a specific target signature that a
signature refers to. For revocation signatures, this subpacket
provides explicit designation of which signature is being revoked.
For a third-party or timestamp signature, this designates what
signature is signed. All arguments are an identifier of that target
signature.
The N octets of hash data MUST be the size of the hash of the
signature. For example, a target signature with a SHA-1 hash MUST
have 20 octets of hash data.
PROPOSED:
5.2.3.25. Signature Reference
(1 octet PK algorithm, 1 octet hash algorithm, N octets hash)
This subpacket refers to a Signature Packet without including the
Signature Packet inside the Signature Reference subpacket. Instead,
the hash of the Signature Packet is included. When used in a
revocation signature, this subpacket refers to the signature being
revoked. For a Independent/Third-Party Confirmation signatures and
Timestamp signatures, this subpacket refers to the signature that
is being confirmed or timestamped.
The signature that is referenced by this subpacket may or may not
be present in the same OpenPGP message; a signing party may even
be totally unaware of the referenced Signature Packet, in which
case the signature with this subpacket would be a blind signature.
The N octets of hash data MUST be the size of the hash of the
signature. For example, a target signature with a SHA-1 hash MUST
have 20 octets of hash data.
Thanks,
Rick van Rein,
OpenFortress.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1B7bbNu044544; Thu, 10 Feb 2005 23:37:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1B7bb3F044543; Thu, 10 Feb 2005 23:37:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1B7baGw044487 for <ietf-openpgp@imc.org>; Thu, 10 Feb 2005 23:37:36 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <ietf-openpgp@imc.org>; Thu, 10 Feb 2005 22:32:25 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Thu, 10 Feb 2005 22:32:24 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619.2)
In-Reply-To: <420A012A.5020204@systemics.com>
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de> <420A012A.5020204@systemics.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <39c100e92dbc54b9fcb678d904676384@callas.org>
Content-Transfer-Encoding: 7bit
From: Jon Callas <jon@callas.org>
Subject: Re: Mandatory Algorithm Changes?
Date: Thu, 10 Feb 2005 17:11:30 -0800
To: OpenPGP <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Mandatory-to-implement does not mean mandatory-to-use.
If we change 3DES to AES, things don't instantly stop working. If we do
that, 3DES would be a SHOULD, of course, and there will be a note that
says that if you don't implement 3DES there could be interoperability
issues.
I don't think that any reasonable implementor is going to run right out
and code stupidly. It will obviously take a couple of years before
someone can safely assume, for example, that the
algorithm-of-last-resort would be AES.
However, if we ever want to roll 3DES over to AES, we have to start
sometime. The couple of years of bake-in doesn't start until a change
is made. Why not now?
I'm willing to concede the point on SHA-256, I wouldn't have brought it
up at all if NIST hadn't said a couple days ago they're phasing out
SHA-1 and rolling to SHA-256.
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AKY59g075985; Thu, 10 Feb 2005 12:34:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AKY5Fc075984; Thu, 10 Feb 2005 12:34:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AKY46p075975 for <ietf-openpgp@imc.org>; Thu, 10 Feb 2005 12:34:04 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <ietf-openpgp@imc.org>; Thu, 10 Feb 2005 11:32:54 -0800
Received: from [192.168.2.164] ([63.251.255.85]) by keys.merrymeet.com (PGP Universal service); Thu, 10 Feb 2005 11:32:52 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <2c54ded8eab5ec5d6ceffc170f8e46f7@callas.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: An article you should look at
Date: Thu, 10 Feb 2005 11:33:31 -0800
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
<http://www.pgp.com/library/ctocorner/openpgp.html>
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19CKcfW013323; Wed, 9 Feb 2005 04:20:38 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19CKcKn013322; Wed, 9 Feb 2005 04:20:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19CKWG4013248 for <ietf-openpgp@imc.org>; Wed, 9 Feb 2005 04:20:37 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j19DKHr14672 for <ietf-openpgp@imc.org>; Wed, 9 Feb 2005 13:20:22 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <420A012A.5020204@systemics.com>
Date: Wed, 09 Feb 2005 12:25:14 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com> <87zmyeyyg9.fsf@wheatstone.g10code.de>
In-Reply-To: <87zmyeyyg9.fsf@wheatstone.g10code.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Werner Koch wrote:
>On Tue, 08 Feb 2005 21:27:30 +0000, Ian G said:
>
>
>
>>If both of the major OpenPGP implementations
>>already support it, is there any reason to doubt
>>the little guys will follow along eventually?
>>
>>
>
>There are other implementations using OpenPGP as well. For embedded
>systems adding another MUST cipher is a problem, in particular if 3DES
>is already done in (old) hardware. There might also be the need to
>implement the preferences system unless both, 3DES and AES, are
>declared as fallback algorithms.
>
>
Right, in that it's a given that there are always
problems for any change. But let's explore this
a bit more.
What is being changed (suggested) is the OpenPGP
RFC - standard. No implementation needs to change,
and the only implementations that would want to
change would be future ones that need to adhere
to the standard.
Embedded devices don't really need to adhere
(here, I am assuming that such embedded are
totally embedded and aren't communicating
with the open email community).
Also, as time goes on, those that do not support
AES are going to raise more and more eyebrows.
I think the time is going to come fairly shortly
where I'd say "implementing AES" was more
important than "slavishly following the standard
in every detail."
Are there any little guys here would like to add
anything? Positive or negative?
FTR: Edwin informs me that the Cryptix OpenPGP
has no objection.
(Which should be taken to mean I vote for the
change - I'm just playing the devil's advocate here.)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19AIfnX069498; Wed, 9 Feb 2005 02:18:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19AIf27069497; Wed, 9 Feb 2005 02:18:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp17.wxs.nl (smtp17.wxs.nl [195.121.6.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19AIaof069299 for <ietf-openpgp@imc.org>; Wed, 9 Feb 2005 02:18:41 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBN00L683A9Q6@smtp17.wxs.nl> for ietf-openpgp@imc.org; Wed, 09 Feb 2005 11:18:09 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 452A32A64F; Wed, 09 Feb 2005 11:18:09 +0100 (CET)
Date: Wed, 09 Feb 2005 11:18:09 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: Policy URL -> Policy URI
In-reply-to: <20050209033914.GA11876@jabberwocky.com>
To: David Shaw <dshaw@jabberwocky.com>
Cc: ietf-openpgp@imc.org
Message-id: <20050209101809.GA89329@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org> <874qgnqryp.fsf@deneb.enyo.de> <20050208183233.GC10858@jabberwocky.com> <20050208213445.GA56118@phantom.vanrein.org> <87ll9ymyn9.fsf@deneb.enyo.de> <20050209033914.GA11876@jabberwocky.com>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
The standards speak!
The very recent STD 66 annex RFC 3986 states, in 1.1.3:
An individual scheme does not have to be classified as being just one
of "name" or "locator". Instances of URIs from any given scheme may
have the characteristics of names or locators or both, often
depending on the persistence and care in the assignment of
identifiers by the naming authority, rather than on any quality of
the scheme. Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].
So...
- my side-claim that a URI is either a URL or a URN is not true anymore
- my suggestion to change Policy URL to Policy URI is a must-do
- changing Keyserver URL to Keyserver URI comes highly recommended as well
Let's just do it as the standard states, change every URL to a URI.
Cheers,
-Rick
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j197ePv3009692; Tue, 8 Feb 2005 23:40:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j197ePJ0009691; Tue, 8 Feb 2005 23:40:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j197eOJW009393 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 23:40:24 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1Cyllv-0000S1-KC for <ietf-openpgp@imc.org>; Wed, 09 Feb 2005 07:56:23 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1CymRC-0002Tb-PP; Wed, 09 Feb 2005 08:39:02 +0100
To: Ian G <iang@systemics.com>
Cc: ietf-openpgp@imc.org
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org> <42092EC2.9040501@systemics.com>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Wed, 09 Feb 2005 08:39:02 +0100
In-Reply-To: <42092EC2.9040501@systemics.com> (Ian G.'s message of "Tue, 08 Feb 2005 21:27:30 +0000")
Message-ID: <87zmyeyyg9.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Tue, 08 Feb 2005 21:27:30 +0000, Ian G said:
> If both of the major OpenPGP implementations
> already support it, is there any reason to doubt
> the little guys will follow along eventually?
There are other implementations using OpenPGP as well. For embedded
systems adding another MUST cipher is a problem, in particular if 3DES
is already done in (old) hardware. There might also be the need to
implement the preferences system unless both, 3DES and AES, are
declared as fallback algorithms.
Shalom-Salam,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j193dNAT060906; Tue, 8 Feb 2005 19:39:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j193dNMt060905; Tue, 8 Feb 2005 19:39:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j193dMWk060897 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 19:39:23 -0800 (PST) (envelope-from dshaw@grover.jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc11) with ESMTP id <2005020903391701300d7kcue>; Wed, 9 Feb 2005 03:39:17 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j193dG7o012623 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 22:39:16 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j193dEse011898 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 22:39:14 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j193dE8c011897 for ietf-openpgp@imc.org; Tue, 8 Feb 2005 22:39:14 -0500
Date: Tue, 8 Feb 2005 22:39:14 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: Policy URL -> Policy URI
Message-ID: <20050209033914.GA11876@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org> <874qgnqryp.fsf@deneb.enyo.de> <20050208183233.GC10858@jabberwocky.com> <20050208213445.GA56118@phantom.vanrein.org> <87ll9ymyn9.fsf@deneb.enyo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ll9ymyn9.fsf@deneb.enyo.de>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.7i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Wed, Feb 09, 2005 at 12:15:38AM +0100, Florian Weimer wrote:
>
> * Rick van Rein:
>
> > Florian,
> >
> >> > Back then, the URI *identified* a resource, but this doesn't make much
> >> > sense in the OpenPGP context (were fingerprints are used to identify
> >> > keys). The keyserver location is just that, a location.
> >> >
> >> > The URI terminology has changed since then.
> >>
> >> If URI doesn't mean what it used to, does it then make sense to change
> >> both the keyserver and policy URLs to URIs?
> >
> > Yes, please specify. We don't want this to end up in a sort of FUD against
> > URIs. To the best of my knowledge, it's all really simple, as summarised
> > here:
> >
> > http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article
>
> Ahem, STD 66 presents a slightly different view. 8-)
>
> The problem is that it's impossible to distinguish identifiers and
> locators at the syntax level. It's not possible to uphold the URN/URL
> distinction.
After giving reading STD 66 a quick once over (and it is indeed new -
less than a month old), I see your point. Especially since there is
no way to tell them apart anyway, I think that the proper thing for
2440bis is to call *both* keyserver and policy URLs, URIs instead.
There are a number of reasons, but the main one as I see it is that it
is not our business (as OpenPGP people) to tell people what is
acceptable for their keyserver or policy fields to point to. If
someone wants to point to a book, great. Go ahead. If some
implementation wants to support URNs, also great.
Making this change has no impact on any implementations since URLs are
URIs.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NFl7R046297; Tue, 8 Feb 2005 15:15:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18NFloa046296; Tue, 8 Feb 2005 15:15:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18NFkW6046281 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 15:15:46 -0800 (PST) (envelope-from fw@deneb.enyo.de)
Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1Cyea2-0006gW-Vo; Wed, 09 Feb 2005 00:15:38 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1Cyea2-00018H-Fv; Wed, 09 Feb 2005 00:15:38 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Rick van Rein <rick@openfortress.nl>
Cc: ietf-openpgp@imc.org
Subject: Re: Policy URL -> Policy URI
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org> <874qgnqryp.fsf@deneb.enyo.de> <20050208183233.GC10858@jabberwocky.com> <20050208213445.GA56118@phantom.vanrein.org>
Date: Wed, 09 Feb 2005 00:15:38 +0100
In-Reply-To: <20050208213445.GA56118@phantom.vanrein.org> (Rick van Rein's message of "Tue, 08 Feb 2005 22:34:45 +0100")
Message-ID: <87ll9ymyn9.fsf@deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
* Rick van Rein:
> Florian,
>
>> > Back then, the URI *identified* a resource, but this doesn't make much
>> > sense in the OpenPGP context (were fingerprints are used to identify
>> > keys). The keyserver location is just that, a location.
>> >
>> > The URI terminology has changed since then.
>>
>> If URI doesn't mean what it used to, does it then make sense to change
>> both the keyserver and policy URLs to URIs?
>
> Yes, please specify. We don't want this to end up in a sort of FUD against
> URIs. To the best of my knowledge, it's all really simple, as summarised
> here:
>
> http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article
Ahem, STD 66 presents a slightly different view. 8-)
The problem is that it's impossible to distinguish identifiers and
locators at the syntax level. It's not possible to uphold the URN/URL
distinction.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LZ33Z040454; Tue, 8 Feb 2005 13:35:03 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18LZ35D040453; Tue, 8 Feb 2005 13:35:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp19.wxs.nl (smtp19.wxs.nl [195.121.6.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LZ2qa040428 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 13:35:02 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp19.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBM00A223XY8Q@smtp19.wxs.nl> for ietf-openpgp@imc.org; Tue, 08 Feb 2005 22:34:46 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id F3A592A64F; Tue, 08 Feb 2005 22:34:45 +0100 (CET)
Date: Tue, 08 Feb 2005 22:34:45 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: Policy URL -> Policy URI
In-reply-to: <20050208183233.GC10858@jabberwocky.com>
To: ietf-openpgp@imc.org
Message-id: <20050208213445.GA56118@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org> <874qgnqryp.fsf@deneb.enyo.de> <20050208183233.GC10858@jabberwocky.com>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Florian,
> > Back then, the URI *identified* a resource, but this doesn't make much
> > sense in the OpenPGP context (were fingerprints are used to identify
> > keys). The keyserver location is just that, a location.
> >
> > The URI terminology has changed since then.
>
> If URI doesn't mean what it used to, does it then make sense to change
> both the keyserver and policy URLs to URIs?
Yes, please specify. We don't want this to end up in a sort of FUD against
URIs. To the best of my knowledge, it's all really simple, as summarised
here:
http://rick.vanrein.org/blog/notes/urn-uri-url.2005-02-07-13-53.article
Best,
-Rick
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LN2YW039697; Tue, 8 Feb 2005 13:23:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18LN2eN039696; Tue, 8 Feb 2005 13:23:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from www.enhyper.com (mailgate.enhyper.com [62.49.250.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18LMuTE039686 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 13:23:01 -0800 (PST) (envelope-from iang@systemics.com)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by www.enhyper.com (8.11.6/8.11.6) with SMTP id j18MMYr10548 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 22:22:44 GMT
X-Authentication-Warning: www.enhyper.com: localhost.localdomain [127.0.0.1] didn't use HELO protocol
Message-ID: <42092EC2.9040501@systemics.com>
Date: Tue, 08 Feb 2005 21:27:30 +0000
From: Ian G <iang@systemics.com>
Organization: http://financialcryptography.com/
User-Agent: Mozilla Thunderbird 1.0 (X11/20050108)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-openpgp@imc.org
Subject: Re: Mandatory Algorithm Changes?
References: <20050208194442.F2C6A57E2A@finney.org>
In-Reply-To: <20050208194442.F2C6A57E2A@finney.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I agree that switching from SHA1 to SHA256 seems
like a move without clear basis, given the results
from that last conference. I think we just have to
sit it out and see what happens.
As far as AES is concerned, I'm less definately for
or against ;)
I can't see a problem directly with making it a must,
as we are now at the point where TDES is "ok if
you have to but we'd rather you didn't." (The
comments by Steve Bellovin last week were new
for me at least.)
If both of the major OpenPGP implementations
already support it, is there any reason to doubt
the little guys will follow along eventually?
(I agree it should be AES128 that should be the
must, if it is going that way...)
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18KNaSG035177; Tue, 8 Feb 2005 12:23:36 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18KNaVu035172; Tue, 8 Feb 2005 12:23:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtpq2.home.nl (smtpq2.home.nl [213.51.128.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18KNZhq035077 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 12:23:36 -0800 (PST) (envelope-from edwin@woudt.nl)
Received: from [213.51.128.136] (port=33198 helo=smtp5.home.nl) by smtpq2.home.nl with esmtp (Exim 4.30) id 1CybtM-0004gc-GI; Tue, 08 Feb 2005 21:23:24 +0100
Received: from cc718542-a.ensch1.ov.home.nl ([84.31.118.254]:5198 helo=[10.24.64.4]) by smtp5.home.nl with esmtp (Exim 4.30) id 1CybtK-000564-Co; Tue, 08 Feb 2005 21:23:22 +0100
Date: Tue, 08 Feb 2005 21:23:22 +0100
From: Edwin Woudt <edwin@woudt.nl>
To: Jon Callas <jon@callas.org>, OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
Message-ID: <95D9A97EDD6A76D9F6789F52@[10.24.64.4]>
In-Reply-To: <0e2405990b7f7b186cd70e8603889d04@callas.org>
References: <0e2405990b7f7b186cd70e8603889d04@callas.org>
X-Mailer: Mulberry/4.0.0a4 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie
X-AtHome-MailScanner: Found to be clean
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
--On 8-2-2005 9:42 -0800 Jon Callas <jon@callas.org> wrote:
>
> I almost cringe to suggest this, but I will.
>
> Triple-DES is pretty much obsolete. Yesterday, I saw that NIST announced
> they're moving to stronger hashes.
>
> Does anyone object to changing the MUST cipher to AES (I'd pick 128) and
> MUST hash to SHA-256?
Regarding SHA-256: would that mean switching to SHA-256 for key
fingerprints as well? (shouldn't v5 keys be introduced then?) And use
SHA-256 for MDC packets?
Or is it just adding a MUST implement, so applications can use SHA-256 for
document signatures with RSA keys only? (as DSA forces one to use SHA-1
anyway)
IMHO, the first is what should be done at some point, but that's a really
big change: all implementations out there need to be upgraded. Wouldn't
that conflict with getting the current draft on standards track?
I do not see the point of the second option: as long as keys are only
protected by a 160 bit figerprint, there is not much point protecting
document signatures with longer hashes. It may be harder to generate a
collision resulting in a valid key, then it is to generate a collision
resulting in just some other random document, but I do not think it is wise
to count on such an assumption.
--
Edwin
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18JTEHo031419; Tue, 8 Feb 2005 11:29:14 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18JTEgs031418; Tue, 8 Feb 2005 11:29:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18JTDVW031397 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 11:29:13 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id F2C6A57E2A; Tue, 8 Feb 2005 11:44:42 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: Re: Mandatory Algorithm Changes?
Message-Id: <20050208194442.F2C6A57E2A@finney.org>
Date: Tue, 8 Feb 2005 11:44:42 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I agree with Werner specifically that it seems premature to jump
onto SHA-256, at this time of flux in the cryptographic commmunity's
understanding of hash functions. MD5 and several other comparable hashes
are broken but the techniques are still secret and unpublished AFAIK.
Reduced forms of SHA-1 have some attacks but the full version is still OK.
There were even comments suggesting that the SHA-256 family may not be
as secure as was previously believed.
I haven't heard much more about these since then. Looking at the IACR
eprints archive, I find http://eprint.iacr.org/2005/010 from January 2005,
by Rijmen and Oswald:
"We report on the experiments we performed in order to assess the security
of SHA-1 against the attack by Chabaud and Joux. We present some ideas for
optimizations of the attack and some properties of the message expansion
routine. Finally, we show that for a reduced version of SHA-1, with 53
rounds instead of 80, it is possible to find collisions in less than
$2^{80}$ operations."
That's the known state of the art, and it's not terribly worrisome,
but these researchers are not employing the secret Chinese techniques.
SHA-1 is structurally similar to MD5 so there is reason to fear that the
MD5 break could be extended to SHA-1, either by the original researchers,
or by others once they publish their methods. OTOH SHA-1 does have some
twists and complexity that MD5 does not, which could immunize it against
the attacks.
The information on SHA-256 is available at http://eprint.iacr.org/2004/207,
by Hawkes et al. While this is not an attack, it shows flaws in an
earlier analysis that suggested that the SHA-256 family was strong in
certain ways.
All in all the field is in turmoil these days. I would hesitate to take
any steps right now with the hash functions, beyond of course deprecating
MD5 as we have done.
Hal Finney
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IwiuK029077; Tue, 8 Feb 2005 10:58:44 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IwiVT029076; Tue, 8 Feb 2005 10:58:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IwiVd029056 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 10:58:44 -0800 (PST) (envelope-from dshaw@grover.jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005020818583401500o65nfe>; Tue, 8 Feb 2005 18:58:35 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j18IwY7o010617 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 13:58:34 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j18IwW5v011091 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 13:58:32 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j18IwWH6011090 for ietf-openpgp@imc.org; Tue, 8 Feb 2005 13:58:32 -0500
Date: Tue, 8 Feb 2005 13:58:32 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
Message-ID: <20050208185832.GD10858@jabberwocky.com>
Mail-Followup-To: OpenPGP <ietf-openpgp@imc.org>
References: <0e2405990b7f7b186cd70e8603889d04@callas.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0e2405990b7f7b186cd70e8603889d04@callas.org>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.7i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Tue, Feb 08, 2005 at 09:42:20AM -0800, Jon Callas wrote:
>
> I almost cringe to suggest this, but I will.
>
> Triple-DES is pretty much obsolete. Yesterday, I saw that NIST
> announced they're moving to stronger hashes.
>
> Does anyone object to changing the MUST cipher to AES (I'd pick 128)
> and MUST hash to SHA-256?
This would be difficult to do without breaking backwards
compatibility. There are a lot of deployed systems that expect 3DES
to be the MUST cipher.
I'm not against adding a second MUST cipher without removing the
current 3DES, but I don't see how the 3DES as the
cipher-of-last-resort could be changed except over a significant
amount of time.
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IdxtW027921; Tue, 8 Feb 2005 10:39:59 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IdxCf027920; Tue, 8 Feb 2005 10:39:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IdwXf027888 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 10:39:58 -0800 (PST) (envelope-from wk@gnupg.org)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.34 #1 (Debian)) id 1CyZbD-0003de-2S for <ietf-openpgp@imc.org>; Tue, 08 Feb 2005 18:56:31 +0100
Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1CyaHK-0001tW-1a; Tue, 08 Feb 2005 19:40:02 +0100
To: Jon Callas <jon@callas.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Mandatory Algorithm Changes?
References: <0e2405990b7f7b186cd70e8603889d04@callas.org>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:wk@g10code.com
Date: Tue, 08 Feb 2005 19:40:02 +0100
In-Reply-To: <0e2405990b7f7b186cd70e8603889d04@callas.org> (Jon Callas's message of "Tue, 8 Feb 2005 09:42:20 -0800")
Message-ID: <87sm4628vx.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Tue, 8 Feb 2005 09:42:20 -0800, Jon Callas said:
> Does anyone object to changing the MUST cipher to AES (I'd pick 128)
> and MUST hash to SHA-256?
Breaks interoperability with existing OpenPGP applications. I am not
aware of any new security problems with 3DES which would justify such
a step. Adding AES-128 as another MUST algorithm would be fine with
me but this breaks interoperability too.
SHA-256 is even worser. In addition to the interop problems,
applications using OpenPGP tools need to be changed to make use of the
longer digest. Dropping MD5 is really a good idea, but I doubt that
SHA-256 has been analyzed as much as the older algorithms. Given that
there are now doubts on the general design principle of all common
hash algorithms, I think it is a bit to early to make it a MUST.
I guess that there are other things in OpenPGP that are more
vulnerable to attacks than SHA-1. Better do a new RFC now and then
start thinking about all the open issues.
Shalom-Salam,
Werner
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IWfTi027568; Tue, 8 Feb 2005 10:32:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IWfLe027567; Tue, 8 Feb 2005 10:32:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IWetX027553 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 10:32:41 -0800 (PST) (envelope-from dshaw@grover.jabberwocky.com)
Received: from walrus.ne.client2.attbi.com ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005020818323501100j4ojve>; Tue, 8 Feb 2005 18:32:35 +0000
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.ne.client2.attbi.com (8.12.8/8.12.8) with ESMTP id j18IWY7o010528 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 13:32:34 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j18IWXLo011064 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 13:32:33 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j18IWXxW011063 for ietf-openpgp@imc.org; Tue, 8 Feb 2005 13:32:33 -0500
Date: Tue, 8 Feb 2005 13:32:33 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Re: Policy URL -> Policy URI
Message-ID: <20050208183233.GC10858@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org> <874qgnqryp.fsf@deneb.enyo.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <874qgnqryp.fsf@deneb.enyo.de>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.7i
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
On Tue, Feb 08, 2005 at 11:14:06AM +0100, Florian Weimer wrote:
>
> * Jon Callas:
>
> > Okay, I see what you're saying, but is it necessary?
> >
> > A long time ago, the keyserver URL said URI and we changed it for
> > reasons that I can't remember.
>
> Back then, the URI *identified* a resource, but this doesn't make much
> sense in the OpenPGP context (were fingerprints are used to identify
> keys). The keyserver location is just that, a location.
>
> The URI terminology has changed since then.
If URI doesn't mean what it used to, does it then make sense to change
both the keyserver and policy URLs to URIs?
David
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18I8CE5025905; Tue, 8 Feb 2005 10:08:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18I8COi025904; Tue, 8 Feb 2005 10:08:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18I8Bv8025896 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 10:08:11 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 51CBE57E2A; Tue, 8 Feb 2005 10:23:41 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: Re: confusing terminology
Message-Id: <20050208182341.51CBE57E2A@finney.org>
Date: Tue, 8 Feb 2005 10:23:41 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Rick van Rein writes:
> For this reason, I would never, ever encrypt without compressing first.
> This is the cryptographic advise I would like to see in the indicated place.
I'm afraid I don't agree with this as cryptographic advice. If your
cipher is so weak that you are afraid to encrypt English text, you need
a new cipher! Not a new compression algorithm.
It's fine if you want to say that compression increases the entropy
density which could in theory make the cryptanalyst's problem slightly
harder, but I would definitely not go so far as to advise or imply that
failing to compress is cryptographically insecure.
Hal Finney
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HhQpR024190; Tue, 8 Feb 2005 09:43:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18HhQ1K024189; Tue, 8 Feb 2005 09:43:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HhP8U024180 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 09:43:25 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 09:43:17 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Tue, 08 Feb 2005 09:43:17 -0800
X-PGP-Universal: processed
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Transfer-Encoding: 7bit
Message-Id: <0e2405990b7f7b186cd70e8603889d04@callas.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: OpenPGP <ietf-openpgp@imc.org>
From: Jon Callas <jon@callas.org>
Subject: Mandatory Algorithm Changes?
Date: Tue, 8 Feb 2005 09:42:20 -0800
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
I almost cringe to suggest this, but I will.
Triple-DES is pretty much obsolete. Yesterday, I saw that NIST
announced they're moving to stronger hashes.
Does anyone object to changing the MUST cipher to AES (I'd pick 128)
and MUST hash to SHA-256?
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18AEN01029310; Tue, 8 Feb 2005 02:14:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18AENid029309; Tue, 8 Feb 2005 02:14:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18AEMqP029250 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 02:14:22 -0800 (PST) (envelope-from fw@deneb.enyo.de)
Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CySNi-0005cc-OT; Tue, 08 Feb 2005 11:14:06 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CySNi-0001xo-Dm; Tue, 08 Feb 2005 11:14:06 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Jon Callas <jon@callas.org>
Cc: Rick van Rein <rick@openfortress.nl>, ietf-openpgp@imc.org
Subject: Re: Policy URL -> Policy URI
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org>
Date: Tue, 08 Feb 2005 11:14:06 +0100
In-Reply-To: <3c14e78650fa58b06576b2e617409837@callas.org> (Jon Callas's message of "Mon, 7 Feb 2005 16:50:29 -0800")
Message-ID: <874qgnqryp.fsf@deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
* Jon Callas:
> Okay, I see what you're saying, but is it necessary?
>
> A long time ago, the keyserver URL said URI and we changed it for
> reasons that I can't remember.
Back then, the URI *identified* a resource, but this doesn't make much
sense in the OpenPGP context (were fingerprints are used to identify
keys). The keyserver location is just that, a location.
The URI terminology has changed since then.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j189fcXb017556; Tue, 8 Feb 2005 01:41:38 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j189fcPh017555; Tue, 8 Feb 2005 01:41:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp14.wxs.nl (smtp14.wxs.nl [195.121.6.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j189fb9p017498 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 01:41:37 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp14.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBL00FN96X684@smtp14.wxs.nl> for ietf-openpgp@imc.org; Tue, 08 Feb 2005 10:41:30 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id CFF802A64A; Tue, 08 Feb 2005 10:41:29 +0100 (CET)
Date: Tue, 08 Feb 2005 10:41:29 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: Policy URL -> Policy URI
In-reply-to: <3c14e78650fa58b06576b2e617409837@callas.org>
To: Jon Callas <jon@callas.org>
Cc: Rick van Rein <rick@openfortress.nl>, ietf-openpgp@imc.org
Message-id: <20050208094129.GA43152@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jon,
> If you happened to put in the policy URL an ISBN number, wouldn't it be
> obvious what it meant? Wouldn't it work just fine?
You are suggesting to keep the standard as is and to let those who find it
constraining simply make their own standard, right?
I don't think that's a good idea :) especially because a suitable and
globally accepted mechanism exists -> the URN, part of the URI scheme.
Rick van Rein,
OpenFortress.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
Comment: To understand digital signatures visit http://openfortress.nl
iD8DBQFCCIk4FBGpwol1RgYRAm00AKCN8WRgW8uww4lQqcbEU+KtMiFQDwCfbvA5
PDlZYiSnnQEBNF42bdWGqvs=
=j4Bj
-----END PGP SIGNATURE-----
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j189ONox011492; Tue, 8 Feb 2005 01:24:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j189ONIY011491; Tue, 8 Feb 2005 01:24:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp17.wxs.nl (smtp17.wxs.nl [195.121.6.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j189OMSX011411 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 01:24:22 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBL004K364A83@smtp17.wxs.nl> for ietf-openpgp@imc.org; Tue, 08 Feb 2005 10:24:10 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 4284D2A64A; Tue, 08 Feb 2005 10:24:10 +0100 (CET)
Date: Tue, 08 Feb 2005 10:24:10 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: Policy URL -> Policy URI
In-reply-to: <3c14e78650fa58b06576b2e617409837@callas.org>
To: Jon Callas <jon@callas.org>
Cc: Rick van Rein <rick@openfortress.nl>, ietf-openpgp@imc.org
Message-id: <20050208092410.GC33720@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
References: <20050207105021.GA17950@phantom.vanrein.org> <3c14e78650fa58b06576b2e617409837@callas.org>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Jon, others,
> Okay, I see what you're saying, but is it necessary?
I think it is.
1. I think PGP is providing too little certainty about the meaning of a
signature with its current four-grade signing setup. At least, it is
not suitable for commercial use, which would be great to support. A
suitable policy mechanism can help in that case.
2. It is not smart to fall behind on other signing flexibility; PGP already
lacks the appeal to decision-makers that PKIX and even XML Signing have;
any URN-based policy initiative could therefore easily forget to
incorporate PGP and render it useless for that kind of application.
3. There are always work-arounds. For example, the kind of schemes
suggested under 2. could declare a website to do the translation from
URN to URL for the sake of PGP. Aside from that being awkward, it would
be a challenge to the longevity of the spec and may for that reason be
left out. We don't want that to happen.
> A long time ago, the keyserver URL said URI and we changed it for
> reasons that I can't remember. I think it's because we didn't think it
> was necessary, that if it happened to be a URI, the worst that could
> happen would be that someone wouldn't understand it, but that's always
> a risk.
Indeed, the *keyserver* should not be referenced by name -- if you cannot
determine the location of a server what is it going to be good for?
For policies, I think we have a whole different matter at hand --
references to books, an ISSN-series of widely acknowledged signing policies
and ASN.1 OIDs are all good ways to point at a policy. Moreover, they are
supportive of Internet-wide schemes, which is rarely the case if a URL is
used.
Imagine that I would start pushing PGP-signers to follow
http://openfortress.nl/doc/some-policy.pdf
How would that make you feel? It would mean some company set it up. A
company with full control over the URL. Other companies are going to be
too proud or too smart to use the same signing policy *location*. Even if
they literally copy the content, the average signature validator would not
notice because the strings differ. In short, URLs are bad for
interoperable policies.
A URN-scheme on the other hand, can serve quite well for Internet-wide,
non-proprietary published policies. It can enforce the secure hash of a
document, which can only be weakly suggested in a URL. That would take
care of the pride issue. Furthermore, URNs can support rewriting to
equivalent forms, which would be helpful for supportive software to find
more matches than a simple string match can be.
> If you happened to put in the policy URL an ISBN number, wouldn't it be
> obvious what it meant? Wouldn't it work just fine?
There are always work-arounds, but why invite them? There are no
disadvantages to changing to a Policy URI.
> I don't mind changing it, but is this just a difference without
> distinction?
The change is vital in my opinion.
Thanks,
-Rick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
Comment: To understand digital signatures visit http://openfortress.nl
iD8DBQFCCIUsFBGpwol1RgYRAm41AJ4p8RN6BJ88+BW+gI7vkbodv6BH7ACeP2Wq
GL8TuglRzRNGvW2/PyeDH2Y=
=axg7
-----END PGP SIGNATURE-----
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1891QN3003462; Tue, 8 Feb 2005 01:01:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1891QWV003461; Tue, 8 Feb 2005 01:01:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp19.wxs.nl (smtp19.wxs.nl [195.121.6.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1891Pxj003386 for <ietf-openpgp@imc.org>; Tue, 8 Feb 2005 01:01:25 -0800 (PST) (envelope-from vanrein@vanrein.org)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp19.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBL00AD751X8Q@smtp19.wxs.nl> for ietf-openpgp@imc.org; Tue, 08 Feb 2005 10:01:09 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 1B69F2A64A; Tue, 08 Feb 2005 10:01:09 +0100 (CET)
Received: from cypherpunks.nl ([unix socket]) by cypherpunks.nl (Cyrus v2.2.6) with LMTPA; Tue, 08 Feb 2005 10:00:24 +0100
Received: by cypherpunks.nl (Postfix, from userid 998) id 34E5D705; Tue, 08 Feb 2005 10:00:24 +0100 (CET)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by cypherpunks.nl (Postfix) with ESMTP id 461A934A for <vanrein@cypherpunks.nl>; Tue, 08 Feb 2005 10:00:21 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 1427F2A64A; Tue, 08 Feb 2005 10:00:21 +0100 (CET)
Date: Tue, 08 Feb 2005 10:00:20 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Re: confusing terminology
In-reply-to: <42085A7D.1000704@algroup.co.uk>
To: Ben Laurie <ben@algroup.co.uk>
Message-id: <20050208090020.GB33720@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-Sieve: CMU Sieve 2.2
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
X-Spam-Level:
X-Spam-Checker-Version: Spam_Assassin 2.63 (2004-01-11) on cypherpunks.nl
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
References: <20050207232427.GA37525@phantom.vanrein.org> <42085A7D.1000704@algroup.co.uk>
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Ben, others,
> >As for the "added side-effect" (which states the same thing doubly twice) I
> >see a cryptographic advantage in compression that should go here :- by
> >compressing a message, the entropy of the data that is encrypted is made
> >as high as possible.
>
> Entropy is not altered by (lossless) compression.
Perhaps I wasn't clear enough. The entropy in the total document is not
increased, but the entropy per encrypted block is.
Plain English text is good for about 1 bit of entropy per character/byte;
after compression, the total size is less, certainly for plain English
text. This means that the same information is stored in less bytes, so
the entropy per byte (or per block of bytes) has risen.
It is advantageous to a cryptanalist to know that the input to an
encryption algorithm is plain English text, because it means that
possible variations of the input are greatly reduced. Compression
makes that assumption go wrong.
For this reason, I would never, ever encrypt without compressing first.
This is the cryptographic advise I would like to see in the indicated place.
Cheers,
-Rick
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j186Pa1I034409; Mon, 7 Feb 2005 22:25:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j186Pa8l034400; Mon, 7 Feb 2005 22:25:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org ([217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j186O699032989 for <ietf-openpgp@imc.org>; Mon, 7 Feb 2005 22:25:32 -0800 (PST) (envelope-from ben@algroup.co.uk)
Received: from [IPv6???1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 9054D33CBB; Tue, 8 Feb 2005 06:21:49 +0000 (GMT)
Message-ID: <42085A7D.1000704@algroup.co.uk>
Date: Tue, 08 Feb 2005 06:21:49 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Mozilla Thunderbird 1.0 (X11/20050106)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rick van Rein <rick@openfortress.nl>
Cc: ietf-openpgp@imc.org
Subject: Re: confusing terminology
References: <20050207232427.GA37525@phantom.vanrein.org>
In-Reply-To: <20050207232427.GA37525@phantom.vanrein.org>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Rick van Rein wrote:
>>>Message, data file, object, session
>
> These terms are used in a rotary scheme, but the reader must assume they
> mean the same thing, and not something slightly different. The original
> thought of OpenPGP seems to have been message formats as sent by email,
> but then PGP disk encryption came and the terms had to be altered.
>
> Can be agree on one term for "the stuff that is PGP-ified" perhaps?
> I think "OpenPGP data" will be fine, in contrast to "readable data".
"ciphertext" and "plaintext" sound more usual to me.
> As for the "added side-effect" (which states the same thing doubly twice) I
> see a cryptographic advantage in compression that should go here :- by
> compressing a message, the entropy of the data that is encrypted is made
> as high as possible.
Entropy is not altered by (lossless) compression.
Cheers,
Ben.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j184MluB012385; Mon, 7 Feb 2005 20:22:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j184MlQD012384; Mon, 7 Feb 2005 20:22:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j184MgYI012373 for <ietf-openpgp@imc.org>; Mon, 7 Feb 2005 20:22:42 -0800 (PST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Mon, 7 Feb 2005 20:22:34 -0800
Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Mon, 07 Feb 2005 20:22:33 -0800
X-PGP-Universal: processed
In-Reply-To: <20050207105021.GA17950@phantom.vanrein.org>
References: <20050207105021.GA17950@phantom.vanrein.org>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3c14e78650fa58b06576b2e617409837@callas.org>
Content-Transfer-Encoding: 7bit
Cc: ietf-openpgp@imc.org
From: Jon Callas <jon@callas.org>
Subject: Re: Policy URL -> Policy URI
Date: Mon, 7 Feb 2005 16:50:29 -0800
To: Rick van Rein <rick@openfortress.nl>
X-Mailer: Apple Mail (2.619.2)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Okay, I see what you're saying, but is it necessary?
A long time ago, the keyserver URL said URI and we changed it for
reasons that I can't remember. I think it's because we didn't think it
was necessary, that if it happened to be a URI, the worst that could
happen would be that someone wouldn't understand it, but that's always
a risk.
If you happened to put in the policy URL an ISBN number, wouldn't it be
obvious what it meant? Wouldn't it work just fine?
I don't mind changing it, but is this just a difference without
distinction?
Jon
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NOj6N081980; Mon, 7 Feb 2005 15:24:45 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NOjv6081979; Mon, 7 Feb 2005 15:24:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp19.wxs.nl (smtp19.wxs.nl [195.121.6.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NOdKR081926 for <ietf-openpgp@imc.org>; Mon, 7 Feb 2005 15:24:44 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp19.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBK001NTECREI@smtp19.wxs.nl> for ietf-openpgp@imc.org; Tue, 08 Feb 2005 00:24:28 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id C4CB32A650; Tue, 08 Feb 2005 00:24:27 +0100 (CET)
Date: Tue, 08 Feb 2005 00:24:27 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: confusing terminology
To: ietf-openpgp@imc.org
Message-id: <20050207232427.GA37525@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello,
I entered this list just recently, sorry about that.
I am wading through the spec bit by bit, hoping to add improvements.
After reading sections 1 and 2 I have seen a lot of confusing names,
often covering the same thing and sometimes used with different meaning.
This does not appeal to me as good specification habits I fear.
>> Message, data file, object, session
These terms are used in a rotary scheme, but the reader must assume they
mean the same thing, and not something slightly different. The original
thought of OpenPGP seems to have been message formats as sent by email,
but then PGP disk encryption came and the terms had to be altered.
Can be agree on one term for "the stuff that is PGP-ified" perhaps?
I think "OpenPGP data" will be fine, in contrast to "readable data".
>> OpenPGP: spec or implementation?
Section 1.1 teaches us that "OpenPGP" is the name of a definition
(or specification?) but the list items in section 2.1 use it to indicate
a program. I propose to change "OpenPGP" to "OpenPGP implemetation"
in these list items.
Section 2.0 introduces a self-contradicting loop, by stating that OpenPGP
(the document) does a few things that are beyond the scope of this
document.
A finer note on 1.1 -> I don't think definitions are formalized, instead I
think specifications are described or formulated. Am I going too far?
The subset from 2.5 is sufficiently clear -- but it would not harm to give
it an explicit name, such as "non-encrypting OpenPGP". That would help
clarify references to this document.
>> The goal, course and fine
The start of section 2 mentions a list of four bullets, specifying a few
techniques used. I am not seeing CR-LF standardisation, but I do see
radix-64 which seems to be of similar weight. Both are not nearly as
important as the first three points. I would leave it to these three
bullets and not get down to the level of representation here.
To be frank, I don't see the point of section 2.4; it seems too early.
I may be off here. Either way, isn't it true that implementations SHOULD
only *accept* radix-64 representations of OpenPGP data?
Somewhat funny: confidentiality is not mentioned here at all!
>> Procedures, data
Section 2.1 describes the same procedure twice. Once in the
introductionary paragraph, once in the list. What I would have expected
from the plaintext (not the list) in both 2.1 and 2.2 is a description of
the data structure -- that would remove procedurally irrelevant details
from the procedures.
Point 4 of 2.2, "attached" means "appended", so at the end, right?
Point 5 of 2.2, "keeps" means? Should it be "receives"?
>> Compression
Section 2.3 stresses that compression SHOULD be done, but it is not
mentioned in the procedure under 2.1.
The second paragraph contradicts itself, doesn't it? It speaks of
implementations that do not implement compression and says that they should
at least decompress. This should be said about implementations that do not
compress outgoing messages prior to their encryption.
As for the "added side-effect" (which states the same thing doubly twice) I
see a cryptographic advantage in compression that should go here :- by
compressing a message, the entropy of the data that is encrypted is made
as high as possible.
Let me know if you want me to write actual text. I'm not sure how this
process works -- but I'll be open to suggestions.
Cheers,
Rick van Rein,
OpenFortress.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17AoU1T052941; Mon, 7 Feb 2005 02:50:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17AoUjN052940; Mon, 7 Feb 2005 02:50:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from smtp17.wxs.nl (smtp17.wxs.nl [195.121.6.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17AoTVG052902 for <ietf-openpgp@imc.org>; Mon, 7 Feb 2005 02:50:29 -0800 (PST) (envelope-from rick@openfortress.nl)
Received: from phantom.vanrein.org (ip545163dc.direct-adsl.nl [84.81.99.220]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBJ00DTEFFXLK@smtp17.wxs.nl> for ietf-openpgp@imc.org; Mon, 07 Feb 2005 11:50:21 +0100 (CET)
Received: by phantom.vanrein.org (Postfix, from userid 502) id 6821A2A650; Mon, 07 Feb 2005 11:50:21 +0100 (CET)
Date: Mon, 07 Feb 2005 11:50:21 +0100
From: Rick van Rein <rick@openfortress.nl>
Subject: Policy URL -> Policy URI
To: ietf-openpgp@imc.org
Message-id: <20050207105021.GA17950@phantom.vanrein.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
User-Agent: Mutt/1.4.2.1i
X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Hello OpenPGP-drafters,
It seems important to me to consider replacing URL with URI in the OpenPGP
spec. This would include URN-schemes, such as references to books that
everybody can pick up in their local bookstore or at Amazon. A book URN
would look like URN:ISBN:1-234-56789-0 (see RFC 3187). There are several
other useful URN schema's.
There are two places in the specification that speak of URL's; one is the
keyserver (which really is a location, so it makes sense to keep it as
a URL) and the other is the policy. I think it makes sense to support more
than just the available-on-my-website kind of local/incompatible policies.
Note that other signing standards do speak of URIs for policies. In the
PKIX standard RFC 3280, there is a CPSuri definiton; in RFC 3275 (XML
Signing) there is no explicit support for policies (...) but the proper way
of getting it into the signature is with a <Reference/> element which
obtains its information from a URI rather than just a URL.
In OpenPGP, replacing a Policy URL with a Policy URI need not lead to
conflicts with older software; inasfar as they interpret the subpacket,
they usually treat it either as a literal string that should be matched or
as something that can be presented in a browser. The reason is that
policies cannot be interpreted by software -- they are usually written in
English.
Browsers are supposed to resolve URN-schemes; as far as they do not
recognise them they will consider the urn: start as a protocol, and of
course state that they do not support it. Same goes for any other
downloading software.
In other words, the change of a Policy URL into a Policy URN seems
advantageous, and I cannot see how it could cause problems. I therefore
warmly recommend changing it.
Thanks,
Rick van Rein,
OpenFortress Digital signatures
- PGP Partitioned Encoding Format "Hal Finney"
- Re: PGP Partitioned Encoding Format Ingo Luetkebohle
- Re: PGP Partitioned Encoding Format Werner Koch
- Re: PGP Partitioned Encoding Format Ingo Luetkebohle