Or put the real world way, the only way we desire one to have a cert within NSS is to get that cert from one of our vendors that pay us a lot of money.
Ken "Ian McGreer" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Kenneth R. Robinette wrote: > > 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: > > > It is perfectly okay for an exported NSS function to call another NSS > function internally. In fact, that is exactly the behavior we desire. > > The reason we don't want applications to call CERT_DecodeDERCertificate > is that we want to reach a point where having a CERTCertificate implies > you actually have a cert in the NSS system, either on a token or in the > temporary cert store. CERT_DecodeDERCertificate returns a > CERTCertificate with no state information, just a decoding. If one was > to pass this CERTCertificate to a function needing state information, > bad things would happen. > > PK11_ImportDERCertForKey uses CERT_DecodeDERCertificate to obtain the > decoding, then imports the cert and fills in all the necessary state > information (token, handle, etc.). It then returns a valid > CERTCertificate, and you're on your way. > > -Ian >
