On Fri, Oct 05, 2001 at 09:15:09AM -0500, Chris M. Lonvick wrote: > 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.
I think this is ok. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
