Re: [GNU Crypto] RFC: New keystore format

[Casey Marshall]

-----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-----