[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNU Crypto] RFC: New keystore format
From: |
Casey Marshall |
Subject: |
Re: [GNU Crypto] RFC: New keystore format |
Date: |
Sat, 12 Jul 2003 18:37:43 -0700 |
User-agent: |
Mutt/1.4i |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Jul 13, 2003 at 09:13:34AM +1000, Raif S. Naffah wrote:
> 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).
>
I don't see why not.
> on contents (packets):
>
> 2.3. Trusted Certificates.
>
> * what are the possible/allowed values for encoding names/schemes?
The idea was to make use of classes such as CertificateFactory, so the
encoding name would be e.g. "X.509" and the data the DER-encoded
certificate.
> * why encoded as a string, not as octets?
>
Because they are variable-length. Octets are meant to be fixed/implied
length. The terminology here is careless; I was using the term "string"
as it appears in the SSH internet-drafts.
That is, 'string' just means:
uint16 length, l
octets[l] data
> 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.
Not sure what you mean.
> * what are the chain types possible/allowed?
Similar to encoded certificates, i.e. something like "PKIX" which is fed
into CertificateFactory.generateCertPath().
Or: just make CERT_CHAIN an enveloped type, that contains the
certificates.
> * 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.
>
Good idea. This could be made generic, and compressed types declare
their encoder ("ZLib") within the packet.
> 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.
I just used the OIDs that GNU has as a placeholder; AES and SHA-1 would
probably be better defaults.
I am also not sure if OIDs are the way to go.
> * ofb-8 saves us from needing a padding scheme altogether. suggest this
> to be the default for version 1.
Ok.
> * 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?
>
Also the _ENTRY variants have an implied single contained entry, while
the others must end with the END byte.
I am not happy with the multiple/single distinction, and it would
probably be better to just have one type that contains the alias field.
> 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?
A single file fits the KeyStore API better -- they are loaded off-disk
from an InputStream.
There is nothing stopping a user from keeping the two separate, however.
This might be the "recommended usage", but forcing this is probably not
the way to do it.
Also: on a provider level we can provide different semantics based
around the desired protection level. I.e. "SecretGKS" could be a
keystore that looks like this at the top level:
GKS_TYPE_PBE {
GKS_TYPE_PBMAC {
(keys and certificates)
GKS_TYPE_END
}
GKS_TYPE_END
}
And also maybe a non-encrypting keystore that does not accept private
keys.
> * shouldnt the secret keyring be constructed as encrypt first and
> authenticate later?
>
As it stands, each envelope type only has knowledge of its contained
type, and if you encrypt then MACify the MAC would be be of the
encrypted data, which would be bad.
I like the construction (encrypt (mac (data))) because the MAC is
encrypted too -- giving the world that much less information about the
encrypted key.
The alternative would be to make a type that encrypts and MACs the
contained types, e.g.:
byte GKS_TYPE_PBE_PBMAC
u8string alias
u8string KDF OID
uint32 iteration count
string salt
u8string Cipher OID
u8string MAC OID
string encrypted payload
octets MAC of decrypted payload
which I think is unnecessary.
Also:
* Maybe just choose a KDF/iteration count instead of making them
explicit?
* GKS (GNU Key Store) -- any better name ideas?
* Metadata mechanism? I.e. a way to encode how the store may be used,
whether or not the store may be modified, etc.
Cheers,
- --
Casey Marshall || address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/ELfWgAuWMgRGsWsRApM6AJ0cITaFeIorM3logFhSwWRHi22ECQCbBx6U
IevkhhaIEiCo6gUCWI3vn8M=
=v2Gd
-----END PGP SIGNATURE-----
- [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 <=
- 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
- Re: [GNU Crypto] RFC: New keystore format, Raif S. Naffah, 2003/07/18