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
