| 1 |
3.2 (MPI) doesn't specify what the unused bits should be set |
|---|
| 2 |
to. This may be deliberate but I think it should either say they MUST |
|---|
| 3 |
be zero (which I prefer) or that their content is unspecified. |
|---|
| 4 |
|
|---|
| 5 |
4.2 refers to Content Tags, but 4.3 calls them Packet Tags. |
|---|
| 6 |
|
|---|
| 7 |
5.5.2 doesn't mention V2 keys. |
|---|
| 8 |
|
|---|
| 9 |
In section 9.1, Schneier is given as the reference for DSA - why not refer to FIPS 186-2, which is freely available? Or, indeed, HAC 11.5.1, available here: http://www.cacr.math.uwaterloo.ca/hac/about/chap11.pdf. |
|---|
| 10 |
|
|---|
| 11 |
Similarly 9.2, TripleDES (which, presumably is EDE 3DES - it'd be good |
|---|
| 12 |
to be specific) is on some FIPS document which I forget or in HAC |
|---|
| 13 |
chapter 7 (7.32 in 7.2.3 and 7.4.2). |
|---|
| 14 |
|
|---|
| 15 |
---- |
|---|
| 16 |
|
|---|
| 17 |
In 5.2.1: |
|---|
| 18 |
|
|---|
| 19 |
"0x10: Generic certification of a User ID and Public Key packet." |
|---|
| 20 |
|
|---|
| 21 |
Does this mean that the signature is over the User ID packet and the Public Key packet, concatenated, in that order? Or what? |
|---|
| 22 |
|
|---|
| 23 |
Also, what on earth does: |
|---|
| 24 |
|
|---|
| 25 |
Note that all PGP "key signatures" are this type of |
|---|
| 26 |
certification. |
|---|
| 27 |
|
|---|
| 28 |
mean? |
|---|
| 29 |
|
|---|
| 30 |
In 5.2.2: |
|---|
| 31 |
|
|---|
| 32 |
"The data being signed is hashed, and then the signature type and |
|---|
| 33 |
creation time from the signature packet are hashed (5 additional |
|---|
| 34 |
octets)." |
|---|
| 35 |
|
|---|
| 36 |
is unclear, suggest: |
|---|
| 37 |
|
|---|
| 38 |
"The concatenation of the data to be signed, the signature type and |
|---|
| 39 |
creation time from the signature packet (5 additional octets) is hashed." |
|---|
| 40 |
|
|---|
| 41 |
In 5.9: |
|---|
| 42 |
|
|---|
| 43 |
" - File name as a string (one-octet length, followed by file name), |
|---|
| 44 |
if the encrypted data should be saved as a file." |
|---|
| 45 |
|
|---|
| 46 |
but no mention of what if it shouldn't be saved as a file. 0 length, |
|---|
| 47 |
perhaps? |
|---|
| 48 |
|
|---|
| 49 |
Then: |
|---|
| 50 |
|
|---|
| 51 |
" - A four-octet number that indicates the modification date of the |
|---|
| 52 |
file, or the creation time of the packet, or a zero that |
|---|
| 53 |
indicates the present time." |
|---|
| 54 |
|
|---|
| 55 |
I would _guess_ that it means modification date of the file if there's |
|---|
| 56 |
a filename, the creation time if there isn't. I have no idea what zero |
|---|
| 57 |
is supposed to mean. Nothing, would be the obvious interpretation - |
|---|
| 58 |
"the present time" is nonsensical. |
|---|
| 59 |
|
|---|
| 60 |
Once more, when I know what its supposed to mean, I'll suggest |
|---|
| 61 |
wording. |
|---|
| 62 |
|
|---|
| 63 |
------ |
|---|
| 64 |
|
|---|
| 65 |
5.2.3.5 Issuer |
|---|
| 66 |
|
|---|
| 67 |
should be: |
|---|
| 68 |
|
|---|
| 69 |
5.2.3.5 Issuer key ID |
|---|
| 70 |
|
|---|
| 71 |
A tiny point, I know, but it made it hard to find. |
|---|
| 72 |
|
|---|
| 73 |
Key algorithms ... these are used in various contexts, and there's a |
|---|
| 74 |
list in 9.1 - some of these are clearly unsuitable in some contexts - |
|---|
| 75 |
for example, one would not expect to see RSA Ecnrpyt-Only (3) in a |
|---|
| 76 |
signature. But I can't find any language saying anything about |
|---|
| 77 |
this. Are there any rules? |
|---|
| 78 |
|
|---|
