At 02:58 PM 10/1/2001 -0700, Jon Callas wrote: >At 11:21 AM +0200 10/1/01, Balazs Scheidler wrote: > >John may have some comments, too, but here's my comments on your comments: > >>I have reviewed the draft and have the following comments: >> >>- signature blocks description: >> "Priority" field is said to be 3 bytes long in the summary, but >> details show that it's really 4 bytes (two bytes version, 1 byte hash, 1 >> byte signature scheme) >> > >This appears to be correct. John? Chris? Comments? Which part is wrong?
I'm still grappling with this one myself. I can't see the reason for having both the "version" and the "priority" fields, as Balazs noted. Both of them contain the value that this defines version "1" in %b0000000000000001. This is hashed in with other stuff in the "priority" field but is standalone in the "version" field. Could these be combined into a single "version" field? This "version" field would then contain: 16bits of protocol Version with the first version being the ABNF value of %b0000000000000001 to denote Version 1. 8bits of Hash Algorithm with the definition that %b00000001 denotes SHA1. [FIPS-180-1] 8bits of Signature Scheme with the definition that %b00000001 denotes OpenPGP DSA [RFC2440], [DSA94]. As such, the version, hash algorithm and signature scheme may be represented as %h00010101. The "version" field will be the base64 encoding of that value with a space character appended. This would yield 32bits of binary stuff that would be run through base64 encoding. A space would be appended as the ending delimiter. Does that make sense? Thanks, Chris
