This is how I would do it. The idea behind the KeyInfoResolver was exactly as you are doing. It provides a call-back mechanism for the library to pass the key information to the application which can then do the key lookup.
Like you, I'd use an X509Data for the DN of the subject of the applicable cert, and as you mention, KeyName is designed for arbitrary identifiers such as a URI. The former is a bit more abstract - if there are different systems that store the cert in different ways, then the SubjectName works well, and the app can work out how to get the certificate. It also means that you can change the cert storage without impacting signatures, which is a potential in the URI case.
There are similar (but more comprehensive) mechanisms in the Java library for registering resolvers that will do the lookups.
In most cases, the fact the KeyInfo is outside the signature should not be an issue. If someone changes the KeyInfo, the key used to validate the signature will change and the signature verification will fail.
As an aside - XKMS abstracts this yet again. The theory is you provide an X509Data (or other key info element) to an XKMS service, which then handles the specifics of
1) Should you trust the key; and 2) What is the key.
It's kinda nice, because it means the client can be very thin - it only knows how to talk to an XKMS service, but that in turn can talk to anything. It also doesn't have to work out whether to trust a particular key - it can hand that function off to the XKMS service.
Mind you - we still have to implement one :>.
Cheers,
BerinJohn Moore wrote:
I to would be interested in other peoples opinions. We are looking at doing something similiar (although for non-technical reasons we propose to use an SQL database to hold the certificates instead of LDAP)
Our current thoughts are as follows:
In our application, we will only deal with "known people", ie ones that we have a contract with.
We will store their Dig Cert, and verify that it is Ok, and store that status away as well. Periodically we would re-check all Dig Certs against a revocation list and change the status. Also change status when Dig Cert expires. This will save us from having to check for revocation on each transaction (and thus minimise dependencies on other peoples systems). Our application area isnt too time dependant on this checking.
XML files will come in signed. We will use the "KeyInfo" element in the XML DSIG standard to identify the Dig Cert. The only KeyInfo elements that make sense in a PKI environment is X509Data. We may also support KeyName, since ours is a "closed group" of customers.
The X509Date element can either contain a X509 Digital Certificate or a reference to a X509 certificate (eg X509IssuerSerial, X509SubjectName, etc). In either case, we dont plan to "believe" the Dig Cert in the XML file, but use the info to check it for validity against the database and use the Dig Cert held in the database.
The KeyName element could contain some type of reference that is mutually agreed between our organisation and the signer (eg the signerâs customer reference number with our organisation). It your case that may be the URL you are talking about. Note, unless you purposely include the KeyInfo XML subtree in a DSig Reference, it is not signed by default.
In the XML Security software, this involves writing a class that inherits from XSECKeyInfoResolver and using it as follows:
// use the xxxResolver xxxKeyResolver ires(NULL);
sig->setKeyInfoResolver(&ires);
just before
sig->load(); result = sig->verify();
I have already written a toy xxxKeyResolver class to do this lookup.
I am happy to swap C++ code fragments with others if there is interest. (It is not very big, so converting it to Java shouldnt be too difficult).
Hope this helps and I look forward to others opinions on how best to architect applications in this area.
ta john
