gnu-crypto-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Crypto] More keyrings, PBE.


From: Raif S. Naffah
Subject: Re: [GNU Crypto] More keyrings, PBE.
Date: Mon, 6 Oct 2003 21:41:33 +1000
User-agent: KMail/1.5.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

hello Casey,

On Fri, 3 Oct 2003 10:48 am, Casey Marshall wrote:
CM> >>>>> "Raif" == Raif S Naffah <address@hidden> writes:
CM> >>...
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'
 file CM> >> distributed with the JDK.

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


CM> ...
CM> Raif> in parallel, may be we can finalise the issue i raised about
 the CM> Raif> optional packets.
CM>
CM> My intention with the optional packet types (non-password encrypted
CM> and authenticated) was to allow such things to be used in site- or
CM> application-specific contexts. That is, normal applications such as
CM> the KeyStore implementation just ignores these packets, since there
CM> are no methods to decode these packets in the API to do so.
CM> Applications where a password-based encoding is inconvenient or
CM> 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 be
CM> decoded.

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

but, the issue i wanted to raise is the structure of the optional 
packets.  the way they are defined currently, it's difficult for 
communities to use this format for own purposes.  in other words, the 
specification promotes a central authority that keeps track of the 
encryption/authentication IDs for such packets.  i'd rather see in the 
specs an unbounded way of specifying methods for such purposes; e.g. an 
encrypted packet would contain properties that fully define the 
parameters for encryption/decryption.  similarly for the 
authentication.

- -- 
cheers;
rsn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Que du magnifique

iD8DBQE/gVTv+e1AKnsTRiERA3TsAJ911yO6NBXWe0a9iD09u+sL1vD6KACg/sEd
4EqbC4h46VEqZ2u8UzHxWPI=
=iD2+
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]