[Top][All Lists]
[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-----
- [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format,
Raif S. Naffah <=
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/12
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/13
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/13
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/14
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/16
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/17
- Re: [GNU Crypto] RFC: New keystore format, Casey Marshall, 2003/07/17