classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: Certificates support


From: Sascha Brawer
Subject: Re: PATCH: Certificates support
Date: Tue, 22 Apr 2003 10:11:48 +0200

Casey Marshall <address@hidden> wrote on Mon, 21 Apr 2003 22:51:11
-0700:

>Which brings me to a question I have about official Mauve tests: should
>they test non-API classes that nevertheless exist in standard JDK
>implementations (e.g. X.509 certificates, DSA, MD5 and SHA-1 -- that is
>what exists in the "SUN" provider in Sun's JDKs)?

I'm not sure whether I understand what you mean with "non-API classes".
For example, according to Sun's Javadoc, the static method

  java.security.MessageDigest.getInstance(java.lang.String)

takes one of six names specified by [1], namely "MD2", "MD5", "SHA-1",
"SHA-256", "SHA-384", or "SHA-512".

So, I'd assume that the Mauve test for MessageDigest would test whether
the instance that is returned for each of those six names conforms to the
respective specification, and whether a
java.security.NoSuchAlgorithmException is thrown for some random name.

However, I would not test for the provider name being "SUN", or for the
name of the returned MessageDigest subclass. For example, even though the
following evaluates to true on Sun's J2SE1.4.1, I would not expect Mauve
to test for this:

  MessageDigest.getInstance("SHA-1").getProvider().getName().equals("SUN") 

Of course, it is a lot less work to state requirements like these than it
is to actually implement those tests...

Best regards,
Sascha

-- Sascha Brawer, address@hidden, http://www.dandelis.ch/people/brawer/

[1] Java Cryptography Architecture API Specification & Reference, Appendix A
    http://java.sun.com/j2se/1.4.1/docs/guide/security/CryptoSpec.html#AppA







reply via email to

[Prev in Thread] Current Thread [Next in Thread]