Yea, but that function also calls CERT_DecodeDERCertificate, along with a whole bunch of other functions. I thought the problem was with CERT_DecodeDERCertificate, as was pointed out in a previous reply as follows:
"Bob Relyea is the best person to answer this question. Previously he marked CERT_DecodeDERCertificate as NSS internal, which means he thinks this function will be impossible to emulate on top of the new NSS core API (code name Stan)." So, I must assume the problem must be with generating the CERTCertificate structure itself, and I was just suggesting to bypass that step and store the data direct. Ken "Ian McGreer" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Kenneth R. Robinette wrote: > > If implementing the above function is a problem with the new NSS, I would > > recommend a new function exported in the nss3.dll named > > PK11_ImportDERCertForKeyToSlot with the same parameters as the current > > PK11_ImportCertForKeytoSlot, except replacing the cert parm with the SECItem > > DERCert parm and adding one more for the creating the trust, such as > > "u,u,u". > > This function exists as PK11_ImportDERCertForKey: > > http://lxr.mozilla.org/mozilla/source/security/nss/lib/pk11wrap/pk11func.h#3 98 > > It is exported in nss.def, but marked as "JSS-only". I looked in > nss.def and found that there are, in fact, no "publicly available" > functions for importing a cert, save CERT_ImportCAChain, which is > certainly not useful here. > > I second your motion to move PK11_ImportDERCertForKey to the public > section. I will also up the ante by suggesting that PK11_ImportCert be > exported, so that applications have a method for importing a cert not > associated with a key. > > -Ian > > >
