Boris Zbarsky schrieb: > Kai Engert wrote: >> nsIX509Cert expects the underlying CERTCertificate to be complete and >> valid, and serializing/restoring it based on the DER representation >> will ensure it. > > The message I got from Nelson's reply is that the DER representation > doesn't actually capture everything about the CERTCertificate... did I > misunderstand?
In my own words, Nelson said, the CERTCertificate contains additional information that a simple dump of the DER representation will not contain. So, a binary representation of the DER cert will have less information than the in-memory representation of the structure. But where did NSS get that additional information from? By combining it with the other information that NSS has available internally (like it's cert database and built in roots certs and their trust). Because you want to restore the serialization into the same context, NSS should be able to derive all the additional pieces of information, just as it did initially. I hope I'm not mistaken. I can think of only one piece of information that you'd loose: If someone marks an untrusted certificate as "ok for this session only". But IMHO we should not worry about that. (If you really want to, we would have to invent a mechanism to obtain and store all explicit trust assigned to the given cert.) You should not have to worry about the "nickname", because you probably do not want to serialize the built-in root certs, but server certs, and those get a dynamically assigned nickname anyway. But even if you did, when we restore from DER, and it's one of the stored certs with an explicitly assigned nickname, I hope NSS will be able to detect that. Kai _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
