Subject: What's left before a new RFC?

From: Jon Callas <[email-masked]>
Date: Wed, 17 Apr 2002 15:54:01 -0700

When I sent out bis04, it had all previous changes and additions in it.

Thomas Roessler is convincing me that I may need to tighten up the language
about UTF-8. If anyone out there disagrees with him, speak up.

I'm willing to put in a note to say that the Version and Comment headers in
armor SHOULD or MUST be ASCII. I don't like it (I want everything to be
UTF-8), but I'll do it. Is UTF-7 too grotesque?

I know of no other desired changes. I would like bis-05 to be Penultimate
Call. Does anyone object?

	Jon

---

From: "Michael Young" <[email-masked]>
Date: Wed, 17 Apr 2002 20:20:26 -0400

From: "Jon Callas" <[email-masked]>
> Call. Does anyone object?

I still desire a "revocation target" subpacket to identify the
specific signature being revoked:

    5.2.3.1. (add:)
       31 = revocation identification 

    5.2.3.25. Revocation identification
        (1 octet PK algorithm)
        (1 octet hash algorithm)
        (N octets hash)

where the N octets are the hash from the signature being revoked.

My original suggestion did not include the PK algorithm field.
Jon Callas added that in his revised sketch.  I don't feel a need
for it, but I won't object, either.

David Shaw also suggested including the timestamp from the revocation
packet, to allow a blazingly fast comparison.  Again, I could live
with or without this.

Without the ability to revoke a specific signature, I strongly object
to multiple self-signatures being interpreted "any way it sees fit".
Yes, there's a RECOMMENDED behavior, and that may be the best we can
hope for in old implementations.  It's sad to suggest that when
conversing among new implementations, a key owner cannot update its
self-signature in a clear and unambiguous way.  But a revocation
target would satisfy my objection.  There may be other solutions to
this specific problem, such as a "supercedes" subpacket, but I don't
think they're as generally powerful or useful.

Note that I would not limit the use of this subpacket to self-signatures.
I think it would be equally meaningful for ordinary certifications,
to disambiguate between signatures with different subpackets (e.g.,
notation, trust limits, policy) or classes (e.g., 0x10 through 0x13).

---

From: David Shaw <[email-masked]>
Date: Wed, 17 Apr 2002 20:52:50 -0400

> specific signature being revoked:

[..]

> packet, to allow a blazingly fast comparison.  Again, I could live

After further consideration of Jon's comments about hash comparison, I
don't see the need.

> notation, trust limits, policy) or classes (e.g., 0x10 through 0x13).

See also the mail I just sent about designated revokers - there is a
good potential use there as well.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Marcel Waldvogel <[email-masked]>
Date: Thu, 18 Apr 2002 10:17:03 +0200

Jon,

I agree with Thomas on the UTF-8 issue.

For the Version and Comment headers, I propose to state that they are 
UTF-8, but for interoperability, implementations SHOULD restrict 
themselves to generate ASCII characters. This phrase may be put in 
section 14 as a general comment.

-Marcel

---

From: Marc Mutz <[email-masked]>
Date: Thu, 18 Apr 2002 12:48:57 +0200

On Thursday 18 April 2002 10:17, Marcel Waldvogel wrote:
<snip>
> themselves to generate ASCII characters.
<snip>

I don't see the how having UTF-8 inside _ASCII_ Armor can be justified. The 
problem is that the ascii armor is going to be used in non-8but-clean 
environments. Else, you'd use the binary format, no?

Because of that, I'm strongly in favour of stating that implementations MUST 
NOT emit armor headers with non-US-ACSII characters in them.

Re: UTF-7. I understand that UTF-7 could be a solution. Only UTF-7 is widely 
considered to be a big mistake, so it shouldn't be used anymore.

Marc

- -- 
Marc Mutz <[email-masked]>

---

From: Marcel Waldvogel <[email-masked]>
Date: Thu, 18 Apr 2002 16:46:21 +0200

Marc Mutz wrote:

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

One one side, we can consider cleartext signatures, which already can 
contain characters with the MSB set, and which are not necessarily 
armored for 8-bit cleanliness. Even there, the signature block is (among 
other things) ASCII-armored to not confuse the user (or his terminal) 
with weird chars.

There are multiple reasons for armoring non-7bit data:
a) The transport does not allow arbitrary 8bit sequences
b) The transport does not allow arbitrary "line" lengths
c) The transport does charset recoding, probably forth and back.

The headers that use UTF-8 are mostly for human consumption (I presume), 
and most modern non-8bit transports are of the form (b) or (c), which 
(1) should not harm typical headers nor (2) cause any damage, if they 
are slightly mangled (IMHO).

BTW: Does the "Version" header contain the product and version used 
("User-Agent"), or the version of the standard ("MIME-Version")? bis04 
seems to indicate the latter, but usage seems to be the former.

-Marcel

---

From: Marc Mutz <[email-masked]>
Date: Thu, 18 Apr 2002 19:30:33 +0200

On Thursday 18 April 2002 16:46, Marcel Waldvogel wrote:
<snip>
> >I don't see the how having UTF-8 inside _ASCII_ Armor can be justified.
> > The problem is that the ascii armor is going to be used in non-8but-clean

Yes, but the problem is not clearsigning. The problem is armoured encryption 
and armoured keyrings. There also exist binary versions. Why do you think 
exist armoured ones? If the armoured format wasn't restricted to US-ASCII, 
then what right has the armoured format to exist anymore?

<snip>

SMTP falls into this category. That's what I'm mainly concerned with and 
that's where we ran into problems a few months ago. The PGP/MIME rfc3156 
defines all app/pgp-* mimetypes to be 7bit only. Allowing 8bit octets in 
ascii armour would break rfc3156 (and rfc1847, too, IIRC) for no apparent 
added value.

Marc

- -- 
Marc Mutz <[email-masked]>

---

From: Florian Weimer <[email-masked]>
Date: Sat, 20 Apr 2002 08:47:06 +0200

>  Call. Does anyone object?

3.2 is lacking a hint to implementors that the bit count feild for
encrypted MPIs reflects the number of bits in the decrypted MPI (IOW,
encrypted MPIs might not be well-formed as required by 3.2).

There's a formatting error in the second table of section 5.2.3.16.

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

---

From: Jon Callas <[email-masked]>
Date: Sat, 20 Apr 2002 00:53:50 -0700

> encrypted MPIs might not be well-formed as required by 3.2).

Thank you. I wrote as the last paragraph of 3.2:

Also note that when an MPI is encrypted, the length refers to the plaintext
MPI. It may be ill-formed in its ciphertext.

> There's a formatting error in the second table of section 5.2.3.16.

Thanks. David Shaw also pointed that one out and it's fixed.

    Jon

---

From: Jon Callas <[email-masked]>
Date: Tue, 23 Apr 2002 15:39:11 -0700

On 4/17/2002 5:20 PM, "Michael Young" <[email-masked]> wrote:

> specific signature being revoked...

In the immortal words of Rod Serling, submitted for your approval:

.head 4 Revocation Target

.block blank
(1 octet PK algorithm,
 1 octet hash algorithm,
 N octets hash)

This subpacket identifies a specific target signature that a revocation
signature revokes. This provides explicit designation of a revocation. All
arguments are an identifier of that 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.