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

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

Re: [GNU Crypto] RFC: New keystore format


From: Raif S. Naffah
Subject: Re: [GNU Crypto] RFC: New keystore format
Date: Sun, 13 Jul 2003 09:13:34 +1000
User-agent: KMail/1.5.1

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

On Sun, 13 Jul 2003 04:47 am, Casey Marshall wrote:
> Hello,
>
> I've been scribbling some notes on a new keystore format, and would
> like some feedback.
>
> The notes are attached.

here are my comments/suggestions/questions:

on data types:

* re-use types implemented in SASL mechanisms (see OutputBuffer and 
InputBuffer in gnu.crypto.sasl).


on contents (packets):

2.3. Trusted Certificates.

* what are the possible/allowed values for encoding names/schemes?
* why encoded as a string, not as octets?

2.4. Private Keys.

* same question re. key encodings.
* same question re. value (string v/s octets).

2.5. Certificate Chain.

* should be renamed to reflect x.509 certificate parentage.  we may want 
to support GPG packets in the future.
* what are the chain types possible/allowed?
* same question re. value (string v/s octets).

3. Envelope types.

* how about compression?  suggest we add 1-byte for compression type and 
support only zlib deflate in version 1.

3.1. Password-encrypted.

* hmac-md5 is accepted to be not suffering from md5 potential weakness.  
suggest use it as the default for version 1.
* aes should be the default.
* ofb-8 saves us from needing a padding scheme altogether.  suggest this 
to be the default for version 1.
* same question re. ciphertext (string v/s octets).

3.2. Password-Encrypted Entries.

* the difference between this and the previous type is the alias. how 
about always having the alias field, and use an empty string for 
multi-contents envelopes?

3.3. Password-Authenticated.

* same question re. ciphertext (string v/s octets).

3.4. Password-Authenticated Entries.

* same question re alias.


4. Recommended constructions.

* why not consider 2 files: a public keyring and a secret one --similar 
to GPG?
* shouldnt the secret keyring be constructed as encrypt first and 
authenticate later?


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

iD8DBQE/EJYp+e1AKnsTRiERA7InAKCZW2h6Gp6v4u9LuuxChJFDghvRnwCg3Srp
8rUJGBSNIAjVpLSn3CZ9VXc=
=iIFg
-----END PGP SIGNATURE-----





reply via email to

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