Fix xmlsec1 --id-attr option

We need to know _the name of the attribute_ that represents the identifier of the node
that is being signed, or encrypted, or verified. We guess the name -by trying `ID`, `Id`
and `id`- and pass it to `xmlsec1` using the `--id-attr` command line option.

_Why is this needed?_ Shouldn't the attribute names be specified by the corresponding
specifications? Let's look into the specs to find out.

* saml-core:
  * `StatusResponseType` uses `ID`
  * `RequestAbstractType` uses `ID`
  * `Assertion` uses `ID`

* xmldsig-core:
  * `SignatureType` uses `Id`

* xmlenc-core:
  * `EncryptedType` uses `Id`

So, the answer is _yes_ - the attribute names are defined and, instead of guessing, we
should be passing in the id-attribute names as defined by the specs.

_Note_: But, do we even need to do this? If the names are standardized, why do we bother
with this? In fact, the manual for `xmlsec1` explicitly says that

    --id-attr[:<attr-name>] [<node-namespace-uri>:]<node-name>

        adds attributes <attr-name> (default value "id") from all nodes
        with<node-name> and namespace <node-namespace-uri> to the list of
        known ID attributes; this is a hack and  if you can use DTD or schema
        to declare ID attributes instead (see "--dtd-file" option), I don't
        know what else might be broken in your application when you use this
        hack

However, it seems that `xmlsec1` by default will only look for an attribute with name
`id`. The right way to solve this is to pass in a DTD file. Then, `xmlsec1` will
understand that it needs to look up a different attribute name. Unfortunately, there are
no official DTDs (or even unofficial, to my knowledge) for SAML. The SAML specifications
instead provide XSD files. Even though `xmlsec1` mentions _schema_, there doesn't seem
to be a way to pass in an XSD file. So, we have to resort to this "hack".

When we sign a document, we need to point to the node that will be signed. The nodes
that we are signing are always SAML nodes (Assertion, StatusResponseType (Response,
etc), RequestAbstractType (AuthnRequest, etc)). All SAML nodes that will be signed use
`ID` as the attribute name. So, in order to sign and verify a signature, we need to pass
in `ID`.

When encrypting a document, we need to point to the node whose content will be
encrypted. Currently, we use XPath to point to that node, without the use of an id. But,
we could be using an identifier to locate the node, and if we did so, we would still be
using `ID`.

When decrypting a document, we need to point to the node that contains the encrypted
data. This is where things change. Since the SAML node itself is encrypted we cannot
point to an `ID` attribute, as we did in the other cases. Instead, it is specified that
a node named `EncryptedData` exists, that may have an `Id` attribute. This is where we
want to point to. So, we need to use `Id`.

Signed-off-by: Ivan Kanakarakis <[email protected]>

Author: c00kiemon5ter