Jon Callas <jon(_at_)callas(_dot_)org> writes:
I have some comments:
Thanks for looking at it!
* We're deprecating V3 keys. You should either not mention them, or
mention that they're deprecated.
What would a suitable reference for that decision be?
On the other hand, you could just punt the whole issue by allowing a
fingerprint to just be a string of hex digits. The length tells you
what you need to know. If it's 128 bits in length, it's a V3 key; 160
means V4. Even key ids are implicit based on length. (And with V4 keys,
the key id is just a truncation of the fingerprint.)
This seems like a good solution. Will there ever be a need to have
key id's of different length than 4, 8, 16 and 20 bytes? The BNF now
reads:
id := 4*HEXDIG / 8*HEXDIG / 32*HEXDIG / 40*HEXDIG
And I'm not certain it is a good idea to allow the flexibility of
id := *HEXDIG
However, I have replaced the references to v3/v4 with:
The length of the field imply the kind of key id, i.e., short or
long form, or a v3 or v4 key.
Note that each of the following examples includes a comment, which is
optional.
id=12345678 (short key ID)
id=1234567890ABCDEF (long key ID)
id=1234567890ABCDEF01234567890ABCDEF0123456 (v4 fingerprint)
id=1234567890ABCDEF01234567890ABCDE (v3 fingerprint, deprecated)
* I also don't think you need the 0x. Just define it to be hexadecimal.
The breaker is needed to know that literals in a programming language
are of one base or another. Key IDs and fingerprints come in only one
base. I know it's a MAY. Drop it anyway, because if it's there, an
implementation has to handle both its presence and absence. It's merely
noise.
I agree, I've dropped it.
* I understand why you have the url header, and think it's nice. But
once you have that, (or the key is uniquely identified by key id or
fingerprint) you don't need the algorithm, size, and created fields.
These are merely comments all on their own, and if you have them there,
you have to deal with what happens if they are wrong.
Let's suppose a URL points to my key and the header erroneously states
that it's a DSA key, when it is in fact an RSA key. Now what? What if
the creation time in the header is wrong? Since all that information is
in the key itself, better to just get it from the key.
So to answer the question in section 6, I think you should drop them.
Thanks for this input. I have been trying to understand why
algo/size/created are needed, but nobody has been able to explain it
to me.
The reason was supposedly that with v3 keys, you subject to something
called the 0xDEADBEEF attack, where I infer that keys can be created
easily with any given key id. The attack is not possible with v4
keys. Someone said the attack is harder for v3 keys if you also
compare the key size, key algorithm and creation time.
What nobody has explained to me is how much difficult the attack is.
If the attack is only slightly more difficult, I don't think it is
worth the added complexity in OpenPGP:. However, if the attack is
completely avoided by comparing these fields, there may be some point
to it. On the other hand, if v3 keys are deprecated, it might be
simpler to forget about all v3 issues.
Without understanding the motivation for size/algo/created, I'm in
favor of dropping them.
* I think the other open question you have, as to whether someone wants
MIME encodings or not is much more important. At PGP, we're starting to
code that into the certificates themselves, so the encryption mechanism
can do the right thing.
I realize it is a big issue, and potentially a contentious one.
I'd hate to see disagreement on this part stop the document, though,
so if consensus on this matter cannot be reached, I think we should
simply drop it.
Thanks,
Simon