Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt

From: Jon Callas <[email-masked]>
Date: Mon, 2 Oct 2000 15:27:21 -0700

At 2:15 PM +0200 9/29/00, Werner Koch wrote:
>Thanks for updating the draft Jon.
>
>I think we should add the section on the new MDC packets.  Those are
>implemented in PGP 7 and GnuPG 1.0.3.  Hal: Can you post this
>proposed section again?
>

I've added in the MDC packets, editing the text from Hal's submission. I
also added in a "features" subpacket to state that you speak MDC. Excerpts
will be forthcoming. I made a few other edits surrounding MDC use (for
example in the BNF). I also put in a reminder in the packet header
description that you have to use a new-format packet for tags of 16 and
greater.

>Assuming that AES will be announced quite soon, we could issue a new
>draft right after this event.
>

What changes need to be made for that? We've already reserved constants for
the AES. Do I need to do anything other than remove the word "reserved"?
Hmmm. A Rijndael reference. That seems to be it to me, though.

	Jon

---

From: Ulf Möller <[email-masked]>
Date: Mon, 2 Oct 2000 23:21:35 -0400

The security notes still don't mention that there is a cryptographic
flaw in v4 signatures.  This needs to be fixed, or if there are good
reasons for not fixing it, it must at least be explained in the
document.

As I explained on January 19th:

| > I think I'm confused here. Suppose I have an implementation that does DSA
| > with SHA-1. Let us also suppose that Tiger gets broken. How does this
| > affect my DSA/SHA signature?
| 
| Then if I want to forge a signature, I find a message for which the
| Tiger hash value is identical to your original SHA-1 hash.  Unless
| your original signature was a v3 RSA signature, nothing in OpenPGP
| prevents me from setting the hash algorithm identifier for that
| message to Tiger.  That's why the RSA value in PKCS #1 contains a
| DigestInfo, and why the DSS specifies SHA-1 as the only signature
| algorithm.  Putting the hash algorithm identifier in the data
| protected by that very hash algorithm is pointless.
| 
| That clearly is a cryptographic weakness in the protocol, so it has to
| be mentioned in the RFC.

Most of the other issues I raised haven't been addressed either, but
as things are it looks like it would be pointless to invest a lot of
time in OpenPGP.

---

From: Thomas Roessler <[email-masked]>
Date: Tue, 3 Oct 2000 10:47:30 +0200

This draft still does not say anything about name spaces for
notation data tags, making notation data essentially useless.

Suggestion:

   The present document defines two name spaces for notation data
   names: The IETF name space and the user name space.
   
   Notation data names in the IETF name space consist of an
   arbitrary string of UTF-8 encoded characters, with the exception
   that the character "@" ("at") MUST NOT occur in such a name.
   
   XXX - describe IANA registration procedures.
   
   Notation data names in the user name space consist of a tag,
   followed by the "@" character, followed by a DNS domain name.
   The tag may be an arbitrary string of UTF-8 encoded characters,
   with the exception that the character "@" MUST NOT occur in such
   a name.  The DNS domain name must be under the exclusive control
   of the person or entity which introduces the notation data name
   in question.
   
   For example, if The Example Corporation wishes to introduce
   sample notation data, the appropriate notation data name could be
   "[email-masked]".

-- 
Thomas Roessler                         <[email-masked]>