Scott,
One of the things I wrote into the XML Encryption code was an "Algorithm
Handler". It *can* still use the encryption constants, but it will also
work if you pass in a URI to the (for example)
XENCCipher::encryptElement() method. The AlgorithmHandler class is
empty by default, and at initialisation has a number of algorithms
registered.
So the Encryption code should be fairly easy to extend for new
algorithms - simply implement the correct handler, register it with the
library and the library will automatically call it when it finds that
URI in an EncryptedType element. The various encrypt calls will take the
older style enums or, if you pass in ENCRYPT_NONE, and then a URI, it
will use the URI. (In fact, internally, the library simply maps the
enum to the appropriate URI and then calls the handler.)
Which doesn't help for signatures :>.
So one of the things I already wanted to do for 1.3 was refactor the
signature processing code to insert the same AlgorithmHandler in a
manner that is extensible in the same fashion. I think that would solve
the problem you mention below, but by using the methodology above we
should be able to avoid breaking the current API.
Cheers,
Berin
Scott Cantor wrote:
Something to consider for the future is that the use of proprietary
eumeration constants in the API for specifying signature and digest
algorithms makes application code on top of this very brittle in terms of
handling future evolution.
It would be better to let dependent code use the URI strings when passing in
or returning the algorithms, and handle any shorthand notation you want
internally to the code.
Looking at this new version, if I want to extend support for more than just
SHA1 and MD5, I think I have to both conditionally allow for the newer
algorithms at compile time, and I can't easily handle future algorithms by
way of a configuration file because I wouldn't know what constant to pass
into the library.
Sorry for not bringing this up before, I hadn't really tried to add support
for multiple algorithms in my code until now.
-- Scott
