Subject: Tighter MPI spec (and on keychains)

From: Rick van Rein <[email-masked]>
Date: Thu, 24 Feb 2005 10:30:32 +0100

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

---

From: Ian G <[email-masked]>
Date: Thu, 24 Feb 2005 12:35:51 +0000

(on the keyrings only)

>   a keyring in an OpenPGP message, it is represented as the concatenation

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.

>      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/

---

From: Jon Callas <[email-masked]>
Date: Fri, 25 Feb 2005 07:38:09 -0800

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

---

From: Rick van Rein <[email-masked]>
Date: Fri, 25 Feb 2005 20:52:02 +0100

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 
> 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

---

From: Jon Callas <[email-masked]>
Date: Fri, 25 Feb 2005 18:12:04 -0800

> 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:

and

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

---

From: Florian Weimer <[email-masked]>
Date: Sun, 27 Feb 2005 23:21:47 +0100

> 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.)