Re: [GNU Crypto] More keyrings, PBE.

[Raif S. Naffah]

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

hello Casey,

On Tue, 7 Oct 2003 07:30 am, Casey Marshall wrote:
> >>>>> "Raif" == Raif S Naffah <address@hidden> writes:
> Raif> On Fri, 3 Oct 2003 10:48 am, Casey Marshall wrote:
> CM> >>>>> "Raif" == Raif S Naffah <address@hidden> writes:
> 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'
> Raif>  file CM> >> distributed with the JDK.
>
> Raif> i noticed that the library now requires jdk 1.4 to compile! 
> are Raif> we sure we want to exclude the jdk 1.3 users?
>
> Oops, I didn't consider that. I know SecretKey is a problem in
> PrivateKeyEntry, are there any others?

later, On Tue, 7 Oct 2003 09:43 am, Casey Marshall wrote:

CM> Oh, yeah. CertPath. This should probably be replaced with a simple
CM> certificate array.

correct.  the full list of problems follows:

/data/workspace/cvs/gnu-crypto/source/gnu/crypto/jce/cipher/PBES2.java
    Error:  line (137) Semantic Error  : No applicable overload was found for a 
constructor of type "java.lang.Error". Perhaps you wanted the overloaded 
version "Error(java.lang.String $1);" instead?
/data/workspace/cvs/gnu-crypto/source/gnu/crypto/jce/keyring/GnuKeyring.java
    Error:  line (61) Semantic Error  : The import 
"java/security/cert/CertPath" is not valid, since it does not name a type in a 
package.
    Error:  line (259) Semantic Error  : No method named "generateCertPath" was 
found in type "java.security.cert.CertificateFactory".
/data/workspace/cvs/gnu-crypto/source/gnu/crypto/keyring/CertPathEntry.java
    Error:  line (54) Semantic Error  : The import 
"java/security/cert/CertPath" is not valid, since it does not name a type in a 
package.
    Error:  line (95) Semantic Error  : No method named "generateCertPath" was 
found in type "java.security.cert.CertificateFactory".
/data/workspace/cvs/gnu-crypto/source/gnu/crypto/keyring/GnuPrivateKeyring.java
    Error:  line (56) Semantic Error  : The import 
"java/security/cert/CertPath" is not valid, since it does not name a type in a 
package.
    Error:  line (243) Semantic Error  : No applicable overload was found for a 
constructor of type "gnu.crypto.keyring.CertPathEntry". Perhaps you wanted the 
overloaded version "CertPathEntry(?? path, java.util.Date creationDate, 
gnu.crypto.keyring.Properties properties);" instead?
/data/workspace/cvs/gnu-crypto/source/gnu/crypto/keyring/IPrivateKeyring.java
    Error:  line (50) Semantic Error  : The import 
"java/security/cert/CertPath" is not valid, since it does not name a type in a 
package.
/data/workspace/cvs/gnu-crypto/source/gnu/crypto/keyring/PasswordAuthenticatedEntry.java
    Error:  line (290) Semantic Error  : No applicable overload was found for a 
constructor of type "java.lang.Error". Perhaps you wanted the overloaded 
version "Error(java.lang.String $1);" instead?
    Error:  line (296) Semantic Error  : No applicable overload was found for a 
constructor of type "java.lang.Error". Perhaps you wanted the overloaded 
version "Error(java.lang.String $1);" instead?
/data/workspace/cvs/gnu-crypto/source/gnu/crypto/keyring/PasswordEncryptedEntry.java
    Error:  line (260) Semantic Error  : No applicable overload was found for a 
constructor of type "java.lang.Error". Perhaps you wanted the overloaded 
version "Error(java.lang.String $1);" instead?
    Error:  line (269) Semantic Error  : No applicable overload was found for a 
constructor of type "java.lang.Error". Perhaps you wanted the overloaded 
version "Error(java.lang.String $1);" instead?


> CM> ...  Raif> in parallel, may be we can finalise the issue i raised
> CM> about
> Raif>  the CM> Raif> optional packets.
> CM>  My intention with the optional packet types (non-password
> CM> encrypted and authenticated) was to allow such things to be used
> CM> in site- or application-specific contexts. That is, normal
> CM> applications such as the KeyStore implementation just ignores
> CM> these packets, since there are no methods to decode these packets
> CM> in the API to do so.  Applications where a password-based
> encoding CM> is inconvenient or 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
> CM> be decoded.
>
> Raif> agreed.  how to react to unrecognised packet types IMO must be
> Raif> in the specs.
>
> I've modified the definitions of these optional packets to state that
> implementations have to accept these packets, but can discard their
> contents if no mechanism for decrypting/authenticating them is
> available.

agreed --an implementation may decide to also print a warning or such.


> Other undefined packet identifiers should raise an error.

i'd argue for treating them the same way unsupported optional packets
are treated --similarly to the above, an implementation may emit a
warning but not abort the process.


> Raif> but, the issue i wanted to raise is the structure of the
> Raif> optional packets.  the way they are defined currently, it's
> Raif> difficult for communities to use this format for own purposes.
> Raif> in other words, the specification promotes a central authority
> Raif> that keeps track of the encryption/authentication IDs for such
> Raif> packets.  i'd rather see in the specs an unbounded way of
> Raif> specifying methods for such purposes; e.g. an encrypted packet
> Raif> would contain properties that fully define the parameters for
> Raif> encryption/decryption.  similarly for the authentication.
>
> I would like to see the encoding identifiers (including such things
> as compression algorithms, encodings for keys, certificates) get
> moved into the properties field of the packet. My only concern with
> this is making sure the names are unambiguous.

for mandatory packets it does not make a big difference, although using
the same mechanism for all packets --i.e. based on values of properties
- -- is IMO a plus.  if we put the emphasis on the property names rather
than on IDs, we have more flexibility --i.e. we only have to update the
list of properties when new technologies arise; yet with the same set
of properties we allow implementations to support a larger combinations
of algorithms.


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

iD8DBQE/go3Z+e1AKnsTRiERA9IeAJ9eJTcwCEl2nhCk9euqI/sLLlBEkwCfWhC5
WfrZXpf7kBwCElxAM9dYmA8=
=9OoN
-----END PGP SIGNATURE-----