Subject: acceptable comment lines in between pgp header and message block

From: [email-masked]
Date: Wed, 30 Oct 2002 16:03:28 -0500

have been under the impression that the only lines accetable in between the pgp
header and message block {or the pgp signature header and signature block} were:

[1] HASH identification
[2] Version identification
[3] Comment: lines

pgp 2.x also has a 'Charset:' line identifying the character set used
{this line is acceptable to all versions of pgp and gnupg}

are there any other line headings that are acceptable?
{i.e.  will not invalidate a signature if placed into a signed message}

tia,

vedaal

---

From: "Michael Young" <[email-masked]>
Date: Thu, 31 Oct 2002 11:25:30 -0500

From: <[email-masked]>
> {i.e.  will not invalidate a signature if placed into a signed message}

Section 6.2 of draft 6 mentions the following: Version, Comment, MessageId,
Hash, and Charset.  It *suggests* that implementations emit warnings
for others that they do not understand, but process the message anyway.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: acceptable comment lines in between pgp header and message block
Date: Thu, 31 Oct 2002 11:25:30 -0500
Sender: [email-masked]

From: <[email-masked]>
> {i.e.  will not invalidate a signature if placed into a signed message}

Section 6.2 of draft 6 mentions the following: Version, Comment, MessageId,
Hash, and Charset.  It *suggests* that implementations emit warnings
for others that they do not understand, but process the message anyway.

From: [email-masked]
To: [email-masked]
Subject: acceptable comment lines in between pgp header and message block
Date: Wed, 30 Oct 2002 16:03:28 -0500
Sender: [email-masked]

[1] HASH identification

tia,

vedaal

Content-Class: urn:content-classes:message
Subject: RE: Text canonicalization
Date: Mon, 21 Oct 2002 12:31:14 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Florian Weimer" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi.

> > What about the other line ending characters?  With Unicode (or even
> > ISO-8859-x close to an EBCDIC environment), there a few more
> > characters which could end a line.
> 
> Let me repeat this question. ;-)
> 
> If you look at the discussion about the XML 1.1 specification, you'll
> see that there is a real ambiguity.
All behind the 128-bit ASCII code should be left unchanged.
This will do no harm, because all other soft- and hardware
in the trasportsystem will do the same.
If an editor interpret those "in text format comands", it might
do (for display reasons) but should also not change the text!!!

Again: This is not a topic to PGP at all, because those chars
are uncritical to the mail-system.
The whole thing about CR and LF is, that the mail sytem on
some systems change them, insert additional whitespace to
the end or cut it of - nothing like this will happen to unicode
line endings.

Best Regards
-- 
Dominikus Scherkl
[email-masked]

To: [email-masked]
Subject: Re: Text canonicalization
From: Florian Weimer <[email-masked]>
Date: Fri, 18 Oct 2002 19:42:03 +0200
Lines: 21
Sender: [email-masked]

Florian Weimer <[email-masked]> writes:

> [email-masked] writes:
>
>> The first is that it does not make clear what constitutes line endings.
>> In PGP we treat CR LF, CR, and LF all as line endings and convert each
>> one to CR LF.
>
> What about the other line ending characters?  With Unicode (or even
> ISO-8859-x close to an EBCDIC environment), there a few more
> characters which could end a line.

Let me repeat this question. ;-)

If you look at the discussion about the XML 1.1 specification, you'll
see that there is a real ambiguity.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          fax +49-711-685-5898

Date: Tue, 08 Oct 2002 09:55:01 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: ASN.1 OID for TIGER/192
Sender: [email-masked]

Jon Callas wrote:
> I confess I am wondering why this is needed. Five years ago, we flirted with
> Tiger and Haval because you need wider hashes for better signatures.

but then HAVAL-5-160 was selected. I wonder why not 256..

> 192
> bits is a bit dodgy because it only gets you an effective strength of 96
> bits (over 80 bits for SHA-1).

> Today, we have all the wide SHAs in the
> suite, which balance with symmetric ciphers up to 256 bits of key size.
> Adding in TIGER/192 now seems like too little, too late. In 1998, this would
> have been great. In 2002 (pushing 2003), it's at best a yawn.
>
> In short, here's a pragmatic question I have: if I were making a signature
> today, and I thought that SHA-1 weren't big enough, why would I want to use
> TIGER/192 over SHA-{256|384|512}?

hmm..
it's faster (but it's weak argument)

> Without a good answer to that question, I don't see why it should be there.
> I'm even slightly sympathetic to people who think it and HAVAL should be
> removed. They've both been overtaken by events.
>     Jon

or replaced with HAVAL-5-256. I agree there is no need for 3rd 160bit hash,
but maybe alternate 256bit one...

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

Date: Sun, 06 Oct 2002 14:43:02 -0700
Subject: Re: ASN.1 OID for TIGER/192
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I confess I am wondering why this is needed. Five years ago, we flirted with
Tiger and Haval because you need wider hashes for better signatures. 192
bits is a bit dodgy because it only gets you an effective strength of 96
bits (over 80 bits for SHA-1). Today, we have all the wide SHAs in the
suite, which balance with symmetric ciphers up to 256 bits of key size.
Adding in TIGER/192 now seems like too little, too late. In 1998, this would
have been great. In 2002 (pushing 2003), it's at best a yawn.

In short, here's a pragmatic question I have: if I were making a signature
today, and I thought that SHA-1 weren't big enough, why would I want to use
TIGER/192 over SHA-{256|384|512}?

Without a good answer to that question, I don't see why it should be there.
I'm even slightly sympathetic to people who think it and HAVAL should be
removed. They've both been overtaken by events.

    Jon

Date: Tue, 01 Oct 2002 21:20:24 +0000
From: David Hopwood <[email-masked]>
To: [email-masked]
Subject: Re: ASN.1 OID for TIGER/192
Sender: [email-masked]

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

David Shaw wrote:
> In 2440 and in all the 2440bis drafts, the TIGER/192 hash is not fully
> usable as it has no OID.  Werner Koch and I, with the cooperation of
> TIGER's authors, recently arranged an OID for it:
> 
>         1.3.6.1.4.1.11591.12.2

I hope that is only the OID for Tiger-192 with 3 passes (as used by OpenPGP),
not Tiger in general. SHA-256, SHA-384 and SHA-512, for example, have
separate OIDs.

> It would be good to put this in 2440bis so TIGER will be usable.

Note the potential problems with the Tiger specification and test vectors
described here:
<http://www.users.zetnet.co.uk/hopwood/crypto/scan/md.html#Tiger>

> I have a sneaking suspicion that this may raise the question whether
> TIGER should be in the standard at all, as so long as it did not have
> an OID, the question was moot.  I have no strong feelings on this
> point, but if we are not going to allow the use of TIGER, then perhaps
> we should remove it from the standard altogether or explicitly
> disallow its use as the current halfway state is confusing now that
> there is an OID available.

I agree, and the same applies to HAVAL. However, my vote is to remove both
Tiger and HAVAL; there's no reason to believe they have any security or
other advantages over the other supported hashes.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip