--- Berin Lautenbach <[EMAIL PROTECTED]> 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.
I would be interested in the c++ way of doing this if someone has an example - I know both languages although the end result will be java in my case. Sorry but I have a problem understanding how to "include the KeyInfo XML subtree" may look or be different in xml terms. Could the KeyInfoResolver callback work in a web container like tomcat via an axis handler? Could I avoid the JAASRealm/JNDIRealm headache in tomcat via something already available in xmlsec? > > 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. So the keyinfo then becomes the unique identifier for the cert, and is part of the message in place of the cert? And that is the sole protection for the integrity of the message? This is what I'm trying to understand - I appreciate the paitence. > > 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 :>. That'll be kool - looking forward to it. iksrazal > > 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
