--- Sean Mullan <[EMAIL PROTECTED]> wrote: > For Java developers, you may also want to use the > J2SE 1.4 CertStore class, > which allows you to retrieve certificates and CRLs > from repositories, > such as LDAP: > http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/CertStore.html > > For example, in your KeyInfoResolver implementation, > you could retrieve > the X509Data SubjectName out of the KeyInfo and > retrieve the certificate > from LDAP as follows: > > CertStore cs = CertStore.getInstance("LDAP", > ldapParams); > X509CertSelector xcs = new X509CertSelector(); > xcs.setSubject(subjectName); > Collection certs = cs.getCertificates(xcs); > > if (certs.isEmpty()) { > throw new Exception("can't find cert"); > } else { > // try to verify signature with each cert (if more > than one) > ... > } > > The LDAP CertStore implementation assumes you have > set up your directory > according to the standard schema specified in RFC > 2587: > http://www.ietf.org/rfc/rfc2587.txt > > HTH, > Sean
That's what I need - thanks alot. Might you know if that could work inside a web container/axis? I ask because weblogic, tomcat et al seems to have there own special way of doing container callbacks. For those following the thread - here's how jboss is doing something a bit similair - axis/xmlsec/jaas - I'm basing my thinking of that. http://www.thecortex.net/clover/eg/jboss/report/org/jboss/net/axis/server/JBossAuthenticationHandler.html Thanks a lot - iksrazal > > Berin Lautenbach wrote: > > John, > > > > 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, > > Berin > > > > > > John 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 > >> > >> > >> > >> > >> > >> > > > > __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
