Raif asks a number of questions in his reply. Specifically, do we have an OID. I think for the standard Crypto algorithms, we can use the standardized OIDs. From RFC 1321 (MD5):
For OSI-based applications, MD5's object identifier is
md5 OBJECT IDENTIFIER ::=
iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5}
In the X.509 type AlgorithmIdentifier [3], the parameters for MD5 should have type NULL.
It may be a neat trick tracking them down. :-(
Raif - Let us take a schedule for a DSA implementation under advisement. We need to get our heads together and figure out (1) Whether I am too contaminated with my access to the Sun sources, (2) Who will actually do it, and (3) When in relation to everything else that needs doing.
Reply-To: "Open discussions regarding cryptix-java."
<CRYPTIX-JAVA@HELPLETS.COM>
Subject: Re: Using Cryptix 3.0.3 for E
At 11:00 2/10/98 -0700, Bill Frantz wrote:
>For the Cryptix people, E is a secure distributed system based on Java
>which is available on an open source basis. For more information, see
>http://www.erights.org/
>
>For the E people...
>
>...With the Cryptix library, we can use the IJCE
>Cypher.getAlgorithms() static method, along with a property to dynamically
>build our list of supported protocols.
>
>This works fine for symmetric encryption, but we do have a problem with
>public key. We need to send public keys over the wire. Neither JCE or
>IJCE have an interface for getting a PublicKey object from an encoded
>public key. Worse yet, the Cryptix implementations don't have code to
>convert the public key to a byte string, needed for both sending the key
>and generating an identity.
>
>While the Javasoft official interface doesn't have a way of getting a
>public key from a encoded key, the Sun provider class
>sun.security.provider.DSAPublicKey has a public constructor which does the
>job. It takes a DER encoded structure which looks like:
>
>seq{
> seq{
> OID {1,3,14,3,2,12} // ISO code for DSA data
> SEQ{
> INT the DSA parameter P
> INT the DSA parameter Q
> INT the DSA parameter G
> }
> }
> BIT_STRING Y // The DSA public key
>}
>
>This structure is now a de facto part of our wire protocol. It does have
>the advantage that the OID specifies the public signature method, so if we
>introduce more than one method, the key is self identifying.
>
>I would like the Cryptix people to consider two additions to their package:
>
>(1) A way to get a PublicKey subclass of the correct type from a byte
>stream encoded public key that doesn't require provider-specific code. (I
>don't require ASN1 coding, but I do think we should be compatible with the
>current Sun provider encoding.)
>
>(2) Public key implementations which support encoding to self identifying
>byte strings and decoding same.
the basics are there in 3.0.3 (eg. cryptix.provider.rsa.RawRSAPublicKey). some design time/effort should be spent though to come up with a robust implementation strategy that extends the Base... and Raw... infrastructure already in place. i'm happy to do that in my spare time.
ian (IanG) do we have or can we obtain an OID for cryptix.org?
bill, do you (erights.org) have an OID?
if not, it might be worth applying for one at <http://www.iana.org/forms.html> (Enterprise Numbers).
>I think we can do a DSA implementation, and since DSA is not an encryption
>algorithm, we can probably export it to be part of the Cryptix package.
can you confirm this with am estimated time-of-release?
>Reactions?
>
>