# Re: JDK's Security API recommendations

Jan Luehe (luehe@laguna.eng.sun.com)
Wed, 19 Aug 1998 18:50:10 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: war99@megsinet.com: "Asylum Consultants"
- Previous message: marketing@countyweb.co.uk: "COUNTYWeb UK Network"
- Maybe in reply to: Roni Korenshtein: "JDK's Security API recommendations"

    Date: Wed, 19 Aug 1998 18:50:10 -0700 (PDT)

    From: Jan Luehe <luehe@laguna.eng.sun.com>

    Subject: Re: JDK's Security API recommendations

    To: java-security@java.Sun.COM, ronikoren@yahoo.com

Hi Roni:

> As a individual user of the JDK
> I'd like to say that I think you guys did a great job in the JDK
> and I really enjoy using it. I always say that your use of design
> patterns
> is excellent and programming to the JDK forces even a novice
> programmer to write
> better code.

Thanks for the positive feedback!
We're always glad to hear that!

> The main realization I had a few minutes after our meeting is that
> signature
> (and MessageDigest, and eventually Certificate) should be completely
> analogous
> to a key in the JDK, and should have a framework of classes and
> concepts
> (opaque vs. transparent) associated with it, as there is for keys.
> Mainly, there should be a "ThingGenerator" , a "Thing", a "ThingSpec",
> and a "ThingFactory".

Your thoughts on this are very interesting, and I agree with
you that the same concepts that we use for keys in JDK 1.2 (including
KeySpec's and KeyFactory) could have been used for "Signature"
and "MessageDigest".

Unfortunately, it's too late to add similar functionality for
"Signature" and "MessageDigest" in JDK 1.2,
because the JDK 1.2 APIs are frozen as we speak.

My only concern would be that if we added similar functionality for
MessageDigest and Signature as we did for keys, the number of classes
in the JDK
would explode. Also, one of the reasons why we introduced KeySpec's
and KeyFactory classes in JDK 1.2 is that keys are inherently
provider dependent, whereas the result of a signature or message
digest operation is not. For example, the "SunJCE" provider and
RSA's "JSAFE" provider implement Diffie-Hellman keys differently,
but the result of a Diffie-Hellman key agreement (or RSA signature,
or MD5 digest) is the same for both, because it is defined by
standards and therefore is provider-independent.

For example, NIST and OIW define the result of a DSA signature
to be an ASN.1 SEQUENCE of "r" and "s", and PKCS#1 specifies
the format of an RSA signature. If OpenPGP wants to keep
the digest, it should encode the digest as part of the signature result,
e.g., define the resulting signature to be a SEQUENCE of
"r", "s", and the digest. You would get such a signature result
if you specified

Signature.getInstance("DSAOpenPGP")
when you instantiate your Signature object.

> Of course, eventually Certificate should also have the same framework,
> consisting of
> a CertificateGenerator, Certificate, and CertificateSpec, and then the
> security API would be
> more usable and consistent.

Yes, if we decide to provide a Java extension package for certificate
creation, we will certainly follow the design patterns adopted for keys.

Jan

- Next message: war99@megsinet.com: "Asylum Consultants"
- Previous message: marketing@countyweb.co.uk: "COUNTYWeb UK Network"
- Maybe in reply to: Roni Korenshtein: "JDK's Security API recommendations"