Re: [GNU Crypto] More keyrings, PBE.

[Casey Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Raif" == Raif S Naffah <address@hidden> writes:

Raif> hello Casey,
Raif> On Tue, 7 Oct 2003 07:30 am, Casey Marshall wrote:
>> 
>> Oops, I didn't consider that. I know SecretKey is a problem in
>> PrivateKeyEntry, are there any others?

Raif> later, On Tue, 7 Oct 2003 09:43 am, Casey Marshall wrote:

CM> Oh, yeah. CertPath. This should probably be replaced with a simple
CM> certificate array.

Raif> correct.  the full list of problems follows:

I'll fix these in the next day or so.

>> Other undefined packet identifiers should raise an error.

Raif> i'd argue for treating them the same way unsupported optional
Raif> packets are treated --similarly to the above, an implementation
Raif> may emit a warning but not abort the process.

I'm not so sure about that. Right now we have defined the bytes 0
through 10 to have meaning as the prelude to a specific sequence of
data; the presence of a byte 11-255 should be a signal that something
is very wrong with the keyring, and since we don't know the form of
this unknown packet, we don't know how many bytes to skip.

UNLESS, we define that every packet (except property packets) all have
this exact form:

   uint8       Packet type.
   eos         Properties (which defines things such as ciphers,
               MACs, salts, etc.)
   eos         Packet data.

This does add some small costs in storage size and extra parsing
steps, but I like the uniformity it brings to the format.

Raif> but, the issue i wanted to raise is the structure of the
Raif> optional packets.  the way they are defined currently, it's
Raif> difficult for communities to use this format for own purposes.

Raif> in other words, the specification promotes a central authority
Raif> that keeps track of the encryption/authentication IDs for such
Raif> packets.  i'd rather see in the specs an unbounded way of
Raif> specifying methods for such purposes; e.g. an encrypted packet
Raif> would contain properties that fully define the parameters for
Raif> encryption/decryption.  similarly for the authentication.
>>  I would like to see the encoding identifiers (including such
>> things as compression algorithms, encodings for keys, certificates)
>> get moved into the properties field of the packet. My only concern
>> with this is making sure the names are unambiguous.

Raif> for mandatory packets it does not make a big difference,
Raif> although using the same mechanism for all packets --i.e. based
Raif> on values of properties -- is IMO a plus.  if we put the
Raif> emphasis on the property names rather than on IDs, we have more
Raif> flexibility --i.e. we only have to update the list of properties
Raif> when new technologies arise; yet with the same set of properties
Raif> we allow implementations to support a larger combinations of
Raif> algorithms.

Another possibility is to define one more algorithm ID for every
packet that deals with an encoding, e.g.

   #define  GKR_CIPHER_PRIVATE 255

In which case the actual name of the cipher and mode will be included
in the packet's properties.

- -- 
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE/gzsugAuWMgRGsWsRAjjjAJ0TyUNzLAAqtcKga8WHln2QH4FUXQCffhYg
niEF6eADBkCe2Poi8NY80SI=
=Gr+H
-----END PGP SIGNATURE-----