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 Fri, 3 Oct 2003 10:48 am, Casey Marshall wrote:
CM> >>>>> "Raif" == Raif S Naffah <address@hidden> writes:
CM> Also new is a KeyStore adapter for GNU keyrings, and I have been
CM> >> able to use `keytool' to read a public keyring. Attached is an
CM> >> example public keyring with the same contents as the `cacerts'
Raif>  file CM> >> distributed with the JDK.

Raif> i noticed that the library now requires jdk 1.4 to compile!  are
Raif> we sure we want to exclude the jdk 1.3 users?

Oops, I didn't consider that. I know SecretKey is a problem in
PrivateKeyEntry, are there any others?

CM> ...  Raif> in parallel, may be we can finalise the issue i raised
CM> about
Raif>  the CM> Raif> optional packets.
CM>  My intention with the optional packet types (non-password
CM> encrypted and authenticated) was to allow such things to be used
CM> in site- or application-specific contexts. That is, normal
CM> applications such as the KeyStore implementation just ignores
CM> these packets, since there are no methods to decode these packets
CM> in the API to do so.  Applications where a password-based encoding
CM> is inconvenient or impossible can use the alternatives.
CM> 
CM> Maybe it would be better to state in the spec that these optional
CM> packets must be parsed (or skipped), but their contents need not
CM> be decoded.

Raif> agreed.  how to react to unrecognised packet types IMO must be
Raif> in the specs.

I've modified the definitions of these optional packets to state that
implementations have to accept these packets, but can discard their
contents if no mechanism for decrypting/authenticating them is
available.

Other undefined packet identifiers should raise an error.

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.

- -- 
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/gd7xgAuWMgRGsWsRAvNiAJ9MWlTyBtslIBhRwZAJpRUFYz5OZACeO5BF
9ORgeGWKLsVS9bQYUFWhaDw=
=M90S
-----END PGP SIGNATURE-----