Kenneth R. Robinette wrote: > 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
What does that mean? I think you are confusing NSS with the builtin token. NSS is a set of libraries that manage multiple tokens, including the softoken and builtin token. The softoken is a writeable token with databases for storing certs and keys. The builtin token is a read-only list of default trusted roots. If you want "a cert within NSS", naturally, you would import it into the softoken, since it is writeable. If you want a root that is trusted by default for any application that uses NSS, that is a much larger statement. -Ian > > "Ian McGreer" <[EMAIL PROTECTED]> wrote in message > 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 >> >> > >
