Subject: Some -15 comments

From: David Shaw <[email-masked]>
Date: Thu, 10 Nov 2005 12:54:33 -0500

I did a quick read over bis15:

In 5.2.1. Signature Types, in the section about the 0x18 subkey
binding signature, the binding for a signing subkey MUST (not SHOULD)
contain a back signature.  This was discussed on the list.

======

We discussed a change to 5.2.3.16 (Notation Data) on the list to
change:
 
     First octet: 0x80 = human-readable. This note value is text, a
                         note from one person to another, and need
                         not have meaning to software. 
to:
     First octet: 0x80 = human-readable. This note value is text.

Any way that can go in?  I'm perfectly happy to get an "I Told You So"
if someone is confused :)

======

5.11. User ID Packet (Tag 13) makes reference to a "RFC 2822 mail
name", but there is no such object in 2822.  2822 calls it a
"name-addr".

======

In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the
phrase:

 "(often literal data packets or compressed data packets)"

should probably be:

 "(often a literal data packet or compressed data packet)"

since we no longer allow multiple literal packets in a row.

======

In 13. Security Considerations, in the section discussing the
Mister/Zuccherato attack, the last sentence of the third paragraph is
missing a period.

======

Aside from that, has anyone heard anything new about the rumored
"bigger DSA" update?

David

---

From: Jon Callas <[email-masked]>
Date: Mon, 14 Nov 2005 14:46:26 -0800

> contain a back signature.  This was discussed on the list.

Fixed.

> if someone is confused :)

I remember the discussion, I just don't remember the agreement. Such  
is the way with rough consensus.

Does it matter one way or the other? I admit to being confused as to  
why it matters. Enlighten me, please.

> name", but there is no such object in 2822.  2822 calls it a

Changed to name-addr

> since we no longer allow multiple literal packets in a row.

Changed.

> Mister/Zuccherato attack, the last sentence of the third paragraph is

Fixed.

> Aside from that, has anyone heard anything new about the rumored

I asked during the hash bash and was told, "soon." But then, that's  
what I was told at CRYPTO 2004. Don't hold your breath.

Incidentally, I apologize for not getting this out before. I sent it  
to the I-D desk, who whined at me. My correction was eaten by an MTA,  
which took two weeks to tell me that it was confused, and by then the  
meeting lull had happened.

So can we take the two-week comment period for last call and make it  
be Nov 21?

	Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 15 Nov 2005 01:01:08 +0100

> >since we no longer allow multiple literal packets in a row.

Actually, can it be anything else? Most OpenPGP parsers would understand an
arbitrary nesting of compressed, encrypted and MDC-protected encrypted
packets, but does that make sense?

I can see a different use for it, however. Being a bit uneasy about the
secret key packet format (Packet tag 5, Section 5.5.1.3.), I think, it is
ultimately up to the implementation, how they store and protect private
keys, as it does not affect interoperability, as long as private keys can be
exported and imported in a common format.

Some text about this should be added to 5.5.1.3., in my opinion, stating that
implementations SHOULD be able to export and import private keys in this
format. It is the more important, as the passphrase-protected version is
vulnerable to the Klima-Rosa attack. I am hesitant whether to say that they
MAY store them in this way (as most actually do) or would it be more
appropriate to say that new implementations SHOULD NOT do that.

For secure storage and transmission of private keys, one could put a
private key packet (tag 5) without passphrase protection into an
MDC-protected encrypted packet (tag 18), maybe with compression in between.
This would thwart the Klima-Rosa attack, while not requiring dramatical
changes to the standard.

But again, I think that the storage format of private keys needs not be
standardized. For example, our ePointPGP tool (see
http://pgp.epointsystem.org/tool-help) generates private keys directly from
the passphrase, without storing them in any way. Yet, it is fully
interoperable with many other RFC2440bis implementations on the message
and public key level.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Mon, 14 Nov 2005 21:14:29 -0500

> is the way with rough consensus.

Yes.  I didn't think we had consensus yet.  I'm re-raising it to get
some more discussion.

> why it matters. Enlighten me, please.

It matters because the current text states something as true that
shouldn't be true.  A human-readable notation isn't necessarily a note
from one person to another.  Using the only commonly used notation
([email-masked]) as an example, it is human
readable, but is a note from software to software and humans aren't
necessarily involved.

> So can we take the two-week comment period for last call and make it  

Sounds good to me.

David

---

From: Ian G <[email-masked]>
Date: Tue, 15 Nov 2005 13:12:12 +0000

Jon Callas wrote:

> I remember the discussion, I just don't remember the agreement. Such  is 
> the way with rough consensus.
> 

I agree with the second reading.  The first tries
to define something that eludes definition, and
any attempt to further define it takes us inevitably
into needing more flags (as per Daniel's discussion).

---

From: Ian G <[email-masked]>
Date: Tue, 15 Nov 2005 13:12:53 +0000

Jon Callas wrote:

> So can we take the two-week comment period for last call and make it  be 
> Nov 21?

No disagreement here!

iang