Re: [Jsdsi-devel] Algorythm names

[Sean R. <sra...@ae...>]

I guess we could change Algorithms from using straight Strings for the
constants to an Enum class style for type-safety.

Something akin to:

http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
 

Sean

On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> Guys,
> 
> I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> names:
> 
> Algorithms
> DigestUtils
> SignatureUtils
> 
> 
>  - not implemented any of them yet as want input/comments first.
> 
> The idea being that in Algorithms there is a list of constants which
> clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> There are then utility methods to calculate the SPKI or JDK versions of
> such (This includes the problematic Signatures).
> 
> I would suggest the following coding ethos is JSDSI:
> 
> 1. jsdsi object constructors that need algorythm names use SPKI format
> names (this is what they should use now as that is the format dumped to
> Sexpression, and consequently read from a stream)
> 
> Not so sure about Hash.. has anyone looked at an Sexpression for hash
> and know that if you supply MD5 it comes out (incorrectly) in upper case
> in the Sexpression? I guess the current implementation would cause a
> problem with SHA-1? (as in SPKI that should be sha1).
> 
> Which then begs the question: should Hash.getAlgorithm() return the SPKI
> or JDK version (I guess JDK to be consistent with Key and Signature)?
> 
> 
> 
> 2. static create methods use the constants for easy client use.
> 
> The question I have for this is about jsdsi.Signature. Should the create
> methods take a digest constant and from that calculate the JDK Signature
> algorythm and corresponding SPKI algorythm using the provided constant
> and by examining the given keypair?
> 
> 
> 
> Thoughts? (in particular problems this approach would lead to with
> existing applications)
> 
> 
> Sean
> 
>  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com